| Re: [hatari-devel] Blitter emulation corner case |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 15/05/2017 à 18:19, "Markus Fröschle" a écrit :
On 10 May 2017 at 20:45, Christian Zietz wrote:
PS: I'm still interested if the COMBO chip or the Falcon's Blitter work
the same here.
OK, attached is a ZIP with the following:
.. modified C source to write info to file instead of screen
.. resulting binary
.. FALCON1.TXT->FALCON5.TXT: these are results of 5 different runs
of the modified binary under TOS 4.04 on my Falcon. All the sets
of results seem to be different!
Note: In case you care, FALCON1.TXT/FALCON4.TXT are the first runs
immediately after a cold boot.
.. ST1.TXT->ST2.TXT: results from 2 runs on a 1040STe. These seem
to be consistent.
Roger
Hi everybody,
just subscribed to this list.
Before anyone get's desparate: better make sure you haven't been fooled by the Falcon's 030 data cache here (at least I didn't see any code to invalidate the cache).
The blitter is a DMA device, so without a cache invalidate, you probably won't see the new values the blitter just copied (or only more or less randomly).
You're right, this is probably what happened.
Either data caches should be disabled before running the test program
(from GEM preferences if this exist ? or some utilities might already do
it), or the following code could be added to Christian's program to make
a falcon specific version :
_asm_save_030_cache_settings:
movec cacr,d0
move.l d0,save_cacr
rts
_asm_deactivate_030_datacache:
movec cacr,d0
bset #0,d0 ; i cache on
bset #4,d0 ; i burst on
bclr #8,d0 ; d cache off
bclr #12,d0 ; d burst off
movec d0,cacr
rts
_asm_restore_030_cache_settings:
move.l save_cacr,d0
bset #11,d0 ; clear data cache
bset #3,d0 ; clear inst cache
movec d0,cacr
rts
code if from Mikro http://dhs.nu/bbs-coding/index.php?request=3608 , it
could be shorter if we don't care restoring cacr.
Nicolas