Re: [hatari-devel] Blitter emulation corner case

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 09/05/2017 à 18:58, Christian Zietz a écrit :
> Christian Zietz schrieb:
>
> > Hatari 2.0.0. But I would suggest waiting until Markus has figured out
> > the current problem in his Blitter-enabled fork of EmuTOS (that doesn't
> > show up on Hatari, but on real hardware and Steem). Then you'd have a
> > test case for this possible Blitter emulation issue.
>
> I think, Markus Fröschle inadvertently found a very weird Blitter
> behavior when doing single-word-per-line (XCOUNT=1) copies with FXSR and
> NFSR bits set. While the Blitter only *writes* one word per line it
> seems to read *two* and to skip one. This is not correctly emulated in
> Hatari. (According to the Atari docs, one does not set FXSR and NFSR for
> blitting with XCOUNT=1, however, I still think this should be emulated
> correctly.)
>
> Consider the test case in
> <https://ocean.czietz.de/index.php/s/GHImnU2KZsfNEoU> (Pure-C source
> included), that copies some memory with the settings mentioned above. On
> my STfm (with Blitter made by SGS-Thomson) and on my STE it will print
> "0 2 4 6 8 [...] 58 60 62". With Steem 3.9.1 this prints "1 3 5 7 [...]
> 59 61 63" -- correct stride but offset by one word.
>
> On Hatari 2.0.0, the program prints "32 33 34 [...] 61 62 63" instead.
>
> Also, it would be interesting if different Blitters, e.g. the one
> integrated into newer (Mega)STEs or the one in the Falcon, show
> different results.

Hi

thanks for this test program, this should indeed be fixed.

I think the problem in Atari blitter doc from june 1987 is that they say 
for NFSR "when this bit is set the last source read of each line is not 
set".

But the word "last" seems ambiguous here, it seems Atari considers that 
"last" implies there were other words before, ie XCOUNT > 1. But in this 
case where XCOUNT=1, we have last=first.

It's quite possible NFSR is always simply ignored when XCOUNT=1 and 
"forced" to 0. For example, if we setup blitter with XFSR=0, NFSR=1 and 
XCOUNT=1 and YCOUNT=10, does it really copies 10 consecutives words ?
Could you try this ? (sorry no STE available on my side at the moment). 
If so, then it means NFSR=1 is ignored when XCOUNT=1, whatever the value 
of XFSR.

Now, regarding your example, I also get even numbers if I apply a fix to 
Hatari to read a 2nd word per line without modifying the rest of the 
code "1 3 5 .. 61 63".

If I unroll the code from Hatari, hopefully matching the blitter's doc, 
I get :

process 1st line, ycount=32 :

 - read source
   - xfsr=1, so shift buffer to the right and read "63" in upper word
   - buffer = 0x003f 0000
   - nfsr=1 but read one word anyway : shift buffer to the right and 
read "62"
   - buffer = 0x003e 003f

 - write lower 16 bits of buffer to dest, so we write "63" and not "62" 
as expected.

 - end of line : decrement YCOUNT and process next line.

ycount=31 :
 similar to above, buffer is shifted, so "62" is lost, and we write 
"61" this time.

This is the general loop that worked until now for other values, but 
maybe when XCOUNT=1 there's a really different order to process source ? 
Or maybe we should write the upper 16 bits to dest instead of the lower 
as usual ?


Could you make a similar test with x_incr/y_incr=2 for src/dest ? I 
wonder if the src_xincr value (positive or negative) might not affect 
how the 32 bit internal buffer is processed before writing to dest in 
the case where xcount=1.


Nicolas