They are not the same thing.

If chain4 bit is 0, then the odd/even bit controls the access mode.
If chain4 bit is 1, then the odd/even bit is ignored, and planes are in chained mode.

Only standard mode 13h uses chain4=1. Because the mode is chained, the odd/even bit is ignored.

Wolf3d should run in unchained mode, therefore chain4=0. And since it must use the plane select register, the odd/even bit must be 1.

IIRC, possibly only text modes utilize that odd/even bit (this is one of the several bits controlling different things called odd/even).
In text mode, even addresses are the characters and they are in plane 0, and odd addresses are the color attributes so they are in plane 1. Also the character font is loaded on either plane 2 or 3 so that hides it from the user by default.

IIRC, there's another bit then which selects whether the accesses go to planes 0&1 (cannot access planes 2&3), or to planes 2&3 (cannot access planes 0&1).
Somehow, also CGA modes only use two planes, not four, so this odd/even bit may be used on CGA modes as well.

Thank you Jepael. That makes a lot of sense.

Regards,
Vlad.

Jepael wrote:

Somehow, also CGA modes only use two planes, not four, so this odd/even bit may be used on CGA modes as well.

CGA works differently.
The pixel format is 'chunky', as in, you have 2 4-bit pixels packed into each byte.
They store even and odd scanlines in two separate buffers though. This is done to circumvent the limitations of the 6845. It is meant for textmode and only supports up to 127 rows. To get 200 lines of bitmap, it programs the 6845 to a 100-row mode, and alternates between the two buffers for each scanline.

Scali wrote:

CGA works differently.
The pixel format is 'chunky', as in, you have 2 4-bit pixels packed into each byte.
They store even and odd scanlines in two separate buffers though. This is done to circumvent the limitations of the 6845. It is meant for textmode and only supports up to 127 rows. To get 200 lines of bitmap, it programs the 6845 to a 100-row mode, and alternates between the two buffers for each scanline.

Yes, but a VGA has to emulate CGA in a certain way. It does not work like real CGA.
And this odd/even bit we are talking about is not about CGA even/odd scanlines, read on 😀

Basically, CGA mode on a VGA is still a 16-color mode (4 bits per pixel), as everything on VGA is 4 bits per pixel (even the 256 color mode, it just has to fetch two 4-bit pixels to generate 8-bit pixels).

In CGA mode, the VGA fetches a byte from each of the four color planes, like it does in 16-color modes.
The odd/even bit discussed earlier limits the CPU data write access to write to VGA plane0 and plane1 only, instead of all four planes. So basically, you can only set two color bits per pixel, instead of four.

Also in CGA mode, the VGA sequencer is configured to mangle the fetched data from all four color planes so that a bytes are combined so that only plane0 and plane1 is used for 2 bits per pixel in CGA compatible way.
So when a CGA mode program writes to video ram, it is written to only two planes, and the sequencer combines the data from all four planes in CGA compatible fashion.

In fact the bytes from plane2 and plane3 would be the remaining 2 bits per pixel, but they are just zero because video memory is cleared when CGA mode is initialized.
Changing the mode to access plane2&3 instead of plane0&1 can set the other 2 bits per pixel in similar mapping like the original 2 bits per pixel.

Yes, in fact, VGA is 99% EGA. EGA implements CGA compatibility in pretty much the same way.
In unchained mode you basically manipulate the 4 'EGA' bitplanes, VGA just interprets the data differently to make it into a 256 colour chunky mode instead of a planar mode.

VGA chain4:

1address in plane:   0     1   2   3   4
2plane 0:          byte0 | x | x | x | byte4
3plane 1:          byte1 | x | x | x | byte5
4plane 2:          byte2 | x | x | x | byte6
5plane 3:          byte3 | x | x | x | byte7
6CPU addr:        0/1/2/3             4/5/6/7

EGA/VGA o/e:

1address in plane:   0     1     2     3   4
2plane 0/2:        byte0 | x | byte2 | x | byte4
3plane 1/3:        byte1 | x | byte3 | x | byte5
4CPU addr:          0/1         2/3       4/5

And bit "chain" in graphics controller/register 6 is bit more complex as it allows you to use these "x" (holes) in memory.