Re: [hatari-devel] Blitter emulation corner case

[ Thread Index | Date Index | More Archives ]


great to hear that! Thank you. I can only have a look at it next week, though.


Gesendet von Windows Mail

Von: Nicolas Pomarède
Gesendet: ‎Donnerstag‎, ‎10‎. ‎September‎ ‎2020 ‎17‎:‎44
An: Hatari Development, Christian Zietz

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:
> <>. 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.
> Regards
> Christian
> 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
more details


Mail converted by MHonArc 2.6.19+