Voodoo 5 6000 Lab Method: Two Motherboards, One Dead BIOS

Key takeaways

• One card, two motherboards: an EPoX EP-8RDA+ (nForce2) with 511 MB whose BIOS died mid-campaign, then an Athlon XP 2400+ at 2004 MHz with 255 MB. Their numbers are never placed in the same table.
• The software is pinned by hash, not by version string: AmigaMerlin 3.1-R11 (driver 5.1.2605.5, dated 6-9-2005), whose OpenGL ICD identifies itself as 1.2 Mesa 6.3 by Brian Paul.
• "cfg N" is the value of one registry string, SSTH3_SLI_AA_CONFIGURATION; the labels beside it are the driver's own words from 3dfx Tools, quoted — not the lab's description of the hardware.
• One driver setting per clean boot. A second write in the same boot can wedge the display driver, and a wedged board still answers the network.
• A setting counts as applied only when the rendering changes. Reading the value back proved nothing, which is how Part 4 happened.
• The engine takes every picture. The remote agent's screen capture of a Glide exclusive-fullscreen surface returns noise.

Which two machines hosted the Voodoo 5 6000?

The card arrived once and went into two boards. Host 1 was an EPoX EP-8RDA+ — an nForce2 board, identified by its PCI bridge IDs — with 511 MB and Windows XP SP3. It produced the campaign's first verified cells and then stopped booting with no video: a corrupted main BIOS, with the warning signs recorded in Part 5. Its CPU clock is deliberately not printed here, because the failing BIOS reported two different values on two days.

Host 2 is an AMD Athlon XP 2400+ at 2004 MHz (family 6, model 8) with 255 MB and Windows XP SP3, driving the same Gateway VX1120 4:3 CRT. Its published hardware record lists the CPU's instruction set as FPU, MMX, CMOV, 3DNow! and SSE — no SSE2, which matters for the driver plans in Part 6 — and does not record the chipset, so this series does not name one.

The card itself identifies as PCI\VEN_121A&DEV_0009&SUBSYS_0001121A behind a HiNT bridge VEN_3388&DEV_0021 — the 6000's subsystem ID, where a Voodoo 5 5500 reads 0002121A — and Glide reports four framebuffers present under every setting. It ran in the 128 MB mode of its dual-VBIOS switch throughout; the 256 MB mode is Part 6's business.

What exactly was under test?

AmigaMerlin ships rebranded 3dfx binaries whose version resources do not reliably distinguish builds, so the lab identifies every file by size and MD5 and records those on each benchmark row. The driver package installed through oem2.inf under the provider string "3dfx Interactive, Inc."; AmigaMerlin 3.1 R11 itself dates from June 2005 and is the community's usual choice for a Voodoo 5 on Windows XP (VoodooAlert, PhilsComputerLab).

The OpenGL under test is Mesa. That is worth a sentence on its own: the ICD AmigaMerlin installs is a Mesa 6.3 build over Glide, and every Quake III row in this series carries its renderer string, Mesa Glide v0.63 Voodoo5 6000 (tm). Quake III loads it by name (r_glDriver 3dfxogl), so there is no ambiguity about which library drew the frames. Unreal Tournament, by contrast, was run through its native Glide render device with no OpenGL in the path — which is what let Part 4 separate a driver fault from an ICD fault. Full file list: the versions record.

What does "cfg 2" mean, and why are the driver's labels only quotes?

On this driver the chip topology and the anti-aliasing mode are a single registry string, SSTH3_SLI_AA_CONFIGURATION, under the display adapter's Glide settings key. The 3dfx Tools control panel exposes it as three pick-lists whose values the lab read out of the driver's own descriptor keys; the words in the table are the driver's, verbatim.

The labels are printed as quotes because the measurements contradict them. The setting the driver calls "Dual Chip" reaches 3.47 times the "Single Chip Only" figure at 1600×1200 and beats "Quad Chip" at every resolution (Part 3), and every anti-aliasing label produced a frame identical to its no-AA sibling (Part 4). What the lab can state is which value was written and what the card then did; how many VSA-100s were actually working is an open question, not a caption.

How was each run taken?

The rules below are the method. Each one exists because its absence produced a wrong number at some point in the campaign.

• One driver setting per clean boot. The value is written, the machine is rebooted, the setting is read back, a Glide probe confirms the board can still initialise, and only then does a game start. Resolutions are cycled freely inside that boot, because a resolution change is not a topology change.
• A setting counts as applied only when the rendering changes. The harness once recorded a column called aa_verified that meant "the registry value read back". It now records reg-readback-only, and any anti-aliasing cell that keeps 97% or more of its no-AA frame rate is reported as not applied.
• Quake III demo four, 1,260 frames, 16-bit colour, 16-bit depth, com_maxfps 0, swap interval 0, at 640×480, 800×600, 1024×768, 1280×960 and 1600×1200. The high mode is 1280×960, not 1280×1024, because the monitor is a 4:3 tube and 5:4 would be a different pixel count and a squashed image.
• The latched cvars are set before the renderer starts. r_mode, r_customwidth and r_colorbits are read once at renderer init, so they are supplied both in a config the engine executes before R_Init and on the command line, and no vid_restart is ever issued — a renderer restart is exactly what hung the driver at the 8-sample setting on host 1.
• The box is quiesced: the fleet's AI engine, wallpaper rotator, Windows Update client, the 3dfx Tools tray application and stray error reporters are stopped before a run. These are single-core machines; a background process reads several fps low.
• Every row records what ran: game binary path, size and MD5; driver package and version; Glide and ICD hashes; OS build; agent version; and the renderer string parsed from the engine's own log. A row without its versions cannot be compared with a later one.
• Results are written somewhere durable. Fourteen measured rows were lost when a session's scratch directory was deleted; the harness now refuses a temporary output path, and the lost cells were re-measured rather than reconstructed from notes, because a reconstructed row would have no renderer attribution.

Why is a resolution change safe when a settings change is not?

Because the failure the lab kept meeting is in the display driver, not the game. Writing SSTH3_SLI_AA_CONFIGURATION more than once within a boot — and sometimes creating a second Glide context after a single write — leaves the driver wedged: the game window opens, the renderer never identifies itself, and the machine either loses its remote agent or sits with the game on screen until someone cuts the power.

Two consequences shaped the method. First, agent liveness is not board liveness: the remote agent kept answering on a machine whose 3D board could no longer open a context, so six configurations were briefly and wrongly recorded as "wedges the driver" before the lab learned to probe the board separately. Second, a Run-key watchdog now restarts the agent within about 30 seconds when a wedge kills it — proven by killing it on purpose — which turns most wedges into a remote reboot instead of a walk to the machine. It does not help when the game is frozen on screen; that still needs a person.

Why are the two hosts never compared?

The same card, the same driver files and the same setting gave 150.2 fps at 640×480 on host 1 and 122.8 then 108.1 on host 2. Nothing about the card changed; the machine did. A single-resolution comparison across those two boxes would say more about 511 MB versus 255 MB of RAM and two different boards than about four VSA-100s, so host 1's four verified cells stand in their own table in Part 3 and are never subtracted from host 2's.

Repeatability within a host is the check that matters, and it is reported honestly. Two full ladders for the "Single Chip Only" and "Quad Chip" settings were taken on host 2 on different days: three of the eight fill-bound cells landed within 0.1 fps of their first run and none moved more than 1.7%, while the CPU-bound 640×480 cell fell 8% and 12%. The lab's hypothesis is that 640×480 is the noisy cell because it is CPU-bound; the caveat is that the agent watchdog — a loop that polls the process list every 30 seconds — was installed between the two runs, and a re-measurement with it paused was scheduled but host 2 went offline before it ran.

How were the images captured?

The remote agent can photograph most fullscreen games on Windows XP, but a Glide exclusive-fullscreen surface is the case where it cannot: what it returned for Unreal Tournament was dark noise, and a capture that might be resampled or of the wrong buffer is worse than none when the question is edge quality. So every image in this series is the engine's own — screenshotJPEG in Quake III on a fixed frame of demo four, and Shot in Unreal Tournament, triggered with the F11 key the game already binds. Unreal Engine 1 accepts a synthetic keystroke in exclusive fullscreen; id Tech 3 does not, which is why the two engines needed two routes.

When an engine will not write a log, its own on-screen counter is the measurement channel: Unreal Tournament's stat line, read off the engine's own screenshot on host 2 at the driver's "Quad Chip, Fastest Performance" setting.

A deterministic scene turned out to be the hard part. Quake III's demo playback is deterministic and wait counts frames, so the same frame is photographed at every setting regardless of frame rate. Unreal Tournament's ?quickstart spawns at a random start point, so two of its frames differ in most of their pixels for reasons that have nothing to do with anti-aliasing; there the lab judged edge quality, which does not depend on the scene, and quantified it with a per-column edge metric whose script is published with the evidence.

What can this method not tell you?

It cannot give a frame-rate table for any anti-aliasing setting, because none of them engaged (Part 4); every such number would describe the card with AA requested and not delivered. It cannot give an Unreal Tournament frame-rate table: the build's -benchmark mode never exits on this system, so UT99's figures are single readings of its stat overlay, not averages. It cannot name host 2's chipset, and it cannot say how many chips each driver setting really lights up. And it cannot compare this card with a Voodoo3 3000 or a Voodoo 5 5500 — no other card was measured under these rules. Everything it can say is in the results CSV and the campaign dossier, including every correction.

Bottom line

One card, two hosts, files pinned by hash, one setting per boot, and a rule that a setting is real only when the picture changes. That discipline cost a lot of reboots and produced fewer numbers than a naive sweep would have — and every number it did produce can be traced to the exact binary, driver and frame it came from. The card's own benchmark page renders those rows with their host on each one, and the site's methodology lists the Retro Lab as a named source.

Related guides

• Part 1 — the card that never shipped, and the reproduction that did
• Part 3 — Quake III at five resolutions, and the 3.47× spread
• Why Nvidia killed 3dfx — and how Voodoo still shapes every GPU launch
• Building a period-correct 1999 Voodoo3 Windows 98 PC
• Glide on modern PCs: dgVoodoo2 and nGlide for 3dfx-era games

Citations and sources

• https://nscagentstorage.blob.core.windows.net/article-images/voodoo5-6000-strange-god/dataset/host2-124-versions.json — the exact software under test on host 2, by size and MD5 (accessed 2026-09-16)
• https://nscagentstorage.blob.core.windows.net/article-images/voodoo5-6000-strange-god/dataset/host2-124-results.csv — every host 2 row with its renderer string and versions (accessed 2026-09-16)
• https://nscagentstorage.blob.core.windows.net/article-images/voodoo5-6000-strange-god/dataset/campaign-dossier.md — method, retractions and status (accessed 2026-09-16)
• https://nscagentstorage.blob.core.windows.net/article-images/voodoo5-6000-strange-god/dataset/fsaa-evidence-README.md — what each evidence frame proves, and the edge metric (accessed 2026-09-16)
• https://www.voodooalert.de/board/forum/index.php?thread/9135-amigamerlin-3-1-r11-erschienen/ — AmigaMerlin 3.1 R11 release discussion (accessed 2026-09-16)
• https://www.philscomputerlab.com/drivers-for-voodoo-5.html — Voodoo 5 driver options on Windows XP (accessed 2026-09-16)

This is a first-party lab report: the measurements above were taken by the SpecPicks Retro Lab on its own hardware. The full dataset, method, driver and game file hashes, evidence frames and every correction are published at https://nscagentstorage.blob.core.windows.net/article-images/voodoo5-6000-strange-god/dataset/campaign-dossier.md. It is not editorial synthesis of third-party sources.

— SpecPicks Retro Lab · Last verified Sep 16, 2026