Pinball Fantasies (SVGA): wrong colors in table selection

[carlosefr]

Opening an issue specifically for this, as it seems like something that won't have a quick fix, and to avoid the discussion being split between issue #550 and PR #552.

Summary (from what was said before):

Pinball Fantasies has historically required vgaonly in DOSBox. Right now, under SVGA the table selection screen shows the wrong colors (the 16-color palette change for the bottom half isn't applied).

Even though the table selection screen is 640x480 (vga.mode=2), which doesn't require double-scanning in VGA, the game still sets double-scanning explicitly in the maximum scan line register (SD=1).

In vgaonly the SD bit in that register is ignored for vga.mode 2 and 3 — here — which is then expected to be compensated later on — here. The side-effect of this is making the frame always double-scanned regardless of what's set in the "Aspect Ratio Correction" core option.

In SVGA, the SD bit is honored — here — and later causes the reported horizontal resolution to be halved — here.

Looking at the code in "DOSBox-X" and "DOSBox Staging" doesn't help much, as vga_draw.cpp has been changed beyond recognition in those forks.

[carlosefr]

I'm not sure what to try next. Unless the issue is properly understood, any changes to original DOSBox behavior on this will likely break other stuff. The code in vga_draw.cpp is just too convoluted for my current understanding of it. I think I get why the other forks rewrote it... 😮‍💨

Putting vgaonly aside and thinking just about the SVGA case, here's some differences in vga.crtc between Syndicate Plus (which also uses 640x480, 16-colors) and Pinball Fantasies:

	vertical total	maximum scan line	cursor location low	vertical retrace end	start vertical blanking	end vertical blanking	index
Syndicate Plus	0x0b (525 lines)	0x40	0x00	0x8c	0xe7	0x04	0x755aed8c
Pinball Fantasies	0x0d (527 lines)	0xc0	0x59	0x00	0xea	0x06	0x9176ed8c

What I really don't understand, and feel it's critical to what's happening here is...

Why is the final resolution in the table selection reported as 640x240, but no corruption is seen other than the wrong colors? The double-scanning done later on could explain this, but the frame is still 640x480 even when Aspect Ratio Correction is set to On (single-scanning). 🫤

@schellingb Any ideas?

[carlosefr]

I've found this commit in DOSBox Staging which might point in the right direction: "Improve VGA double scanning criteria"

Lemmings also uses the same trick for the bottom control area. It also requires vgaonly for the level briefing screen, but the reason for that seems to be different (it doesn't require #552 to work).

[alexb3d]

There are many games that only work with VGA.

SVGA is just the standard, it is compatible with VGA but does not support all its features, it is not a video card compatible with both standards, VGA/SVGA.

[carlosefr]

@alexb3d SVGA cards were backwards compatible with VGA but, even if they weren't, that would not be relevant for this issue. The reason why DOSBox requires vgaonly for some games is due to limitations in DOSBox's code.

I've spent a few more hours on this after opening this issue and got nowhere. My conclusion is that the way vga_draw.cpp is written doesn't allow fixing this issue without a massive rewrite, there are just too many workarounds on top of other workarounds.

In summary, vgaonly is required for Pinball Fantasies to avoid breaking the default "SVGA" code paths in other ways, not because Pinball Fantasies depends on behavior that only original VGA cards implemented. In fact, vgaonly does not mean original VGA behavior at all, despite the name. From what I've seen, vgaonly should be interpreted as "kludge mode".

[carlosefr]

@schellingb Continuing here, since #552 has been merged...

Maybe we can look into what DOSBox Staging did, it looks like Staging has gotten rid of vgaonly as a machine altogether, having only the SVGA cards above EGA.

They rewrote the whole thing, and seem to rely more closely to what's set in the VGA registers to derive the correct behavior. That's the correct approach.

Roughly, what Pinball Fantasies is doing here is setting things up in a way that triggers an interrupt midway through the frame as if it were starting a new frame (and that's why the resolution is reported as 640x320 instead of the correct 640x480). At that point it switches the palette, but the draw continues from the same position without doing a VSYNC.

Line Counter Register:

"When the scan line counter reaches the value in the Line Compare field, the current scan line address is reset to 0 and the Preset Row Scan is presumed to be 0."

I see places in the code where VGA triggers interrupts, and I see some references to the line counter. But can't, for the life of me, figure out where the two are glued together regarding this specific behavior. Nor where it is triggering a different behavior based on vgaonly. I've messed about with this, getting this mode to behave similarly to vgaonly under SVGA on the double scanning side, but it still doesn't trigger the palette switching (and that breaks the game's 320x240 modes... sadface).