First findings (X ray): 馃樂

Upper region has 2 bitplanes enabled and looks OK. Middle region has 4 bitplanes enabled and is broken.
Relevant part of Copper list:

Could be a DDFSTRT, DDFSTOP timing issue.
Maybe this wedding gun fireworks helps ... to make the bug go away and vanish, no????
It is very loud 馃檳 ... keep your ears covered
Maybe this wedding gun fireworks helps ... to make the bug go away and vanish, no????
Actually that helped 馃コ. I think I know what it is...
Here is the thing:

In raster line $60, updateBplEventTable() is called twice. The first call is triggered by the write to BPLCON0 and the second one by the write to BPLCON1. But there is write to DFFSTRT in between which causes trouble. The Copper list is set up in a way that makes the raster beam not to hit the DDSTRT value. Hence, no DMA takes place in this line on the original Amiga. The DDFSTRT handler recognized this correctly and clears the bitplane event table. But then, the second call to updateBplEventTable() happens which lets vAmiga restore the original bitplane event table. Hence, bitplane DMA is emulated in the rest of the raster line which lets the bitplane pointers get out of sync 馃檲.
Old code:
bool
Agnus::inBplDmaLine(u16 dmacon, u16 bplcon0) {
return
ddfVFlop // Outside VBLANK, inside DIW
&& bpu(bplcon0) // At least one bitplane enabled
&& bpldma(dmacon); // Bitplane DMA enabled
}
Proposed fix:
bool
Agnus::inBplDmaLine(u16 dmacon, u16 bplcon0) {
return
ddfVFlop // Outside VBLANK, inside DIW
&& ddfstrtReached != -1 // Raster beam hits DDFSTRT value
&& bpu(bplcon0) // At least one bitplane enabled
&& bpldma(dmacon); // Bitplane DMA enabled
}
And here is the result: 馃槑

Unfortunately, inBplDmaLine()is a very critical function. I hope this change doesn't break too much. 馃檮
It really works , now I think we have to write that paper about declaring war to a bug and about the needed perseverance to win ... 鉁岋笍馃い
Now I think we have to write that paper...
Definitely. Now image we combined it with the so fruitful "Priority Inversion Approach". This is going to revolutionize industry... 馃槑
Most helpful comment
Here is the thing:
In raster line $60, updateBplEventTable() is called twice. The first call is triggered by the write to BPLCON0 and the second one by the write to BPLCON1. But there is write to DFFSTRT in between which causes trouble. The Copper list is set up in a way that makes the raster beam not to hit the DDSTRT value. Hence, no DMA takes place in this line on the original Amiga. The DDFSTRT handler recognized this correctly and clears the bitplane event table. But then, the second call to updateBplEventTable() happens which lets vAmiga restore the original bitplane event table. Hence, bitplane DMA is emulated in the rest of the raster line which lets the bitplane pointers get out of sync 馃檲.