Re: [hatari-devel] Blitter emulation corner case

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


Nicolas Pomarède schrieb:

> 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 ?

OK, new test case:
<https://ocean.czietz.de/index.php/s/ZifW0yKW8im1nOB>. This now copies
10 words, with XCOUNT=1 and YCOUNT=10. It does all 8 combinations of
positive/negative increment, FXSR=0/1 and NFSR=0/1. The destination
buffer is initialized to -1  (0xFFFF) each time, so you can see which
memory locations are actually written to. Note that I use OP = 1
(Destination = Source AND Destination, so this a read/modify/write) and
OP = 3 (Copy only).

Results on my STE are here:
<https://ocean.czietz.de/index.php/s/CytgB1YIJlEcooW>
<https://ocean.czietz.de/index.php/s/eC5kBPuAWplNbMG>
I can just say that the blitter behaves very strangely for XCOUNT=1...
Only the variant positive increment, FXSR=NFSR=0 really works as
expected by me.

A short look into the schematic of the Blitter shows me that some
internal signals are latched when XCOUNT reaches 2, so this explains why
some things are different for XCOUNT=1. However, without a very deep
look into this schematic I cannot explain what happens in detail. Also,
I think this is all of the time I can devote to this today.

Regards
Christian

PS: I'm still interested if the COMBO chip or the Falcon's Blitter work
the same here.
-- 
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/