The XGA was introduced on October 30, 1990, about the same time when several other companies just started selling their own 8514/A clones. The XGA was a combination and superset of VGA and 8514/A: VGA compatible, high-resolution, accelerated graphics chip. Initially, an XGA chip was built into the new PS/2 Model 90 and 90 XP, and also available as a stand-alone upgrade for existing PS/2 systems in the form of the “IBM PS/2 XGA Display Adapter/A” (a typical IBM product name). The initial price was $1,095 for an XGA with 512KB VRAM and additional $350 for a memory upgrade to 1MB VRAM.

OS/2 1.3, which was announced on the same day as XGA, shipped with built-in XGA drivers. IBM also supplied drivers for Windows 2.1 and 3.0, OS/2 1.2, and several popular software packages such as AutoCAD. The XGA also shipped with an implementation of the AI (Adapter Interface). Existing applications written to the AI and supported on the 8514/A continued to work on the XGA.

In mid-1992, IBM released an updated version called XGA-2 or XGA-NI (Non-Interlaced), with significantly more flexible display support and several other enhancements.

XGA vs. 8514/A

Perhaps the biggest architectural change compared to the 8514/A was that the XGA integrated a VGA subsystem. In a way this was an admission of defeat: IBM’s earlier strategy of providing an on-board VGA chip with an additional high-resolution accelerator such as the 8514/A clearly hadn’t worked out.

In terms of capabilities, an XGA was very much like a VGA + 8514/A. In addition to standard VGA functionality, there was a new 132-column text mode. With 1MB VRAM, there was also a new high-color mode with 640×480 resolution and 65,536 colors (16 bits per pixel).

The mode support was otherwise the same: 640×480 and only interlaced 1024×768. IBM did not support the increasingly popular 800×600 resolution. The likely reason was that at the time, IBM didn’t sell multi-frequency monitors; as a consequence, the original XGA only supported four pixel clock frequencies (four separate oscillator chips are clearly visible near the center of the board).

The XGA draw engine was very similar to the 8514/A in terms of capabilities (hence the AI level compatibility), but was not compatible on the register level. A significant change was that IBM fully documented the XGA register interface, something that was never officially available for the 8514/A.

XGA Hardware

The VGA compatibility circuitry on the XGA was nothing new, but the accelerator engine and the overall architecture were significantly different from the 8514/A.

A major new feature (if not a mainstream one) was the fact that up to 8 XGA boards could coexist in a system, with a single one providing VGA compatibility. On system start-up, each XGA would be assigned an instance number which determined the I/O addresses used by the board.

Unlike the 8514/A, the entire XGA framebuffer could be directly accessed by the host CPU. There were three options: a 4MB aperture could be mapped anywhere in the 4GB address space, ideal for 32-bit operating systems and any number of XGAs; a 1MB aperture could be mapped below 16MB for 16-bit protected-mode operating systems; and a 64KB window was optionally available for a single XGA at the VGA A000h or B000h segment (real-mode accessible).

It should be noted that some XGA drivers did not require any memory aperture to be enabled, resulting in a framebuffer not addressable by the host CPU at all, similar to the 8514/A. Due to the bus-mastering capabilities of the XGA, the inability to access the framebuffer directly did not necessarily cause any performance loss, whereas on the 8514/A transfers to/from video memory required programmed I/O and hence CPU attention.

The look-up table (LUT) on the XGA was still essentially the same as VGA, with the addition of a direct-mapped 65,536 color mode.

A new feature was a 64×64 hardware sprite, almost exclusively used as a mouse cursor. On previous devices, including the EGA, VGA, and 8514/A, a mouse cursor had to be managed entirely in software, a non-trivial implementation which incurred a sizable performance hit when the cursor was moving quickly. With the 8514/A, the implementation was less costly as offscreen memory could be used to save the underlying image as well as provide a cursor image to be drawn with the BitBLT engine, but it still hardly counted as simple.

With the XGA, the mouse cursor could be implemented as a completely independent sprite displayed on top of framebuffer contents. Moving the cursor was simply a matter of updating the X/Y position registers, but more importantly, the cursor did no longer need to be hidden and re-drawn every time when the current drawing operation and the cursor intersected.

To support saving and restoring of the XGA state, all registers were readable (while many 8514/A registers were write-only). The XGA could even save and later continue the operation currently in progress, a potentially useful feature as blitting a large rectangle could take a relatively long time.

The Draw Engine

The XGA draw engine was very similar to the 8514/A but enhanced in several respects. A new (for IBM) concept was that of maps. An XGA map provided a translation between linear memory and a 2D bitmap. The XGA supported four maps, each with a given starting address, pixel depth, width, and height. An unusual feature of the XGA was that maps could reside both in video memory and in system memory. The XGA could not only copy between system and video memory but also draw into system RAM using bus mastering. In a multi-XGA system, one XGA could potentially even access another XGA’s memory without host CPU intervention.

A similar implementation of maps was found in the earlier Intel 82786 graphics coprocessor (1986), one of Intel’s several unsuccessful attempts to enter the graphics hardware market.

With the 8514/A, there was essentially a single fixed map covering the entire framebuffer. The XGA enabled much more flexible use of offscreen memory because linear (one-dimensional) memory management was possible. The 8514/A forced rectangle-based 2D memory management which is much more complex to implement and less efficient.

The pixel pipeline and drawing operations in the XGA were similar to the 8514/A, with mixes, color comparisons, plane mask, etc., although the hardware interface was different and used 32-bit memory-mapped registers—very typical for 1990s 2D accelerators.

The XGA supported Bresenham lines, short stroke vectors, rectangle fills, and BitBLTs just like the 8514/A. One new feature was the mask map which allowed an arbitrary mask bit-map to be applied to operations, allowing the user to draw arbitrarily-shaped objects. The mask map could be empty/undefined and only its dimensions used, in which case it worked much like the 8514/A scissors (clip rectangle).

Another new feature was the support for patterns (“brushes” in Windows GDI parlance, “tiles” and “stipples” in X11 terminology), both monochromatic and color. The patterns were very rather naturally specified through the use of XGA maps. On the 8514/A, the same effect could be achieved but required more effort.

XGA Virtual Memory

The most exotic feature of the XGA was probably its support for virtual memory. The XGA essentially replicated the 386 memory-management unit (MMU). Just like the 386, it used physical addresses by default, but virtual memory (i.e. paging) could be enabled. The XGA had its own PDBR (Page Directory Base Register) corresponding to the CR3 register in the x86 architecture.

With virtual memory enabled, the XGA used the host’s page tables and was able to process page faults. Protection violations and non-present pages encountered while the XGA accessed system memory were reported via an interrupt. The equivalent of the CR2 register also existed on the XGA in order to report the fault address.

The same basic idea was used by Intel several years later in the form of the AGP GART, except the XGA had gone much further. Both solved the same underlying problem, namely taking discontiguous physical memory pages and transforming them into contiguous regions that the graphics adapter could access. The XGA also made it possible to support task switching and easy access from user mode applications.

The XGA virtual memory feature was used by IBM’ OS/2 2.x VDM (Virtual DOS Machine) subsystem; it was utilized to provide support for DOS software which used XGA bus mastering. It is unclear whether any other drivers used the virtual memory features of the XGA. Since no hardware besides the XGA supported such technology, it was not useful to general-purpose software which also needed to run on non-IBM hardware.

The XGA-2

On September 21, 1992, IBM announced the XGA-2, an improved XGA with support for non-interlaced 1024×768 resolution and 1MB VRAM standard. The XGA-2 sported a programmable PLL circuit and handled pixel clocks up to 90MHz; this enabled support for up to 75Hz refresh rate at 1024×768 resolution. Finally, the 800×600 resolution was also supported, at up to 16bpp.

The XGA-2 had an improved DAC with 8 bits per channel, rather than 6 bits like the original XGA (as well as the VGA and 8514/A). The draw engine was enhanced to support 16bpp maps and performance was generally increased by using faster VRAM and several minor optimizations. At introduction, the “IBM PS/2 XGA-2 Display Adapter/A” cost mere $360.

XGA Clones

For the XGA, IBM chose a novel strategy: Instead of making the hardware specifications secret, the register interface was fully documented; in addition, IBM licensed the XGA chip design to SGS-Thomson (inmos) and Intel. Worth of note is that Radius manufactured ISA-based XGA-2 adapters built around chips from inmos (as usual, IBM didn’t bother with non-MCA adapters).

There were no clones to speak of in the true sense of the word, i.e. non-licensed chip designs based on reverse-engineering the IBM originals. IBM’s strategy was not particularly successful—while the XGA-2 was a decent chip, there were very capable alternatives already available (from S3, Tseng, and others), and implementing the bus-mastering design in an ISA environment was troublesome.

The XGA Legacy

The XGA architecture was a very modern design, with a linear framebuffer aperture, highly flexible bus-mastering draw engine, and hardware cursor. It was released at a time when most PC graphics cards were dumb framebuffer SuperVGAs limited to banked memory access; it took the rest of the PC graphics hardware industry several years to catch up with XGA’s capabilities. In many ways, the XGA was a classic 1990s design even if it never reached its full potential (it could have easily supported up to 4MB VRAM as well as 24/32bpp True Color pixel formats).

However, measured against IBM’s own goals, the XGA was a failure. Not only was the XGA unsuccessful in establishing a hardware standard, the experience persuaded IBM to quit the PC graphics market altogether and rely on graphics chips from companies like Cirrus Logic or S3 for its own systems.

There is little doubt that Microsoft Windows and IBM’s own OS/2 were a major cause of this failure. When a graphics chip vendor only needed to supply one or two drivers for widely used GUI environments (rather than a dozen or more, with custom driver development often needed), there simply wasn’t enough value in register-level compatibility. The hardware was evolving too quickly for that.

As a consequence of XGA’s failure to establish itself, VGA has remained as the only hardware standard to date, a sad fact more than 25 years since its introduction.

References

Power Programming the IBM XGA by Jake Richter, MIS Press, 1992, ISBN 1-55828-127-4
IBM PS/2 Hardware Interface Technical Reference—Video Subsystems, S42G-2193

S3 Inc. (later known as S3 Graphics) was founded in 1989 and in mid-1991 it released the S3 911, the first single-chip SuperVGA GUI accelerator (the 911 designation was a reference to the Porsche 911). This was soon followed by S3 924, 928, the S3 Vision family (864/964/868/968), and finally by the extremely successful S3 Trio integrated GUI accelerators (Trio32, Trio64, Trio64V+). The 3D-capable S3 ViRGE and Savage chips never reached the popularity of their 2D-only predecessors.

Reviewing a data sheet for the “S3 Trio64V+ Integrated Graphics/Video Accelerator”, it is obvious that there was a very close relationship between S3 accelerators and the 8514/A. The same relationship is also apparent in the OS/2 DDK for example, where the sample Presentation Manager accelerated driver shares a significant portion of code between 8514/A and S3 drivers.

The S3 draw engine was obviously designed to be compatible with the 8514/A. This includes register naming (VESA-approved 8514/A register names), I/O addresses used for the registers (at least in later chips only optionally), and register layout. This similarity made it easy to port existing 8514/A drivers to support S3 hardware. At the same time, the S3 chips were never 100% 8514/A compatible and running unmodified 8514/A code on S3-based cards was out of the question.

The S3 graphics chips combined a VGA core with SuperVGA capabilities with an accelerated draw engine. The Trio series also added a DAC and a PLL synthesizer on the same chip (hence a “trio” of integrated chips). The display engine (often called CRTC, or CRT Controller) was a VGA/SuperVGA design and didn’t resemble the 8514/A at all. No less important was the fact that as integrated VGA/GUI accelerator designs, the S3 chips never had separate VGA and accelerator framebuffers, and the framebuffer was directly accessible from the host (whether in a banked fashion or mapped linearly).

The draw engine itself was also not identical to the 8514/A, despite the very high degree of similarity. S3 extended it to support higher color depths (16, 24, and 32 bits per pixel) and larger memory sizes, but even the in 8-bpp modes there were differences.

Where the 8514/A supported 32 mixes, S3 only supported 16 (the basic logical operations were retained while the additions/subtractions were dropped). There was no provision for the host to read the data which the draw engine would write—since the host could access the framebuffer directly, this functionality was unnecessary. Color comparisons were simplified to only support equality or inequality, no ranges.

The draw engine commands were also slightly different. S3 dropped the vertical rectangle fills (which achieved the same effect as the standard horizontal fill) as well as area fills, but added pattern blits (PatBLTs) which replicated an 8×8 pattern to a destination rectangle, a common GUI operation.

It is apparent that if an existing 8514/A driver were used as a starting point, the mode setting code would have to be very significantly modified if not entirely replaced to support S3 chips. On the other hand, the drawing code could most likely be kept with minor modifications (perhaps changing the register access mode from I/O to MMIO and slightly changing certain operations) and certainly retaining the overall structure.

Overall, S3 was clearly very much inspired by the 8514/A draw engine and its register interface, but felt free to both extend the functionality and drop existing 8514/A features that were not considered important, presumably to simplify the design and reduce cost. Being compatible with existing 8514/A software was not S3′s objective, and not a requirement in the age of Windows.

8514/A and VGA

There 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 Modes

The 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 Interface

The 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 Engine

The 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 Clones

IBM’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, 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 32

Probably 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.

Impact

Even 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.

References

Graphics 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

Such boards were relatively rare because by the time the Tualatins were released (2001), Intel was busy pushing Pentium 4s onto every desktop. On the other hand, there were numerous Tualatin-based server boards because the Tualatin (especially the Pentium III-S variant) had significantly better performance per Watt. Server boards typically had onboard graphics (often a Rage XL chip) and no AGP slots.

The P3TDDE was designed for workstations, with an AGP Pro 4x slot, 5 PCI slots, ATA/100, onboard Intel 100Mbps Ethernet controller, and support for up to 4GB PC133 SDRAM. The board has good power management, additional onboard Promise ATA/100 RAID controller, the BIOS supports larger than 128GB ATA disks, and being a Supermicro it’s a generally well made product.

The board is based on the VIA Apollo Pro 266T northbridge with VT8233 southbridge. The chipset supports DDR SDRAM thought the board does not; it’s questionable how much the Pentium III would really benefit anyway.

Since the AGP 4x slot is the most attractive feature of this board (being AGP 1.0/2.0 compatible, it can support just about every AGP card), how well does it work? Unfortunately, not well… because of the VIA chipset. To be more precise, the system is unstable with AGP 4x. 3D intensive applications lock up the system, or in the best case “only” kill the display.

The same problem occurs with several AGP cards which are known to be working. A quick Google expedition revealed that these problems were far from unusual. Both ATI and nVIDIA cards are affected, though not all. A Radeon 9200 works stable at AGP 4x, but it’s considerably slower than a Radeon 9800 at AGP 2x. It’s likely that the Radeon 9800 uses more advanced AGP features which cause trouble (R300 vs. R200 GPU generation).

The BIOS has curious options like “AGP drive strength” which is essentially black magic that no one understands. Until now I’ve only used AGP boards with Intel chipset and have been blissfully unaware of such abominations.

Despite my best efforts, I have not been able to get AGP 4x stable with either of two different Radeon 9800s (Pro and XXL) with Windows XP. Updated VIA 4-in-1 drivers, various BIOS setting combinations, nothing helped. After a few minutes of heavy 3D activity, graphics fails in one way or another.

It is likely that AGP 4x only brings a minimal speed improvement over AGP 2x. But somehow it feels like a huge letdown that a board/chipset advertising AGP 4x support is in reality unable to use AGP 4x in a reliable fashion with faster cards.

This was clearly a common yet very poorly understood problem. The solutions suggested generally amount to little more than voodoo (along the lines of “reboot the system”). I could not find any official word from VIA, let alone any authoritative documentation. The problem also clearly persisted across several generation of chipsets. All in all, this does not inspire confidence in VIA chipsets…

At the moment the board is running with AGP 2x and I keep wondering how much of a difference AGP 4x would have made. Incidentally, the board is surprisingly good at running Windows 7, with dual 1.4GHz Pentium III-S processors of course.

Luckily there are slockets (or slotkets) which convert a Socket 370 processor into a Slot 1 one. For historical reasons, Intel’s Pentium III lineup was a bit schizophrenic. To understand the reasons, one must go back to the Pentium Pro (1995) which packed the processor core and between 256KB and 1MB of L2 cache onto a single “dual cavity” PGA or PPGA package. This approach proved less than ideal as the processors were very difficult to manufacture.

For the Pentium II (1997) Intel designed a completely new processor package called Slot 1. The slot processors contained a circuit board on which the processor core and L2 cache were mounted as separate chips. This approach solved the manufacturing problems, but at the cost of slowing the L2 cache to half of the clock speed of the processor core. Unlike the Pentium Pro, the Pentium II proved quite popular as it outperformed the Pentium and Pentium MMX by a healthy margin (the Pentium Pro didn’t for 16-bit code). Numerous motherboards were designed for one or two Slot 1 Pentium II processors.

For the cost-conscious, Intel introduced the Celeron line of processors. The first generation (Covington, April 1998) was essentially a Pentium II with no L2 cache whatsoever. These processors were poor performers and not very popular. Shortly thereafter the Mendocino Celeron (August 1998) processors came. These processors were also built around the Pentium II core but had 128KB of L2 cache as opposed to 256KB of the “real” Deschutes Pentium II. The catch was that the Mendocino’s cache ran at full clock speed while the Deschutes’ was half-speed. In some situations, the Celerons with smaller but faster L2 cache outperformed their supposedly higher-end brethren.

To make matters more interesting, Intel manufactured the Mendocino Celerons in  Slot 1 packaging but also introduced new PPGA Celerons in Socket 370 form factor. At this point, manufacturing the CPU core and the L2 cache on a single die was no longer a problem (note that the Mendocino Celerons also only used 128KB L2 cache as opposed to at least 256KB of the old Pentium Pro).

This caused minor confusion among users and motherboard manufacturers. There were a few Socket 370 boards (including the famous ABIT BP6) but most vendors stuck with the Slot 1 form factor. To bridge the gap, “slockets” (or “slotkets”) were introduced: Socket 370 to Slot 1 converters. Since the Slot 1 and Socket 370 processors had essentially identical electrical interface, it was possible to build slockets that could be sold for about $20.

When the first Pentium III (Katmai, 1999) processors were introduced, Intel seemed to continue sending a clear message: Slot 1 is for high-end processors, Socket 370 is for the cheap ones. Katmai Pentium III processors were only available in Slot 1 packaging. But then the Coppermine Pentium III CPUs came (2000) and threw everything upside down. Next to the Slot 1 Coppermine processors, Intel started manufacturing Socket 370 FCPGA Pentium IIIs which only differed in packaging. It is likely that laptops provided an impetus for better support of Socket 370. For obvious reasons, Slot 1 processors were useless for laptops, but Socket 370 CPUs were quite small and laptops could (and did) use them.

With Slot 1 processors, Intel stopped at 1GHz (with both 100MHz and 133MHz FSB). On the other hand, Socket 370 Coppermine Pentium IIIs were also available in 1.1GHz (and the infamous aborted 1.13GHz). Once the Tualatin die shrink was released (2001), the Slot 1 packages were completely gone and only Socket 370 Pentium III processors remained. At that point, Intel was able to manufacture processors with up to 512KB full-speed L2 cache on-die: the Pentium III-S, everyone’s favorite Tualatin processor.

This increased the need for slockets; motherboards continued being manufactured predominantly with slots, since that way users could install both Slot 1 and (with a slocket) Socket 370 processors. Only the latter-day boards designed for Tualatin CPUs (roughly 2001-2003) came strictly in Socket 370 format.

MSI Master Slockets

The OS/2 Museum obtained several MSI Master slockets (version 2.0) for use with the UMPC. Almost immediately, a serious problem became apparent: While these slockets can support any Coppermine processor, they only support one. Ironically, the slockets support Mendocino Celerons in SMP configurations, but not Pentium III processors.

If it weren’t for that, the MSI Master slockets would be perfect for the UMPC. They support 66/100/133MHz FSB and voltages at least down to 1.5V; the default settings provide automatic frequency and voltage selection, which means that in the typical case one only needs to socket the CPU, install a heatsink/fan, and plug the slocket into the motherboard. As long as “typical case” means “one processor only”.

Note that for Coppermine CPUs, these slockets require a Coppermine-enabled motherboard (such as the P2B-DS rev. 1.06). The MSI Master slockets (just like most other slockets) do not include a voltage regulator; they simply request the correct voltage from the motherboard’s VRM.

There was one well known slocket which supported dual processors: the ASUS S370-DL. Unfortunately this slocket is impossible to find (especially if one needs a pair of them). There were rumors about a modification of other slockets which involved pin N33 on the CPU/socket. Pin N33 is marked as “reserved for future use” by Intel in Pentium III documentation.

It is clear that pin N33 is significant in Coppermine SMP systems and various slocket models may need connecting the N33 pin in order to support dual processor operation. It is less clear what the pin does exactly or why it’s not documented. It’s apparent that the pin is significant during system reset when the bus agent IDs are determined; in other words, one CPU is designated as “primary” or the BSP, the other as “secondary” or the AP.

Fixing the MSI Master slocket isn’t particularly complicated:

The modification is in fact quite easy… if one has the right kind of wire and a suitable soldering iron. The pins are connected on the reverse side of the PCB which is normally hidden under a plastic cover. The patch wire is then nicely protected and can’t be accidentally ripped off.

The modification does indeed work and was verified with two 700MHz Coppermine processors. The next step is finding faster processors; the question is which ones. Supporting Tualatins requires further modifications which are somewhat destructive. Then there’s the hairy FSB frequency problem.

440BX at 133MHz FSB

The 440BX chipset only supports 66/100MHz FSB speeds. It can be overclocked to 133MHz without much trouble (in fact it is said to handle 150MHz FSB speeds quite well), but at least in the P2B-DS boards, there are several problems:

The P2B-DS rev. 1.06 can be jumpered to 133MHz FSB easily enough, but then the PCI bus will be run at 44MHz, significantly out of spec (33MHz). That can be fixed with a hardware modification which isn’t entirely trivial.

Worse yet, the AGP bus will remain out of spec at 89MHz (vs. 66MHz). Many graphics cards tolerate this, but most notably the ones using ATI R300/R360 GPUs do not (the graphics card will not POST at all).

Perhaps the nastiest problem is that at 133MHz, the P2B-DS boards do not reliably work with four DIMMs. The maximum memory is reduced from 1GB to 768MB or possibly only 512MB. There is no known solution for this problem. Note that many 440BX-based boards only sported three DIMM slots which would have likely avoided this problem.

At the same time, using 133MHz FSB does not appear to have a big performance impact, or at least not always. With many SDRAM chips, the system will use 2-2-2-X memory timings at 100MHz FSB but 3-3-3-X at 133MHz. That almost completely eliminates the speed advantage from the faster FSB.

Given all these restrictions, sticking with 100MHz FSB speeds certainly generates far fewer problems; but the question has not been settled yet.

For reasons that I won’t go into now, I had to remove the heatsink/fan assembly from a normal-looking Radeon 9800 Pro, a card manufactured by Sapphire sometime at the very end of 2004 or the very beginning of 2005 (given that the PCB indicated week 52 of 2004):

Once I removed the heatsink (and cleaned off a thin residue of thermal paste), I found this:

A R360 GPU… Apparently once the Radeon 9800 XT was released, ATI stopped manufacturing the R350 chip and used the R360 in both the 9800 XTs as well as the 9800 Pros. Therefore the 9800 Pro boards manufactured in 2004 typically used a R360 chip, even though the model designation did not change.

The 9800 Pro boards used slower memory and therefore couldn’t reach the 9800 XT performance levels, even though the BIOS could be flashed and made to look like a 9800 XT.  Still, the performance could be increased somewhat.

At any rate, it’s obvious that the R360 GPU does work in AGP 2x systems, even though no Radeon 9800 XTs with AGP 2x support do appear to have been made.

Motherboards with dual Tualatin support do exist, but nearly all of them have either ServerWorks or VIA chipsets. While it is possible to run a Tualatin with an Intel 440BX/GX chipset, this requires an adapter or a modified processor. The 440BX/GX chipset is (in theory) fundamentally incompatible with Tualatin processors due to a difference in signaling voltage levels (AGTL vs. AGTL+).

Ironically, Intel itself sold server boards (SDS2, SAI2) with dual Tualatin support… boards built around chipsets from ServerWorks (the ServerSet III). This inevitably led to a few conspiracy theories.

The suspicion was that Intel did not want to promote Tualatin processors because they made the Pentium 4 look bad. A 1.4GHz Tualatin performed as well as a faster-clocked Pentium 4 and used plain PC133 SDRAM instead of expensive RDRAM.

Intel’s position at the time (2001) was clearly schizophrenic: There was a huge push to sell Pentium 4s, power-hungry and under-performing processors. For laptops, Intel initially had no choice but to sell Pentium IIIs. For servers, there were Pentium 4-based Xeons, but again power-hungry. For low-power 1U rack-mount servers, the Tualatin Pentium IIIs were an excellent choice.

For reference, the TDP of a 1.4GHz Pentium III-S was 32.2W (less than the 34.5W of a 600MHz Katmai Pentium III) while the TDP of an early desktop 1.7GHz Pentium 4 was 64W. The contemporary Foster Xeon processor had a TDP of 56W at 1.4GHz.

It is a question whether the Tualatin Pentium IIIs might have scaled past 1.4GHz or truly hit a wall, especially in light of the (much) later Pentium M. It’s certain that they didn’t get much love from Intel, with questionable “features” such as having multiprocessing support disabled in all but the server versions. Based on the performance of Tualatins relative to Pentium 4s, it’s no wonder there was suspicion Intel just didn’t want the Tualatins around.

Whatever Intel did back in 2001-2002, nowadays a Tualatin 1.4GHz Pentium III-S is quite easy to find. I myself ended up with a small pile of 1.26 and 1.4GHz Tualatins and a question: What’s a good board for these babies?

Dual Tualatin Boards

There is a handful of motherboards which support dual Tualatin processors. There are Intel’s own server boards, the SDS2, SCB2, (both extended ATX) and SAI2. All are based on the ServerWorks ServerSet III HE-SL chipset. This is a high-performance chipset with support for interleaved SDRAM memory; the boards support up to 6GB RAM. The boards come with relatively poor on-board graphics (ATI Rage XL) and no AGP slots; this is typical for server boards.

Supermicro built several P3TDE boards based on the ServerWorks HE, HE-SL, and LE chipsets; the P3TDE6-G with a 2x AGP Pro slot. Supermicro also offered P3TDD boards based on the VIA Apollo Pro 266T chipset. The P3TDDE board came with an AGP Pro 4x slot which should be capable of supporting quite fast graphics cards.

There were several other dual Tualatin boards based on the VIA Apollo 266 chipset: The AOpen DX37, MSI Pro266TD Master (MS-9105), and Iwill DVD266.  The Iwill was rather unusual because it supported DDR SDRAM, although with questionable benefit.

Back in August 2001, Anandtech had a nice review of the then-current dual Socket 370 boards with an emphasis on desktop boards. The most exotic was the Acorp 6A815EP, the only one based on an Intel chipset (815EP), despite the fact that the 815EP did not officially support multiple processors. Many boards were based on VIA’s earlier Apollo Pro133 chipset, often with the dreaded 686B southbridge.

I must admit being tempted to get one of the ServerWorks-based boards, just to see what Tualatin Pentium IIIs can do with a high-performance chipset. It’s truly a shame that Intel did not build any dual Tualatin chipsets… but ultimately just a footnote in the annals of corporate stupidity.

The system has been very stable so far. Perhaps unsurprisingly—nothing is overclocked and all components are on the higher end of the quality spectrum (if a decade-plus old). The disk was moved from the older BP6-based system and already contained DOS, OS/2, and Windows XP.

Getting Windows XP to run prompted some cursing, occasioned by Windows’ brain damaged “Plug and Play” implementation. Windows XP kept starting to boot but then simply resetting the system (perhaps a triple fault?), without any indication what might be going wrong. Safe mode etc. made no difference. OS/2 had no trouble booting up, which was an indication that the hardware was probably fine. The cause of the problem was perhaps obvious to anyone familiar with Windows XP’s quirks…

Windows had been installed with the ACPI HAL, but between BIOS upgrades, clearing the CMOS, and testing various BIOS setting, the ACPI support in the BIOS ended up being disabled. Incidentally, enabling ACPI in the P6DBE BIOS is anything but obvious: the power management setting must be “disabled”.

Once ACPI was re-enabled, Windows XP had no trouble booting. That prompted the installation of Sandra 2001 to verify that the system is performing as it should (it is), as well as the addition of 3DMark 2000 and 3DMark 2001SE to help find the right graphics card.

The Ultimate Museum Graphics Card

Finding the “best” graphics card isn’t entirely straightforward. The objective is to find something close to the best performing card with can operate in a 3.3V AGP 2x slot. For logistical reasons, the card should have both VGA and DVI output. PCI cards weren’t considered (perhaps a mistake?) on the assumption that the interface would be too limiting compared to AGP 2x; the maximum PCI bandwidth is 133 MB/s, while AGP 2x can deliver 533 MB/s, moreover an AGP device uses a separate bus where it doesn’t have to compete for bandwidth with other devices.

It’s worth noting that finding a graphics card with AGP 2x support is easy (at least on eBay and the like), but finding a fast graphics card with AGP 2x support is much harder. All newer graphics card typically only support AGP 8x and aren’t backwards compatible with old AGP motherboards due to different voltage.

The obvious contenders are nVIDIA and ATI. Matrox cards are relatively uninteresting due to their noticeably lower 3D performance, even though, say, a Matrox G450 is a very fine graphics card otherwise. “Other” brands like S3 weren’t even considered.

Around 2003, both nVIDIA and ATI stopped making their high-end graphics chips compatible with AGP 2x. ATI’s top of the line model and king of 3D performance back then was Radeon 9800 XT. Unfortunately the 9800 XT is based on the R360 GPU with no AGP 2x support. However, the older and only slightly slower Radeon 9800 Pro (R350) can still be used in the old 440BX boards.

A slight complication is that Radeon 9800 Pro existed in several variants, with the newer ones no longer being AGP 2x compatible. On pictures, this is easy to distinguish by checking whether the AGP connector has two notches (AGP 2x compatible) or just one (not AGP 2x compatible).

In theory, ATI’s fastest would be a Radeon 9800 Pro with 256MB RAM. In practice, these cards turned out to be very hard to find, while 9800 Pros with 128MB RAM are plentiful and only slightly slower. The lower amount of memory reportedly didn’t make noticeable difference for games of the era.

On the nVIDIA side, one obvious choice is the FX5950 Ultra. This was a direct competitor of the Radeon 9800 Pro/XT, with very similar performance levels but generally slightly slower than the 9800 XT. It is currently unclear whether any newer nVIDIA cards with AGP 2x supports might have been actually faster than the FX5950 Ultra.

Performance aside, there is also driver support to consider. Both the ATIs and the nVIDIAs are of course well supported under Windows, but with other operating systems things look a bit different. For OS/2, Radeons are clearly the better choice. For X11, nVIDIA might be better as long as a particular release is supported by nVIDIA’s own drivers. Since ATI was more open about providing programming documentation, the Radeons tend to be generally better supported under “alternative” operating systems.

A week or two after the initial research, the new old graphics cards arrived. There’s a nVIDIA FX5950 Ultra built by MSI (FX5950U-VTD256) and a Sapphire Radeon 9800 Pro Atlantis.

The nVIDIA has large heatsinks and fans on both sides of the card. The ATI is purely passively cooled with massive heatsinks. The passive cooling is both good and bad news—the card is absolutely quiet, but it’s also wider, and just barely fits on the P6DBE board (the processors get in the way a bit). On other motherboards it might not fit at all. Both cards require a separate power supply cable to be plugged in.

Here’s how the two cards do in benchmarks; for comparison, the figures for the older Radeon 9700 Pro are also listed. Again this is with a Supermicro P6DBE board, 2x Pentium III 850 MHz at 100MHz FSB, 1GB SDRAM.

• MSI nVIDIA FX5950 Ultra (256MB)
  • 3DMark 2001 SE: 6511 3D marks
  • 3DMark 2000: 5173 3D marks
• Sapphire ATI Radeon 9800 Pro (128MB)
  • 3DMark 2001SE: 6750 3D marks
  • 3DMark 2000: 5357 3D marks
• ATI Radeon 9700 Pro (128MB)
  • 3DMark 2001SE: 6674 3D Marks
  • 3DMark 2000: 5351 3D marks

Despite the smaller video RAM size (128 MB vs. 256 MB), the Radeon 9800 Pro has a slight edge in 3DMark. That said, the difference is clearly not big enough to be a deciding factor. If anything, both cards are a bit overpowered for the Ultimate Museum PC. It’s also worth noting that the older Radeon 9700 Pro does almost as well as the 9800 Pro and still a tad better than the FX9590 Ultra, at least in the default benchmarks.

In a quick real-world test (the original Max Payne running at 1680×1050, 32bpp), both cards performed very well indeed with no discernible differences.

Possible Improvements

With 1GB SDRAM, the system is maxed out in terms of memory capacity. A 120GB IDE disk is also about the largest that can be used without hitting the 128MB BIOS limit. Either of the above mentioned graphics cards is probably fairly close to the fastest a 440BX-based board can handle.

The weak spot is the CPU. Without slockets or overclocking, the board could take a 1GHz processor. Unfortunately, the 100MHz FSB Coppermine Pentium IIIs are quite hard to find, especially in Slot 1 form factor. With the use of slockets, 1.1GHz processors could be used, but then there are two problems: the 100MHz FSB variants are again hard to find, and because only Socket 370 variants existed, slockets would be required. That brings another problem—finding slockets which support dual-CPU Pentium III operation. Many slockets support dual (Mendocino) Celerons, but not Pentium IIIs. Slockets are easy to find, but slockets known to support dual Pentium IIIs are apparently more or less extinct.

Another avenue yet to be explored is installing Windows 7 (32-bit, obviously) on the Ultimate Museum PC… just to see how painful it might be.

To be continued…

The file is EXEHDR.EXE, dated June 11, 1986 (size 32,896 bytes). It was shipped in the Microsoft Windows 1.03 SDK and then again unchanged in the Windows 1.04 SDK. For reference, OS/2 was announced on April 2, 1987 and the first OS/2 SDK was shipped around May 1987.

The mid-1986 EXEHDR.EXE is a classic dual-mode executable, with a DOS-compatible “stub” followed by an OS/2 NE format module—essentially two separate executables in a single file (it is not a bound executable). The OS/2 portion imports several routines from the DOSCALLS module, such as DOSOPEN, DOSREAD, DOSALLOCSEG, DOSGETVERSION, or DOSEXIT. It is notable that this old EXEHDR.EXE imports from DOSCALLS by name, while actual OS/2 applications imported by ordinal number.

This EXEHDR.EXE from June 1986 is currently the earliest known OS/2 executable released outside Microsoft/IBM. There is a slight chance that others might have been published with earlier Windows SDKs or perhaps some other Microsoft tools. It is likely that the release of this dual-mode EXEHDR.EXE was an omission, as the OS/2 portion effectively wasted about 16KB of disk space.

The June 1986 EXEHDR utility does not run on any known version of OS/2 (either early betas from mid-1987 or later 32-bit versions). On the other hand, the utility—unsurprisingly—understands its own format and produces the following output when run against itself in a DOS environment:

Magic number:             5a4dH
Bytes on last page:       128
Pages in file:            65
Relocations:              3
Paragraphs in header:     32
Extra paragraphs needed:  0
Extra paragraphs wanted:  65535
Initial stack location:   0455:0800
Word checksum:            ca7fH
Entry point:              0000:1206
Relocation table address: 0040H
Reserved words:
 0000 0000 0000 0000 0000 0000 0000 0000
 0000 0000 0000 0000 0000 0000 0000 0000
New .EXE header address:  4400H
Memory needed:            32K

Module:                   EXEHDR
Description:              EXEHDR.EXE
Linker version:           5.00
32-bit Checksum:          f7de06d1
Data:                     INSTANCE
Segment Table:            00004440 length 16
Resource table:           00004450 length 0
Resident Names Table:     00004450 length 10
Imported Names Table:     0000445c length 157
Entry Table:              000044f9 length 10
Non-resident Names Table: 00004503 length 14
Movable entry points:     1
Segment sector size:      512
Entry point:              seg   1 offset 0fd7
Stack:                    seg   2 offset 16d0
DGROUP:                   2

no. type address  file  mem   flags
  1 CODE 00004600 02ee1 02ee1 relocs, movable, preload
  2 DATA 00007600 00a80 016d0 movable, preload

ord seg offset name

  1 type   offset target
    PTR     2ca2  imp DOSCALLS.DOSWRITE
    PTR     1cad  imp DOSCALLS.DOSSETVEC
    PTR     1729  imp DOSCALLS.DOSEXIT
    PTR     0ff5  imp DOSCALLS.DOSGETVERSION
    PTR     2a5c  imp DOSCALLS.DOSALLOCSEG
    PTR     2dba  imp DOSCALLS.DOSREALLOCSEG
    PTR     2c8e  imp DOSCALLS.DOSCHGFILEPTR
    PTR     2d4a  imp DOSCALLS.DOSCLOSE
    PTR     2e1a  imp DOSCALLS.DOSOPEN
    PTR     2e38  imp DOSCALLS.DOSQFILEMODE
    PTR     1c87  imp DOSCALLS.DOSQHANDTYPE
    PTR     2c73  imp DOSCALLS.DOSREAD
    PTR     2d96  imp DOSCALLS.DOSSETFILEMODE
    BASE    1b6f  seg   2 offset 0000

Both the DOS and OS/2 executables included in EXEHDR.EXE had been built with Microsoft C, presumably version 4.0 with unreleased OS/2 run-time libraries.

It is currently not known whether anyone discovered this back in 1986, or if they understood the implications. The fact that Microsoft was working on “Advanced DOS” was understood at the time, although not many details were known.

Worth noting is also the fact that the LINK4.EXE segmented-executable linker (dated July 18, 1986) shipped with the Windows 1.03 SDK also clearly included some OS/2 support. The list of keywords includes for example PROTMODE and IOPL, neither of which was used with Windows 1.x/2.x or with the multitasking DOS 4.

Enter 1988… around that time Microsoft just released MS-DOS 4.01 and IBM shipped OS/2 1.1. Compare to the others, this OS was years ahead of its time pretty much on every aspect. Now some 25 years later QNX2 is still found running industrial machinery, clean rooms, avionics and military hardware. Some people report systems up and running non stop for 15 years and longer!

It took me similar amount of time to find and acquire a usable media set. QNX2 never seen life on a desktop machine, so finding these was rather hard and expensive adventure. Fortunately I can finally let it see some daylight. Let’s examine how the system will install on a modern hardware under VMware Workstation.

The install is rather straight forward. Floppy boot comes with a login prompt.

After you log in as qnx you need to swap the floppy disk to Boot Utilities and run install. The script guides you through setup steps.

First you need to select the disk controller. For compatibility mode QNX 2 provides access via int 13 (real mode).

Then you partition the disk. QNX partition type is either 7, 8 or 9. You will be asked to mark it bootable later on.

Then you have to select the kernel. QNX can operate in real mode and protected mode on AT286. 

The install script copies all the data from distribution floppy disks, asks about boot loader and active partition. Finally you get to choose some video options.

The system also asks about networking options. Unfortunately it only works with custom Acnet cards so I skipped this. Once complete you are asked to remove the boot floppy disk and reboot the machine. This is what comes up after first hard disk boot.

I guess what is in the system will be the a subject of another post.