Vamiga: "The Pawn" intro screen is scrambled

[dirkwhoffmann]

Todo: Implement HAM mode

[dirkwhoffmann]

Hmm, experimental HAM mode seems to work:

However, Pawn looks like this 🤔:

[Alessandro1970]

Pawn intro screen for me was not HAM, it was a palette swap per line via the copper ...Dynamic Hires from Newtek Digi-View maybe interlaced (flicker)

[dirkwhoffmann]

That explains a lot. I took a screenshot from SAE and and it appeared to me that the pixels are squares. HAM pixels are lores pixels which means they are twice as wide as heigh.

But how come the HAM flag is set 🤔😟.

BTW, as HAM pixels are twice as wide as high, one could assigned the first pixel a mixed colour which should result in improved HAM picture quality (HAM is all about changing colours smoothly). I'll try to do some experiments with such an extra-smooth HAM mode.

[dirkwhoffmann]

Pawn intro screen for me was not HAM, it was a palette swap per line via the copper ...Dynamic Hires from Newtek Digi-View maybe interlaced (flicker)

I just run The Pawn with some debug output enabled. It turns out that we're both right. The Pawn draws in HAM mode (interlaced), just as it uses palette swapping. The Copper is used to update the color registers ever line:

E.g., the following is happening in frame 2970, line 50:

[2970] ( 50,  2)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR00(0)
[2970] ( 50,  6)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR01(13)
[2970] ( 50, 10)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR02(12)
[2970] ( 50, 14)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR03(0)
[2970] ( 50, 18)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR04(0)
[2970] ( 50, 22)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR05(0)
[2970] ( 50, 26)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR06(0)
[2970] ( 50, 30)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR07(0)
[2970] ( 50, 34)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR08(0)
[2970] ( 50, 38)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR09(0)
[2970] ( 50, 42)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR10(0)
[2970] ( 50, 46)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR11(0)
[2970] ( 50, 50)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR12(0)
[2970] ( 50, 54)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR13(0)
[2970] ( 50, 58)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR14(0)
[2970] ( 50, 62)  FC0F94: PCBD 65AC 1000: Colorizer: pokeCOLOR15(0)

This makes Pawn a brilliant test case for checking the timing of color registers. Right now, Denise picks up a changed color value immediately which is not accurate.

[dirkwhoffmann]

New color management code has recorded more than 128 color changes in a single row 😳.

Todo: Check how this is possible. Assuming that only Copper is used to change the color registers (to be checked), changes should be limited by approx. 224 / 4 = 56.

[dirkwhoffmann]

Upper part of the intro screen:

SAE:

vAmiga:

Either vAmiga starts with wrong bitplane data or it starts drawing too early (maybe for certain biplanes only which may cause the graphics glitches).

[dirkwhoffmann]

This bug is giving me a hard time, but I am coming closer. I faked the HAM mode in both SAE and vAmiga such that only 1 bitplane is drawn (without hold and modify).

This shows clearly that

• the bitplane data itself is not corrupted in vAmiga (at least plane 1)
• the bitplane data is shifted in vAmiga. But why? 🤔

[dirkwhoffmann]

vAmiga starts DMA in rasterline 26:

[1610] ( 26,191)  FC0F94 BCB-DA 65AC 0000 Agnus: addBPLMOD0 +30 = 159594 ($26F6A)
[1610] ( 27,191)  FC0F94 BCB-DA 65AC 0000 Agnus: addBPLMOD0 +30 = 159654 ($26FA6)
[1610] ( 28,191)  FC0F94 BCB-DA 65AC 0000 Agnus: addBPLMOD0 +30 = 159714 ($26FE2)

It is doing so, because lines 0 ... 25 belong to the VBLANK area where no DMA can take place.

Strangely enough, SAE DMA starts DMA in line 19 😳:

amiga.js:295 (19,191) add_modulo 0: add 30 to bplpt = 159594 bplptx = 159594
amiga.js:295 (20,191) add_modulo 0: add 30 to bplpt = 159654 bplptx = 159654
amiga.js:295 (21,??) add_modulos 0: 159714 (159714) 1: 174714 (174714) 2: 189714 (189714) 3: 204714 (204714) 4: 219714 (219714) 5: 234714 (234714)
amiga.js:295 (22,??) add_modulos 0: 159774 (159774) 1: 174774 (174774) 2: 189774 (189774) 3: 204774 (204774) 4: 219774 (219774) 5: 234774 (234774)

How come? 🤔

[dirkwhoffmann]

Solved 😎. DMA can take place in VBLANK area, it is simply not displayed. DMA is only delayed by the vertical DIW flop. Hence, if the DIW V flop is set inside the VBLANK area, DMA starts early.