[hatari-devel] Blitter emulation corner case

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


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.

Regards
Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz@xxxxxxx
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA



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