On April 2, 1987, when IBM rolled out the PS/2 line of personal computers, one of the hardware announcements was the VGA display chip, a standard that has lasted for 25 years and counting. While the VGA was an incremental improvement over its predecessor EGA (1984) and remained backwards compatible with the EGA as well as the earlier (1981) CGA and MDA, an entirely new display adapter was also introduced: The IBM 8514/A. The 8514/A was the first fixed-function graphics accelerator for PCs with support of 1024×768 resolution and up to 256 colors.
8514/A and VGAThere were several pieces of the puzzle: The actual 8514/A adapter, a VGA display built into a PS/2 Model 50, 60, or 80, and if one wanted to use the high-resolution 1024×768 mode, the new 8514 color monitor. The 8514/A was a microchannel (MCA) adapter which included a complete standalone display controller (IBM never built ISA-based 8514/A boards, but several clone manufacturers did). It was not compatible with any previous IBM graphics standards; for that purpose, the 8514/A used a pass-through mechanism whereby an on-board VGA provided backwards compatibility.
Unlike later pass-through solutions used by video decoder or 3D accelerator boards (notably the 3Dfx Voodoo line), the 8514/A did not use an analog pass-through. The PS/2 VGA chips supported a special digital connection which provided digital data before passing it through a palette look-up table (LUT). In pass-through mode, the LUT and DAC of the 8514/A were used, bypassing the on-board VGA ones. To this end, the 8514/A could shadow the VGA palette—writes to the VGA DAC were also directed to the 8514/A DAC, which was fully compatible but supported higher pixel clocks. The 8514/A’s DAC could also be controlled separately without affecting the VGA DAC.
Like other pass-through solutions, this set-up also allowed users to attach two monitors and use the VGA and the 8514/A simultaneously, even if that was not the typical usage scenario. This was a notable difference from nearly all follow-on designs which integrated a VGA core with an accelerator on a single chip (or at least a single board).
8514/A Display ModesThe IBM 8514/A only supported two resolutions: 640×480 and 1024×768. The basic 8514/A with 512KB VRAM only supported 16 colors; the 512KB memory expansion brought the total to 1MB VRAM and supported 256 colors as well.
The very limited set of resolutions was purely a function of the 8514/A display controller—the accelerator was much more flexible, and in fact 8514/A clones often supported 800×600 and 1280×1024 resolutions as well. The limitation was a consequence of only two oscillators on the board (and no programmable PLL), providing 25.175MHz and 44.9MHz pixel clocks for the 640×480 and 1024×768 resolutions, respectively.
The 1024×768 pixel clock was the cause of one of the biggest drawbacks of an 8514 system: The 16-inch 8514 monitor only supported a 43Hz interlaced 1024×768 resolution, and so did the 8514/A board. This was purely a cost-saving measure, especially on the part of the monitor. However, it resulted in unpleasant flicker at the high resolution. Again, clone boards often removed this limitation.
Memory Architecture and I/O InterfaceThe 8514/A internally used memory organized into planes, much like the EGA and VGA. In the basic 512KB configuration, only four planes were available, providing 16-color support (although a non-standard 256-color 640×480 mode was also achievable on those boards). The 512KB memory expansion added four more planes, bringing the total to 8 and hence 256 possible colors per pixel.
The planar organization was natural for the draw engine which always addressed memory the same way but could process either 4 or 8 bits at a time.
The memory organization was however not directly exposed to the programmer. Unlike MDA/CGA/EGA/VGA, the 8514/A was not mapped into the host system’s memory space at all and the framebuffer could not be accessed directly.
The 8514/A only provided an I/O port interface, and a strange one at that. Because the 8514/A required a relatively large number of 16-bit registers (around 30) to be mapped in the I/O space, IBM chose a non-traditional way to conserve the overcrowded ISA register space (the ports below 400h). The 8514/A occupied the 2E8h-2EFh space, but additionally used bits 10-15 of the I/O port address traditionally not decoded by ISA devices. The 8514/A thus for example decoded I/O addresses 02E8h, 06E8h, 12E8h, 16E8h, and so on up to BEE8h.
The I/O-space-only mapping had advantages and disadvantages. The good thing was that the 8514/A did not need to compete for the already severely overcrowded below-1MB address space. The bad thing was that reading or writing to the framebuffer had to be performed through a single 16-bit data register.
The 8514/A Draw EngineThe part which made the 8514/A really interesting was of course the accelerator (or draw engine) itself. The 8514/A was the first widespread fixed-function and therefore relatively cheap and fast accelerator. Other accelerators common at the time often used the Texas Instruments TMS34010/TMS34020 chips—RISC processors running at around 50MHz. The 340×0 chips were extremely flexible, but also significantly more complex to manage in software, more expensive, and generally about as fast as the simpler 8514/A.
The 8514/A introduced a 2D accelerator architecture which remained common for many years to come. The drawing commands included line drawing, rectangle and area fills, and BitBLTs (bit-block transfers) with X/Y coordinates. All drawing operations were subject to a scissor (clipping) rectangle.
The pixel pipeline used a specified foreground and background ‘mix’, which allowed to combine source and destination pixels with logical operators (AND, OR, XOR, NOT), addition/subtraction, maximum/minimum, etc. In many GUI environments, these are called raster operations or ROPs. A color compare register allowed to exclude certain pixels when drawing (and therefore retain the original pixel data). A mask register enabled the user to exclude specified memory planes.
Drawing commands were written by the host to a command queue (FIFO); the host was responsible for ensuring that there was enough free space in the queue which only had 8 slots on the original 8514/A (typically more on the clones). Since the the accelerator engine ran in parallel with the host CPU (a key source of accelerator performance), the 8514/A provided a mechanism to check whether the draw engine was still busy or idle.
The 8514/A line drawing was somewhat complex. Horizontal, vertical, and 45-degree lines were simple to draw, but all other lines required the user to calculate parameters for the Bresenham line drawing algorithm and program those to the accelerator. Several 8514/A clones provided enhanced functionality where the accelerator itself calculated the parameters.
There was also a special short-stroke vector (SSV) line drawing mode which provided an efficient interface for drawing short lines at multiples of 45 degrees. SSVs were often used for drawing text (the 8514/A did not provide any text mode).
The BitBLT functionality supported copying of rectangular blocks of pixels, subject to the applicable mixes etc. Optionally, either the source or the destination could be the PIX_TRANS register, which was a way for the host to write data to or read data from the 8514/A’s framebuffer. The source could be monochrome, providing color-expansion functionality often used with bit-mapped fonts.
In all supported modes, there was some amount of off-screen memory. This was often utilized to store frequently-used bitmaps or bit-mapped fonts. The draw engine could access off-screen memory considerably faster than it could receive data from the host.
Adapter Interface (AI)IBM never published register-level documentation for the 8514/A (although several clone manufacturers did). The only documented programming interface was the so-called AI, or Adapter Interface. The AI was a software interface (implemented as a DOS TSR), deliberately not specific to the 8514/A.
The AI was reasonably easy to use and had one major benefit—hardware independence. Various TMS340x0 boards supported the AI, as did IBM’s own 8514/A successors (Image Adapter/A, XGA) and 8514/A clones. The AI also had one major drawback: Roughly 50% performance compared to direct register access. Developers had to carefully weigh the advantages and disadvantages of writing to the AI.
The one product which significantly undermined the AI idea was Microsoft Windows, as well as IBM’s own OS/2 Presentation Manager. Especially on OS/2, using the AI was a non-starter, so IBM provided 8514/A register specifications to Microsoft. Microsoft and IBM also shipped sample 8514/A drivers in their various DDKs for Windows and OS/2; these were often used as a basis for developing accelerated drivers for other boards.
8514/A ClonesIBM’s 8514/A boards were not cheap in absolute terms, although they were relatively cheap for what they could do at the time (initially $1,290 for the adapter, $270 for the 512KB memory expansion). The 8514/A market was severely limited by the fact that IBM’s boards only supported MCA systems.
In the late 1980s, several companies reverse-engineered the 8514/A and started producing clone chips, often with ISA support. Notable among those was Western Digital Imaging’s PWGA-1 (also known as the WD9500 chip set), the Chips & Technologies 82C480, and ATI’s Mach 8 and later Mach 32 chips.
The clones were all in one or way or another better than the original: faster, with enhanced drawing functionality, and/or improved mode support. The clones often supported non-interlaced modes, 800×600 and/or 1280×1024 resolutions, and typically featured deeper command queues for increased performance.
ATI Mach 8 and Mach 32Probably the most widespread and longest-lived 8514/A clones were the ATI Mach 8 and Mach 32 family of products. ATI’s initial offerings (notably 8514/Ultra) were direct 8514/A replacements, accelerator-only boards which required a separate VGA device.
ATI’s 8514/Ultra was unique in that it supported both MCA and ISA systems. In MCA systems, it used the built-in pass-through functionality; in ISA systems, it connected to a supported VGA card through a special cable.
The 8514/Ultra supported non-interlaced 1024×768 modes, and provided several draw engine enhancements including a proprietary Crystal fonts technology for anti-aliased text.
ATI soon (late 1990) started offering single-card solutions which combined a VGA chip with a Mach 8 accelerator. These included the ATI Graphics Vantage (DRAM) and ATI Graphics Ultra (VRAM) cards. The Mach 8 boards behaved much like separate VGA + 8514/A chips with fixed pass-through. The (Super-)VGA chip, typically an ATI 28800, had its own 512KB of memory. A separate Mach 8 chip (ATI 38800) had additional 512KB or 1MB of DRAM or VRAM. The DAC was shared, which naturally reduced the cost.
The ATI Mach 32 was a second-generation 8514/A clone which integrated a VGA core and an 8514/A-compatible accelerator on a single chip (ATI 210688). The Mach 32 supported 16-bit and 24-bit color depths, up to 2MB memory (again VRAM or DRAM), a hardware cursor, and no longer had physically separate VGA/accelerator memory. The latter-day Mach 32 boards (1994) were available for the PCI bus and were thus among the first PCI graphics cards.
The Mach 32 was a modern accelerator which still retained register compatibility with the 8514/A and also supported the AI. The follow-on product, the Mach 64 (1994) was architecturally similar but used a much more modern register interface suitable for 32-bit PCI systems, and was no longer compatible with the 8514/A.
ImpactEven though the 8514/A itself was never a best-seller, it essentially created a market for fixed-function PC graphics accelerators which exploded in the early 1990s. The ATI Mach 8 and Mach 32 chips were popular clones, and several companies (notably S3) designed graphics accelerator chips which were not register compatible but were conceptually very similar to the 8514/A.
ReferencesGraphics Programming for the 8514/A by Jake Richter and Bud Smith, M&T Books, 1990, ISBN 1-55851-086-9
Chips and Technologies 82C480 datasheet Revision 2.1, August 1991
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4
