Vamiga: Graphics glitches in "Icewind" demo

Created on 14 Jul 2020  路  7Comments  路  Source: dirkwhoffmann/vAmiga

Icewind.adf.zip

UAE: 馃槂

Bildschirmfoto 2020-07-13 um 14 43 06

vAmiga: 馃檲

Bildschirmfoto 2020-07-14 um 10 00 25

Bug

Most helpful comment

Here is the thing:

87403152-c81ba580-c5bc-11ea-8983-51b281651aa6

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 馃檲.

All 7 comments

First findings (X ray): 馃樂

Bildschirmfoto 2020-07-14 um 10 24 49

Upper region has 2 bitplanes enabled and looks OK. Middle region has 4 bitplanes enabled and is broken.

Relevant part of Copper list:

Bildschirmfoto 2020-07-14 um 10 27 31

Could be a DDFSTRT, DDFSTOP timing issue.

https://youtu.be/IJEO3rmefmI

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:

87403152-c81ba580-c5bc-11ea-8983-51b281651aa6

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: 馃槑

Bildschirmfoto 2020-07-19 um 16 09 27

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... 馃槑

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dirkwhoffmann picture dirkwhoffmann  路  3Comments

KenDFish picture KenDFish  路  3Comments

Alessandro1970 picture Alessandro1970  路  4Comments

dirkwhoffmann picture dirkwhoffmann  路  5Comments

dirkwhoffmann picture dirkwhoffmann  路  3Comments