Re: [hatari-devel] Blitter emulation corner case

[ Thread Index | Date Index | More Archives ]


I'm not convinced that your code is completely correct. You appear to use the blitter in NO-HOG mode and simplify the blitter start to

while (LINE_NUM & 0x80)

As far as I understand, this will assign only one single portion of 64 "NOHOG"- bus cycles to the blitter. As you do not restart the blitter until finished (which required a RMW cycle to LINE_NUM[BUSY] until its eventually signalling a zero bit, to my understanding), it might get into some kind of undefined state (assuming it needed more than these initial 64 cycles to finish which is something I don't know) affecting further tests. We also do not know if there is any difference between Falcon and ST blitters regarding the number of cycles it might need for certain operations (at least I don't).

Of course this is a shot into the dark and could only explain any difference from the second round onwards but might be worth a try.

Am 17.05.2017 um 18:51 schrieb Christian Zietz:
Nicolas Pomarède schrieb:

Although not 'random', it seems the xcount=1 case had no 'official'
defined behaviour, which makes it quite dangerous to use, especially
when using same code for STE and Falcon.

I wonder if TOS tries not to use xcount=1 when using OS functions ?
Atari TOS uses xcount=1, however of course by far not every possible
permutation of x_inc, y_inc, NFSR, FXSR etc. Thorsten Otto sent me a
disassembly of the Blitter routines from TOS 2.06/3.06, however, I
didn't have the time to understand it yet.

I don't know if a logic pattern can be seen from the STE blitter
schematics, but if not it could be handled with a hardcoded table
combining those 8 possible cases (and a 2nd table for falcon)
I'd be more comfortable if we found the logic pattern behind it, given
that there are even more permutations than those currently tested by
BLITEMU. For example, what if x_inc is positive (or zero) and y_inc is
negative or vice-versa? It would result in a huge table, I'm afraid.
I cannot promise, though, that I'll be able to reconstruct the ST/STE's
Blitter inner workings from the schematic.


Mail converted by MHonArc 2.6.19+