|Re: [hatari-devel] Blitter emulation corner case|
[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]
great to hear that! Thank you. I can only have a look at it next week, though.
Gesendet von Windows Mail
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:
> 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.
> PS: I'm still interested if the COMBO chip or the Falcon's Blitter work
> the same here.
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
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|