Retro gaming is often sold as a content problem: find the ROM, map the buttons, press Start, and the past reappears on demand.
MiSTer refuses that framing. It treats retro gaming as a behavior problem—a question of clocks, buses, contention, odd refresh rates, audio timing, and the small edge cases that were never written down because the original machines were the documentation. When those machines age, fail, and disappear into parts bins, the thing we lose is not only plastics and PCBs. We lose a way of working.
MiSTer’s most honest description is not “a device,” but a platform: a shared hardware baseline plus an open toolchain and a living library of FPGA “cores” that can reconstruct many classic computers, consoles, and arcade boards on modern programmable logic. It is messy in the way real preservation work is messy. It asks you to care about the chain rather than the screenshot. And if you accept that bargain, it can turn “I still want to play this” into something closer to “this remains operable.”
A platform, not a box
A typical MiSTer build starts with the Terasic DE10-Nano: an FPGA development board that pairs an Intel Cyclone V FPGA with an ARM-based SoC running a lightweight Linux environment. The Linux side handles the everyday conveniences—menus, storage, networking, scripts, controllers—while the FPGA side loads a core that implements the target system’s logic.
That split is the key to why MiSTer feels different from both emulators and consumer FPGA products. It’s not trying to hide its layers. The “main” MiSTer software is not a single monolithic game launcher; it is the host runtime that knows how to configure the FPGA, expose a common interface, and coordinate video/audio/input across wildly different machines. The cores are the exhibits, and the platform is the cabinet that keeps them accessible.
This is also why MiSTer doesn’t have one stable “product identity.” Your MiSTer is partly defined by the hardware you stack onto the DE10-Nano, partly by the updater workflow you trust, partly by the display chain you build around it, and partly by the cores you actually use. In practice it becomes less like buying a console and more like adopting an ecosystem.
“Core” is not a ROM slot: it is a behavioral claim
MiSTer cores are FPGA implementations of classic hardware, written in hardware description languages and built within a shared framework. When a core is loaded, the FPGA is configured to behave like the target system’s components and their relationships—CPU timing, video pipeline, audio generation, memory mapping, bus arbitration, and the subtle “this register does something odd if you read it twice” realities that define many real machines.
That does not mean every core is perfect, and MiSTer is at its best when it admits this openly. Accuracy is not a binary property; it is a gradient, and it can vary by subsystem. A core can be “good enough to finish the game” while still being wrong in ways that matter for speedrunners, for demoscene software, or for the small set of titles that lean on undocumented behavior. MiSTer’s value is that it makes these questions discussable in engineering terms: a bug is something you can reproduce, isolate, patch, and version—not a vague feeling that your laptop is “doing something.”
This also reframes what “compatibility” means. In emulator culture, compatibility is often judged by whether a title boots and plays. In MiSTer culture, compatibility tends to drift toward whether a system’s behavioral envelope is represented: timing edge cases, video modes, audio quirks, and the interactions between them. It’s not that MiSTer users are always more demanding; it’s that the platform invites a different standard of argument.
Why the SDRAM module exists (and why it keeps showing up in every build list)
One of MiSTer’s most confusing practical details is that the DE10-Nano already has DDR3 memory, and yet many builds add an external SDRAM module anyway.
The short explanation is latency and determinism. A significant number of cores rely on low-latency external SDRAM because the onboard DDR3 is not optimized for the kinds of timing-sensitive access patterns some classic systems expect. MiSTer’s own hardware documentation frames the external SDRAM module as a solution for cores that require larger, fast memory, noting that the DE10-Nano’s DDR3 has high latency for this use case.
This is a perfect example of MiSTer’s philosophy leaking into the bill of materials. If you only care whether a game draws the right pixels, you can hand-wave memory timing. If you care whether a system behaves like itself across its weird corners, memory behavior stops being “just RAM.” It becomes part of the system’s identity.
The common outcome is practical: many people treat SDRAM not as an optional upgrade but as the first “you probably want this” addition, because it expands the set of cores you can run comfortably and reduces the number of platform-specific caveats you’ll hit later.
The display chain is half the experience
MiSTer’s reputation is often summarized as “low latency” or “hardware accurate,” but what many users are actually reacting to is something more mundane and more important: MiSTer encourages you to treat the display path as part of the machine.
Classic consoles and arcade boards did not target HDMI. They targeted CRT behaviors: 240p, 480i, odd refresh rates, non-square pixels, and signal characteristics that modern flat panels often “correct” in ways that produce added lag, unstable motion cadence, or scaling artifacts. Software emulation can absolutely look fantastic, but it is typically mediated by a modern OS compositor and a modern display pipeline that was never designed to respect those old assumptions.
MiSTer offers multiple strategies, and the best one depends on what you are trying to preserve.
If you are primarily on modern displays, MiSTer’s HDMI output gives you a controllable, consistent source where you can tune scaling and sync behavior per core, and you can keep the system’s timing intent more intact than many generic “retro modes” on televisions.
If you are CRT-minded—or simply want to keep analog output as a first-class option—MiSTer supports analog video in two culturally important ways.
One path is the classic I/O board approach, where an add-on board provides analog outputs designed for CRT and other legacy equipment.
The other is MiSTer’s “Direct Video” mode, which routes an analog-compatible signal through the HDMI port using a suitable DAC/adapter. The MiSTer documentation describes Direct Video as an option that avoids requiring an I/O board while still delivering minimal latency comparable to the I/O board’s VGA output, and in some cases offering improved color depth depending on the core. In the MiSTer world, that’s not a footnote; it’s an ideological statement: analog is not just a legacy connector, it is a preserved grammar of display.
The consequence is that MiSTer tends to produce fewer “it looks right but feels wrong” moments, because you are encouraged—almost forced—to think about the entire path from button press to phosphor glow.
Latency: where MiSTer helps, and where it can’t
MiSTer cannot repeal physics. It can, however, reduce the number of layers that lie to you.
A modern gaming PC running an emulator can be extremely fast and extremely accurate, yet still accumulate latency through a chain of small decisions: OS scheduling, input polling, buffering, frame pacing, GPU queues, scaling, display processing. Any one of those may be negligible, but the sum can be felt—especially in genres that were built around immediate feedback.
MiSTer’s architecture tends to simplify the critical loop. Input is read by the host environment and delivered into an FPGA core that generates frames and audio with deterministic timing goals. That does not guarantee “zero lag,” but it does reduce the amount of “who knows what happened between my controller and the game.”
The bigger enemy often becomes the display. Many modern televisions add processing, frame buffers, motion interpolation logic, and scaling pipelines unless you explicitly disable them. MiSTer can deliver a clean signal with consistent cadence; it cannot force your panel to respect it.
This is why MiSTer culture frequently sounds like CRT culture even when the user is not a CRT purist. The point is not nostalgia for glass. The point is respect for timing.
Maintenance is not a downside; it is the price of keeping things operable
MiSTer is sometimes marketed as “pay once and get accuracy.” That is not how it behaves.
MiSTer behaves like a maintained system because it is one. Cores change, frameworks evolve, and community tooling moves. MiSTer’s official Distribution repository exists precisely because the platform is more than a single binary; it is a coherent set of files that make an SD card “a MiSTer.” The MiSTer Downloader tool exists because keeping up-to-date is not a side feature; it is essential infrastructure. The Downloader README describes its scope bluntly: it installs and updates cores and extra files, and it also updates the menu core, MiSTer firmware, and even the Linux system, pulling from the Distribution repository.
Then there is the reality that most MiSTer users eventually adopt a higher-level script workflow. The widely used “Update All” script explicitly positions itself as an all-in-one updater that runs MiSTer Downloader under the hood and expands it with additional databases and options. Even its own README includes a warning that scripts run with root access and should be treated with caution—a reminder that MiSTer is closer to a small computer you administer than a console you consume.
This maintenance aspect is not an accident. It is the inevitable cost of a platform that wants to outlive hardware scarcity. If you want a sealed appliance, you will be happier elsewhere. If you want a system that stays current because a community is still actively making it better, MiSTer’s upkeep is part of the deal.
Can MiSTer run original cartridges?
This is the point where many people’s mental model diverges, especially if they are coming from a world where “FPGA hardware” is marketed as “use your original collection.”
In theory, running original cartridges is “just I/O”: a physical ROM device on a bus with timing requirements. In practice, MiSTer is not designed to be a universal cartridge host, and the project’s own documentation is explicit about the direction here. The MiSTer FAQ states that MiSTer will never officially use physical cartridges, describing cartridge support as physically impractical given the number of GPIO pins available from the FPGA, and framing the project goal as replacing the need for original hardware rather than becoming an accessory dock for it.
That does not mean your original cartridges are irrelevant. It simply means MiSTer treats them as sources, not as runtime media. The common preservation workflow is to dump a cartridge (using appropriate external hardware) into a ROM image and then run that image from MiSTer’s storage like any other title. Conceptually, the cartridge remains part of the provenance of the game; operationally, MiSTer standardizes around files to keep the platform manageable and broadly compatible.
This detail also clarifies an important distinction. MiSTer can be very friendly to “original-feeling” peripherals—controllers, light guns (with the right display constraints), and so on—because those map to narrower, more controllable interfaces. Physical game media is a much harder universal target, and MiSTer chooses not to make that trade.
MiSTer and openFPGA: separate ecosystems, shared DNA
MiSTer is frequently mentioned alongside Analogue ’s openFPGA, and at a distance the resemblance is obvious. Both involve FPGA cores. Both attract developers who care about authenticity. Both encourage a “hardware first” mental model.
But the relationship is not direct compatibility. It is closer to a family resemblance.
Analogue’s developer documentation defines a Pocket “core” as an FPGA bitstream packaged with JSON definition files, with loading and operation managed by the Analogue Platform Framework (APF). The APF provides abstractions for buses and I/O, and Analogue’s documentation describes how integration code simplifies access to BRIDGE and PAD buses while providing examples for VIDEO and AUDIO.
MiSTer cores, by contrast, live in a different host environment with different expectations, different file structures, and a different runtime framework. Even when two cores implement the same target system, they are not drop-in equivalents. A port typically requires rebuilding the platform glue: how assets are loaded, how input is surfaced, how video modes are negotiated, how saves are handled, and how the core’s assumptions map onto the host’s bus abstractions.
This is why you can truthfully say “many openFPGA cores are ports of MiSTer work” while also truthfully saying “MiSTer cores are not directly runnable on Pocket.” The overlap tends to be in upstream HDL designs and developer communities, not in binary compatibility.
Cross-platform developers make that boundary feel thinner than it is. When one developer maintains similar implementations across both ecosystems, the user experience can converge—even though the frameworks remain distinct.
In short: MiSTer and openFPGA are cousins, not clones. MiSTer optimizes for openness and modularity as a community platform. openFPGA optimizes for a developer framework inside a product ecosystem. Both can serve preservation; they simply do it through different kinds of sustainability.
What MiSTer is really preserving
MiSTer is not preserving “games” in the narrow sense. It is preserving a way of making games run—a set of electrical and temporal assumptions that were once ordinary and are now exotic.
That matters because original hardware is becoming less maintainable, not more. The longer we wait, the more “authentic play” risks becoming an artifact of who can source parts, who has repair knowledge, and who can tolerate failure. MiSTer does not replace original hardware’s material history, but it can prevent operability from becoming a luxury.
There is also a forward-looking implication that makes MiSTer feel larger than “retro.” A well-maintained core is, in effect, a publishable artifact: a versioned, reviewable, reproducible behavioral model of a classic machine. That is a preservation strategy with a future. It treats hardware not as a finite stash of aging boards, but as something that can be documented in logic and kept alive as long as we still know how to program logic.
MiSTer is not the only path to that future, but it is one of the clearest statements that the past is not just something we watch. It is something we can keep operable—if we are willing to treat it seriously.
References
MiSTer (official / primary)
MiSTer FPGA Documentation (MkDocs):
https://mister-devel.github.io/MkDocs_MiSTer/MiSTer-devel organization (core and platform repos):
https://github.com/MiSTer-develMiSTer Hardware official repo:
https://github.com/MiSTer-devel/Hardware_MiSTer
MiSTer (community tooling)
- Update All (theypsilon):
https://github.com/theypsilon/Update_All_MiSTer
openFPGA (Analogue primary docs)
Analogue Developer Docs :
https://www.analogue.co/developer/docs/overviewopenFPGA Library :
https://openfpga-library.github.io/analogue-pocket/Jotego jtcores (multi-platform intent, incl. MiSTer / Analogue Pocket):
https://github.com/jotego/jtcoresAnalogue “Getting Started with openFPGA”:
https://www.analogue.co/support/resource/getting-started-with-openfpga