FPGA vs Software Emulation: Accuracy Is Not a Matter of Technology, but of Understanding
For years, retro gaming discussions have often repeated the same convenient idea: FPGA is “real hardware” while software emulation is merely an approximation. It is a seductive claim, because it sounds simple, technical, and reassuring. A console implemented on an FPGA feels like a physical machine. It boots instantly, outputs video directly, and does not look like an emulator running inside a modern operating system. By contrast, software emulation still carries the reputation of old, inaccurate emulators from the 1990s and early 2000s: frameskip, bad sound, glitches, latency, and games that only worked “well enough.”
But that opposition is too easy. More importantly, it is technically wrong.
FPGA systems and software emulators are both forms of emulation. They both attempt to reproduce the behavior of another machine. The difference is not between “real” and “fake,” but between two different ways of describing and executing a model of the original hardware. An FPGA describes hardware behavior in a hardware description language and implements it as configurable logic. A software emulator describes hardware behavior in code and executes it on a CPU. In both cases, the decisive question is the same: how accurate is the model?
A bad FPGA implementation is not automatically more accurate than a good software emulator. A mature, cycle-accurate software emulator can be more faithful than an incomplete FPGA core. Likewise, a well-developed FPGA core can provide an extremely convincing and responsive recreation of a console or computer. The medium does not guarantee accuracy. Research, testing, documentation, and implementation do.
FPGA Is Not Original Hardware
The first misconception to remove is the idea that FPGA-based systems are the original hardware reborn. They are not. An FPGA is a programmable logic device. It can be configured to behave like a CPU, a video chip, an audio chip, memory glue logic, bus arbitration, controller ports, and so on. That is impressive, and in many cases it can be extremely close to the original machine. But it remains a reimplementation.
When a MiSTer core, an Analogue console, or a C64 Ultimate recreates an old machine, it does so by describing how the old chips are believed to behave. If the description is incomplete, if an undocumented edge case is missed, if a bus timing is slightly wrong, or if an audio envelope behaves differently from the original chip, the FPGA implementation will be inaccurate.
This is especially important with machines from the 1980s and 1990s. They were not clean abstractions. Games and demos often relied on hardware quirks, race conditions, undocumented registers, unstable timing, analog behavior, and precise relationships between CPU, video, sound, memory, cartridge hardware, and I/O devices. A game may work perfectly for hours and still expose a flaw in one very specific scene. A demo may rely on cycle-exact behavior that no commercial game ever used. A disk loader may depend on the mechanical and electrical behavior of a real drive. A sound routine may rely on a bug or oddity in the original audio chip.
In those situations, the question is not whether the implementation is FPGA or software. The question is whether it models that specific behavior correctly.
Software Emulation Has Changed
The other major misconception is that software emulation means “high-level approximation.” That may have been true for some old emulators, especially when computers were slower and the priority was playability. But modern accuracy-focused emulators are often the result of decades of research.
Projects such as MAME, ares, SameBoy, bsnes, higan, BlastEm, Mednafen, and many others are not simply trying to make games boot. They are attempts to document and reproduce hardware behavior with great precision. Some are cycle-accurate. Some pass extensive test ROMs. Some emulate differences between hardware revisions. Some include debugging tools that allow developers to inspect memory, timing, registers, interrupts, scanline behavior, and audio output in ways that are extremely difficult to reproduce on physical hardware.
This is where software emulation has a major advantage: visibility. A software emulator can be instrumented. Every CPU instruction can be traced. Every memory access can be logged. Every register write can be compared against known hardware behavior. Automated tests can be run thousands of times. A developer can stop the machine at an exact moment, inspect its complete state, change one hypothesis, and run the same test again.
FPGA development can also be debugged, of course, but it is often more constrained. Recompiling a core takes time. Internal signals are harder to inspect. Timing closure can introduce new constraints. The design must fit within the available FPGA resources. A correction that is easy to express in software may be more difficult to implement cleanly in hardware logic.
That does not make software emulation automatically better. But it does mean that software can sometimes reach a level of analytical precision that is extremely powerful for preservation.
Cycle Accuracy vs Hardware Parallelism
A common argument in favor of FPGA is that hardware runs in parallel, while software runs sequentially. This is true at a physical level, but it does not settle the accuracy question.
Original consoles and computers were made of many components operating simultaneously. An FPGA is well suited to representing that structure because it can implement multiple pieces of logic running in parallel. That is one of its great strengths. A video chip, CPU, sound generator, and memory controller can all exist as interacting logic blocks rather than as a single loop of software instructions.
However, software can still model parallel hardware accurately by advancing components according to a precise timing model. A cycle-accurate emulator does not need to be physically parallel to be behaviorally correct. It needs to produce the same externally observable results at the correct time. If the emulator knows exactly when the CPU reads memory, when the PPU fetches tile data, when an interrupt is triggered, when DMA steals cycles, and when audio samples are generated, it can reproduce the machine with extraordinary fidelity.
Conversely, an FPGA core that is physically parallel but has one incorrect state machine, one incorrect wait state, or one inaccurate bus contention rule will be wrong. Parallelism is useful, but it is not magic. Accuracy is not created by running logic in parallel. Accuracy comes from modeling the right logic.
Timing Is the Battlefield
The most difficult problems in both FPGA and software emulation usually involve timing. Old systems often depended on exact relationships between components. The CPU may be stalled by video memory access. A cartridge mapper may respond after a certain number of cycles. A disk drive may return data at a speed that varies by track. A scanline interrupt may need to occur at exactly the right moment. A sprite overflow bug may depend on a very specific evaluation order.
This is why compatibility can fail in strange ways. A game may load correctly, show the title screen, and then crash later. A boss may behave incorrectly. A line-scrolling effect may shimmer. A racing game may show tiny graphical artifacts. A demo may fail while commercial games seem fine. A sound effect may miss a channel. A save state may restore almost everything but leave the audio subsystem in the wrong state.
On FPGA platforms, timing issues are visible in many areas. MiSTer, for example, sometimes requires external SDRAM because certain cores need memory access with reliable timing. The DDR3 memory available on the DE10-Nano is fast, but fast is not the same as deterministic. If a system needs predictable random access latency, variable latency can become a compatibility problem. This is a perfect example of why FPGA does not automatically mean “like the original.” The FPGA is still hosted on a modern board with its own memory architecture and constraints.
Commercial FPGA systems also receive firmware updates that correct timing problems. Analogue’s Mega Sg firmware, for example, has included fixes for bus timing affecting Virtua Racing, audio issues in OutRun and Tiny Toon Adventures, tearing in Master System mode, and graphical artifacts in Sonic 3. These are not criticisms of the Mega Sg; they are evidence that FPGA accuracy is a process. The same is true for Analogue Pocket, which has received updates related to cartridge bus timing, sleep/wake behavior, save states, and dock behavior.
If FPGA were inherently exact, those fixes would not be necessary. The reality is healthier and more interesting: FPGA platforms improve because developers find inaccuracies, test them, and correct them.
Audio Is Often Harder Than Video
Many retro gamers focus on pixels, scaling, and latency, but audio is one of the hardest areas to reproduce accurately. Old audio chips often have analog characteristics, imperfect envelopes, filters, non-linear distortion, DAC quirks, and model-to-model variation.
The Commodore 64 SID is a famous example. It is not just a digital sound chip. Its filter behavior varies between revisions and even between individual chips. Some music and sound effects rely on subtle behavior in envelopes, waveform mixing, volume register samples, or filter response. Recreating that perfectly in FPGA is difficult. Recreating it perfectly in software is also difficult. But software emulators can sometimes model these characteristics in more detail because they are not forced to express everything as real-time digital logic within a limited FPGA fabric.
The same applies to arcade audio circuits, FM synthesis, PSG behavior, ADPCM playback, and CD audio timing. A modern software emulator can afford complex mathematical models, oversampling, analog filter simulation, or per-chip configuration. An FPGA can do some of this, but the implementation has to fit the target device and run in real time with available logic resources.
This is why we should be careful when someone says, “FPGA sounds more real.” Sometimes it does. Sometimes it does not. The correct question is: what exactly is being modeled? Which chip revision? Which filter? Which test cases? Which known edge cases? Which comparison against real hardware?
Cartridges, Mappers, Flashcarts, and Expansion Hardware
Another area where FPGA systems can run into compatibility problems is physical cartridge support. Loading a ROM file is one thing. Supporting real cartridges is another.
A cartridge is not always passive storage. Many contain extra logic: mappers, coprocessors, SRAM, protection chips, enhancement chips, real-time clocks, bank-switching hardware, or unusual bus behavior. The Sega Genesis version of Virtua Racing includes the SVP chip. Super Nintendo cartridges may include enhancement chips such as Super FX, SA-1, DSP variants, S-DD1, or others. Game Boy and Game Boy Advance cartridges may include different memory controllers, save types, sensors, rumble, real-time clocks, or unusual clone hardware. Flashcarts add yet another layer of complexity, because they are modern devices pretending to be many kinds of cartridges.
An FPGA console that accepts original cartridges must reproduce not only the console, but also its bus behavior well enough for all of those cartridges to work. Slightly wrong timing can affect a small number of games. A firmware update may improve one cartridge and reveal another edge case. A flashcart may work on one hardware revision and fail on another. The user experiences this as “the game does not boot,” but the technical cause may be extremely subtle.
Software emulators often avoid this physical layer because they load ROM images directly. That can be a disadvantage if the goal is to use original media. But it can also be an advantage for accuracy research, because the emulator can focus on accurately modeling the cartridge hardware itself without dealing with electrical tolerances, connector wear, flashcart firmware, voltage behavior, or modern cartridge adapters.
Again, neither approach is inherently superior. They solve different problems.
Computers Are More Difficult Than Consoles
The FPGA vs emulation debate often focuses on consoles, but old home computers are a much harder test. A console is usually a relatively closed system: console, controller, cartridge or disc. A computer is an ecosystem.
Consider the Commodore 64. Compatibility is not only about running games. It involves the C64 motherboard, the VIC-II, SID, CIA chips, cartridge port, tape port, IEC serial bus, disk drives, fast loaders, freezer cartridges, RAM expansions, alternative DOS systems, printers, modems, hard drive solutions, modern SD adapters, GEOS, C64 OS, demo loaders, copy protections, and countless unofficial expansions.
The Ultimate64 and 1541 Ultimate are remarkable devices, but they illustrate the complexity of this problem. They can emulate drives, cartridges, RAM expansions, SID variants, network functions, storage systems, and more. But every feature increases the compatibility surface. A virtual IEC drive may be convenient but not fully equivalent to a CMD hard drive, SD2IEC, or real 1541 in all situations. Fast loaders and DOS extensions may expose timing differences. Modern operating systems such as C64 OS may rely on storage behavior that a simplified virtual IEC layer does not fully provide.
This is not a failure of FPGA. It is the unavoidable reality of recreating an entire computer ecosystem. A software emulator with detailed models of drives, storage devices, cartridges, and expansions may be more compatible in some scenarios. A real C64 with real peripherals may be more compatible in others. An FPGA recreation may be wonderfully convenient but still incomplete in edge cases.
Video Output and the Modern Display Problem
Original machines were designed for CRTs, not HDMI displays. Their video signals were often strange by modern standards. They used non-square pixels, unusual refresh rates, interlacing tricks, composite artifacts, unstable sync behavior, border effects, mid-frame resolution changes, and analog color encoding. Some games and demos deliberately exploited these properties.
FPGA systems must decide how to present that output to modern displays. Should the system produce a clean digital image? Should it mimic composite artifacts? Should it preserve the original refresh rate even if a modern TV dislikes it? Should it buffer frames to improve HDMI compatibility at the cost of latency? Should it use variable refresh rate? Should it offer integer scaling, interpolation, scanlines, or CRT simulation?
These choices affect both accuracy and experience. A perfectly smooth HDMI output may not be the most faithful representation of the original signal. A more faithful signal may not work well on every display. A low-lag mode may be incompatible with some monitors. A buffered mode may be more compatible but add latency. This is why FPGA devices and software emulators both include video options. There is no single correct answer for every user and every display.
Software emulation has become very strong in this area. Modern emulators can use shaders, CRT masks, beam simulation, phosphor persistence, composite blending, color correction, and latency reduction techniques. FPGA systems can also offer excellent scaling and analog output options, especially MiSTer with CRT setups, but the idea that FPGA always has the more authentic video output is too simplistic.
Authenticity depends on the whole chain: core, scaler, output mode, display, controller, and settings.
Latency: The Most Misunderstood Argument
Latency is one of the strongest arguments used against software emulation. It is also one of the most misunderstood.
Old software emulators often had significant input lag because of operating system scheduling, USB polling, graphics APIs, buffering, VSync, display processing, and inefficient emulator design. That reputation still influences the debate. But modern software emulation can be very low-latency when properly configured. Features such as run-ahead, frame delay, high polling rates, low-latency APIs, VRR, beam racing, and careful synchronization can produce excellent results.
FPGA systems can also have latency. USB controllers have polling intervals. Wireless controllers add processing time. HDMI output can involve scaling and buffering. Displays add latency. Some video modes trade compatibility for responsiveness. MiSTer, for example, offers options that can reduce display latency, but the result depends on the controller, polling rate, video settings, and display.
The fairest statement is this: FPGA systems often make low latency easier to achieve in a console-like setup, especially when using original controllers or low-lag adapters. But software emulation can also be extremely responsive, and FPGA is not automatically zero-lag. The latency of a system is the sum of the entire chain, not a property of the word “FPGA.”
Save States, Sleep Mode, and Modern Convenience Features
Modern users often expect features that original machines did not have: save states, instant sleep and resume, screenshots, rewind, cheats, display filters, controller remapping, and fast loading. These features are natural in software emulation because the emulator already represents the machine state in software. Capturing and restoring that state is technically complex, but conceptually aligned with how the emulator works.
On FPGA, save states are much harder. The core must expose and restore the complete internal state of every relevant component: CPU registers, video state, audio state, memory, mapper state, DMA, timers, interrupts, controller state, and sometimes disc or cartridge state. If one small part is not captured correctly, the restored game may glitch later. This is why save state support varies significantly between FPGA cores.
This matters because users often judge compatibility by modern features, not only by whether a game boots. If sleep mode breaks a game, if a save state corrupts audio, or if a cartridge with a special save type behaves oddly, the FPGA system has a compatibility problem. Software emulation has its own problems here, but it often has a structural advantage because state capture is more native to the architecture of an emulator.
The Strengths of FPGA Are Real
None of this means FPGA is overrated. FPGA systems have real strengths.
They often provide a dedicated, appliance-like experience. You turn on the device and play. There is no general-purpose operating system in the foreground, no desktop environment, no window manager, no emulator frontend to configure. On platforms like MiSTer, the experience can be extremely direct, especially with original controllers and CRT output. Analogue consoles offer polished cartridge-based experiences for users who want modern HDMI output with original media. The Ultimate64 gives C64 enthusiasts a powerful modern motherboard with real ports, modern conveniences, and deep integration.
FPGA can also be excellent for preserving hardware behavior in a form that is closer to schematics than traditional software. HDL descriptions can be educational, transparent, and reusable. For many systems, FPGA cores produce superb results. For arcade games, consoles, and computers with well-understood hardware, the experience can be outstanding.
The point is not to dismiss FPGA. The point is to stop treating FPGA as a magic word.
The Strengths of Software Emulation Are Also Real
Software emulation deserves more respect than it often receives. It is one of the most important preservation tools in video game history. Many machines would be poorly understood without emulator developers documenting their behavior. MAME, in particular, has preserved knowledge about thousands of arcade boards, computers, consoles, gambling machines, development systems, and obscure pieces of hardware that might otherwise disappear.
Software emulation is also more accessible. It runs on common hardware. It can be distributed, updated, inspected, forked, tested, and preserved easily. It can support debugging, netplay, TAS tools, accessibility features, high-resolution rendering for 3D systems, translation patches, ROM hacks, and preservation workflows. It can model multiple hardware revisions. It can include experimental accuracy modes that would be impractical on a small FPGA.
Most importantly, software emulation has accumulated decades of knowledge. Many FPGA cores are themselves informed by the research done by software emulator authors. The two worlds are not enemies. They feed each other.
Accuracy Is a Method, Not a Marketing Claim
The real issue is not FPGA versus software. The real issue is methodology.
A serious emulator or FPGA core should be judged by the same questions. Does it pass known test suites? Does it document hardware behavior? Does it distinguish between hardware revisions? Does it reproduce edge cases? Does it handle bus conflicts, DMA timing, interrupts, audio quirks, and video timing? Does it have public issue tracking? Are bugs investigated and fixed? Are claims compared against real hardware? Does the developer explain limitations?
A vague claim of “hardware accuracy” is not enough. A commercial FPGA console can have compatibility bugs. An open-source software emulator can be more accurate than a closed FPGA core. An old emulator can be terrible. A new FPGA core can be brilliant. Every case must be evaluated individually.
The best attitude is not ideological but empirical.
Conclusion: Stop Dismissing Emulation
The retro community should stop using “emulation” as an insult. FPGA is emulation too, just implemented differently. Software emulation is not automatically inaccurate. FPGA is not automatically exact. Both can be excellent. Both can be flawed. Both depend on the quality of the model and the seriousness of the development process.
If your goal is to enjoy games with a console-like experience, low latency, original controllers, cartridges, and a clean HDMI or CRT setup, FPGA may be the perfect choice. If your goal is preservation, debugging, broad compatibility, hardware research, test automation, save states, shaders, accessibility, or support for many systems, software emulation may be more powerful. In many cases, the best answer is to use both.
What matters is not whether the machine is described in HDL or C++. What matters is whether it behaves like the original machine.