|Re: [hatari-devel] Blitter emulation corner case|
[ Thread 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.
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 :
bset #0,d0 ; i cache on
bset #4,d0 ; i burst on
bclr #8,d0 ; d cache off
bclr #12,d0 ; d burst off
bset #11,d0 ; clear data cache
bset #3,d0 ; clear inst cache
code if from Mikro http://dhs.nu/bbs-coding/index.php?request=3608 , it
could be shorter if we don't care restoring cacr.