VGA's memory layout has less overhead than CGA's, afaik.

It could be that VGA mode 13h (320x200x256c) is actually more efficient than CGA mode 04h (320x200x4c).

Personally, I'm curious about a test on real hardware.
With both a real CGA and a real VGA card.
Would be interesting how both perform.

Especially, how a real IBM CGA card compares to..
a) a real IBM VGA in CGA graphics mode
a) an VGA/SVGA card in CGA graphics mode, while in VGA native mode
b) an VGA/SVGA card in CGA graphics mode, while in CGA emulation mode (via mode utility).

Edit: I forgot. Mode 13h is an MCGA mode, strictly speaking. So it's a fair comparison, since CGA and Multi-CGA are step sisters, kind of. 😉

Jo22 wrote on 2022-09-27, 19:00:

VGA's memory layout has less overhead than CGA's, afaik.

It could be that VGA mode 13h (320x200x256c) is actually more efficient than CGA mode 04h (320x200x4c).

The discussion whether that mode is an MCGA or a VGA mode doesn't add much value, so leave it aside. We know one thing for sure: 256 colors means 8 bits per pixels, and 4 colors means 2 bits per pixel. That means you have to shove 4 times as much data over the ISA bus to change the same number of pixels. Bus cycles are slow. But this kind of consideration only works when you need to modify larger blocks of pixels, so being able to write 4 pixels at once using a single byte write is an advantage. It won't help you if you want to modify single pixels. For writing single pixels, mode 13h is perfectly suited, as the pixel bit count maps perfectly to the bus size of the PC/XT. For games rendering a scene pixel-by-pixel, most work is done determining the color of the pixel, which is equally complicated whether we run in mode 4 or mode 13, but building a byte out of four pixels is slightly more complicated than just storing the four pixels into video RAM, so mode 13h is likely better.

For games that blit sprites to the screen, especially if transparency isn't required because the background color is known to be black, CGA might be at a big advantage. You just MOVSW one or two words from sprite data into screen space to write 8 or 16 pixels. If you need pixel precision, just store four copies of the sprite in the game data. You can slightly vary the images to create an animation for the moving sprite consisting of four frames. So if you design your game in a way that you seldomly have to merge seperately calculated pixels, CGA modes can be a big win. Actually, this might even apply to 3D rendered games, if the rendering consists of solid colored polygons: You render a polygon by drawing horizontal lines. In mode 13h, drawing a solid horizontal line requires a byte write per pixel. In mode 4, drawing a horizontal line is more complicated at the start and the end, but drawing the bulk if line allows you to draw four pixel with a single write. Big polygons are quicker drawn in mode 4, small polygons are quicker drawn in mode 13h.

Bottom line: don't expect a CGA edition of Wolfenstein 3D to beat the VGA edition, but I played Stunts 4D sports driving in CGA mode on my 386 machine to get a better frame rate than I would get in VGA/MCGA mode.

Afaik, IBM's CGA (the card, I mean, most of all) is (was) dog slow, for various reasons.
It's even a bottleneck for a 286/386 system, not all to different to HGC.
For example, the 'Set Pixel' function of the PC BIOS was infamous for being slow.
It would be interesting to see how an equivalent on a VGA BIOS would perform.

Edit: A test with real hardware would be interesting, I think.
I'm not just referring to CGA/MCGA modes, but also how VGA cards do perform CGA mode 04h in both native mode and CGA emulation mode. In comparison to a real IBM CGA card.

Edit: Please let me explain, why I'm saying this.
Third-party VGA/SVGA cards don't use or emulate a Motorola CRTC in native mode.
However, they may partially do in CGA emulation mode.
Second, the VGA BIOS is in control in native mode. Maybe in emulation mode still, too.
In emulation mode (locked), after a reset, the PC BIOS may be in control for the CGA routines, if the VGA still pretends to be a CGA.

Jo22 wrote on 2022-09-27, 20:13:

Afaik, IBM's CGA is (was) dog slow, for various reasons.

That's true indeed. The reasons include PCB space and cost. There were no integrated custom chips specifically designed for the CGA. The only chip more advanced than simple TTL logic on the CGA is the 6845 CRTC. The complete memory arbitration is done using DIP 74xx series logic chips. For the IBM PC, the speed of CGA memory access was not stellar, but usually not the bottleneck.

Jo22 wrote on 2022-09-27, 20:13:

It's even a bottleneck for a 286/386 system, not all to different to HGC.

For sure. As that card is just fast enough to not be a bottoleneck for the 5150 in most scenarios, it is slow enough to be a bottleneck on all faster systems. The EGA card is not significantly faster in CGA modes.

Jo22 wrote on 2022-09-27, 20:13:

For example, the 'Set Pixel' function of the PC BIOS was infamous for being slow.

If you use a BIOS or operating system API call for setting lots individual pixels, you might get some bonus points for hardware abstraction, but you already gave up on performance. Especially in CGA graphics mode, setting single pixels is nearly always the wrong way to go. If at all possible, write 4 pixels (one byte) at once. The issue with the IBM BIOS is that the only graphics primitiv it offers is "set pixel", so you are forced to ignore the BIOS and access the video RAM directly from your application.

Jo22 wrote on 2022-09-27, 20:13:

It would be interesting to see how an equivalent on a VGA BIOS would perform.

Possibly a lot better, but still far from good for the general reasons pointed out above. One BIOS call per pixel is never going to cut it. As SetPixel is a function often benchmarked, EGA/VGA BIOSes often have a "fast path" that handles this function as efficiently as possible (slowing all other functions down slightly). Furthermore, AT-style VGA compatible cards can offer 16-bit access to the BIOS which is way faster than the BIOS access time an the original PC.

Jo22 wrote on 2022-09-27, 20:13:

I'm not just referring to CGA/MCGA modes, but also how VGA cards do perform CGA mode 04h in both native mode and CGA emulation mode. In comparison to a real IBM CGA card.

Don't bother with benching the difference between native and CGA emulation mode. The emulation mode only affects I/O access to graphics control register (CRTC, Mode register, Color register), but doesn't interfere with memory access. I expect early 8-bit VGA cards to provide up to twice the raw performance of the IBM CGA, and advanced 16-bit cards with write buffers and page mode memory access (like the ET4000) can be up to 20 times as fast as the CGA card when writing to screen memory. (Or even faster if you clock the ISA bus higher than 8MHz).

mkarcher wrote on 2022-09-27, 18:47:

For some games, low performance doesn't make the game unplayable, but just slightly more tedious. I'm thinking about early LucasArts adventures like Monkey Island (original 16-color edition) for example. This game supports AdLib sound, was distributed on 8 360KB floppies and should run at an acceptable speed on the PC/XT.

In the interest of science, I just tested King's Quest IV on my Tandy 1000 HX running @ 4.77 MhZ.

This is I believe the first Sierra game that would have supported Adlib (although mine is using Tandy 3 channel sound) and probably one of the earliest games in general to support it.

Loading time between scenes is noticeably slow. Movement is okay as long as no other animations are occurring on the screen. But the moment other animations are happening, things slow down considerably.

I would describe it as moderately playable, but not particularly enjoyable. This game really needs a 286 to shine. I imagine other adventure games of that era would be the same.

t that point, I consider a VGA and an AdLib card in an 5150 similar: It's mildly challenging and tedious to find software that makes good use of the card in a system like that, but if you do find such software, it can feel rewarding.

I get that. It can be fun to trick out and push the limits of old hardware.

Though OP has stated they want to use this for an actual gaming machine. Which is a different set of goals. The latter involves working within the limitations of the hardware and using it for stuff that is actually playable.

Shponglefan wrote on 2022-09-27, 21:04:

Though OP has stated they want to use this for an actual gaming machine. Which is a different set of goals. The latter involves working within the limitations of the hardware and using it for stuff that is actually playable.

At this point, I'll be happy if the thing turns on after I recap it.

Lylat1an wrote on 2022-09-27, 21:27:

At this point, I'll be happy if the thing turns on after I recap it.

It's actually very rewarding to play around with an IBM PC and its basic CGA graphics. The best part about CGA is that the games are perfectly playable using the composite video output because all you need is a regular television set, no special monitor required. And some of the games were even specifically designed to be played on a television set because they use "artifact colours". Plus, it's the original IBM PC games that are hardest to play on a more modern DOS machine: they assume a fixed 4.77mhz CPU speed, often come as "booter" games that don't even use DOS, and play tricks with the CGA hardware that most EGA/VGA cards can't emulate.

kdr wrote on 2022-09-29, 04:49:

Lylat1an wrote on 2022-09-27, 21:27:

At this point, I'll be happy if the thing turns on after I recap it.

It's actually very rewarding to play around with an IBM PC and its basic CGA graphics. The best part about CGA is that the games are perfectly playable using the composite video output because all you need is a regular television set, no special monitor required. And some of the games were even specifically designed to be played on a television set because they use "artifact colours". Plus, it's the original IBM PC games that are hardest to play on a more modern DOS machine: they assume a fixed 4.77mhz CPU speed, often come as "booter" games that don't even use DOS, and play tricks with the CGA hardware that most EGA/VGA cards can't emulate.

I second this, that's why I'm using both CGA and Hercules in my Nixdorf 8810 M35.
The Hercules is nice for professional applications like Windows 3.0,
while CGA is useful for games and simple applications without Hercules support.
That being said, I'm using monochrome monitors for both. 😁
The monochrome output with CGA is so much more eye-friendly. 😉

Anyway, if you're interested in a nice artifact experience, please consider two things.

a) There's Composite CGA in the form of hacked low-res text-modes (160x120 or something) and there are artifact colors.

Artifact colors are an NTSC thing and not bound to CGA's video modes.
These artifact patterns would work with VGA, too, if VGA was outputting to an NTSC TV.
The Apple II used artifacts, too. Which is fascinating, because the European model allowed artifact colours on PAL monitors, somehow!
The PAL versions had some extra chips installed for conversion.

b) Video output to a real TV via RF cable (VHF/UHF) might make low-res graphics more natural.
So if you've got an RF modulator or an old VCR lying around..
It's worth using it to convert composite video to RF.
That way, you can try out a real 1960s/1970s NTSC TV.
As it was used in the Atari 2600 and pong era.
Seriously, an RF connection doesn't need to be fuzzy and grainy. If the RF modulator is stable (it is, in a VCR) and if the TV has an AGC..

Here's an example (PAL system, though).
It's blurry/filtered, but less ugly/fuzzy than the average composite video also:

Source: Re: Amstrad Mega PC

@mkarcher Thanks a lot for taking your time for replying and your excellent explanation.
Not all people do respond so respectfully, also. Kudos to you. 🙂👍