Ever since companies reverse-engineered IBM's EGA and produced compatible adapters, they have been pushing the IBM standards to their limits-first with Super EGAs, and more recently with Super VGAs. Both the EGA and VGA architectures (which are similar in many respects) suggest rather obvious extensions to accommodate higher resolution and more colors.

However, for many users, owning a Super VGA adapter hasn't been all it's cracked up to be. Dreams of glorious high-resolution color soon fade when you realize how few programs support the extended modes. Typically, you can get Super VGA-aware drivers for AutoCAD, Lotus 1-2-3, and, if you're lucky, Windows. But that's it. Most programs treat a Super VGA just like an ordinary VGA adapter. Why? There's been no standard way for programs to test for the presence of a Super VGA adapter, to identify what type of Super VGA is present, or to find out how to use its extended modes.

Enter VESA, the Video Electronics Standards Association, made up of several dozen leading manufacturers of graphics adapters, monitors, and software. The VESA Super VGA extensions let real-mode DOS programs recognize and exploit Super VGA hardware in a consistent manner. I'll focus on how manufacturers have extended Super VGA and how the VESA standard helps applications use those extensions.

Beefing Up VGA

The first natural VGA extension involves boosting the resolution of the display. Because of its bit-plane architecture, which locates several layers (or planes) of video memory in a single address range, VGA requires only 64K bytes of address space for its 256K bytes of on-board memory. Each high-resolution mode uses one linear bit for each pixel displayed. The highest standard VGA resolution, 640 by 480 pixels (hereafter expressed as 640 x 480), consumes only 38K bytes of the available 64K bytes. Boosting resolution to 800 x 600 fills 60K bytes of address space while maintaining square pixels and a simple addressing scheme. It also pushes close to the upper limit of the early multifrequency displays. Thus, 800x 600 became one of the more popular high-resolution extensions.

The second natural extension is additional color. VGA memory is usually arranged in a planar configuration: four bit planes, or 16 simultaneous colors (2⁴). But VGA has 8-bit registers. The Map Mask Register, which controls CPU writes to the various planes, usually reserves 4 unused bits. By enabling these (and making internal hardware changes to accommodate the extensions), Super VGA could support 256 colors. However, I've yet to see an adapter that works that way, probably because of the hardware modifications required.

Another possibility (implemented by the standard VGA mode 13 hexadecimal) is to address each pixel with one linear data byte, again allowing 256 colors. This method wastes CPU address space, requiring almost the entire 64K-byte segment for 320 x 200. But it greatly simplifies address calculations-you just multiply the x and y coordinates to get the byte offset of the pixel. This eliminates the bit offset calculation required by the planar modes.

The next step involves using more than one segment for linear byte-wise storage. The memory IBM reserved for video includes the 128K bytes that comprises the A and B segments. Fortunately, IBM chose to start VGA address at A000h (the older CGA standard began at B800h), so it is possible to extend resolutions by addressing two segments.

Of course, this technique won't work with a dual-monitor configuration. Programmers prefer two monitors for debugging: a monochrome monitor (and adapter) for viewing debugging information, and a VGA for the actual graphics display. Some spreadsheet users like to have a monochrome spreadsheet with color graphics on the other display. And some CAD users appreciate a full screen of graphics with the menus on a separate display. But in all such cases, the monochrome adapter uses address B000h, eliminating the B segment for VGA memory expansion.

Nevertheless, there are Super VGAs on the market that support 1024 x 768, 4- and 16-color modes (a 96K-byte footprint), and high-resolution 256-color modes with linear addressing (up to 480K-byte footprints). And these adapters still allow dual monitor configurations. How do they squeeze such a large footprint into a 64K-byte segment? With an old technique popularized by the LIM/ EMS standard: bank switching. The adapter lets the program select which bank (usually 64K bytes) of memory should appear at the A000h segment. Thus, a 1024 x 768 mode might have two 64K-byte banks, numbered 0 and l. The first 512 rows would be in bank 0 and the last 256 rows in bank 1.

Extending VGA does create some problems. The easiest ones to deal with (from the programmer's view) are the adapter's internal timings and addressing. Such parameters are set once and, except for unusual applications, never altered. Adding new bits to a few key registers for additional colors is not very difficult, either. But which mode number should set an 800 x 600 mode, or any other Super VGA mode? How do you know if a Super VGA mode is available? With the more complex bank-switching schemes, how do you request a bank switch? How large are the banks, and what are their attributes?

VESA: Passport to the Extended Modes

The first VESA standard, which was created in April 1989, established mode 6Ah as an 800 x 600, 16-color mode. Except for the larger address space, programming mode 6Ah is identical to working with standard mode 12h (640 x 480, 16 colors). Both are planar modes with a 64K-byte address map one plane for each primary color, and one to represent intensity. With the palette registers and the D/A converter, you can map a plane combination to any one of 262,144 different colors.

Before writing data to the adapter, a program must set the color to be written or the bit planes to modify. When reading data, the program must select a single plane (four reads to retrieve all data in a byte) or a particular color (16 reads to retrieve all data). In Super VGA mode 6Ah, a program accomplishes these tasks just as in mode l2h-that is, by standard VGA registers.

The Super VGA modes require faster scan rates for the display. Other timings, such as the retrace and overscan, require compensating adjustments. These timings can affect image size and placement on the display. In some cases, you may find yourself adjusting the screen controls every time you switch applications (for example, from an older 640 x 480 program to a newer Super VGA program). Accordingly, VESA has also set some display signal-timing specifications for 800 x 600 modes.

The next set of standards (October 1989) extended the BIOS calls. It established eight new graphics modes (all the way up to 1280x 1024, 256 colors), five function calls, and several attribute tables. All the new calls are implemented as subfunctions of interrupt 10h, function call 4Fh. As with the IBM-defined video BIOS calls, register AH takes the function call (4Fh), and the subfunction goes in register AL. A revision of these standards (May) added five new text modes and two new function calls. All VESA revisions will be backward-compatible to the original. A list of the functions appears in Table l. The new modes appear in Table 2.

Table 1: VESA FUNCTION CALLS

 With VESA calls, you can identify whether Super VGA is present and, if so, how to
control its video modes and bank switching.

Table 2: VESA MODES

Version 1. 0 standardized the popular 800 X 600, 256-color mode and left plenty of room
for growth. Version 1.1 added enhanced text modes.

VESA Functions

Function 0 (Return Super VGA information) confirms that a VESA adapter exists. The calling program must reserve a 256-byte area and pass a pointer via registers ES:DI. The VESA function returns a table of information that includes the current VESA version supported and a pointer to the valid video modes.

The program may determine the attributes of a mode by calling function l (Return Super VGA mode information). Like function 0, a pointer to a 256-byte reserved area passes through register ES:DI. The CX register receives the mode number. This function returns operational information such as memory layout and window properties (discussed later). The standards define enough detail so that a vendor can describe unusual non-VESA modes such as nonstandard resolutions or memory mapping (e.g., extended CGA). Functions 2 and 3 simply set and return the video mode. Unlike the standard video BIOS routines, which use an 8-bit mode number, the VESA routines use a 16-bit mode number. Programs get and set the mode number by way of the BX register.

Function 4 saves all, or selected portions of, the Super VGA video state. The complete video state includes all the registers (including vendor-specific registers) and BIOS data areas, but not the video memory.

Function 5 (CPU video memory window control) sets or reads the current window (bank); it's a prelude to bank switching. Register BH sets the current mode (0 for set, 1 for read), BL selects the window (0 for A, 1 for B), and DX holds the bank number. VESA also provides a direct call for setting the current window-the address of the call is returned through function 1.

Version 1.1 of the specification adds two function calls that support scrolling and multiple display pages. Function 6 sets the logical screen width. A line longer than the display width may be subject to horizontal scrolling. Additionally, longer logical lines are useful for rounding out odd-length lines, so windows always break between scan lines rather than within scan lines. For example, a 640-column graphics mode (80 bytes wide) does not divide evenly into 64K bytes. This can be fixed by rounding up to 128 bytes (1024 columns).

Function 7 sets and reads the display start address. This allows for panning across wider logical screens set through function 6, for scrolling vertically, or for switching between two or more display pages.

The standards recognize that some adapters have unique modes or limited abilities. VESA provides information about vendor-specific modes in the form of mode lists and mode attribute tables. A program can search for a specific resolution, find the closest matching resolution (either VESA or vendor-specific), and determine the necessary programming information-all with VESA calls. Note that an adapter does not have to support each, or any, of the VESA standard modes. For example, I have yet to see a 1280 x 1024 VGA.

Memory Windows

The standard VESA modes return information, too. This is especially critical for the bank-switching modes, such as 1024 x 768, and all the extended-memory modes (e.g ., those that require VGA with 512K bytes of memory). There are three separate bank-switching techniques: single-window (see Figure 1), dual overlapping windows (see Figure 2), and dual non-overlapping windows (see Figure 3). In each case, programs accomplish bank-switching with a VESA call or with a direct call to a bank-switch routine located with a VESA call.

Figure 1: SINGLE-WINDOW BANK SWITCHING

In this diagram, the offset in video memory has changed from 0 to 1000h (the CPU continues to address segment A000h). The shaded area is the displayed memory in 1024 by
768-pixel, 16-color mode.

Figure 2: OVERLAPPING WINDOWS 

Window A is write only, and Window B is read-only. Both are 64K bytes in length and addressed at segment A000h. The top half of the diagram represents an arbitrary initial
state where you can read video memory at offset 1000h and write to video
memory at offset 0. You might use this configuration to transfer an object from the nondisplayable memory in Window B to Window A. Moving to the bottom, both banks are switched, so you read from video offset 0 and write to video offset 1000h (e.g. , to store background information from Window Bin the nondisplayable area).

Figure 3: DUAL NONOVERLAPPING WINDOWS  

The CPU addresses two segments: A000h and A800h. In the top half, the CPU can read or write to either the first or last 32K-byte portion of displayable memory. In the bottom
figure, Window A has been moved to the second 32K-byte bank, while Window B continues to address the last displayable bank. In 1024- by 768 pixel, 16-color mode, there will be at least one more 32K-byte bank of nondisplayable memory, which could be used as supplementary storage for commonly used characters or objects.

With the single-window technique, the CPU can both read and write to the same address range-typically, a full 64Kbyte segment. Dual overlapping windows map to the same address, but one window is read-only while the other is write-only. The two windows can map to the same bank, thus emulating the single-window technique (but requiring two function calls to switch banks). Dual nonoverlapping windows, a variation on the basic dual-window theme, occupy different segments-typically A000h and A800h-and are 32K bytes long. Nonoverlapping windows can also emulate a single window, in this case by selecting consecutive 32K-byte banks (also requiring two calls to switch banks).

Most programmers will probably emulate single windows to simplify their plotting routines. So why bother with dual windows? To improve performance when you are moving data between display areas. Since each window is independently addressable, you can move data from one area to any other without reloading segment registers. Applications that do animation or that maintain libraries of frequently drawn images (e.g., fonts) will work much faster if they exploit dual windows.

Programmers must be very careful not to assume that attributes for one adapter will apply to another, similar adapter (or even from mode to mode on a single adapter-I've seen multiple windowing methods on a single adapter). For example, you cannot assume that single-window systems will have 64K-byte banks - the banks may be smaller than the window size. The smallest address step is called the granularity.

Most Super VGAs use a 64K-byte window and 64K-byte granularity, but Paradise Super VGAs use dual nonoverlapped Windows with a 4K-byte granularity. Each window is 32K bytes: one at segment A000h and the other at A800h. Each window can be individually programmed to 4K-byte offsets within the adapter memory. A single-window emulation would use banks 0 and 8, not banks 0 and 1.

Once you master the bank switching, programming with VESA is basically the same as with the standard VGA modes. The addressing generally follows either the 4-bit planar model (e.g., 640x480, 16 colors) or the linear packed-pixel model (e.g., 320x200, 256 colors).

What VESA Means to You

One of the unique features of the VESA standard is that it supports existing hardware. In an industry that is driven by selling new hardware, I think it's exciting to see some recognition of a large installed base that has been underutilized. By August of this year, most of the major manufacturers had implemented version 1.0 VESA BIOS calls as TSR programs for their existing VGAs. A few had the VESA calls in BIOS.

The next big step is software that supports VESA. As of August, several shareware programs supported VESA. Two CAD applications, Microstation and Generic CADD, had VESA drivers. Although CAD and paint applications will be the first adopters of VESA, the extended text-mode support in version 1.1 will make VESA attractive to spreadsheet and word processing applications. 0 fall the people I've talked to about VESA, Everex's Gary Lorenson is the most enthusiastic, and it's easy to see why. Everex has several Super VGA models with different architectures. With VESA, Everex can distribute programming information that applies to all its VGA models rather than trying to document the differences.

Of course, there are still benefits to be had by writing for a specific chip set. By knowing which registers control bank switching, or through special features such as direct-latch register writes, a programmer can improve the performance of an application-at the expense of portability to different adapters. I expect to see growing support for generic VESA drivers within programs over the next few years. But I doubt that customized drivers for popular programs will disappear. VESA primarily helps the software developer and those hardware vendors who have to support multiple architectures.

Note, however, that VESA is distinctly a real-mode standard. Writing a VESA driver for Windows 3.0 (which is something of a real-mode/protected-mode hybrid) would be a very difficult task due to the tight integration of the virtual device driver with the underlying hardware. Microsoft is looking into VESA but has not yet decided whether to participate. VESA is not useful for protected-mode applications such as Xenix, Unix, and OS/2. This is perhaps the biggest weakness of VESA-it is a software standard rather than a hardware standard. This is what makes VESA a significant advance, insofar as it supports old hardware, but it also restricts it from advancing to new operating systems.

VESA is unlikely to adopt a Super VGA hardware standard, for several reasons. Foremost, perhaps, is the fact that a hardware standard would give some companies an edge, since it would likely be built around an existing architecture. Also, a hardware standard would not be backward-compatible to the installed base of Super VGAs.

The VESA committee is looking at a generalized protected-mode library that could work across platforms such as the Phar Lap extensions, Xenix, Unix, and OS/2. But a generalized driver would be difficult to design and may not be practical if Super VGA is only a transitory phase on the way to graphics coprocessors.

A Graphics Coprocessor in Every PC?

Will graphics coprocessors make VESA obsolete before it establishes a significant installed base? I doubt it. Already, VESA is available to most Super VGA owners for the price of a software update (either free or for a minimal charge) or a call to a vendor-supported BBS. This gives a potential installed base of millions of computers. The next stage is VESA support in applications software. I expect rather quick adoption here. It's difficult for developers to ignore higher resolutions and additional colors when the conversion from existing VGA programs is straightforward.

Despite the initial excitement over the Texas Instruments Graphics Architecture and the 8514/ A, adoption of these graphics coprocessor standards has been slow. I think the primary factor working against graphics coprocessors is price. You still pay a premium for a graphics coprocessor-not just for the adapter, but for the monitor, too. Once resolutions push past 800 x 600, monitor prices go up dramatically. And although many coprocessors work at lower resolutions, the target market is 1024 x 768 and above.

Even when coprocessor prices drop (and they almost certainly will), the changeover from VGA to graphics coprocessors may be more evolutionary than revolutionary. One of the interesting aspects of the IBM-compatible market is that every aspect of a system must be cost-justified. Each computer is a collection of components tailored to an individual's budget and needs. Thus, even a few hundred dollars' difference between a coprocessor and Super VGA could tilt the balance in favor of VGA unless the coprocessor appears to improve performance significantly.

There are plenty of character-based applications that form the cornerstone of DOS- based computing. Graphics is more of a perk than a foundation for programs such as spreadsheets, databases, and, to some extent, word processors. Does it matter whether a 1-2-3 graph displays a few tenths (or perhaps only a few hundredths) of a second faster? Compared to spreadsheet recalculation times, minor improvements in graphics speed are practically insignificant.

The fate of Super VGA is probably more closely tied to acceptance of graphical-user-interface systems, such as Windows and OS/2-the areas where the VESA extensions are weakest. And since all GUI applications rely on graphics, a coprocessor begins to look more like a requirement than an option.

I think the VESA Super VGA standards have at least a few good years ahead. They should fill an important gap in the transition from VGA to whatever coprocessor standard establishes itself in the marketplace-and may have some staying power considering the older hardware standards that are still in use.

The VESA standard demonstrates a commitment to improve products that have already been sold, rather than to always push for something newer and better. It's a refreshing example of how cooperation between competing manufacturers can benefit the entire computer industry

Bradley Dyck Kliewer is the author of EGA/VGA: A Programmer's Reference Guide, Second Edition (McGraw-Hill, 1990) and principal of DKMicro Consultants, a microcomputer consulting business in Minneapolis, Minnesota. You can reach him on BIX as "bkliewer."