VOGONS


First post, by Jinxter

User metadata
Rank Member
Rank
Member

I've been working on a DOS TSR called **CGA2VGA** that gives CGA composite games 16 colors on any VGA system. I thought I'd share it here and see if anyone has ideas on the problems I've hit.

### The goal

I know that many games designed for CGA composite also have EGA or VGA modes — those are obviously better off using their native support. The goal here is specifically for games that are **CGA-only** or **CGA composite-only** — games like Hard Hat Mack, Bruce Lee, and many others that have no EGA or VGA option at all. For these games, CGA composite was the best display option available at the time. On a VGA system without a composite output, you're stuck with 4 RGBI colors.

To be clear: the goal is **not** to mimic how these games look on a CRT composite display — no blurring, no blending, no NTSC simulation. The goal is to provide a clean, **pixel-perfect 16-color display** on VGA, even though the games were never designed for it. Each CGA nibble maps directly to one of 16 colors. It's a reinterpretation, not an emulation.

### How it works

The idea comes from the Olivetti Prodest PC1, which has a V6355D video chip that mirrors the CGA framebuffer and reinterprets each nibble as a 16-color palette index — giving CGA games 16 colors with zero CPU overhead. My TSR does the same thing in software:

- Hooks INT 10h to intercept CGA mode sets (modes 4, 5, and 6)
- Sets VGA Mode 13h behind the scenes
- On every INT 08h tick (~18.2 Hz), converts the CGA framebuffer at B800h to VGA pixels at A000h using a 256-entry lookup table
- Each CGA byte is split into two nibbles, each nibble maps to one of 16 colors
- Graphics Controller register 6 is set to 128K memory map so both A000h and B800h are accessible simultaneously
- CRTC registers are saved at Mode 13h setup and restored every frame, because CGA games reprogram them directly

It includes four palettes (two curated, two reference — based on reenigne's composite model and Nerdly Pleasures' artifact color chart), auto-selected by video mode. Hotkeys let you switch palettes and toggle VSync on the fly.

Requires a 386+ with VGA. Written in NASM, builds to a 3.3KB .COM file.

### What works

Tested on real hardware:

- **West PC** (386-40, Trident TVGA 9000B ISA) — Planet X3, Hard Hat Mack, Flight Simulator 3, King's Quest 1 & 2, Zak McKracken, Bruce Lee, Frogger 2, NM-Pinball all work
- **WIC PC** (Pentium 200 MMX, ATI Mach 64 PCI) — all of the above plus Commander Keen 4, Battle Chess
- **IBM ThinkPad i1411** (NeoMagic NM2160) — Planet X3, Hard Hat Mack, Bruce Lee, King's Quest 1, Tapper

Zak McKracken, Bruce Lee, and the Sierra AGI games are probably the best results — they look like they were meant to have 16 colors.

### Problems I haven't been able to solve

**1. Games that bypass INT 10h**
Ms. Pac-Man and California Games crash. They set the video mode using direct port I/O instead of INT 10h, so the TSR never gets a chance to set up Mode 13h. Is there a practical way to detect CGA mode sets that go around the BIOS? I've considered hooking the CGA register ports, but that seems impractical without V86 mode or a hardware trap.

**2. Cirrus Logic VLB cards**
Both the CL-GD5424 and CL-GD5428 show a garbled display. The problem is that I set GC register 6 to 00h (128K memory map) so that both A000h and B800h are visible. Cirrus's display engine apparently can't render chain-4 Mode 13h correctly with that memory map setting. Has anyone dealt with this? Is there a Cirrus-specific workaround, or is this just a hardware limitation?

**3. Stuttering**
Even with VSync waiting before each frame conversion, some games show visible stutter. The conversion itself takes a measurable chunk of time (~20ms on a 386), and if it overlaps with the game updating the CGA framebuffer, you get tearing or partial frames. I'm not sure if there's a better synchronization approach.

**4. Boulder Dash (and probably others)**
Black screen, but music plays. I suspect it uses a non-standard VRAM layout. Anyone know the details of how Boulder Dash organizes its video memory?

### Source and screenshots

Everything is on GitHub with real hardware screenshots:
https://github.com/RetroErik/CGA-Composite-to-VGA

Any input, ideas, or testing on different hardware would be very welcome. C

Check out my YouTube channel: Retro Erik https://www.youtube.com/c/RetroErik
My collection: https://retro.hageseter.com
X: https://x.com/Retro_Erik

Reply 1 of 6, by middlenibble

User metadata
Rank Newbie
Rank
Newbie

Nice idea and implementation. Re: Games that bypass INT 10h: how about listening for a key combination and let the user enable the tool once they think it's safe?

Reply 2 of 6, by mkarcher

User metadata
Rank l33t
Rank
l33t

You might try unsetting the 256-color bit in the attribute controller after initializing mode 13h. As far as I know, some cards will provide the dual-nibble two-pixel format that way. Internally, there is only a 4-bit channel between the shift registers and the attribute controller on the original VGA, so the 8-bit color value has to be passed as two nibbles in some way. If you are unlucky, the order of the pixels if wrong, though. AFAIK there is no "standardized" order, as this configuration ("serialize as 256 colors" but "parse as 16 colors") is not intended to be used by applications. This can avoid the software conversion process if it works.

Reply 3 of 6, by zyzzle

User metadata
Rank Member
Rank
Member

Outstanding utility. It gives new life to old CGA games on new DOS systems. I'm surprised no one had coded a program like this before. Thanks for coding it.

Actually, there was a similar program called StarEmu written in 1996 which was intended as a TSR for the DOS game Starflight, but it works on many other CGA games to convert to composite 16-color on VGA systems. It has a manual toggle function.

I think mkarcher's advice is on target. Unsetting the 256 color bit may increase compatibility with your program.

Reply 4 of 6, by marxveix

User metadata
Rank Oldbie
Rank
Oldbie

Thank you for this CGA2VGA TSR Tool! Even if i am usually not playing that old games, its good to know that it works with Mach64, hope it works with newer Mach64 based (Rage2 and Rage3) cards as well.
I did try your tool with ati-264vt2 pci, rage2 pci, rage2c agp,ragepro and rage xl agp, all have errors, tested one game, brucelee, also i did try m64vbe.com (ati 64vbe221.exe,version 2.21) to change settings.
I do not have older ATi graphics cards for PCI, also in your package there is smaller and bigger CGA2VGA file, whats the difference and maybe i do not know how to use it? Without CGA2VGA game is working.

PCI MACH64 VT : https://theretroweb.com/expansioncards/s/ati-mach64-vt2
VESA Driver https://vogonsdrivers.com/getfile.php?fileid= … 238&menustate=0

Best ATi Rage3 drivers for 3DCIF / Direct3D / OpenGL / DVD : ATi RagePro drivers and software
30+MiniGL / OpenGL Win 9x dll files for all ATi Rage3 cards : Re: ATi RagePro OpenGL files

Reply 5 of 6, by marxveix

User metadata
Rank Oldbie
Rank
Oldbie
zyzzle wrote on 2026-04-23, 23:48:

Actually, there was a similar program called StarEmu written in 1996 which was intended as a TSR for the DOS game Starflight, but it works on many other CGA games to convert to composite 16-color on VGA systems. It has a manual toggle function.

Staremu worked better, but not perfect on brucelee and later ati cards. F12 makes screen colors visible and items on screen are in correct place, but it jumps back to colorless state at some time.

CGA2VGA shows only partly whats on screen and whats not on my Slot1 Celeron PC and newer ATi cards.

Best ATi Rage3 drivers for 3DCIF / Direct3D / OpenGL / DVD : ATi RagePro drivers and software
30+MiniGL / OpenGL Win 9x dll files for all ATi Rage3 cards : Re: ATi RagePro OpenGL files

Reply 6 of 6, by MagefromAntares

User metadata
Rank Newbie
Rank
Newbie

Very nice utility! I have been already thinking about joining this forum, but this TSR had made me finally decide to join 😀

About the problem with Boulder Dash, unfortunately I currently don't have any version of it installed, but if I recall correctly it was originally a booter game, and versions for DOS was only released later. Booter games did a lot of stuff that games written originally for DOS didn't as they assumed to have an even more direct control over the machine, so aside the possibility of non-standard VRAM layout (Which is possible, but I don't remember that much graphical trickery from that game), I would also investigate the possibility of that game somehow knocking out the TSR, most likely by reconfiguring interrupts, timers or overwriting fully or partly the TSR in memory.