There's a BIOS function to set the CGA palette, Int 10/AH=0Bh/BH=01h. On actual CGA this just writes to the Color Select register at 3D9h, but EGA and VGA don't have this register - on these cards the same BIOS call works by setting the EGA/VGA-specific palette entries.

Most games just use the BIOS function, so they'll work, but some do write to the CGA's Color Select directly. This will fail on EGA/VGA, unless the card offers a specific compatibility program to expose this functionality as a 'register'. The CGA compatibility tester does the same (https://github.com/MobyGamer/CGACompatibility … er/CGACTEST.PAS) - after all, it wants to test compatibility. 😀

+1

I might add that this intentionally, as well.

In order to be 100% compatible with the IBM PS/2 Display Adapter (IBM VGA),
many third-party VGA/SVGA cards copied the limitations/bugs of it.

In order to gain CGA hardware compatibility, most of the early ISA VGA cards had a separate CGA emulation mode (via supplied mode utility).
It emulated the 6845 CRTC registers, the palettes and the blocky CGA font.

In addition, Hercules was often available as emulation, too.
That way, old programs such as AutoCAD 2.x could be made run correctly.
Example: Re: MS-DOS, S-100, hi-res graphics and AutoCAD ?

You can find some mode utilities here, though I'm not sure about Cirrus.:
Re: WD90C11 and AT&T Model 6300 video mode

Jo22 wrote on 2025-05-24, 00:26:

I'm not sure about Cirrus

I'm sure the 54xx series lacks CGA/Hercules compatibility modes.

VileR wrote on 2025-05-23, 18:59:

Most games just use the BIOS function, so they'll work, but some do write to the CGA's Color Select directly.

Want to add here: BurgerTime is one game like that. If you want to test it, go to [O]ptions and select RGB when it asks for your monitor type. When you start a new game, a true CGA should give you palette 0 (low intensity) with a blue background. On a typical EGA/VGA you'll get the default palette 1, like you're seeing in the compatibility test.

(Shots from Moby)

VileR wrote on 2025-05-23, 18:59:

There's a BIOS function to set the CGA palette, Int 10/AH=0Bh/BH=01h. On actual CGA this just writes to the Color Select register at 3D9h, but EGA and VGA don't have this register - on these cards the same BIOS call works by setting the EGA/VGA-specific palette entries.

Most games just use the BIOS function, so they'll work, but some do write to the CGA's Color Select directly. This will fail on EGA/VGA, unless the card offers a specific compatibility program to expose this functionality as a 'register'. The CGA compatibility tester does the same (https://github.com/MobyGamer/CGACompatibility … er/CGACTEST.PAS) - after all, it wants to test compatibility. 😀

That was enlightening and now everything makes sense, thank you.

So the BIOS call actually does something on (some) VGA cards, it sets colors -that was the missing link for me
And the Compatibility Tester (correctly) is not interested in showing if the user will see the palette, but looks for compatibility at the lower, register level.

Practically if someone just wants to see if a couple of games that he cares for will have the correct colors, it's better to run them all and find out.

konc wrote on 2025-05-24, 07:59:

So the BIOS call actually does something on (some) VGA cards, it sets colors -that was the missing link for me
And the Compatibility Tester (correctly) is not interested in showing if the user will see the palette, but looks for compatibility at the lower, register level.

Practically if someone just wants to see if a couple of games that he cares for will have the correct colors, it's better to run them all and find out.

Yes. The BIOS call should work on practically all cards - IBM decided that backward compatibility with CGA would be on the BIOS level, so their EGA/VGA video BIOS extensions modified this function to give the expected palettes, just using the new mechanisms under the hood. The usual exception is the alternate cyan/red/white (mode 5) palette, which shows up as palette 1.

Theoretically, on a 386+ in V86 mode (w/EMM386 or similar), one could write a chipset-independent "mode utility": trap accesses to the CGA-specific ports and translate them to standard VGA functions. Of course, many of these games will have a whole new bunch of issues running on a 386.

VileR wrote on 2025-05-24, 08:59:

Theoretically, on a 386+ in V86 mode (w/EMM386 or similar), one could write a chipset-independent "mode utility": trap accesses to the CGA-specific ports and translate them to standard VGA functions. Of course, many of these games will have a whole new bunch of issues running on a 386.

That reminds me of Windows/386, which has CGA "emulation" on higher end graphics cards, such as EGA/VGA.
It seems to support the alternate palette 0, at very least.
Not sure if's support on register level, though, I'm not familiar with that game.

Source: https://gunkies.org/wiki/Windows_2.0

What's also possible is supporting such things via external 286 MMUs, maybe. They were made to support EMS, but also could be used for multitasking OSes.
That would be useful, because an 6 MHz PC/AT might still be within the speed range of late CGA titles.

Sophisticated CGA games such as StarFlight (looks best via composite artifacts) were released in 1986 and afterwards, still.
That's two years past the release of IBM PC/AT.
The game also needs raw CPU power to calculate the 3D landing sequence in a smooth way.
On a stock IBM PC, that part is a slide show.

Anyway, a "modern" 386SX PC at 16 MHz still is slow enough to be on par with a 12 MHz 286 PC, so the V86 solution is more "real world compatible".
A 12 MHz 286 PC in turn was the state of ca. 1988-1989.
It was most popular 286, even, maybe, aside from later 16 MHz model. :)

The 10 MHz 286 clone PCs were more common between 1986-1988, I guess.
Which still were slower than the Compaq Deskpro 386,
which debuted in 1986 and had 16 MHz and some Static RAM to get away without a complex cache.

Speaking under correction, I'm rather thinking out loud here. Hope you don't mind.

Edit: What's also interesting: There was the IBM 8514/A graphics emulator for ET-4000AX cards.
It was shareware (?) and bundled with some driver disks of ET-4000 cards, I think.
So such emulation concepts were feasible not only in theory.

Jo22 wrote on 2025-05-24, 23:25:

Edit: What's also interesting: There was the IBM 8514/A graphics emulator for ET-4000AX cards.
It was shareware (?) and bundled with some driver disks of ET-4000 cards, I think.
So such emulation concepts were feasible not only in theory.

That emulator is called RIXAI does not emulate the hardware of the 8514/A, but just the software interface called the "adapter interface" (AI). On the original IBM 8514/A, this adapter interface was also provided by software. Think of it like a BIOS that is not in a ROM chip, but a loadable TSR. So this is just an example of driver level compatiblity, and not of hardware emulation. Think of it more like a VESA driver than like a harware emulator.

Yes, RIXAI allows to use the IBM8514.BGI driver from Borland Pascal 7.0, as it uses the AI API.
But can't run Windows 3.x with the 8514/A driver, as it accesses the hardware directly.

@mkarcher: Thank you for the info! I merely knew that this Mahjongg game used it..

Grzyb wrote on 2025-05-25, 07:56:

Yes, RIXAI allows to use the IBM8514.BGI driver from Borland Pascal 7.0, as it uses the AI API.
But can't run Windows 3.x with the 8514/A driver, as it accesses the hardware directly.

Hi, I'm not certain about the latter.
The Number Nine TIGA card that I have doesn't work with Windows 3.1's TIGA driver, either.
The Windows 3.1 TIGA driver works in tandem with the DOS TIGA driver, so it's more of a, um, "middleware" driver.
Not sure about 8514/A driver, though. Maybe it uses hardware access, maybe not. I'm not certain, at least. 🤷‍♂️

Jo22 wrote on 2025-05-25, 15:01:

Grzyb wrote on 2025-05-25, 07:56:

Yes, RIXAI allows to use the IBM8514.BGI driver from Borland Pascal 7.0, as it uses the AI API.
But can't run Windows 3.x with the 8514/A driver, as it accesses the hardware directly.

Hi, I'm not certain about the latter.

I am. The 8514/A driver is provided as source code in the Windows 3.x driver development kit. It does not use the AI, but accesses hardware directly.

mkarcher wrote on 2025-05-25, 15:06:

I am. The 8514/A driver is provided as source code in the Windows 3.x driver development kit. It does not use the AI, but accesses hardware directly.

Thanks for the info, that's good to know.

I wonder why, though, considering that Windows 3.0 still was more of an "graphical environment" than an OS (but 3.1x gravitated torwards that).

Someone should have thought it should try to use high-level access, use a form of abstraction,
whenever possible (such as DOS, BIOS, VGABIOS etc).

Doing direct hardware access, low-level access, is something that a real OS such as OS/2 should do, rather.
Since a real OS can't utilize DOS, and Real-Mode BIOS is tricky to access from Protected-Mode.

Jo22 wrote on 2025-05-25, 16:11:

I wonder why, though
[...]
Real-Mode BIOS is tricky to access from Protected-Mode.

You have pretty much answered your question...

Windows 3.x was designed for protected mode.
Calling any real mode services from protected mode is tricky, and reduces performance.
That's exactly why 8514/A is accessed directly, and not via AI.

It would be a good idea for Windows to access TIGA cards directly as well, but there was one problem: lack of single hardware standard.
Microsoft basically had three options:
- provide direct support for every TIGA card - too expensive!
- convince hardware vendors to provide direct support - but some cards were already out of market, and they were targetted primarily for CAD stuff, which didn't exist on Windows yet
- just do it via the TIGACD.EXE

Grzyb wrote on 2025-05-25, 16:57:

You have pretty much answered your question...

Um, by a "real OS" I was thinking of a OS/2 1.x in 16-Bit Protected-Mode, of course.
A clean OS, which doesn't rely on V86 or DOS.

By contrast, Windows/386 was all about V86. DOS VMs were all around all time.
Windows 3.0 had two different set of drivers, if you will.
Normal *.DRV drivers that run in 16-Bit world (real, PM) and virtual drivers, *.VXDs.
In 386 Enhanced-Mode, the 386 grabbers and virtual drivers can be used.

Windows 3.x uses DOS by default, to access files.
It can also use BIOS and a Protected-Mode HDD driver.
Swap file can be a file or a contingous "block" on HDD at fixed location, so that no filesystem-awareness is needed to access it (good for access without DOS).

Edit: Windows 3.x has a 16-Bit Protected-Mode Extender, DOSX.
So communications with DOS world was already implemented.
16-Bit OS/2 had a DOS "penality" box, admittedly. But there was no real DOS to take advantage of:
There were no DOS-based network drivers or drive compression running that should remain available.

Edit:

It would be a good idea for Windows to access TIGA cards directly as well, but there was one problem: lack of single hardware standard.

Hm. I don’t think that idea would have been wise, though, considering the IBM PGC clones that existed before.
Many clones/compatibles were compatible on language/interface level, but didn't use an 8086/8086 processor.
This in turn made certain applications failon clones/compatibles which could not execute x86 code (the PGC sprcs allowed natuve code execution).

Jo22 wrote on 2025-05-25, 17:19:

Normal *.DRV drivers that run in 16-Bit world (real, PM)

Exactly. The graphics driver for Windows 3.x is supposed to run in 16-bit protected mode (or possibly real mode in Windows 3.0). Getting from protected mode to real mode on a 286 system can take around a milliscond. If the real mode service accesses rotating media (no cache hit), this one millisecond is not that notable. On the other hand, if the real mode service instructs the 8514A to draw a single line, the millisecond is way too much time.

Some late windows 3.1 graphics driver put more functionality in the .386 grabber (which just is a VxD with a funny file name), and invoke the 32-bit protected mode from their 16-bit protected mode shim driver, but this is not how Microsoft intended that system to work. The 386 mode is still designed as a 32-bit Virtual Machine Monitor that runs one Windows VM and multiple DOS VMs, with the windows logic implemented in the 16-bit Windows VM.

Jo22 wrote on 2025-05-25, 17:19:

Windows 3.x uses DOS by default, to access files.
It can also use BIOS and a Protected-Mode HDD driver.
Swap file can be a file or a contingous "block" on HDD at fixed location, so that no filesystem-awareness is needed to access it (good for access without DOS).

It also makes a lot of sense the "swap file" is the first point Microsoft violated the design principle of "32-bit stuff is just for running multiple 16-bit VMs": The virtual memory management is one of the core tasks of the 32-bit virtual machine monitor, so any page fault is handled by that kernel, it helps performance if the complete page fault handling can be performed in 32-bit mode. Before WfW3.11 with its 32-bit file access, all file-level access went through V86 / real mode anyway, so it wouldn't make sense to use 32-bit VxD drivers for it.

Sorry if this is off topic, I’m working on a little project to implement my own mode setting code for a series of Matrox cards and the register values of mode 0 and 1, mode 2 and 3 and mode 4 and 5 are the same pairs. Looking at Ralf Brown’s interrupt list, it’s not really clear to me what the difference is supposed to be between these pairs of modes. Does anyone here know? Right now I only implement one of each (I don’t use mode numbers, but rather mode attributes to set modes, so they naturally merge together). I would love to bring those duplicates back with their distinct features enabled.

riplin wrote on 2025-05-25, 18:30:

Sorry if this is off topic, I’m working on a little project to implement my own mode setting code for a series of Matrox cards and the register values of mode 0 and 1, mode 2 and 3 and mode 4 and 5 are the same pairs. Looking at Ralf Brown’s interrupt list, it’s not really clear to me what the difference is supposed to be between these pairs of modes. Does anyone here know? Right now I only implement one of each (I don’t use mode numbers, but rather mode attributes to set modes, so they naturally merge together). I would love to bring those duplicates back with their distinct features enabled.

There's only a difference on CGA, and only in the composite output at that. One of each pair is in color, the other B&W. But with RGBI out, and on all later standards, there's absolutely no difference - the duplicate numbers were just retained for backward compatibility.

Ok, I could add B/W versions to my mode list so it’s still possible to use those modes in B/W.

Thanks for the info!

riplin wrote on 2025-05-25, 18:30:

Sorry if this is off topic, I’m working on a little project to implement my own mode setting code for a series of Matrox cards and the register values of mode 0 and 1, mode 2 and 3 and mode 4 and 5 are the same pairs. Looking at Ralf Brown’s interrupt list, it’s not really clear to me what the difference is supposed to be between these pairs of modes. Does anyone here know? Right now I only implement one of each (I don’t use mode numbers, but rather mode attributes to set modes, so they naturally merge together). I would love to bring those duplicates back with their distinct features enabled.

The difference between the "odd" and "even" CGA modes became obsolete as soon as people did no longer connect video monitors using composite cable to CGA cards. The idea is that the "color" modes 1, 3 and 4 are meant to produce a color image (including the color burst signal), while the "black/white" modes 0,2 and 5 are meant to produce a grayscale image. The modes 0, 2 and 5 disable the color burst generator on the CGA card. Mode 0,2 and 5 are meant to provide a sharper image without color fringing, while modes 1 and 4 are meant for composite color. Mode 3 is not meant for use with the composite output at all, and it produces a non-conforming color burst that doesn't work with all NTSC monitors.

Applications are expected to respond accordingly and only use grayscale colors in modes 0 and 2, while they may use all 16 colors in modes 1 and 3.

Mode 5 is quite interesting on CGA cards. While it is meant to provide a 4 shades of gray image on the composite output, it also provides and RGBI image on the monitor port, which is just a side effect, but happens to be arguably the "most pleasing" 3-color palette offered by the CGA card. The default palettes are background + cyan/magenta/white and background + red/green/yellow. So you either get two "strange" colors (cyan and magenta), or you lose access to white. In mode 5, the RGBI output uses backgroun + cyan/red/white. As this was an unwanted side-effect, this palette is not supported by EGA and VGA BIOSes.

If all you want to do is setting up something that doesn't care about composite output, it's perfectly fine to handle modes 0/1, modes 2/3 and modes 4/5 the same way.