CGA graphics mode (INT 0x10, AX=0x0004)

[Antti]

I have been looking for a reliable graphics mode that could be used before stepping into the world of VBE. I want to have a boot GUI for selecting boot settings, VBE graphics modes, etc. Prototypes look quite nice using this 320x200 mode. At some point I would like to use my boot code on very old hardware so I am likely to choose this video mode. It looks like it is the most supported graphics mode.

Now the question: do I find a modern BIOS-based computer with a graphic card that does not support setting this video mode? Would the VGA mode ("0x12") be more realiable on modern hardware? All the few computers I tested this on have worked.

[tom9876543]

I would aim for minimum specs of Pentium II (with FXSAVE and FXRSTOR) + VGA. This also allows you to make other assumptions eg BIOS has E820 memory map.
If you want to support hardware that is ancient, obsolete and with absolutely terrible performance..... that is your choice I guess.

[Combuster]

The problem is that you can't exhaustively test all modern graphics hardware. The most likely thing you'll see are headless machines, or anything that's not even close to VGA where it doesn't matter if you used mode 4, 12 or 13 because none of them work (and probably, neither does VBE).

But then again, I don't bother with anything 16-bit, which means VGA already is the baseline standard. And in that regard, mode 0x13 might be safer than 0x12 on shabby implementations because it's a LFB mode with no need for port I/O

[Antti]

If you want to support hardware that is ancient, obsolete and with absolutely terrible performance..... that is your choice I guess.

We can compare this to the default text mode. Instead of using the text mode, I would choose using graphics mode from the very beginning. I think using a pixel-addressable mode is more advanced anyway. If I set up a CGA graphics mode, it does not mean it has terrible performance. Also, it does not mean that supporting the CGA is the main goal in itself. I am trying to find a video mode that is the most reliable one. Of course, it would be a nice extra feature if that worked on really old hardware. We are talking about boot code here and the OS might have very high system requirements.

And in that regard, mode 0x13 might be safer than 0x12 on shabby implementations because it's a LFB mode with no need for port I/O

Exactly. That is something I like when using mode 0x04 too. So the question is whether the 0x04 or 0x13 would be more reliable.

[Combuster]

The problem is basically, I don't have any personal cases (except for one strictly non-VGA device) where one mode doesn't work while the other does. Many of the DOS games used mode 13 or even Mode X for the epic graphics, Windows used mode 12 whenever it lacked a better driver. I haven't personally tested mode 4 to the extent that I would claim mastery over it - I simply assume register-level VGA compatibility which means that mode 13 and mode 12 are pretty much always the superior alternatives.

It is only when you look in the details that you find discrepancies in hardware implementations, but they only appear on borderline usages. There are some hinted cases that the EGA palette in the early days of clones had compatibility issues, but that's also rather specific and not something you're going to get close to if you're using INT 10 to set modes. And it's also very likely that all the manufacturers have a stock VGA core they just stick in the 1% of their GPU dies where all the errors have long been filtered out from, so things are unlikely to change as well and modes 12/13 stay safe as long as the standard itself is.

Bottom line, you will need to ask the grandmasters of old to find out what the "broken" devices were, but even then there's no officially conclusive statement to make on this.

[Octocontrabass]

I am trying to find a video mode that is the most reliable one. Of course, it would be a nice extra feature if that worked on really old hardware.

Use the mode given to you by the BIOS, it's the most reliable and it'll work on the oldest PCs out there.

Otherwise, I wouldn't worry too much about it. RBIL covers most of the quirks you might run into running on really old hardware, and it doesn't mention any cards that aren't compatible with that mode when they claim to be CGA/EGA/VGA-compatible.

[Antti]

The main thing is to have a graphics mode that works, i.e. a user can see something. It is not so easy to use a VBE video mode and be sure that it really works. Or would it be better to set a VBE mode, like 640x480x??, and hope that it really works? And if VBE is not supported, then try the CGA mode.

Use the mode given to you by the BIOS, it's the most reliable and it'll work on the oldest PCs out there.

This is the cruel truth. Let just assume that the text mode is not an option.

[Octocontrabass]

It is not so easy to use a VBE video mode and be sure that it really works.

That's because VBE doesn't guarantee that a particular mode will be supported by either the display or the video card.

What exactly is your concern? Which part of getting pixels from your code to the user's eyeballs is worrying you?

[alexfru]

Since the modern Windows (8+ or 7+?) doesn't require nor can expect the existence of the regilar BIOS or a particular mode/resolution to be supported by the hardware (there can be EFI + a tiny display of a portable device), there are already devices that won't work in all old modes one may be used to and there will be more of them in the future.

[Antti]

Computers that support UEFI are not a problem. I will have a UEFI support for them and it works differently. Also, I am not worrying about old hardware. Mode 0x04 is supported widely enough on old hardware because there are a lot of games using it.

What I am worrying about are modern BIOS-based computers (without UEFI).

[Brendan]

Hi,

The main thing is to have a graphics mode that works, i.e. a user can see something. It is not so easy to use a VBE video mode and be sure that it really works. Or would it be better to set a VBE mode, like 640x480x??, and hope that it really works? And if VBE is not supported, then try the CGA mode.

What matters most isn't the video mode, but the video mode timings. Mode 4 is 320*200 (from software's perspective), but the video card will send each pixel twice and send each row twice, and (assuming VGA signals) colour is analogue. Because of this there's no difference (from the monitor's perspective) between mode 4 and a 640*400 mode with 16 million colours.

Also note that VESA have defined a pair of "safe video mode timings" that all normal monitors are meant to support (as legacy fallback modes). These are 640*480 and 720*480; however the standard also says that the vertical resolution for both of them can be varied from 400 to 480. It's not a coincidence that these 2 safe mode timings cover all of the video modes that VGA generated. Note: All modes with a horizontal resolution of 360 or less use "double width pixels", and all modes that use a vertical resolution of 240 or less use "double height pixels".

Mostly what I'm saying here is that if you can't get EDID from the monitor it should still be safe to use the "safe mode timings", which includes any video modes where the horizontal resolution is 320, 360, 640 or 720 and the vertical resolution is anything from 200 to 240 or from 400 to 480, regardless of number of colours.


Cheers,

Brendan

[alexfru]

What matters most isn't the video mode, but the video mode timings. Mode 4 is 320*200 (from software's perspective), but the video card will send each pixel twice and send each row twice, and (assuming VGA signals) colour is analogue. Because of this there's no difference (from the monitor's perspective) between mode 4 and a 640*400 mode with 16 million colours.

[timing] which reminds me of the experience with my VGA driver I once had. So, some years ago I wrote a basic window manager (or a foundation for one) and decided to run it in a VGA mode, 640x480x4bpp, to be exact. The thing worked:

but it seemed rather slow. My measurements showed something like 25 or 30 frames per second max. Then I looked at the code and tried to optimize it a bit, obviously the VGA-specific portion of it was somehow slow. In the end it turned out that no matter how good my code was, the CPU simply burned cycles in some wait states (I think, it's those related to the port I/O) while communicating with the video card. Bummer. In the end I switched off redrawing of windows while they're dragged or made it optional (don't remember), so only a window frame moves along with the mouse movements and you have to stop dragging (for a second) for the window contents to redraw.

[Nable]

but it seemed rather slow. My measurements showed something like 25 or 30 frames per second max. Then I looked at the code and tried to optimize it a bit, obviously the VGA-specific portion of it was somehow slow.

Maybe I'm talking about too obvious things but I think I should write it.
Drawing everything in RAM, then copying the changed part^W rects to video RAM might help. At least, one shouldn't ever try reading from video memory - it's a very slow operation.
Write-combination cache is also an interesting thing to note (did you setup MTRRs?).

[alexfru]

Maybe I'm talking about too obvious things but I think I should write it.
Drawing everything in RAM, then copying the changed part^W rects to video RAM might help. At least, one shouldn't ever try reading from video memory - it's a very slow operation.

That didn't help. The maximum rate is from updating the entire screen from memory optimally (minimum port I/O and bit manipulations in the process).

[Brendan]

Hi,

My measurements showed something like 25 or 30 frames per second max. Then I looked at the code and tried to optimize it a bit, obviously the VGA-specific portion of it was somehow slow. In the end it turned out that no matter how good my code was, the CPU simply burned cycles in some wait states (I think, it's those related to the port I/O) while communicating with the video card.

There's several ways to do 16-colour "planar" graphics modes. The smart way is to enable one plane, write everything you have to in that plane, then enable the next plane, etc. The downside here is that you need four "1 bit per pixel" buffers; but the advantage is that you only use 4 IO port writes to update the entire screen.

All the other ways are very very bad (and involve thousands of IO port writes).


Cheers,

Brendan