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