It started as one of those irresistible tinkerer experiments: take a two-decade-old 3D accelerator, graft it into a bleeding-edge AM5 system, and see whether retro hardware can still speak to modern Windows. The result reads like a love letter to PC hardware preservation — a 1998 3dfx Voodoo2 12MB card was physically adapted via a PCIe-to-PCI enclosure and coaxed into life on an AMD Ryzen 9 9900X machine running Windows 11, with Quake II rendering correctly — but the victory was partial: a second Voodoo2 added in SLI collapsed the setup. The experiment demonstrates both the romance and the fragility of legacy hardware revival, and it exposes where modern firmware, drivers, and OS security policies clash with the assumptions of late‑’90s designs.
The Voodoo2 is one of those iconic silicon artifacts: a pure‑3D accelerator card from 3dfx that defined late‑1990s PC 3D gaming through the Glide API and SLI (Scan-Line Interleave) multi‑card scaling. The Voodoo2 was sold in 8MB and 12MB configurations and shipped in early 1998, with the 12MB variant offering more texture memory and better results at higher resolutions for titles of the era. Its architecture relied on discrete texture mapping units paired to an FBI (framebuffer interface) chip — a design that shone in multiplayer SLI setups. Fast forward to the present: AMD’s Zen‑5‑based Ryzen 9 9900X— a 12‑core, 24‑thread AM5 processor with high single‑core clocks— is representative of modern silicon that assumes far different system services, bus interfaces, and driver models than a 1998 PC. Bridging these two eras requires several things to be solved in unison: physical connectivity (PCI -> PCIe), legacy driver compatibility on a 64‑bit OS, and overcoming Windows 11 driver signature and kernel expectations. The experiment in question tackled all three.
The experiment leveraged an experimental community effort dating back to the mid‑2000s — an x64 port of Glide drivers commonly associated with developers in the retro community. Those experimental x64 kernel drivers are not official 3dfx releases, but rather community‑reverse‑engineered projects or patches that adapt old driver APIs to modern 64‑bit kernels. The maker of the video credited a developer known by the handle “Colourless” / Ryan Nun for a 2006 x64 Glide driver, which provided the kernel‑side compatibility necessary to run Glide apps on 64‑bit Windows builds — with additional fixes applied for XP compatibility that were helpful for modern instrumentation. This driver history was reported by observers of the experiment, though public archival of those particular driver binaries and full upstream sources is limited and patchy. Treat the driver provenance as community‑driven and partially reconstructed rather than a formally supported vendor release.
Manufacturers and OS vendors could consider formal preservation pathways: signed legacy driver vetting programs, emulation‑friendly firmware modes, or sanctioned hardware bridges that allow museums and collectors to run legacy silicon without disabling core protections. Until then, retro runs will remain a craft built on careful risk management and community knowledge.
For retro enthusiasts, the lesson is clear: authentic hardware revival is possible but requires patience, careful risk management, and an acceptance that parts of the stack (multi‑card SLI, precise driver provenance) may be irrecoverable. For the wider PC community, the experiment is a reminder that software and platform policies shape the long‑term fate of hardware artifacts — and that community knowledge remains the key resource for bridging computing’s living history to modern platforms.
Source: Tom's Hardware https://www.tomshardware.com/pc-com...-amd-ryzen-9-9900x-powered-windows-11-system/
Background / Overview
The Voodoo2 is one of those iconic silicon artifacts: a pure‑3D accelerator card from 3dfx that defined late‑1990s PC 3D gaming through the Glide API and SLI (Scan-Line Interleave) multi‑card scaling. The Voodoo2 was sold in 8MB and 12MB configurations and shipped in early 1998, with the 12MB variant offering more texture memory and better results at higher resolutions for titles of the era. Its architecture relied on discrete texture mapping units paired to an FBI (framebuffer interface) chip — a design that shone in multiplayer SLI setups. Fast forward to the present: AMD’s Zen‑5‑based Ryzen 9 9900X— a 12‑core, 24‑thread AM5 processor with high single‑core clocks— is representative of modern silicon that assumes far different system services, bus interfaces, and driver models than a 1998 PC. Bridging these two eras requires several things to be solved in unison: physical connectivity (PCI -> PCIe), legacy driver compatibility on a 64‑bit OS, and overcoming Windows 11 driver signature and kernel expectations. The experiment in question tackled all three. How the experiment was done — hardware and the physical bridge
The physical challenge: PCI in a PCIe world
Modern motherboards no longer ship with legacy 33‑MHz PCI slots. That elimination is the first barrier to connecting a Voodoo2 (a PCI card) to an AM5 motherboard. The physical solution used in this experiment was an external StarTech PCIe‑to‑PCI enclosure (a boxed adapter that exposes a PCI slot inside an external chassis and connects to the CPU via a PCIe card). This approach allows an old PCI card to be slotted and enumerated by the modern system while maintaining the necessary electrical and mechanical separation. The enclosure is, essentially, a passive translator that uses the motherboard’s PCIe lanes and an adapter card to present legacy PCI wiring to the inserted board. Key hardware points:- The Voodoo2 remained a native PCI device electrically but was connected to the modern system through the external enclosure.
- Power and passthrough concerns are nontrivial: older cards expect a different power envelope and board layout; the enclosure must provide stable power and present clean PCI enumeration.
- Physical clearance and BIOS/UEFI quirks matter; in some cases the card must be placed in a specific host slot or the motherboard must be configured to allow legacy device initialization.
The CPU and platform used: Ryzen 9 9900X on AM5
The experiment ran on an AMD Ryzen 9 9900X platform — a modern Zen 5 desktop processor with 12 cores, high boost clocks, integrated RDNA graphics, and PCIe 5/AM5 platform support. Using such a fast CPU raises timing, resource and compatibility considerations: early Windows 9x/NT drivers were not designed for high‑frequency CPUs and modern firmware stacks. Still, the experiment showed that the Voodoo2 doesn’t suffer the same GHz‑scaling limitations as the original Voodoo 1 family, making it a better candidate for modern rigs. The Ryzen 9 9900X itself is a mainstream high‑end Zen 5 part, widely available since 2024 and used in many modern enthusiast builds.Software hurdles — drivers, OS bitness, and Glide
Glide, legacy drivers, and 64‑bit Windows
The core software issue is this: 3dfx drivers and the Glide API were written for 32‑bit Windows (and in some cases Windows 9x or early NT). Windows 11 is strictly a 64‑bit OS with driver signature enforcement and a vastly different kernel architecture. To make the Voodoo2 accelerate 3D outside of emulation, a working 64‑bit Glide stack is needed.The experiment leveraged an experimental community effort dating back to the mid‑2000s — an x64 port of Glide drivers commonly associated with developers in the retro community. Those experimental x64 kernel drivers are not official 3dfx releases, but rather community‑reverse‑engineered projects or patches that adapt old driver APIs to modern 64‑bit kernels. The maker of the video credited a developer known by the handle “Colourless” / Ryan Nun for a 2006 x64 Glide driver, which provided the kernel‑side compatibility necessary to run Glide apps on 64‑bit Windows builds — with additional fixes applied for XP compatibility that were helpful for modern instrumentation. This driver history was reported by observers of the experiment, though public archival of those particular driver binaries and full upstream sources is limited and patchy. Treat the driver provenance as community‑driven and partially reconstructed rather than a formally supported vendor release.
Driver signature enforcement and OS configuration
Windows 11 enforces signed kernel drivers by default. To load an unsigned, experimental Glide x64 driver, the experimenter disabled driver signature enforcement (a necessary but risky step), and in other cases used legacy compatibility workarounds. The system encountered a typical legacy‑to‑modern stumbling block — a Mapmem error (a memory mapping failure in the Glide stack), which required either switching PCI slots or replacing Glide library files with modified versions to satisfy the 64‑bit kernel’s expectations. These kinds of kernel messages are common when old drivers try to map device memory in ways modern kernels disallow. Omores’ sequence of trial, error, and slot changes shows how fragile the chain is: a single BIOS/slot/driver variable can flip the system from success to unbootable.What worked: Windows 98, Win10 (32‑bit), and finally Windows 11 with tweaks
The path to full success was iterative:- Confirm the hardware side worked by installing Windows 98 on the same machine using the PCIe‑to‑PCI bridge and a legacy driver set — the Voodoo2 functioned in its native environment and rendered Quake II and scores in 3DMark 2001 SE, indicating no immediate electrical or fundamental hardware incompatibility. This was a sanity check more than a headline.
- Move to Windows 10 32‑bit: Using more modern community‑built 32‑bit drivers confirmed the card could run with later versions of Windows that still supported 32‑bit drivers. This is the last Microsoft release that natively supported 32‑bit kernel drivers in a straightforward way.
- Attempt Windows 10 / 11 64‑bit: The experimental x64 Glide driver was necessary here. With unsigned driver loading allowed and a fix applied that was originally made for XP, the Voodoo2 could run on a 64‑bit Windows 10 system. With driver signature enforcement disabled and a careful slot change, that same approach could be extended to Windows 11 23H2, enabling Glide‑accelerated Quake II to run on a modern AM5 rig. The results were undeniably impressive: a 1998 3D accelerator using drivers that trace back to 1996 NT services, with an experimental 2006 x64 driver, running on a 2011‑era OS architecture iteration updated to the modern 64‑bit world.
What failed: SLI didn’t survive the transition
Perhaps the most telling limitation came when attempting to run two Voodoo2 cards in SLI. Historically the Voodoo2’s SLI (Scan‑Line Interleave) offered near‑doubling of fillrate by alternating scanlines between two cards, but it relied on very particular timing, IRQ sharing and old driver behaviors. When the experimenter installed a second Voodoo2 (a Joytech Apollo 3D Fast II 12MB), the Windows 11 build became unstable and refused to accommodate the dual‑card configuration cleanly. The SLI chain brought the setup down; maintaining a single Voodoo2 provided the maximum practical success point. This failure is indicative: single‑card legacy drivers and hardware can sometimes be nudged into modern systems, but multi‑card topology and tightly timed hardware synchronization are far harder to salvage.Deep dive: Why SLI broke and why single card worked
Timing and IRQ assumptions
Older multi‑card setups made assumptions about PCI slot adjacency, IRQ routing, and ISA/legacy bus timings that UEFI/modern PCIe do not preserve. The Voodoo2 SLI expects tightly coupled behavior from two PCI cards placed side‑by‑side; when those expectations are mapped through a PCIe-to-PCI bridge and modern UEFI, the hardware‑level synchronization steps can fail.Driver expectations
Legacy Glide drivers assume direct control over memory mapping, interrupts, and the display pass‑through cable. When two cards try to coordinate via older drivers adapted to a 64‑bit kernel, race conditions and resource collisions are more likely. The Mapmem error and the necessity to swap PCI slots are clues that the driver is struggling with modern memory mapping and device enumeration semantics.Kernel security and mapping policies
Modern Windows kernels are far stricter about who can create device mappings to physical memory and how. Unsigned or reverse‑engineered drivers sometimes use legacy techniques that modern kernels reject or sandbox, and while forcing test signing or disabling enforcement can work for single devices, multi‑device coordination often triggers more aggressive kernel protections. This explains why the single Voodoo2 could be coaxed to work but adding another card crossed a threshold.Why this matters to retro builders, collectors, and preservationists
- Preservation vs. practicality: The experiment is a practical demonstration of hardware preservation through engineering. It proves that many components from the late‑’90s can still be made to run on modern systems, but it also highlights the cost in time and risk (disabling driver protections, fiddling with slots, accumulating fragile configurations).
- Value of community drivers: Community efforts keep legacy hardware alive. The Glide x64 project (and other community patches) are the last line of support for these GPUs; without them, hardware like the Voodoo2 would be relegated to static museum pieces or to software emulation only. However, community builds are rarely as rigorously tested or documented as vendor drivers, and provenance can be shaky.
- Lessons for emulation: Because of timing, multi‑card coordination, and Direct hardware dependencies, many enthusiasts prefer software emulation or wrapper layers (e.g., Glide emulation over OpenGL/DirectX) as a safer, more reproducible route to run classic titles on modern hardware. Emulation lacks the tactile authenticity of real silicon, but it gives a consistent result across platforms.
Technical checklist — how the experimenter got there (reconstructed from the video and reporting)
- Verify card functionality on a native legacy OS (Windows 98) to confirm the card itself is electrically sound.
- Use a StarTech (or equivalent) PCIe‑to‑PCI external enclosure to physically connect the Voodoo2 to the AM5 motherboard.
- Disable driver signature enforcement in Windows 11 to allow loading of unsigned experimental Glide x64 drivers.
- Install updated Glide libraries and kernel driver patches (community builds), apply XP-era fixes where applicable.
- If the system throws a Mapmem or similar mapping error, try changing the host PCI slot, or swap in modified Glide library files known to address the mapping behavior.
- Test single card operation with Quake II and 3DMark 2001 SE. If successful and stable, proceed with further experiments cautiously.
- Attempt SLI only after ensuring single card stability; expect fail modes and be prepared to revert to single‑card configuration.
Strengths of the approach and notable successes
- Authentic hardware results: Running Quake II on a real Voodoo2 is faithful preservation; the result is more authentic than software emulation for those who care about the original rendering pipeline and analog quirks.
- Hardware confirmation: Initial Windows 98 runs and 3DMark tests showed the card itself was fully functional, meaning the experiment was not a salvage attempt but a demonstration of bridging eras.
- Demonstrates modern hackability: The work proves that with the right combination of hardware adapters and community drivers, legacy acceleration can be integrated into a modern stack — valuable proof for museums, retro labs, and enthusiasts.
Risks, caveats, and why caution is warranted
- Security risks: Disabling driver signature enforcement and loading unsigned kernel drivers reduces OS defenses. Doing this on a daily machine or one connected to sensitive networks is unwise.
- Hardware fragility: Pulling old boards in and out of adapters, or operating them in unsupported power/enclosure setups, risks damaging the card or the host.
- Stability and reproducibility: The necessity to change PCI slots to fix a Mapmem error underscores how brittle the process can be; exact BIOS revisions, extension card firmwares, and host boards can yield different results.
- Driver provenance and legal issues: Community drivers may have uncertain licensing or provenance. Some reconstructions and reverse‑engineered drivers could inadvertently include copyrighted binary fragments. Where driver provenance cannot be independently confirmed, flag the claim and proceed with caution.
Practical takeaways for anyone attempting this
- If your goal is authenticity, and you own a Voodoo2 and an AM5 system, this experiment shows it can be done — but be prepared to:
- Work in an isolated test machine.
- Keep backups and drive images.
- Expect to disable driver signing temporarily and to troubleshoot Mapmem/memory mapping errors.
- If your goal is reproducibility and safety, consider:
- Using a VM with a Glide wrapper or software emulation layer that reproduces Voodoo behavior without kernel tinkering.
- Accepting small fidelity losses in exchange for modern stability and no kernel risks.
Broader implications for retro computing and the modern PC ecosystem
This experiment is emblematic of a broader cultural and technical tension between preservation and progress. On one hand, the community’s ability to resurrect Voodoo2 acceleration speaks to the ingenuity and tenacity of retro enthusiasts. On the other, it highlights how modern OS and platform design choices — greater emphasis on signed drivers, stricter memory mapping, removal of legacy slots — make authentic hardware resurrection increasingly niche and brittle.Manufacturers and OS vendors could consider formal preservation pathways: signed legacy driver vetting programs, emulation‑friendly firmware modes, or sanctioned hardware bridges that allow museums and collectors to run legacy silicon without disabling core protections. Until then, retro runs will remain a craft built on careful risk management and community knowledge.
Conclusion
The sight of a 1998 3dfx Voodoo2 rendering Quake II on a high‑clock Ryzen 9 9900X Windows 11 system is a small, glorious miracle of hardware preservation. It’s a technical triumph that balances on a thin wire of modern workarounds: PCIe‑to‑PCI adapters, unsigned experimental drivers, and precise slot/driver choreography. The triumph is partial — a single Voodoo2 can be made to work; two cannot, at least not without unacceptable instability — but that partial victory is meaningful.For retro enthusiasts, the lesson is clear: authentic hardware revival is possible but requires patience, careful risk management, and an acceptance that parts of the stack (multi‑card SLI, precise driver provenance) may be irrecoverable. For the wider PC community, the experiment is a reminder that software and platform policies shape the long‑term fate of hardware artifacts — and that community knowledge remains the key resource for bridging computing’s living history to modern platforms.
Source: Tom's Hardware https://www.tomshardware.com/pc-com...-amd-ryzen-9-9900x-powered-windows-11-system/
