Re: [hatari-devel] Blitter emulation corner case

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Le 17/05/2017 à 18:51, Christian Zietz a écrit :
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.

Maybe they just use the common case with NFSR=0 and FXSR=0 ? This seems to always give the correct pattern in your test program and this is the most likely use when you want to copy a 16 pixel width block (without shifting)

I will have a closer look to the example in the blitter doc, the generic bitmap copy routine computes NFSR/FXSR, it could be interesting to see which case they take in the end.


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.


That would be of course much better but as you say, could be ard to find a simple "formula". I also wonder if the shit amount in the skew register could play a role in this xcount=1 case ?

Anyway, thanks in advance for any time you could invest on this :)

Nicolas



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/