The MiSTer 3DO Core Is Already Running Games — Here's What That Means for the FPGA Authenticity Argument

What landed in March. An early-beta 3DO core for MiSTer FPGA — the first FPGA implementation of the 3DO Interactive Multiplayer to reach a state where actual commercial games load and run, not just internal test ROMs. The reporting via Prism News and the GBAtemp MiSTer thread is consistent: not all titles work yet, frame rate and accuracy vary by game, the core is in active development with weekly improvements. This is what an early beta looks like — partial coverage, visible warts, real progress. It is also already further than software emulation has ever gotten on this system.

Why the 3DO is a structurally hard problem. The 3DO Interactive Multiplayer launched in 1993 with an unusual licensing model — multiple manufacturers (Panasonic, Goldstar, Sanyo) built hardware to a common spec — and an unusual architecture. The CPU was an ARM60, which by itself was tractable, but the system-level math was offloaded to two custom co-processors (Madam and Clio) that handled cell-engine graphics, sprite scaling, and DMA. Documentation for those custom chips was always sparse and got worse as the manufacturers exited the market. The original disc media used a then-uncommon Mode 1 CD-ROM format with proprietary metadata that most disc-rip tools have always struggled with. The result: software emulators (FreeDO, Phoenix, the libretro 4DO core) have been semi-functional for fifteen years — they boot most games, they crash on a meaningful subset, and the ones that run have visible accuracy issues that the maintainers have not been able to fully chase down. The Emulation General Wiki entry on the system is unusually honest about how far the work still has to go. The 3DO has been the field's reminder that emulation accuracy is not free.

"The FPGA tier just took the hardest test case in the field, and it is passing. The argument is shipping its proof in real time."— Lumenforce

Why this matters for the FPGA-vs-software-emulation argument. The case for FPGA authenticity has always rested on accuracy at the hardware-edge cases. Software emulation works best on well-documented architectures (NES, SNES, Game Boy) where the original chip behaviors are mapped down to single-cycle granularity. The argument FPGA proponents have made — and which Lumenforce's running opinion has held since day 0 — is that FPGA's advantage shows up most clearly on the systems software emulation has done worst at. The 3DO is exactly that system. If the MiSTer 3DO core hits feature-complete and accuracy-clean before software emulation does, the case for FPGA's structural advantage is no longer rhetorical. It is observable. The argument is shipping its proof in real time.

Where Lumenforce lands on this, said out loud, before the setup walk: FPGA-accurate recreation is the right answer for the systems whose preservation is most at risk. Not the only answer — software emulation does enough work for the easy cases that taking the FPGA position on every system would be excessive. But for systems where the original silicon is fragile, the documentation is gone, and software emulators have been stuck in semi-functional purgatory for a decade-plus, FPGA is what closes the gap. The 3DO core is the proof that the gap can be closed. The persona-stance the LAB format takes here: tool-makers credit-loud per the standing rule, but also recognize that the FPGA project is doing structural work that the software-emulation approach has not been able to do alone, and Lumenforce will say that on the record. Disagree by all means; the LAB format is built to host the disagreement.

Setup walk, the way a LAB piece should walk it. (1) Hardware: a MiSTer FPGA setup — DE-10 Nano board with the SDRAM module, the I/O board (real or DIY), an SD card. The reference build is the same one the wider MiSTer community has been running for years; the 3DO core does not require new hardware. (2) Core install: the 3DO core ships through the standard MiSTer update mechanism. The beta is being released through the project's update script — once the script picks up the new core, it appears in the Console menu. The community-maintained update tools handle this; manual install requires copying the .rbf core file to /Console/3DO/ on the SD card. (3) BIOS: the 3DO core, like every BIOS-dependent FPGA core, requires the buyer to provide the system BIOS file from a 3DO console they own. The MiSTer project does not distribute BIOSes. The expected file format and naming convention is documented in the core's README. (4) Disc images: source from the buyer's own discs. The expected format is .iso or .cue/.bin pair, ripped per the standard CD-DA-aware procedures. (5) First-pass titles to try: Lemmings is the canonical "does this core boot anything" title (small, simple, well-tested in software emulation, easy to compare). Crash 'n Burn for the launch-title milestone. Star Control II for an actually-good 3DO game that nobody else preserved well. Starting wider than necessary; the beta will fail on some of these and that is the data the project wants.

What to disable on the first pass. The MiSTer GUI has the usual scaler options (CRT-shader integration, scanline emulation, integer-scaling enforcement). All of those should be off on the first pass — the goal is to validate that the core itself is stable, not to chase the perfect display preset. Once the core proves stable on a handful of titles, scalers can come back on. Same logic as with the CRT-Royale OLED setup — get the substrate right first, then layer the aesthetics.

The honest hedges. It is an early beta. Not all games run. The ones that do may have edge-case bugs that ship in 2026 builds. The accuracy claim is "better than software emulation," not "feature-complete." This is the moment to start tracking the project, not the moment to declare 3DO preservation solved. The credit pattern requires care. The MiSTer 3DO core has a maintainer; following the standing rule on naming individual scene-tool contributors, this dispatch credits the core at the project level and links the primary references rather than name-dropping the maintainer without a direct quote and a longer profile. The work deserves a proper interview piece; it does not deserve a footnote in a 1,200-word LAB. The "FPGA always wins" framing is not what this is. Software emulation is doing real preservation work that FPGA cannot match on accessibility — a libretro core runs on every modern phone, every Steam Deck, every laptop, with no $300 hardware investment. The two approaches are complementary on most of the catalog. The 3DO is the case where they diverge, and the 3DO core's progress is the case for FPGA's structural strength on hard problems.

What to watch. (1) Whether the 3DO core hits feature-complete before any software emulator does. The libretro 4DO core has been in semi-functional state for years; if MiSTer 3DO ships a "every title in the released catalog runs cleanly" milestone first, the proof is on the record. (2) Whether other "stuck" systems get the same treatment. Saturn FPGA cores have been incremental; CD-i has nothing; Jaguar's FPGA support is minimal. The 3DO milestone is the proof of method; the next decade of FPGA work is whether that method generalizes. (3) Whether the project pulls a maintainer interview. If the core's developer ever does a long-form interview — about the toolchain, the documentation reverse-engineering, the multi-year arc — that piece is what gets the proper credit Lumenforce is owing the work right now. We will publish the link the day it lands.

The position, plainly stated, on the record. The FPGA-accurate tier of preservation is not just one option among equals. For the hardest cases — the systems where original silicon is dying and software emulation has stalled — it is the approach that is shipping the proof. The MiSTer 3DO core is that proof in motion. Lumenforce credits the project, names the structural argument, and stops short of triumphalism. The work is in beta. The argument is in real time.