Re: [hatari-devel] Blitter emulation corner case

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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