This video details the ambitious project of connecting and operating a vintage 1998 3dfx Voodoo 2 3D accelerator card on a modern 2023 Raspberry Pi 5 single-board computer. The creator recounts their journey, starting from initial hardware compatibility challenges (5V PCI vs. 3.3V slots) and the eventual use of a PCIe to PCI bridge. After initial success in detecting the card, attempts to use native Linux drivers (SSTFB framebuffer and the open-source Glide driver) revealed instability and artifacts specific to the ARM64 architecture, leading to the development of a custom kernel module. The solution ultimately involved running games within a modified DOSBox X emulator, with all Voodoo 2 I/O operations routed through an IOCTL interface to the kernel driver, rather than direct memory-mapped I/O. This workaround, which introduces significant delays, resolved the observed graphical glitches and crashes, suggesting an underlying issue with how ARM64 PCIe transactions are handled by the vintage hardware. Future plans include building bus analyzers to investigate these subtle transaction differences.
Running a Vintage 3dfx Voodoo 2 on a Raspberry Pi 5: A Deep Dive into Retro Hardware Compatibility
0:00 Project Goal: The video outlines the journey of attempting to run a 1998 3dfx Voodoo 2 3D accelerator card on a 2023 Raspberry Pi 5, an ambitious inter-generational hardware compatibility challenge.
0:22 Personal Motivation: The creator shares a nostalgic motivation, stemming from their teenage years owning Voodoo cards and a long-standing desire to program vintage 3D hardware using APIs like Glide, or even bare-metal register programming.
2:53 Hardware Setup: The project required a PCI Express to PCI bridge (specifically, an ASMedia ASM1083-based adapter) to connect the 5V-keyed Voodoo 2 card to the Raspberry Pi 5's modern PCIe slot, as direct connection was not possible.
5:40 Initial Detection Success: The Voodoo 2 card was successfully detected by lspci on the Raspberry Pi 5, confirming that the basic PCI functionality was working through the bridge.
6:06 Voodoo 2 PCI Characteristics: The Voodoo 2 is described as a relatively simple PCI device, exposing a single 16MB memory-mapped I/O BAR (Base Address Register) and notably not utilizing I/O ports or bus mastering (DMA), which simplifies compatibility.
6:41 SSTFB Driver Issues: Attempts to use the Linux kernel's SSTFB framebuffer driver for Voodoo cards on the Raspberry Pi 5 resulted in graphical artifacts (missing writes), whereas the same driver worked flawlessly on x86 systems, indicating a potential ARM64 or Raspberry Pi 5-specific problem.
8:43 Native Glide Driver Challenges: Efforts to port the official, open-source 3dfx Glide driver to ARM64 were unsuccessful due to the driver's outdated kernel module design, missing necessary PCI initialization calls, and extensive use of problematic 32-bit pointer math in the user-space library, leading to crashes.
12:26 Emulator Approach: A new strategy was adopted: using a modified DOSBox X emulator (chosen over 86Box for performance) to run DOS games. The emulator was altered to intercept emulated PCI accesses and redirect them to the real Voodoo 2 card via a newly written custom kernel driver.
15:34 Initial Emulator Success: Diagnostic tools run within the emulator successfully detected and provided information about the Voodoo 2, confirming the basic communication path was established.
15:52 Tomb Raider Instability: Despite initial success, running Tomb Raider revealed persistent issues; the game would often hang after drawing only a single frame, and the card could enter a "bad state" requiring a cold hardware reset.
17:11 Voodoo 2 Command FIFO: The video briefly explains a key Voodoo 2 performance feature: a large external command FIFO located in frame buffer memory. This allows the CPU to queue drawing commands without waiting for the card, greatly improving efficiency.
21:41 Debugging & IOCTL Fix: Extensive debugging, including adding memory barriers and using kernel-level I/O functions, improved stability but didn't fully resolve the issues. The ultimate solution involved no longer memory-mapping the PCI bar directly to user space; instead, every I/O operation was routed through an IOCTL (Input/Output Control) request to the kernel driver.
24:44 Root Cause Hypothesis: The IOCTL solution, which successfully allowed Tomb Raider to run without crashes or graphical glitches (barring expected game quirks), is believed to work by introducing significant delays between I/O operations. The creator theorizes that the underlying issue is a subtle difference in how PCIe transactions are issued by ARM64 systems compared to x86, which the vintage Voodoo 2 hardware is sensitive to.
26:09 Future Work & Call to Action: To definitively diagnose the problem, the creator plans to build PCIe and/or PCI bus analyzers to monitor raw transaction data. The video concludes with an invitation for viewers to share their theories or suggestions and encourages subscriptions for future updates on this and other tech projects.