Running VESA Local Bus Graphics in MS-DOS 6.22

This article explains how MS-DOS 6.22 executes software requiring VESA Local Bus (VLB) graphics modes. Because MS-DOS lacks an integrated graphics subsystem or a modern hardware abstraction layer, running these modes relies on the cooperation between the operating system's execution environment, the VESA BIOS Extensions (VBE) standard, DOS memory extenders, and the direct hardware architecture of the VLB interface.

The Role of MS-DOS 6.22 as a Program Launcher

MS-DOS 6.22 operates primarily as a 16-bit real-mode operating system. It does not actively process, translate, or render graphics commands. When an executable requiring advanced graphics is invoked, MS-DOS allocates conventional memory, loads the binary into RAM, and hands full execution control over to the program.

From that moment forward, the operating system steps aside. MS-DOS provides standard system interrupts for file input/output and basic character output, but it delegates all display management directly to the application and the system BIOS.

The VESA BIOS Extensions (VBE) Interface

To standardize graphics programming across diverse hardware manufacturers, the Video Electronics Standards Association established the VESA BIOS Extensions (VBE). Instead of requiring developers to write custom drivers for every graphics chipset, VBE provides a uniform software API accessed via system firmware interrupt INT 10h.

When an application requests a VESA graphics mode under MS-DOS 6.22, the process proceeds as follows:

  1. Detection and Capabilities Query: The program calls INT 10h, AX=4F00h to retrieve the VBE Controller Information block. This verifies whether the video card supports VBE and checks which version is implemented.
  2. Mode Information: The program calls INT 10h, AX=4F01h along with a specific mode number to query resolution, color depth, and memory layout parameters.
  3. Mode Initialization: The software initiates the desired video mode using INT 10h, AX=4F02h. The video card’s onboard BIOS configures the digital-to-analog converter (DAC) and the graphics controller registers accordingly.

If a video card’s onboard ROM lacks native VBE support (or contains a buggy implementation), users load a Terminate-and-Stay-Resident (TSR) utility—such as UniVBE—in their AUTOEXEC.BAT or CONFIG.SYS. This TSR intercepts INT 10h calls in memory and provides the missing translation layer between the software and the physical graphics processor.

VESA Local Bus (VLB) Hardware Integration

The VESA Local Bus is a 32-bit hardware bus standard tied directly to the 80486 processor's local bus. Unlike the older 16-bit ISA bus, which ran at roughly 8 MHz and severely bottlenecked video throughput, VLB operates synchronously with the CPU bus clock—typically 33 MHz—providing data throughput up to 132 MB/s.

MS-DOS does not need special drivers to enable VLB capabilities. The motherboard chipset and the CPU handle the bus interface at the physical hardware layer:

  • When the CPU issues read or write instructions to the physical memory addresses reserved for video memory, the memory controller routes these cycles directly across the VLB slots.
  • The VLB graphics card claims these memory cycles with minimal wait states, allowing high-speed pixel manipulation.

Memory Access: Bank Switching and Linear Frame Buffers

High-resolution VESA modes require significantly more memory than the standard 64 KB real-mode video aperture (located at segment A000h in conventional DOS memory). Software running under MS-DOS 6.22 handles this in one of two ways:

  • Bank Switching (VBE 1.2): Real-mode applications access large frame buffers in 64 KB windows. The software calls INT 10h, AX=4F05h to swap banks within video memory as it renders pixels. While functionally compatible with 16-bit real mode, bank switching incurs software overhead.
  • Linear Frame Buffers (VBE 2.0+): Advanced DOS applications use 32-bit protected-mode DOS extenders (such as DOS/4GW, PMODE/W, or Causeway). The DOS extender switches the CPU into protected mode, allowing the application to map the video card's entire multi-megabyte frame buffer directly into a single, continuous 32-bit flat address space. Data is then written directly to the VLB card at native bus speeds without requiring interrupt-based bank switching.