Strange result when writing directly into BLT0DAT

[dirkwhoffmann]

While debugging issue https://github.com/dirkwhoffmann/vAmiga/issues/609 in vAmiga, I’ve written four test cases that utilise the Copper to write directly into BPL0DAT with varying combinations in BPLCON1. Directly after writing to BPL0DAT, the number of enabled bitplanes is modified (I did this to get a better understanding of the shift register logic in Denise).

I.e., the tests consist of several Copper blocks similar to this one:

dc.w    $4A39, $FFFE
dc.w    BPLCON1,<some value>
dc.w    BPLCON0<some value>
dc.w    NOOP,0
dc.w    NOOP,0
dc.w    BPL0DAT,<some value>
dc.w    BPLCON0,<some value>

In WinUAE 4.9.0, I get the following result (ECS Agnus, OCS Denise):

On my real machine (and now in vAmiga), it looks like this:

The test cases (ADFs and sources) are located in the vAmigaTS repo:

https://github.com/dirkwhoffmann/vAmigaTS/tree/master/Denise/BPL0DAT

[tonioni]

4.9.1 already had some fixes (noticed when testing how sprite behaves when BPL1DAT write disables border which is slightly different on all chipset versions. This behavior at least is identical on all HW, OCS Denise, ECS Denise and AGA tested)

It is almost correct after making sure highest bitplane value is used in second pass of display emulation (instead of using number of planes at the start of line..)

But there is still something wrong:

Internal shifter logic probably has off by one bug somewhere or something.

btw, I still would like to have tiny executables.

[tonioni]

Success :)

This needs to be documented but I am not 100% sure how it is working :)