IBM PC/XT EGA recreated in FPGA

Crossing into the video clock domain

The video subsystem runs on its own 28.636 MHz clock, so every I/O write to a video port crosses a clock boundary. That crossing is a posted write: the cycle is captured in the chipset domain, where it is synchronous and a single clock of IOW is enough to take it, and presented to the video side as a pulse of guaranteed minimum width and gap. A new I/O cycle arriving while one is still draining is held through the ready tree.

Reads cross the same boundary and have to come back, which takes two synchroniser stages out, the settled-bus qualifier, the decode, and two stages back — five to six chipset clocks. A free bus is not an answered read, so the crossing holds the CPU for the return trip as well, counted from the moment the read is presented to the video side rather than from when the CPU asserted: a read issued behind a draining write reaches the card late and has to be given the trip from there. At the three lower CPU speeds the bus cycle is longer than the trip and the hold never becomes the thing that ends it. At Max it is what stops the CPU latching the bus while the answer is still crossing, which is what corrupted palette reads and, through them, any software that fades by reading the palette back and scaling it.

The alternative — sampling the live bus and trusting the pulse to be wide enough — works comfortably at the three lower CPU speeds and fails at Max, where an I/O write can be four chipset clocks. Losing a CRTC index leaves the data byte that follows in whatever register the index last named, so the damage accumulates rather than showing up at once. Handling it by construction removes a whole class of speed-dependent faults instead of one symptom: rtl/video/TESTBENCH/ega_io_stretch_tb.sv drives two identical video instances, one through each style of crossing, and sweeps the natural phase drift of the two clocks.

Dual dot clock

A standard IBM EGA runs two dot clocks and selects between them from Miscellaneous Output bit 2: 14.318181 MHz for the 200-line CGA-compatible modes and 16.257 MHz for the 350-line and MDA-compatible ones. Both are implemented and switch per mode, rather than deriving everything from one fixed rate.

Horizontal Pel Panning

The Attribute Controller panning register (3C0h, index 13h) shifts the displayed image left within the character cell, which is what turns a byte-granular start address into smooth pixel-by-pixel scrolling. The core applies it to the finished dot stream, so text, graphics and the splash all go through one implementation, and it follows the same table 86Box derives in vid_ega.c: one step per register value in the 8-dot modes, doubled in the 320-wide modes so a step is one visible pixel, and the 9-dot text cell taking its aligned position at value 8 the way a real EGA does.

A panned line displays part of one more character than it fetches, so the fetch window carries one extra character past the end of the line, and the panning value is latched once per scanline rather than once per frame — that is what a per-scanline panning wave, a stock EGA effect, needs in order to work at all. rtl/video/TESTBENCH/ega_pan_split_tb.v checks the shift table, the extra fetch and the fact that the display window itself does not move against HSYNC.

Line Compare and split screen

The CRTC Line Compare register (18h, with bit 8 in the overflow register and bit 9 in Maximum Scan Line) names the last scanline drawn from the start address. The one after it restarts the display at address 0 with a fresh character row, which is how a status area stays pinned to the bottom of the screen while everything above it scrolls. The core follows the compare 86Box builds in ega_recalctimings and acts on it where ega_poll does, at the scanline boundary.

The register resets to 0FFh — the value the BIOS writes in every ordinary mode — because the compare is the register plus one, so a zero would split every frame at its second scanline.

Monitor profiles

An IBM EGA card carried a switch pack on its bracket telling the option ROM which display was attached. The core models it: the Hardware menu offers IBM 5154/ECD, IBM 5153/CGA and IBM 5151/MDA, and like the real card the setting is read while the machine is held in reset, so a change takes effect at the next boot rather than immediately.

The choice is not cosmetic. Selecting 5153/CGA makes the ROM build its 200-line, 8x8 text tables at 15.7 kHz, which is what a period CGA monitor or a television expects; 5151/MDA selects the 720x350 monochrome configuration and interprets the connector's Mono Video and Intensity pins as normal and bright white, leaving the separate display tint free to render it green or amber.

Driving a 15 kHz set

The 200-line EGA and CGA-compatible modes already scan at 15.7 kHz, which is exactly what a television wants. The core sends them out at that rate, so they reach a set over RGB/SCART the way the original hardware drove one, with VGA mode 13h retimed onto the same raster so a single pair of centring offsets covers everything.

The 350-line modes cannot do that: they scan at about 21.8 kHz, and MDA at 18.4, which no 15 kHz set will lock to. For those the core captures a whole frame into the board's DDR3 and rebuilds the raster from it, publishing only complete frames so a mode change landing mid-picture cannot show half of one frame and half of another. Two targets are offered from the OSD:

• 480i — a standard interlaced television frame, 15.73 kHz at 59.94 Hz. All 350 lines are shown, half in each field.
• 240p — a progressive 262-line frame at the same line rate. Steady, with no interlace flicker, at the cost of fitting 350 lines into 224.

Neither reaches the emulated hardware. The CRTC, the display enable and the retrace bits software polls behave identically whichever setting is chosen; this is the output stage only. Native output is the default and is untouched, for an enhanced display, a 5151, or the scaler.

Why it is called VGA and not MCGA

This extension was called MCGA until the behaviour it actually provides was pinned down. Real MCGA hardware does not implement EGA's 16-colour planar graphics modes (0Dh/0Eh/10h) at all, so an MCGA could never run the mode 0Dh gameplay this feature was built for. 86Box, whose video emulation this path is modelled on, has no MCGA code anywhere - even the one machine that historically shipped it is emulated as a VGA variant. What makes the target software work is the DAC augmenting the EGA modes plus mode 13h, which is VGA behaviour. The name was changed to match.

The DAC feeds every mode, not only 13h

This is the part that matters for real software. A game that detects a VGA, switches to a 16-colour mode for gameplay and then loads its palette through the DAC gets the palette it intended, instead of the stock EGA one. Titus the Fox and Prehistorik 2 both do exactly this, and it is why their title screens looked right while gameplay did not.

A single default table cannot serve both conventions at once - VGA attribute code 14h is brown, the EGA 200-line code 14h is light red - so each of the 256 entries carries a validity bit. Entries software never wrote fall back to the classic EGA palette, which is what keeps the extension-off path unchanged by construction.

Activation and output timing

VGA 13h+ starts disabled after reset. VGATSR.COM enables it through XTEGACTL before installing its INT 10h hook; a warm boot clears the extension again. The OSD's VGA 13h+ CRT choice is independent: it selects a conventional Native 31.5 kHz / 70 Hz raster or the 15.7 kHz / 59.9 Hz TV raster, but does not activate or remove the VGA device.

Should it stay off for EGA-only sessions?

For everyday use, loading the TSR doesn't break EGA software: in ega_top.v, ega_dac_hit only substitutes a palette entry when that specific DAC index was actually written by software (vga_dac_sample_valid), so an EGA game that never writes 3C7h–3C9h looks identical with the extension enabled or disabled, and VGATSR.COM chains every unrecognised INT 10h call straight through to the real BIOS.

But the bounded activation exists for a reason, and not loading the TSR is the right call when the goal is a machine that behaves and is detected as a real EGA with no VGA trace at all — which is why the ports are gated on the extension state rather than left decoding permanently:

• Port-level fingerprint. With the extension enabled, ports 3C7h–3C9h answer as a DAC even when no software ever calls the BIOS for one — a real IBM EGA doesn't decode those ports at all, its palette lives in the attribute controller. Software that fingerprints hardware by probing I/O ports directly, rather than through INT 10h, can see that and conclude a VGA is present. Leaving the extension disabled closes those ports, so the card answers exactly as an EGA should to a port probe as much as to a BIOS call.
• BIOS-level fidelity. With VGATSR.COM resident, INT 10h AH=12h/BL=10h (“Return EGA information”, a standard EGA call, not a VGA-only one) is answered by the TSR with a fixed value instead of being chained to the loaded EGA BIOS ROM. Not loading the TSR means every EGA BIOS call gets exactly what that ROM would answer, with nothing intercepted.

So: fine to load VGATSR for normal play, but omit it when the goal is specifically authentic, untraceable EGA behaviour — testing against real hardware, for example, or running EGA-only software with nothing else in the picture.

Features enabled in config.tcl

Core-specific MiSTer.ini example for 31 kHz analogue output

[PCXT-EGA]
vga_scaler=1
video_mode=6
vsync_adjust=2

The section applies only to this core. Mode 6 is MiSTer's built-in 640x480 preset; use vsync_adjust=1 if a flat panel rejects the core-following refresh, and leave vga_scaler disabled for direct 15 kHz output.

MiSTer port and continued project development by spark2k06, built on important contributions from the FPGA recreation and classic PC preservation community.

The 8088 CPU comes from the MCL86 project by MicroCoreLabs, in the rewrite contributed by Boogermann, and the chipset from KFPC-XT by kitune-san. The EGA and VGA 13h+ behaviour is modelled on the video emulation in 86Box. AdLib sound uses JTOPL by Jose Tejada, and the MIDI path reuses the mt32-pi bridge by Sorgelig and Kitrinx that ships with the MiSTer framework. Earlier releases used the Graphics Gremlin CGA and Hercules adapters by TubeTimeUS, since replaced by the EGA path. Splash artwork by mills32.

The repository is licensed under the GNU General Public License, version 3. Redistribution and modification must comply with that licence and the terms that apply to the integrated components.