Re: [hatari-devel] Blitter emulation corner case

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


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



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