Re: [hatari-devel] Blitter emulation corner case

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


Le 10/05/2017 à 20:45, Christian Zietz a écrit :
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.

Hi

as a follow up to this old discussion where xcount=1 with nfsr=1 gave "strange" results, this is now correctly emulated in Hatari.

See message "New blitter code for xcount=1 nfsr=1" from 2020/09/10 for more details

Nicolas




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