For retro-PC enthusiasts—and Windows users considering whether this could replace a Voodoo card, an emulator, or a familiar FPGA platform—the distinctions matter more than the raw numbers.
What zSST and z486 XL are trying to recreate
zSST is described as a SystemVerilog implementation of the 3dfx Voodoo Graphics, also known as SST-1. The key phrase is programming model. Software communicates with an SST-1 through defined registers, framebuffer behavior, and texture-memory interfaces. Reproducing those visible behaviors is what allows original software written for Glide-era Voodoo hardware to have a chance of working.
The graphics core is integrated with z486, an FPGA PC platform, to create z486 XL: an experimental DOS machine implemented on the programmable logic of a Kria KV260 board. The documented build runs the PC side at 100 MHz, has a 512 KiB write-back L2 cache, and uses the board’s DDR memory rather than relying on a separate SDRAM module or a conventional FPGA expansion board.
That makes this notably different from the route many PC retro enthusiasts know best. It is not presented as a MiSTer core, and it is not a drop-in graphics card for an existing Windows or DOS desktop. It is a complete FPGA system running on particular KV260 hardware. A prospective user needs the board itself, storage via microSD, a display, and USB input devices. That deployment requirement alone puts it in a specialist category rather than the mainstream replacement path for a Windows gaming PC.
There is also a useful conceptual distinction between a system that runs a Voodoo-targeted title and a literal duplication of every original chip-level design decision. zSST is pursuing compatibility with the SST-1 software-facing contract, not preserving every physical characteristic of a 1996 accelerator board.
The feature set is substantial, but validation is narrow
The implemented graphics scope is far beyond a simple framebuffer demonstration. zSST is reported to support fixed-point and floating-point prepared-triangle interfaces, depth and alpha testing, fog, blending, dithering, framebuffer access, buffer swaps, point and bilinear texture filtering, mipmapping, and several texture formats.
That list aligns closely with important published SST-1 capabilities. Original Voodoo Graphics documentation describes alpha blending, depth buffering, dithering, fog, true-perspective texture mapping, level-of-detail mipmapping, and bilinear filtering. In other words, the project is implementing the functions that made the original Voodoo platform technically distinctive rather than only its broad visual style.
Still, implemented features and demonstrated compatibility are not interchangeable. The project’s own reported game validation centers on Tomb Raider. In Level 2, the author observed roughly 12 displayed buffer swaps per second over approximately 20 seconds. That is encouraging evidence that the software interface and enough of the rendering path work together in a real game. It is not, however, evidence of broad Glide compatibility.
No tested-title matrix, failure list, or independent reproduction is available in the supplied material. Edge-case accuracy is especially difficult in hardware recreation work: a game may depend on undocumented timing, register sequencing, numerical precision, memory behavior, or a quirk that was harmless on original boards but exposed in a new implementation. Until substantially more games are tested, the sensible description is that zSST has an important early compatibility proof point, not that it has established comprehensive Voodoo game support.
The presently documented scope also should not be stretched into a claim that all of the Voodoo family has been recreated. There is no verified basis here to call it a completed recreation of multi-TMU configurations, Scan-Line Interleave systems, or later Voodoo generations. For collectors and preservationists, that boundary is important: an original single-Voodoo software target is a much narrower engineering problem than the entire 3dfx product line.
Why its memory architecture is not a copy of the original card
One of zSST’s most revealing technical choices is its memory system. The original SST-1 architecture used separate 64-bit interleaved memory datapaths for the framebuffer interface chip, commonly called FBI, and the texture unit, TREX. That separation reflects the constraints and throughput strategy of the original hardware era.
The KV260 design has a different challenge: graphics and PC functions share modern DDR memory. Rather than attempt to imitate the old memory arrangement literally, the project uses a set of mechanisms designed to manage DDR latency and preserve usable graphics throughput. The reported design includes:
- an 8 KiB texture cache with 64-byte cache lines;
- up to eight outstanding texture fetches;
- a replay queue for work that cannot proceed immediately; and
- a 64-entry reorder buffer to retire work in the required order.
This is an engineering adaptation, not necessarily a compatibility flaw. In fact, it is a practical illustration of what FPGA preservation can mean. The externally observable results must be close enough for old software, while the internal logic is allowed to use resources and strategies appropriate to the target platform.
The trade-off is that internal architectural differences can create subtle behavior differences. Shared DDR arbitration, cache effects, request reordering, and replay behavior can affect timing in ways that original software might notice. The project identifies the SST-1 specification as a behavioral contract, but limited game testing means the degree of success on unusual workloads remains unresolved.
The 78.5 MPix/s figure is not a game benchmark
The most likely number to be misread is zSST’s reported 78.5 megapixels per second for textured triangles. It sounds like a direct speed comparison with a Voodoo 1, but it is not one.
The figure comes from a 100 MHz zSST simulation using a DDR timing model. It is a renderer-throughput result under that modeled setup—not a measurement from a physical KV260 board matched against a physical Voodoo Graphics card, and not a frames-per-second score from a game. It can show that the modeled pipeline has promising potential, but it cannot prove that zSST is faster than original Voodoo hardware in games.
The original SST-1 specification itself gives performance estimates only under explicit conditions, including a 50 MHz graphics clock, 50 ns EDO DRAM, a 640×480 display at 60 Hz, and peak PCI data supply. The specification further warns that effective performance drops when the CPU or PCI master cannot supply data at the assumed rate.
That is why a single megapixels-per-second number is insufficient for historical comparison. Workload composition, texture-cache behavior, PCI or system-bus delivery, enabled rendering effects, memory timing, display resolution, and host CPU behavior all change the result. A renderer simulation and an original-card estimate can both be useful, but they answer different questions.
The right conclusion is modest but valuable: the simulation result suggests the redesigned pipeline can sustain a notable rate in the tested modeled scenario. It does not establish a speed advantage, parity, or a general real-world performance level.
Doom and Quake do not measure Voodoo acceleration here
Two additional figures require equal care. z486 XL reports Doom at 38.5 FPS and Quake 1.06 at 8.1 FPS as complete-PC board measurements. They are not reported as zSST or Glide performance benchmarks.
Most importantly, the Quake test is specifically identified as Quake 1.06, not GLQuake. It therefore cannot be read as proof of Voodoo-accelerated Quake performance. Tomb Raider remains the only reported tested 3dfx game, with the approximately 12 displayed buffer swaps per second observation noted above.
For users accustomed to benchmark charts on Windows, this is a familiar methodological issue. A score must be tied to the component and API it actually exercises. Doom and software-rendered Quake are informative about the 100 MHz FPGA PC as a whole: processor behavior, memory subsystem, DOS environment, and system integration. They do not isolate the graphics accelerator.
Similarly, a displayed buffer-swap rate is not automatically an engine FPS counter. It may be a useful indicator of what appeared on screen over the measured period, but it should not be treated as a standardized, directly comparable game benchmark without knowing the title’s rendering and presentation behavior in detail.
What this means for Windows and retro-PC users
z486 XL is not an obvious answer for someone who wants to play 3dfx games on a modern Windows machine tonight. The supplied evidence does not establish Windows driver support, integration with contemporary PC hardware, or broad game compatibility. Its intended environment is an FPGA-hosted DOS PC, not a Windows graphics stack.
For that immediate goal, the project is better viewed as a research and hobbyist platform than as a consumer replacement for original hardware, software emulation, or established compatibility layers. It requires specialized hardware and accepts early-stage performance and compatibility.
Its value is clearer in three other areas.
First, it contributes to hardware preservation. A public HDL implementation of an old programming model can be inspected, tested, modified, and potentially ported to other FPGA targets. The available project material indicates that the graphics work and its full-system integration are publicly available under an Apache-2.0 license, although independent hardware reproduction of the reported results has not yet been provided.
Second, it creates a platform for empirical compatibility work. Each newly tested title can reveal whether a particular Voodoo behavior is missing, inaccurate, or dependent on timing. That is more durable than simply observing that a game runs under a particular emulator version.
Third, its DDR memory redesign offers a useful lesson for modern reimplementations. Faithful computing history is often about reproducing an interface and observable behavior under new constraints, not about insisting on identical memory chips, bus widths, or board layouts.
A promising milestone, not a finished Voodoo replacement
zSST and z486 XL demonstrate serious technical progress: a 100 MHz FPGA DOS PC, a substantial SST-1-style rendering feature set, a carefully designed shared-DDR strategy, and an actual Voodoo-targeted game running in the project’s experimental environment.
Yet the evidence supports restraint. The 78.5 MPix/s figure is a simulation throughput result, not game FPS or a matched Voodoo 1 comparison. Doom and Quake measurements characterize the full FPGA PC rather than Glide rendering, and the Quake build tested is not GLQuake. Tomb Raider is the meaningful 3dfx validation case, but it remains just one substantially tested title.
That does not diminish the achievement. It defines it accurately. zSST is an early open hardware effort aimed at recreating the original Voodoo Graphics programming experience on a modern FPGA platform. For now, it is best understood as a credible and technically ambitious foundation for further validation—not as final proof that the Voodoo era has been completely recreated in programmable logic.