The Maker Who Solved the Saturn's Quads Problem Just Hit a Wall on the 3DO

The experiment was supposed to be about running 3DO games on the MiSTer. It ended up being about why you can't — not really, not yet, not accurately — and why the person saying so is the one who matters most.

Sergiy Dvodnenko, better known as srg320, is the FPGA core developer behind MiSTer's Sega Saturn core. The Saturn — a console whose architecture defeated commercial emulators for most of its afterlife, whose warped-quad rendering pipeline resisted triangle-based GPU translation for decades — runs on a DE10-Nano because srg320 figured out how to make it fit. That is not a small sentence. The Saturn's dual-SH2 CPU arrangement, its VDP1 sprite distortion, its VDP2 background rotation — the entire system fought the idea of being cloned in programmable logic, and srg320 made it work. Per Time Extension's April 2026 report, sourcing an interview at ReadOnlyMemo, this same developer has now said publicly that the 3DO Interactive Multiplayer — a console most people consider simpler than the Saturn — cannot be accurately replicated on the MiSTer's current FPGA.

That statement deserves the full stop it gets. The person who solved one of FPGA preservation's hardest problems is telling the community that the next problem is harder in a way that doesn't bend to effort alone.

The Wall Is Made of Block RAM

The constraint is specific, which is why it matters. The DE10-Nano uses an Intel (formerly Altera) Cyclone V FPGA. The Cyclone V's defining limitation for console replication isn't its logic element count — srg320's Saturn core proved there's enough combinational logic to model complex systems. The limitation is Block RAM (BRAM): the on-chip memory available for fast, cycle-accurate storage of a target system's internal state.

The 3DO's architecture, designed by The 3DO Company and manufactured by partners including Panasonic, Goldstar, and Sanyo, centers on three custom ASICs: the ARM60 CPU, the CLIO (I/O and audio controller), and the MADAM (math and graphics engine). MADAM handles the CEL engine — the 3DO's sprite-compositing and rendering pipeline — and interfaces with 2 MB of VRAM and 1 MB of system DRAM. Per srg320's accounting, accurately modeling the interplay between these chips demands more on-chip memory than the Cyclone V can provide. The BRAM budget on the DE10-Nano tops out at roughly 553 KB of embedded memory blocks. The 3DO's architecture, once you account for VRAM, DRAM, DSP state, and the internal registers of CLIO and MADAM, exceeds that budget.

This is not an optimization problem. Optimization assumes the ceiling is soft — that clever packing or time-multiplexing can make the data fit. srg320's position, as reported by Time Extension, is that the ceiling is structural. The Cyclone V doesn't have enough BRAM, full stop. You can move some storage off-chip to SDRAM, and the existing 3DO core does this, but off-chip memory introduces latency that breaks cycle-level timing. The result is a core that runs games — as we've covered, the MiSTer 3DO core already boots titles — but cannot claim the cycle-accurate fidelity that defines MiSTer's highest-quality cores.

Why "It Runs Games" Is Not the Same as "It's Accurate"

This is the distinction srg320 is drawing, and it's the one that separates FPGA replication from software emulation in the first place. A software emulator like Yaba Sanshiro or Kronos can tolerate timing approximations because the CPU executing the emulator runs orders of magnitude faster than the target system — there's headroom to catch up, reorder, smooth over. An FPGA core, by contrast, rebuilds the target hardware's timing in silicon. Every register read, every bus arbitration, every video-output scanline happens at the rate the original hardware produced it. When a core needs more fast memory than the FPGA provides, the developer faces a choice: break timing (use slow off-chip RAM and accept inaccuracy) or stop (declare the platform beyond the chip's capability).

srg320 chose to say it out loud. That choice is the real subject of this piece.

"The person who solved one of FPGA preservation's hardest problems is telling the community that the next problem doesn't bend to effort alone. That kind of honesty is rarer than the engineering."

The Saturn Solved, the 3DO Declared

To appreciate the weight of srg320's statement, you have to understand what the Saturn core cost. The Sega Saturn's dual-CPU architecture — two Hitachi SH-2 processors running in parallel, sharing a bus, fighting each other for memory bandwidth — was the console's defining design decision and its emulation's defining obstacle. Software emulators struggled for years to synchronize the two SH-2s accurately. SSF, the gold-standard Windows emulator for most of the Saturn's afterlife, relied on high-level emulation tricks that worked for most games but failed on titles that pushed unusual timing. The Saturn was, for two decades, the console that proved hardware recreation was the only fully honest answer.

srg320's MiSTer Saturn core delivered that answer. It models both SH-2 CPUs, the VDP1 (sprite/polygon engine with its infamous distorted-quad rendering), the VDP2 (background/rotation engine), the SCU (System Control Unit and its DMA controller), and the SCSP (sound processor with its own Motorola 68000 CPU). All of it fits on the Cyclone V. The BRAM budget is tight — Saturn developers at the time will tell you the console itself was tight — but srg320 made it work through meticulous resource allocation, not through compromise on accuracy.

When that same developer says the 3DO exceeds the chip's capacity, the statement carries the weight of proven capability. This is not someone speculating from outside the problem. This is the person who has lived inside the hardest version of the problem and is reporting what they found when they opened the next door.

What the 3DO Actually Demands

The 3DO's reputation as a "simpler" console is a consumer-facing illusion. The system shipped in 1993 as a multimedia appliance with ambitions beyond gaming — Trip Hawkins positioned it as a living-room computer, and the hardware reflects that scope. The ARM60 CPU (a 12.5 MHz ARM6 variant) is straightforward by modern FPGA standards, but the two custom ASICs surrounding it are not.

MADAM handles the CEL engine, which composites layered sprites with per-pixel effects including translucency, corner color interpolation, and subpixel positioning. It interfaces with 2 MB of VRAM through a 32-bit bus. CLIO manages audio (a 13-channel DSP with its own memory), controller I/O, timers, DMA, and CD-ROM interfacing. Both chips maintain significant internal state — registers, FIFOs, status flags — that must be modeled in BRAM to maintain cycle accuracy.

The 2 MB VRAM alone would consume a disproportionate share of the Cyclone V's ~553 KB BRAM budget if stored on-chip. Moving it to SDRAM is possible (and is what the current 3DO core does), but SDRAM access on the DE10-Nano is shared with the Linux host system and other cores, introducing variable latency that prevents the tight, deterministic timing an accurate core requires. Per srg320's analysis, there is no configuration of the existing DE10-Nano platform that resolves this conflict.

The Honest Accounting

The FPGA preservation community has a culture of announcements. A new core boots its first game; screenshots circulate on social media; compatibility lists appear on GitHub. The excitement is genuine and usually earned — every new core represents hundreds or thousands of hours of unpaid labor by developers who care about hardware they grew up with. But the announcement culture has a blind spot: it rarely talks about what can't be done, or what won't be done well.

srg320's public accounting of the 3DO's BRAM problem is the opposite of an announcement. It is a constraint report filed by the person most qualified to file it. Per the Time Extension piece, srg320 frames this not as a failure but as a fact about the relationship between two pieces of hardware — the 3DO's ASICs and the Cyclone V's architecture. The 3DO is not too complex in the abstract. It is too complex for this chip.

That framing matters because it points forward. A different FPGA — one with more BRAM, like the Intel Agilex or a larger Cyclone 10 GX — could potentially host an accurate 3DO core. The problem is solvable. It is not solvable on the hardware the community already owns, and srg320 is saying so before anyone wastes months discovering it independently.

Who srg320 Is, and Where to Find the Work

Sergiy Dvodnenko (srg320) is a Ukrainian FPGA developer whose MiSTer cores include the Sega Saturn, the Sega 32X, and contributions to several other system implementations. The Saturn core — his most significant work — is available on the MiSTer-devel GitHub organization. His work on the 3DO core, including the BRAM analysis, is documented in the same ecosystem. The interview source cited by Time Extension is ReadOnlyMemo, a publication that covers FPGA and emulation development.

Credit here is not decorative. srg320 is a solo developer working without corporate backing, without a marketing department, without anyone to package the message. When someone in that position publishes a constraint report instead of a hype thread, the preservation community should treat it as the technical document it is — and should ensure the person who wrote it gets named every time it's cited.

What This Means for the MiSTer Platform

The MiSTer FPGA project is built on the DE10-Nano, a $150 FPGA development board that was never designed for console replication. Its adoption as a preservation platform is one of the great accidents of the retro-computing scene — Sorgelig (the MiSTer framework developer) recognized that the Cyclone V was powerful enough for most classic systems, and the community built an ecosystem around it. That ecosystem now includes cores for dozens of consoles, home computers, and arcade boards, and it remains the most active FPGA preservation project in the world.

But the DE10-Nano has a ceiling, and the 3DO just marked it. The Saturn was close to that ceiling — srg320's core uses nearly all available BRAM. Every console generation after the Saturn (and several contemporaries, including the 3DO) will push past it. The PlayStation 1 core, the N64 core — these systems all demand more on-chip memory than the Cyclone V provides. The MiSTer community has discussed FPGA upgrades for years, and srg320's 3DO accounting gives that discussion a concrete, cited, technically specific anchor.

This is not a crisis. It is a boundary condition. The DE10-Nano does what it does — and what it does is extraordinary for the price. But the next generation of FPGA preservation will need a different chip, and the developer who knows the Cyclone V's limits better than almost anyone just drew the line.

What Comes Next

The 3DO core will continue to exist on MiSTer in its current form — functional, playable, not cycle-accurate. For many users, that's sufficient. The games boot, the audio plays, the experience is recognizable. But for the subset of the community that uses MiSTer precisely because it promises hardware-level accuracy — the people who chose FPGA over software emulation because the timing matters — srg320's report is a signal to watch the hardware roadmap, not the core roadmap.

The question now is which FPGA platform inherits MiSTer's ecosystem. The Analogue Duo and Analogue 3D use proprietary FPGA implementations with larger resource budgets, but they're closed systems — no community cores, no user-modifiable HDL. An open-platform successor to the DE10-Nano, with a larger Cyclone or an Agilex-class chip, would give developers like srg320 the BRAM headroom to finish what the Cyclone V started. That board doesn't exist yet. When it does, the 3DO will be one of the first systems to prove it was worth building.

In the meantime, the most useful thing srg320 has given the community isn't a core. It's a number — the BRAM deficit between the 3DO's requirements and the Cyclone V's capacity. That number is the starting line for whatever comes next.