VGA 256-color 8BIT behavior

[joncampbell123]

Is your feature request related to a problem? Please describe.

The "8-bit" mode bit in the attribute controller is set for 256-color mode, clear for others.
It appears to set a mode in hardware where every even pixel is repeated twice over the odd pixel.

The reason appears to be how VGA hardware implements 256-color mode from what appears to be a pixel pipeline that is 4 bits wide.

The 4-bit path makes sense if you think about how the video mode is first expanded to a CGA-like 16-color palette, then expanded through the attribute controller to a 6-bit (64 color) palette, then finally to the 8-bit (256 color) palette of the VGA.

All non-256-color modes can be represented as 4-bit color indices, including text mode.

256-color mode appears to be built on top of that such that two nibbles handled at a time and shifted through per pixel through an 8-bit register that directly drives the DAC. This mode is enabled by the SH256 bit. Clearing SH256 triggers the hardware into the VGA planar mode immediately.

256-color mode can be thought of as a 4-bit 640 "pixel" wide mode, in which 8-bit bytes are shifted from video RAM one nibble at a time (based on Paradise SVGA hardware which faithfully emulates the behavior, A = (A << 4) + newnibble). This is hidden by the 8BIT bit which instructs the hardware to hold the previous (valid) pixel while the register is in this halfway state. Clearing 8BIT while in 256-color mode reveals this behavior.

The hardware appears to at least have the normal 8 bits fully loaded for the first pixel on the row (1 of 640), after which this half-nibble-shifting behavior appears when 8BIT=0.

If you print text in 320x200x256-color mode using color index 0x0F (0x0F 0x0F 0x0F 0x0F), and then turn off 8BIT, you will see what looks like 640x200x256-color mode with the 8-bit pixels displayed as if (0x0F 0xF0 0x0F 0xF0 0x0F 0xF0 0x0F 0xF0).

If 320x200x256-color mode had pixels (0x3F 0x3F 0x3F 0x3F) it would appear as if (0x3F 0xF3 0x3F 0xF3 ...).

So far original IBM PS/2 VGA hardware is confirmed to do this, as well as Paradise/Western Digital SVGA hardware.

If you do this on a Tseng ET4000, the hardware will shrink the display horizontally, showing black or invalid data on the right hand half as the hardware is not designed to do that. It will not show this half-shift behavior.

[joncampbell123]

The issue, left as a reminder to self, is to emulate this in DOSBox-X.

[joncampbell123]

Also noted: Switching off SH256 bit on real hardware shows the contents immediately displayed as if VGA planar bitmaps, in place, while DOSBox-X and DOSBox SVN shows them spread out (not obeying the CRTC byte/word/dword it seems).

[joncampbell123]

[joncampbell123]

I'm open to the possibility that real IBM PS/2 VGA hardware might shift in the register the other way.

[joncampbell123]

By the way, while every other VGA mode is consistent with the "divide by 2" bit being set for 320x modes and clear for 640x modes, this quirk is the reason "divide by 2" is clear for 256-color mode (320x) when you would expect it to be set and it's why standard VGA can't be hacked to produce a 640x200x256-color mode.

[joncampbell123]

I forgot to mention, DOSLIB test program VGA256B4.EXE, renders text white on color index 0xFF which in this hacked mode given the color palette gives it an interesting effect where the white has red/blue fringes (as if the transition is rendered 0x00 0x0F 0xFF 0xFF 0xFF 0xF0).

[sikthehedgehog]

I'm open to the possibility that real IBM PS/2 VGA hardware might shift in the register the other way.

Not sure how accurate this is, but it does seem that it can be the case (and for some other cards too):
http://www.osdever.net/FreeVGA/vga/vgaseq.htm

Since the intermediate values aren't meant to be displayed, it doesn't matter which way it's shifted as far as actual color output goes in 8bpp mode.

[joncampbell123]

Shift order does matter if you're a programmer wishing to exploit this "mode" since it affects the value sent to the DAC and therefore which byte values to write to memory :)

[joncampbell123]

@sikthehedgehog Thanks for linking that, I didn't catch on that FreeVGA had already documented that behavior to some extent!

[joncampbell123]

DOSBox-X now contains "alt" VGA emulation code that provides emulation of this 256-color 8BIT=0 mode. To access it, run dosbox-x with --alt-vga or set "alt render=true" in [render] in dosbox.conf