Vamiga: All tests in Copper/copbpl fail

[dirkwhoffmann]

All tests in this suite utilize the Copper to write into the BPLxDAT registers directly (with bitplane DMA disabled):

Amiga 500 8A: 🥰

vAmiga: 🙈

I think the following happens: When bitplane DMA is off, vAmiga clears all events in the BPL_SLOT table, including all events that push the BPLxDAT register values into Denise's shift registers. With some luck, this bug is responsible for some of the graphics glitches we've seen in the recently tested demos.

@tonioni: UAE does it right (in theory), but it seems to have a timing problem here:

The tests are very simple. I've set up a Copper list with a couple of blocks like this:

dc.w    $5001, $FFFE         ; Wait
dc.w    BPLCON0,(0<<12)|$200 

dc.w    $5139, $FFFE         ; Wait
dc.w    DPL1DATA,$F00F
dc.w    DPL1DATA,$F00F
dc.w    $5339, $FFFE         ; Wait
dc.w    DPL2DATA,$F00F
dc.w    DPL1DATA,$F00F
dc.w    $5539, $FFFE         ; Wait
dc.w    DPL3DATA,$F00F
dc.w    DPL1DATA,$F00F
dc.w    $5739, $FFFE         ; Wait
dc.w    DPL4DATA,$F00F
dc.w    DPL1DATA,$F00F
dc.w    $5939, $FFFE         ; Wait
dc.w    DPL5DATA,$F00F
dc.w    $5B39, $FFFE         ; Wait
dc.w    DPL6DATA,$F00F
dc.w    DPL1DATA,$F00F

dc.w    $6001, $FFFE         ; Wait
dc.w    BPLCON0,(1<<12)|$200 
...

https://github.com/dirkwhoffmann/vAmigaTS/tree/master/Copper/copbpl

[tonioni]

I am not yet sure if this is correct fix but if I delay bitplane processing start by 1 cycle, UAE output looks correct (sprites have similar edge cases if copper writes to SPRxDATx exactly when sprite's x-coordinate matches comparison. And others.)

EDIT: could you improve the test and test whole horizontal width? Because right overscan can sometimes work strangely..

I know no programs that tries to generate actual graphics by copper or CPU writing to BPLxDAT. Usual case is "7-plane" which uses 4-plane DMA cycle but Denise still enables planes 5 and 6, BPL5DAT and BPL6DAT can be used as a static pattern.

btw, it would be nice if your test programs could be optionally automatic. Program runs, uses some sprite/bitplane collision etc.. logic to detect if output is correct, returns OK/FAIL.

[dirkwhoffmann]

if I delay bitplane processing start by 1 cycle, UAE output looks correct

Looks perfect now!

it would be nice if your test programs could be optionally automatic.

I agree. It would be awesome to have an Amiga test suite similar to the VICE test suite for testing C64 emulators. It would enable automatic regression testing which is impossible with my tests at the moment.

[emoon]

I actually do use the copper to generate "graphics" in "7-bitplane" mode in Eon. In my case the graphics is just a square box but I still use it

In the middle of the screen here (when bitplane DMA is active) I have some copper activity to set BPL5DAT to 0xffff and then wait a bit and set it back to 0x0000 this way the cube will use color 16-31 during when the DAT value is 0xffff and then I set it back to 0x0000 so the background will start using colors 0-15 again.

I wouldn't be surprised if other demos does similar trickery.

[dirkwhoffmann]

Much better now... 😎

Strange enough it looks alright in vAmiga without emulating any additional cycle delay.

However, I've encountered other problems in my emulator. The hires version of this test case fails. The lower two sections are not displayed, because 5 (resp. 6) biplanes are enabled in this area. In DMA mode, the screen would be black, but when the registers are written manually, I do get visible output on the real machine. I know that the BPU bits in BPLCON0 are treated differently by Agnus and Denise if an invalid bit combination is selected, but I must have mixed up something 🙈.

[dirkwhoffmann]

I have just double-checked some of the failed demos. Unfortunately none of them was affected by this particular bug. They still exhibit the same issues.

[dirkwhoffmann]

could you improve the test and test whole horizontal width? Because right overscan can sometimes work strangely..

No surprises at the very right:

https://github.com/dirkwhoffmann/vAmigaTS/tree/master/Copper/copbpl/copbpl3

[tonioni]

It still is not right enough :)
Horizontal positions 0 to 3 or so are still visible in right overscan. Position 0 is the important point where internal counters are reset and can cause side-effects if there is visible graphics in max right overscan.

[dirkwhoffmann]

It still is not right enough :)

I've extended the Copper list as follows, but the image doesn't change:

    dc.w    $DDDD, $FFFE         ; Wait
    dc.w    DPL1DATA,$CCCC
    dc.w    DPL1DATA,$F00F
    dc.w    $DFDF, $FFFE         ; Wait
    dc.w    DPL2DATA,$CCCC
    dc.w    DPL1DATA,$F00F
    dc.w    $E1E1, $FFFE         ; Wait
    dc.w    DPL3DATA,$CCCC
    dc.w    DPL1DATA,$F00F
    dc.w    $E301, $FFFE         ; Wait
    dc.w    DPL4DATA,$CCCC
    dc.w    DPL1DATA,$F00F
    dc.w    $E503, $FFFE         ; Wait
    dc.w    DPL5DATA,$CCCC
    dc.w    DPL1DATA,$F00F
    dc.w    $E705, $FFFE         ; Wait
    dc.w    DPL6DATA,$CCCC
    dc.w    DPL1DATA,$F00F

At the beginning of the Copper list, I initialize with:

    dc.w    BPLCON0,(0<<12)|$200 
    dc.w    DDFSTRT,$18
    dc.w    DDFSTOP,$E0 

[dirkwhoffmann]

Fixed in v0.9.10