VESA BIOS Extensions
VESA BIOS Extensions (VBE) is a software standard developed by the Video Electronics Standards Association (VESA) to extend the capabilities of the VGA ROM BIOS, enabling applications and operating systems to access advanced features of Super VGA (SVGA) graphics controllers, such as higher resolutions, deeper color depths, and linear frame buffer modes beyond the limitations of standard VGA.[1] Introduced in 1989 with version 1.0, VBE provides a device-independent interface that abstracts hardware-specific details, allowing developers to write portable code for diverse video hardware without needing manufacturer-specific drivers.[1][2] The standard evolved through several versions—1.1 and 1.2 in the early 1990s, 2.0 in 1994 adding support for protected-mode operations and flat frame buffers, and 3.0 in 1998 incorporating enhancements like stereoscopic display support and improved refresh rate control—to address the growing complexity and variety of PC graphics hardware during the rise of multimedia computing.[1][3] Key functionalities of VBE include real-mode BIOS interrupts (via INT 10h) for mode selection, palette management, and display control, as well as optional protected-mode interfaces for 32-bit operating systems like Windows NT and OS/2, facilitating efficient access to video memory and hardware acceleration.[1] It supports a wide range of video modes, from text-based to high-resolution graphics up to 1600x1200 pixels with 24-bit color, and includes mechanisms for querying controller capabilities, such as memory size and pixel clock ranges, to ensure compatibility.[1] Historically, VBE played a crucial role in standardizing SVGA programming during the 1990s, promoting software adoption by reducing fragmentation among vendors like Cirrus Logic and S3, though it has since been largely superseded in modern systems by UEFI's Graphics Output Protocol (GOP) and direct GPU APIs.[1] Despite its age, VBE remains relevant for legacy DOS-based applications, embedded systems, and real-mode environments, with its specifications freely available from VESA to support ongoing compatibility efforts.[1]Overview and History
Definition and Purpose
VESA BIOS Extensions (VBE) is a standard interface defined by the Video Electronics Standards Association (VESA) to extend the capabilities of VGA-compatible graphics hardware. It provides a software API that allows applications to query available video modes, set display configurations, access linear frame buffers, and retrieve detailed information about the graphics controller and attached displays, all through extensions to the VGA ROM BIOS services. These functions are invoked via the BIOS interrupt INT 10h with AH=4Fh, enabling device-independent access to Super VGA (SVGA) features without direct hardware programming.[3] The primary purpose of VBE is to support higher resolutions, increased color depths, and basic hardware acceleration in DOS-based applications, overcoming the constraints of the original VGA standard—which limited displays to a maximum of 640×480 pixels at 16 colors—while avoiding the need for vendor-specific drivers. By standardizing interactions with diverse SVGA controllers, VBE ensures that software can portably utilize advanced graphics modes across compatible hardware, promoting broader adoption of enhanced video capabilities in pre-UEFI environments without disrupting existing VGA compatibility.[3][4] Historically, VBE was developed to unify the fragmented landscape of SVGA implementations from multiple hardware vendors, such as Cirrus Logic and Tseng Labs, whose proprietary extensions had previously complicated software development for high-resolution graphics. This standardization simplified the creation of applications that could leverage evolving video hardware while maintaining a modular, extensible framework for future enhancements.[3][5][6]Development Timeline
The Video Electronics Standards Association (VESA) was established in 1989 by leading display and graphics hardware manufacturers to address the growing need for standardized interfaces in the rapidly evolving personal computer graphics market, particularly focusing on Super VGA (SVGA) extensions beyond IBM's VGA standard.[7] This formation responded to the fragmented SVGA landscape in the early 1990s, where multiple vendors offered incompatible high-resolution modes and features, complicating software development for diverse hardware.[2] VESA's initial efforts centered on creating open standards to promote interoperability, with the VESA BIOS Extensions (VBE) emerging as a key initiative to enable uniform software access to SVGA capabilities via BIOS interrupts. VBE 1.0 was released in 1989, introducing basic functions for querying supported graphics modes, resolutions, and color depths, which allowed developers to detect and utilize SVGA features without vendor-specific code.[2] Subsequent minor updates in versions 1.1 and 1.2 during 1990–1991 refined these capabilities and improved compatibility. This version laid the groundwork for broader adoption, particularly in DOS-based applications and early Windows environments. By the mid-1990s, VBE gained traction in Windows 3.x for enhanced display support and in numerous DOS games seeking higher resolutions like 640x480 with 256 colors, reducing the need for custom drivers and improving compatibility across cards from manufacturers such as Tseng Labs and Cirrus Logic.[8] VBE 2.0 followed in November 1994, driven by demands for more efficient memory access in protected-mode applications; it added support for linear framebuffer addressing, enabling direct, contiguous access to video memory without banking switches, which significantly boosted performance for graphics-intensive software.[9] The standard's ratification marked VESA's response to escalating hardware diversity and the push for 16-bit color depths in mainstream computing. VBE 3.0 arrived in September 1998 as the final major core release, extending 32-bit operations, refresh rate control, and stereoscopic 3D support to accommodate emerging multimedia and gaming needs.[10] No significant updates have occurred since, as industry focus shifted to Microsoft's DirectX API for advanced graphics acceleration in Windows and later to the Unified Extensible Firmware Interface (UEFI), which supplanted legacy BIOS systems. As of 2025, VBE remains relevant primarily as legacy technology for emulating or running vintage DOS and early Windows software on compatible hardware.Core Specifications
Early Versions (1.0 and 2.0)
The VESA BIOS Extension (VBE) 1.0, released in 1989, established the foundational interface for software access to Super VGA (SVGA) graphics controllers, enabling resolutions and color depths beyond the standard VGA limits through a standardized set of BIOS interrupt calls.[9] It introduced core API functions for mode management, primarily operating in 16-bit real mode via interrupt 10h, with key calls including the return of controller information (AX=4F00h), which populates a 256-byte VbeInfoBlock containing the VBE version, vendor strings, and a pointer to a list of supported modes terminated by 0FFFFh.[1] This block, often referred to as the SuperVGA Info Block (SVIB) in early documentation, included fields such as VideoMemory (total video memory in 64 KB units) and ModesPtr (offset to the mode list).[9] A critical innovation in VBE 1.0 was the mode querying and selection mechanism, allowing applications to detect available graphics modes without hardware-specific code. The mode list querying function (AX=4F00h) provided access to supported resolutions, such as 640x480 at 256 colors or up to 1280x1024 in higher modes, by returning mode numbers in the 100h-107h range for standard SVGA configurations.[1] The real-mode return function (AX=4F01h) retrieved detailed mode information into a ModeInfoBlock structure at ES:DI, specifying attributes like resolution (XResolution and YResolution fields), bits per pixel, and memory model (e.g., packed-pixel for indexed color).[9] Additional functions included setting the video mode (AX=4F02h with BX specifying the mode number), saving and restoring video state (AX=4F04h), and controlling banked memory windows (AX=4F05h) to handle frame buffer access beyond the 64 KB real-mode limit.[1] These features focused on basic mode enumeration and switching, with no support for hardware acceleration beyond resolution and color depth changes, and were limited to VGA-compatible controllers using banked memory models.[9] VBE 2.0, released in November 1994, built upon the 1.0 foundation by enhancing memory access models and adding palette control, while expanding the VbeInfoBlock to 512 bytes for greater extensibility and support for non-VGA devices.[9] It introduced the linear or flat frame buffer model, enabled by setting bit D14 in the mode number during AX=4F02h calls, which allowed direct 32-bit memory access to the entire frame buffer via the PhysBasePtr field in the ModeInfoBlock, reducing the overhead of bank switching for high-resolution modes.[1] Banked memory handling remained available through the AX=4F05h function, which adjusted window positions (A or B) in granularity units defined by WinGranularity and WinSize fields in the info block, ensuring backward compatibility with VBE 1.x hardware.[9] Palette management emerged as a key addition in VBE 2.0, with functions for querying the VBE version (integrated into AX=4F00h, returning e.g., 0200h), setting or getting the display start address (AX=4F07h, using CX for X-pixel offset and DX for scan lines), and direct DAC (Digital-to-Analog Converter) control (AX=4F09h with BH=00h).[1] The palette functions supported 6-bit or 8-bit DACs (switchable via AX=4F08h), allowing applications to read or write up to 256 RGB entries via ES:DI buffers, with parameters like first register (DX) and number of registers (CX).[9] The SVIB structure was refined with additional fields like VideoMemory for total available memory and ModesPtr for the extended mode list, which now included higher color depths such as 15-bit or 24-bit true color.[1] Like VBE 1.0, version 2.0 primarily operated in 16-bit real mode, with the addition of a simple protected mode interface, and without hardware acceleration features in the core specification, relying on BIOS calls for all operations and preserving registers except AX in function returns.[9]VBE 3.0 Features
VBE 3.0, released on September 16, 1998, represents a significant advancement over previous versions by extending support to 32-bit protected mode calls through a dedicated entry point, enabling higher-performance access suitable for operating systems like Windows NT and OS/2.[1][11] This allows applications to invoke VBE functions directly in protected mode without relying solely on 16-bit real-mode interrupts, improving efficiency for complex graphics operations.[1] A key enhancement is the full linear frame buffer (LFB) support, providing a flat memory model that eliminates the need for banking in supported modes, with the physical base pointer (PhysBasePtr) indicating the memory location—often starting at 0xA0000 but mappable to higher addresses for better compatibility.[1] This contrasts with VBE 2.0's partial LFB implementation, offering more reliable and direct pixel access for software rendering.[1] Hardware window control is facilitated via function AX=4F05h (Display Window Control), which manages memory windows in banked modes and supports operations like panning and scrolling.[1] New API calls expand functionality, including AX=4F07h for stereoscopic extensions, where subfunction BH=05h enables mode for 3D shutter glasses by swapping left and right image buffers, and BH=06h disables it—supporting hardware-accelerated stereo display with dual start addresses.[1] Function AX=4F0Bh handles get/set pixel clock operations, enabling precise timing adjustments for custom resolutions.[1] The specification also introduces enhanced info blocks, such as the CRT Controller Info Block accessed via function 4F02h, which provides detailed timing data including CRTC registers for programmable refresh rates and scanline parameters.[1] VBE 3.0 improves multi-monitor setups through dual-controller design support, assuming coordinated operation by the same OEM for extended desktop configurations.[12] Error handling is refined with standardized return codes in AH, such as 01h for unsupported functions, 02h for invalid mode, and 03h for no modes available, allowing more robust application feedback compared to VBE 2.0's limited status reporting.[1] These advancements build on VBE 2.0's foundations by prioritizing 32-bit compatibility and advanced display controls for emerging multimedia and 3D applications.[1]Supplemental Extensions
Accelerator and Interface Functions
The VESA BIOS Extension/Accelerator Functions (VBE/AF) specification, adopted on August 18, 1996, defines a standardized interface for software and device drivers to access hardware acceleration features in graphics controllers, enabling efficient 2D rendering operations without heavy reliance on CPU processing.[13] This extension builds on the core VBE framework by providing low-level calls for operations such as bit-block transfers (bitblt), line drawing, and polygon fills, which offload graphical tasks to dedicated hardware, thereby reducing CPU load and improving performance in graphics-intensive applications.[13] Compatibility with earlier VBE versions is ensured through version querying mechanisms, allowing software to detect and utilize accelerator support only when available.[13] Key accelerator functions in VBE/AF include bitblt operations for copying rectangular blocks of pixels, supporting both solid and transparent off-screen bitmaps to facilitate efficient screen updates and compositing.[13] Line drawing and polygon fill capabilities further extend hardware support for vector-based graphics, with subfunctions accessed via interrupt 10h and AX=4F17h, where specific values like BL=00h initiate bitblt transfers, promoting portability across compliant hardware.[13] These features, including hardware cursors and multi-buffering, were designed to standardize access to common 2D acceleration primitives, minimizing software overhead in environments like DOS-based operating systems.[13] Interface extensions in VBE/AF encompass the Display Data Channel (DDC) for querying monitor capabilities, invoked through interrupt 10h with AX=4F15h, which enables retrieval of Extended Display Identification Data (EDID).[14] Subfunctions include BL=00h to report DDC capabilities (such as supported levels and transfer times) and BL=01h to read a 128-byte EDID block into a specified buffer via the I²C bus, providing essential monitor details like supported resolutions and timings for plug-and-play configuration.[14] Additionally, the Serial Control Interface (SCI), outlined in the VBE/SCI standard version 1.0 revision 2 dated July 2, 1997, standardizes serial bus communication between the graphics controller and monitors, allowing BIOS-level commands for control and status exchange over a dedicated serial link.[15] OEM extensions complement these standard functions by permitting vendors to implement custom acceleration features, such as advanced texture mapping or proprietary rendering, typically through vendor-defined interrupts like AX=4F0Eh under the VBE framework, ensuring backward compatibility while allowing innovation in hardware-specific optimizations.[3] These extensions are queried via the core VBE information function to avoid conflicts with standard calls, maintaining a unified interface for diverse graphics hardware.[3]Power and Display Management Extensions
The VESA BIOS Extension for Power Management (VBE/PM), introduced in version 1.0 in 1994, provides hardware-independent services for controlling display power states to support energy conservation in computer systems.[14] This extension builds on the core VBE framework by adding interrupt 10h functions under AX=4F10h, enabling software to query capabilities, set power levels, and retrieve the current state without direct hardware access.[16] Key subfunctions include BL=00h for reporting supported power management features, such as standby, suspend, and off modes aligned with the Display Power Management Signaling (DPMS) standard; BL=01h for transitioning the display to a specified state (e.g., 01h for standby, which dims the display while keeping it responsive; 02h for suspend, reducing power further with a blank screen; or 04h for off, fully powering down the display); and BL=02h for querying the active power state.[14] These capabilities allow operating systems and applications to implement suspend/resume operations efficiently, minimizing power draw during idle periods.[17] The VBE Flat Panel (VBE/FP) extension, proposed in 1994 as part of VBE 2.0 and formalized around 1996, addresses the growing use of LCD panels in portable computing by offering BIOS-level control over panel-specific hardware.[3] Accessed via AX=4F11h on interrupt 10h, it includes subfunctions for installation checks (BL=00h) and capabilities reporting, which reveal support for flat panel features like timing adjustments and identification.[18] Core functionalities encompass LCD timing control, such as configuring horizontal and vertical sync parameters to match panel requirements, and querying panel IDs through extended ModeInfoBlocks that include vendor-specific data like native resolutions (e.g., 800x600 or 1024x768 at 60 Hz).[3] This enables software to optimize display output for non-CRT devices, preventing artifacts from mismatched timings and supporting seamless integration in laptops where panels demand precise clocking for optimal image quality.[5] VBE Audio Interface (VBE/AI), released in version 1.0 with limited adoption due to competing standards, extends VBE to integrate basic audio capabilities with video subsystems.[19] Operating under AX=4F13h, it defines device classes for wave playback, MIDI sequencing, and volume control, with subfunctions like BX=0000h for installation checks, BX=0002h/BX=0003h for querying and opening devices (specifying 16/32-bit API sets), and BX=0004h for closing handles to manage audio modes alongside video rendering.[20] This allows synchronized audio-video operations in multimedia environments, such as querying device lengths or chaining drivers for unified control. These extensions integrate with core VBE through expanded information blocks in the VbeInfoBlock structure (accessed via AX=4F00h), which include flags and pointers indicating support for PM, FP, or AI modules, enabling BIOS detection of supplemental capabilities during boot.[3] For instance, the VBE Serial Control Interface (VBE/SCI) uses similar mechanisms under AX=4F15h to manage serial communication for monitor adjustments, complementing FP by allowing remote control of panel settings like brightness via RS-232 links.[15] Overall, VBE/PM, VBE/FP, and VBE/AI enhance system-level power efficiency, display adaptability, and multimedia support, though with varying levels of adoption, paving the way for more integrated PC hardware before native OS drivers superseded BIOS reliance.[14]Graphics Modes and Detection
Mode Numbering System
The VESA BIOS Extensions (VBE) employ a 16-bit mode numbering system, with VBE modes starting from 100h (bit 8 set) to denote extended capabilities beyond standard VGA modes (00h-7Fh). This scheme allows for standardized identification of video modes. The lower 9 bits (0-8) form the base mode number, bits 9-13 are reserved (must be 0; in VBE 3.0, bit 11 enables user-specified refresh rate control via a CRTCInfoBlock), bit 14 indicates linear frame buffer support (1 for linear, 0 for banked), and bit 15 controls whether display memory is preserved (1) or cleared (0) during mode set. The mode number is passed in the CX register during set-mode operations (VBE Function 02h) and serves as an index into the SuperVGA Information Block (SVIB) mode list for decoding detailed attributes.[3][1] VBE modes maintain backward compatibility with VGA by treating legacy modes as subsets. To decode a mode, software retrieves the SVIB via VBE Function 00h, which provides a far pointer to a list of supported 16-bit mode numbers, then uses Function 01h (AX=4F01h) with the mode number in CX to populate a ModeInfoBlock structure containing full details like exact resolution, bits per pixel, and memory layout.[3][1] Representative examples include mode 101h for 640x480 resolution with 256 colors (8 bpp) in packed pixel mode without LFB, and mode 112h for 800x600 resolution with 16 colors (4 bpp) in packed pixel mode. These can be verified by querying the ModeInfoBlock, which expands the mode number into operational parameters.[3] The mode numbering system has remained largely consistent since VBE 1.0, providing a stable foundation for mode selection across implementations. VBE 3.0 introduces extensions like 32-bit color depths (32 bpp) and enhanced LFB support without altering the core structure. In VBE 3.0, bit 11 for refresh control and bit 15 to preserve display memory extend functionality, but the base encoding for resolution and memory model is queried via the ModeInfoBlock. Querying the supported modes list via the SVIB remains the primary detection method, as referenced in core VBE functions.[1][3]Standard Modes and Vendor Variations
The VESA BIOS Extensions (VBE) specification defines a set of standard video modes to ensure compatibility across compliant hardware, primarily introduced in VBE 2.0 for resolutions beyond VGA limits. These modes include both packed-pixel graphics variants in 256 colors or 16 colors, as well as direct-color modes supporting higher bit depths like 15-bit (32K colors), 16-bit (64K colors), and 24-bit (16.8 million colors). Text modes extend beyond standard VGA for higher line counts. All standard modes use 15-bit mode numbers starting from 100h, with bit 7 set to distinguish them from legacy VGA modes (00h-7Fh).[3] The following table summarizes key VESA-defined standard modes, focusing on common graphics and text variants (more than 20 examples provided for breadth, excluding redundant legacy VGA modes 00h-13h which are optionally supported but not VBE-specific). Resolutions are in pixels, color depths indicate bits per pixel where applicable, and modes are hexadecimal.| Mode (Hex) | Type | Resolution | Color Depth | Notes |
|---|---|---|---|---|
| 100h | Graphics | 640x400 | 8 bpp (256 colors) | Packed-pixel |
| 101h | Graphics | 640x480 | 8 bpp (256 colors) | Packed-pixel |
| 102h | Graphics | 800x600 | 4 bpp (16 colors) | Packed-pixel |
| 103h | Graphics | 800x600 | 8 bpp (256 colors) | Packed-pixel |
| 104h | Graphics | 1024x768 | 4 bpp (16 colors) | Packed-pixel |
| 105h | Graphics | 1024x768 | 8 bpp (256 colors) | Packed-pixel |
| 106h | Graphics | 1280x1024 | 4 bpp (16 colors) | Packed-pixel |
| 107h | Graphics | 1280x1024 | 8 bpp (256 colors) | Packed-pixel |
| 10Dh | Graphics | 320x200 | 15 bpp (32K) | Direct color (1:5:5:5) |
| 10Eh | Graphics | 320x200 | 16 bpp (64K) | Direct color (5:6:5) |
| 10Fh | Graphics | 320x200 | 24 bpp (16.8M) | Direct color (8:8:8) |
| 110h | Graphics | 640x480 | 15 bpp (32K) | Direct color (1:5:5:5) |
| 111h | Graphics | 640x480 | 16 bpp (64K) | Direct color (5:6:5) |
| 112h | Graphics | 640x480 | 24 bpp (16.8M) | Direct color (8:8:8) |
| 113h | Graphics | 800x600 | 15 bpp (32K) | Direct color (1:5:5:5) |
| 114h | Graphics | 800x600 | 16 bpp (64K) | Direct color (5:6:5) |
| 115h | Graphics | 800x600 | 24 bpp (16.8M) | Direct color (8:8:8) |
| 116h | Graphics | 1024x768 | 15 bpp (32K) | Direct color (1:5:5:5) |
| 117h | Graphics | 1024x768 | 16 bpp (64K) | Direct color (5:6:5) |
| 118h | Graphics | 1024x768 | 24 bpp (16.8M) | Direct color (8:8:8) |
| 119h | Graphics | 1280x1024 | 15 bpp (32K) | Direct color (1:5:5:5) |
| 11Ah | Graphics | 1280x1024 | 16 bpp (64K) | Direct color (5:6:5) |
| 11Bh | Graphics | 1280x1024 | 24 bpp (16.8M) | Direct color (8:8:8) |
| 108h | Text | 80 columns | 60 rows | Extended text |
| 109h | Text | 132 columns | 25 rows | Extended text |
| 10Ah | Text | 132 columns | 43 rows | Extended text |
| 10Bh | Text | 132 columns | 50 rows | Extended text |
| 10Ch | Text | 132 columns | 60 rows | Extended text |