Behavior with BPLCON1 shifts and mid-scanline BPLCON0 change

[losso]

I've run into a bitplane rendering mismatch when using BPLCON1 shifts and changing the number of bitplanes mid-scanline.

Display setup:

• 352px overscan + 16px invisible
• BPL1 = full-width (used as overlay)
• BPLPT2/BPLPT3 and BPLPT4/5 point to the same 2-bitmap image (256px wide)
• BPLPT2-BPLPT5 are set on each new line
• Switch to 5 bitplanes at hpos $42 and back to 1 bitplane at $c4
• PF2 bits of BPLCON1 are used to shift the center image ($00 .. $F0)

The copper instructions look like this for each line (with different values for BPLCON1):

 0100 1200 [06c 0d0]  ;  BPLCON0 := 0x1200
 6d01 fffe [06c 0d6]  ;  Wait for vpos >= 0x6d and hpos >= 0x00 VP 6d, VE 7f; HP 00, HE fe; BFD 1
 0102 0000 [06d 008]  ;  BPLCON1 := 0x0000
 00e4 0001 [06d 00c]  ;  BPL2PTH := 0x0001
 00e6 5c14 [06d 010]  ;  BPL2PTL := 0x5c14
 00e8 0001 [06d 014]  ;  BPL3PTH := 0x0001
 00ea 5c14 [06d 018]  ;  BPL3PTL := 0x5c14
 00ec 0001 [06d 01c]  ;  BPL4PTH := 0x0001
 00ee 5c34 [06d 020]  ;  BPL4PTL := 0x5c34
 00f0 0001 [06d 024]  ;  BPL5PTH := 0x0001
 00f2 5c34 [06d 028]  ;  BPL5PTL := 0x5c34
 6d43 fffe [06d 02c]  ;  Wait for vpos >= 0x6d and hpos >= 0x42 VP 6d, VE 7f; HP 42, HE fe; BFD 1
 0100 5200 [06d 048]  ;  BPLCON0 := 0x5200
 6d51 fffe [06d 04c]  ;  Wait for vpos >= 0x6d and hpos >= 0x50 VP 6d, VE 7f; HP 50, HE fe; BFD 1
 01a2 0eee [06d 058]  ;  COLOR17 := 0x0eee
 6dc5 fffe [06d 05e]  ;  Wait for vpos >= 0x6d and hpos >= 0xc4 VP 6d, VE 7f; HP c4, HE fe; BFD 1
 01a2 0aaa [06d 0cc]  ;  COLOR17 := 0x0aaa
 0100 1200 [06d 0d0]  ;  BPLCON0 := 0x1200
 ...

I used a cover-up sprite for my specific use case, hence the COLOR17 stuff. Screenshots and test executable are attached. The red boxes show where the BPLCON0 switches occur and can be moved when the left mouse button is pressed.

Tested with WinUAE 4.4.0 and latest Beta, showing slightly different behaviors.

(EDIT: test executable updated)

[Toni Wilen]

Great, new undocumented feature

It is more correct in subpixel mode (missing left part becomes visible). I haven't yet debugged why it even happens..

There is probably some internal Denise delays that cause this effect.

[Toni Wilen]

Could you do following tests:

- I assume it does not happen if PF1 == PF2?
- does it happen if you swap PF1 and PF2?
- does it happen if PF1 BPLCON1 bit is F (instead of zero. Or some other non-zero static value)? (or when swapped, PF2 is F)
- does it happen only if PF1 > PF2 and/or PF2 > PF1?

PF1 != PF2 requires subpixel mode which explains the difference.

[losso]

Test executable updated (adjust PF1 portion of BPLCON1 with RMB + mouse up/down). Screenshots with PF1 values of $0 to $f attached, that should cover all combinations.

I hope the literal screenshots are still helpful, don't have any capturing equipment...

[losso]

For completeness: This is how the center image looks like

[Toni Wilen]

Interesting tiny difference when ECS Denise or AGA. (Check black/red in right edge) OCS Denise or A1000: identical to image in first post.

Old test executable. Image is from real A500 connected OSSC + custom configured "extreme" overscan mode.

[dirkwhoffmann]

I've probably made it work in vAmiga. Some details can be found in this GitHub issue:
https://github.com/dirkwhoffmann/vAmiga/issues/609

However, I am not sure if this can help troubleshooting UAE since the code base of vAmiga is completely different.

Furthermore, I’ve only tested the program with the start configuration and I haven’t compared my emulator output with the real machine for other BPLCON combinations yet (in other words: I didn’t push any mouse button when running the test).

[Toni Wilen]

Should now work correctly in WinUAE (winuae.7z updated). ECS Denise/AGA extra feature is not yet emulated.

Denise logic was not correct. Normal sequence is:

- Agnus does BPLxDAT DMA. Denise stores the data.
- When BPL1DAT DMA happens, Denise copies all BPLxDAT contents to internal storage registers. All planes.
- When BPLCON1 shift matches horizontal counter, only currently active planes are copied to shift register. (UAE used plane count value when BPL1DAT was written but it needs to be current value)
- All planes' shift registers are active, including disabled planes. (UAE only shifted active planes, even if plane count decreased mid scanline)

(Possibly more detailed description will appear in undocumented features thread later)

EDIT: just noticed earlier post. interesting timing..

[Toni Wilen]

ECS Denise/AGA side-effect: if bitplane gets disabled mid-scanline and if bit 0 of disabled bitplane's last word copied to shifter is one, it appears twice on screen. This logic results in 100% identical output when compared to real ECS Denise A500 and A1200.

Quite weird behavior.

Emulation added, supported only in subpixel mode.

[dirkwhoffmann]

- When BPLCON1 shift matches horizontal counter, only currently active planes are copied to shift register.

Quick question: This means that if BPLCON1 contains the same shift values for even and odd planes and assuming that all bitplanes are enabled, all shift registers get updated simultaneously. But if the shift values for even and odd planes differ, we have two copy events. When the shift value for odd planes matches, shift registers 1,3, and 5 are filled. When the shift value for even planes matches, shift registers 2,4, and 6 are filled. is this correct? (My emulator is doing this wrong at the moment).

[dirkwhoffmann]

@losso: Do you mind if I add your program to my regression test suite for vAmiga? It's a public repo on GitHub: https://github.com/dirkwhoffmann/vAmigaTS

[Toni Wilen]

btw, I did some quick tests how hires<>lores changes work and it looks like OCS Denise, ECS Denise and AGA all have slightly different behavior (few pixels during change have "undocumented" behavior). Going to examine this more after 4.9 is out.

Originally Posted by dirkwhoffmann

- When BPLCON1 shift matches horizontal counter, only currently active planes are copied to shift register.

Quick question: This means that if BPLCON1 contains the same shift values for even and odd planes and assuming that all bitplanes are enabled, all shift registers get updated simultaneously. But if the shift values for even and odd planes differ, we have two copy events. When the shift value for odd planes matches, shift registers 1,3, and 5 are filled. When the shift value for even planes matches, shift registers 2,4, and 6 are filled. is this correct? (My emulator is doing this wrong at the moment).

Yes. Odd and even planes are always processed separately (even if not dual playfield mode).