You’re holding a working NES from 1985. The cartridge slides in, the screen flickers to life, and Mario jumps exactly as he did four decades ago. Then you pick up your phone, load an emulator, and play the same game perfectly. Then you hear about an FPGA device that claims to replicate the original console’s behavior at the hardware level. Which one are you actually playing?
This question sits at the heart of retro gaming today, and it’s not as simple as “original good, fake bad.” The answer requires understanding actual electronics: how processors work, how video signals generate, how timing errors cascade, and what “authenticity” even means when we’re talking about silicon and electrons. I’ve spent 25 years designing and troubleshooting electronics, and I can tell you that the real differences between these three approaches are measurable, specific, and far more interesting than most people realize.
Most discussions about original hardware versus emulation versus FPGA are driven by nostalgia, gatekeeping, or marketing. You’ll hear claims that emulation is “basically perfect now” or that FPGA is “100% accurate” or that only original hardware is “authentic.” All three statements contain kernels of truth wrapped in incomplete information. The actual engineering picture is richer, more complicated, and more useful than any of these narratives.
What We’re Actually Comparing
Before we dive into the technical weeds, let’s be precise about what these three approaches are doing differently.
Original hardware is the actual circuitry designed and manufactured in the original era. When you play a game on a real NES, you’re running code on a Ricoh 2A03 processor, generating video through an R2C02 PPU (Picture Processing Unit), and managing state with discrete RAM chips. The entire system is deterministic: given identical inputs, it produces identical outputs every single time, down to the clock cycle.
Software emulation is a program running on modern hardware (a PC, phone, or console) that simulates the behavior of the original hardware. An emulator like FCEUX or Nestopia implements the 2A03’s instruction set, models the PPU’s behavior, and tracks memory state. It’s software pretending to be hardware.
FPGA emulation (Field-Programmable Gate Array) uses programmable silicon to configure itself as the original hardware would behave. Instead of simulating instructions, an FPGA literally recreates the logic gates, bus architecture, and timing of the original chip. Devices like the Analogue Mega Sg or MiSTer use this approach.
These sound like they’re just different speeds to the same destination. They’re not. The differences in how they operate create measurable, audible, and sometimes visible consequences.
The Architecture Question: Why Original Hardware Works the Way It Does
To understand why emulation and FPGA diverge from original hardware, you need to understand the hardware’s actual design constraints and how tightly the software depends on them.
A real NES processor doesn’t exist in isolation. It communicates with the PPU through specific memory-mapped I/O addresses. When the CPU reads from address $2004, it’s not calling a function—it’s pulling data from a physical pin that’s connected to the PPU’s output. That data changes based on what the PPU is currently doing: what scanline it’s rendering, whether it’s in vertical blanking, what the current tile data is. The timing of that data is not approximate; it’s a hard physical requirement.
Here’s a concrete example: imagine the CPU tries to read sprite data from the PPU at the exact moment the PPU is in the middle of rendering. Depending on the precise cycle alignment, the CPU might get garbage data, partial data, or correct data. The NES’s design documentation doesn’t always specify this behavior clearly, which means developers discovered these quirks through experimentation. Some games actually rely on these timing-sensitive behaviors working in specific ways.
Original hardware handles this because the physical constraints are absolute. The PPU generates signals on a fixed crystal oscillator. The CPU clock is derived from that same oscillator. There’s no approximation; the timing relationships are hardwired.
How Software Emulation Models This Behavior
Software emulation has a fundamental problem: it’s not running on the same hardware, so it can’t use the same timing mechanisms. A modern processor doesn’t have a 1.79 MHz clock that dictates its speed—it runs at billions of cycles per second and executes instructions in microseconds.
Emulators solve this by implementing a cycle-accurate or instruction-accurate model. The emulator maintains an internal clock that tracks how many NES cycles have passed. When the CPU is supposed to execute an instruction in 4 cycles, the emulator increments its cycle counter by 4. When the PPU is supposed to render a scanline, the emulator runs PPU logic for the number of cycles that would actually occur.
The problem: this requires knowing exactly which instructions take how many cycles, and it requires perfectly modeling every component’s behavior at every cycle. For a CPU, this is feasible—we have the instruction set documentation. For a PPU, it’s harder. The PPU was reverse-engineered by the emulation community over decades. There are still edge cases and undocumented behaviors.
But here’s what’s crucial: even a perfectly cycle-accurate software emulator runs on a different physical substrate. The instructions that implement the emulation are x86 or ARM code. That code runs on a modern CPU with caching, branch prediction, and out-of-order execution. Your emulator process competes for CPU time with your operating system. When you hit a performance hiccup—your OS schedules another process, or a garbage collection event occurs—the emulator can stall. That stall doesn’t exist on original hardware.
Practical consequence: on original hardware, if you’re playing Mario and holding the jump button for exactly 5 frames, Mario’s jump height is always the same. In an emulator, if your operating system hiccups and the emulator skips a frame, the jump height might differ. Most people never notice this. Some games, especially those with tight timing requirements, expose it immediately.
FPGA: Reconstructing Hardware in Programmable Logic
FPGA devices take a different approach. Instead of simulating behavior with software, they use programmable silicon to implement the actual logic gates and buses of the original hardware.
To understand this, imagine you have a schematic of the original NES—the actual gate-level design showing every transistor and connection. An FPGA allows you to specify that logic in a hardware description language (Verilog or VHDL), and the FPGA’s programmable switches reconfigure themselves to implement exactly that circuit.
The critical advantage: timing is explicit. You’re not approximating cycle timing with software counters; you’re implementing the actual logic gates that produce the timing signals. If the original design says the PPU generates a specific signal every 341 cycles, the FPGA logic generates it every 341 cycles by virtue of how the gates are wired.
But FPGA implementation has its own challenges. The original NES’s CPU and PPU were designed at a physical level—specific transistor counts, specific power consumption characteristics, specific electromagnetic properties. An FPGA reconstructs the behavior, but not the physics. The FPGA’s timing is based on clock cycles of the FPGA’s own oscillator (typically much faster than the original), but the behavior should emerge correctly if the logic is implemented properly.
The real complication: we don’t have perfect documentation of the original hardware at the gate level. Nintendo didn’t publish the transistor-level schematics. FPGA implementations are based on reverse-engineered designs—people like kevtris (who created the Analogue Nt mini’s FPGA core) read the original chips with scanning electron microscopes, analyzed the circuit, and reconstructed it in hardware description language.
This means FPGA accuracy depends entirely on how completely and accurately that reverse engineering was done. A perfect reconstruction would be pixel-perfect and cycle-perfect. A reconstruction with gaps will have differences.
Where These Three Approaches Actually Diverge in Practice
Now that we understand the architecture, let’s talk about where they produce different results.
Timing-sensitive behavior
Some games depend on precise timing in ways that weren’t documented. The classic example: mid-scanline writes to PPU registers. The PPU is actively rendering a scanline. The CPU writes new data to the PPU’s name table address register mid-scanline. On real hardware, the timing of this write relative to the PPU’s rendering state determines what gets displayed. It’s complex, poorly documented, and games like Battletoads and Contra actually rely on this behavior working in specific ways.
Software emulation handles this if the emulator has modeled the undocumented behavior. FCEUX, for example, has been refined over 20+ years and handles many of these edge cases. But each implementation makes assumptions. If the developer didn’t know about a specific quirk, it won’t be emulated.
FPGA implementations attempt to reproduce this by reconstructing the actual gate logic. If the reverse engineering was accurate, the behavior emerges automatically—you don’t have to explicitly code for every edge case because the circuits behave the way the original circuits did.
In practice: nearly all games work identically on all three approaches. But approximately 2-3% of NES games have known compatibility or visual glitch issues with some emulators, while FPGA cores typically handle them correctly (assuming the core’s reverse engineering is solid). Original hardware always works correctly, by definition.
Video output fidelity
Original hardware generates a composite video signal—an analog waveform encoded on a coaxial cable. That signal contains color information, brightness, and synchronization data all mixed together. An RF modulator (or later, AV cables) carries this to your TV, which decodes it.
Software emulation generates a digital image in RAM. That image is typically RGB data, one pixel per output pixel. When displayed on a modern screen, there’s no analog processing; it’s digital the entire way. Visually, this means perfectly clean, sharp edges and no color artifacts.
Real hardware’s composite video has subtle artifacts—color bleeding at high-contrast edges, reduced sharpness, slight color shifts depending on the monitor. For many people, this is the “authentic” look. For others, it’s degradation.
FPGA devices output both. Most FPGA systems like the MiSTer can output either HDMI (digital, like emulation) or composite/S-video (analog, like original hardware). If you use the analog outputs and feed them into a quality monitor, you get the original signal characteristics.
Practical consequence: if you’re playing on a modern LCD via HDMI, emulation and FPGA look nearly identical. If you’re using analog outputs on original hardware or FPGA, you get the composite video characteristics. Which is “better” is subjective, but they’re measurably different.
Audio generation
The NES produces audio through three pulse wave generators and a noise generator. The original hardware synthesizes these in real time and outputs analog audio at line level.
Software emulation models the audio synthesis behavior and generates a digital audio stream (typically 44.1 kHz or 48 kHz). The waveforms produced should be mathematically identical to the original hardware.
FPGA reconstructs the actual audio synthesis logic. Again, if the reverse engineering is accurate, the waveforms are identical to the original hardware.
In practice: audio quality is nearly identical across all three approaches. The main differences are in output impedance and harmonic content related to the analog circuitry of the original hardware. If the original audio path had slight filtering or harmonic distortion from the output stage, emulation and FPGA don’t replicate that (unless the FPGA includes a model of the output circuitry, which some do). For most listeners, the difference is inaudible.
Input latency
This is where real differences become obvious to the player. When you press a button on a controller, how long until your action affects what’s displayed on screen?
Original hardware: minimal latency. The controller input is sampled by the CPU each frame. Within the next frame, the game logic processes it and updates game state. The PPU renders the new state. Depending on the game, this is typically 1-2 frames (17-33 ms at 60 Hz).
Software emulation: can vary significantly. The emulator runs at the host OS’s scheduling granularity. Input is polled by the emulation loop. Depending on the host system’s performance and OS scheduling, there can be additional buffering. On a well-optimized emulator on a modern CPU, this is competitive with original hardware—but it’s dependent on the system’s behavior.
FPGA: similar to original hardware. The logic is implemented directly in silicon with deterministic timing. Input latency is measured in microseconds of logic delay, not milliseconds of software scheduling.
Practical consequence: for twitch-reflex games (Contra, Battletoads, Castlevania), latency matters. Original hardware and FPGA are typically imperceptible. Software emulation can introduce 1-3 additional frames of latency depending on the system, especially under system load. This is one area where FPGA has a clear technical advantage over software.
Testing and Measuring These Differences
If you want to verify these claims yourself, here are testable procedures that require only basic equipment.
Procedure 1: Measure input latency across all three approaches
You’ll need: a camera capable of 120+ fps (most modern smartphones can do this), a controller, and access to all three systems (or at least two).
- Set up a test game with clear visual feedback for controller input. Super Mario Bros. is ideal: jump immediately upon button press, and landing is clearly visible.
- Film at high frame rate (120 fps minimum) as you press the jump button. Include the controller in the frame.
- Count the number of frames between the moment the button visibly depresses and the moment Mario leaves the ground.
- Convert to milliseconds: (frame count / 120) × 1,000.
- Repeat 5-10 times for each system and average the results.
Expected results: Original hardware typically shows 17-33 ms (1-2 frames). FPGA cores typically match this. Software emulation can range from 17 ms (optimized, no load) to 50+ ms (under system load). The variability on software emulation is often larger, reflecting OS scheduling.
Procedure 2: Visual comparison of specific edge cases
Many games have known visual differences. Battletoads’ flying level is famous for this—the way sprites wrap and blend is timing-dependent.
- Load Battletoads on original hardware and an emulator (FCEUX, BizHawk, or similar).
- Play to the flying level (Stage 5). Use save states or Game Genie codes to skip to it quickly.
- Observe the sprite rendering, especially around screen edges and sprite overlaps.
- Take screenshots or video from both systems at the same gameplay moment.
- Compare pixel-for-pixel in an image editor.
Expected results: Many emulators show slight differences in sprite positioning or color blending compared to original hardware. FPGA cores (if you have access to one like MiSTer with a quality NES core) typically match original hardware perfectly. The differences are subtle but visible on careful inspection.
Procedure 3: Analyze audio waveform differences
This requires a sound card capable of line-in recording and free audio analysis software (Audacity works).
- Record audio output from original hardware, emulation, and FPGA for the same sequence of gameplay (e.g., the first 30 seconds of Metroid).
- Use Audacity’s Spectrogram view to visualize the frequency content of each recording.
- Export a zoomed section of the waveform as an image for each system.
- Compare the harmonic content and overall shape.
Expected results: Emulation and FPGA should produce nearly identical waveforms. Original hardware might show slight harmonic variations or filtering artifacts from the analog output stage, but these are subtle. Most casual listening reveals no difference.
The Reliability Question: Component Failure and Longevity
Original hardware carries a significant practical disadvantage: it’s aging. A NES from 1985 is almost 40 years old. Specific components have known failure modes.
The 72-pin cartridge connector develops poor contact over time. The electrolytic capacitors (especially in the power supply) age and capacitance drifts or they fail catastrophically. The chips themselves are generally robust (MOS processors are tough), but the surrounding circuitry degrades. If you’re interested in understanding these failure mechanisms in detail, read about how to maintain vintage electronics and what common failure points are.
Original hardware can be restored and preserved, but it requires active maintenance. Replacement capacitors cost $20-40 and the soldering work is intermediate-level difficulty. A connector cleaning kit costs under $15. Many collectors maintain their hardware for decades, but it’s not passive—it requires periodic attention.
Software emulation has no hardware degradation. A ROM file from 1990 works identically in 2025 and will work identically in 2055 (assuming you have compatible operating systems).
FPGA devices are newer but based on modern manufacturing. An FPGA board from 2020 should remain functionally identical for decades. The main risk is loss of firmware or configuration files, not component failure.
Accuracy and Completeness: Which Approach Is “Most Accurate”?
This is the question that sparks the most heated discussions, so let’s address it directly with specifics.
Original hardware is 100% accurate to original hardware (by definition), but original hardware also includes all its quirks, bugs, and undocumented behaviors. This is actually more “authentic” than carefully curated accuracy, but it also means any weird behavior is preserved exactly.
Software emulation accuracy depends on the emulator and how thoroughly it’s been developed. FCEUX is highly accurate for most NES games; its developers spent 20+ years refining it. BizHawk (used in speedrunning communities) is cycle-accurate for CPU and PPU and passes rigorous test ROMs. But even the best software emulators have edge cases. Games that rely on undocumented hardware behavior might not work perfectly unless the developer specifically coded for that edge case.
Accuracy metrics: a well-developed software emulator passes ~99% of compatibility tests and handles ~99% of games identically to hardware. The remaining 1% includes games with known glitches on some emulators, games that use undocumented features, or games with very strict timing requirements.
FPGA accuracy depends on the quality of reverse engineering. A well-done FPGA core (like kevtris’s NES core) is exceptionally accurate—sometimes more accurate than documentation suggests, because it’s based on observing actual chip behavior. However, FPGA implementations must make choices about what to replicate. Do you replicate the analog audio filtering? Do you replicate the RF shielding quirks that affected some units? Most FPGA cores focus on the critical path logic and approximate or omit secondary details.
The practical reality: for >99% of games, all three approaches are indistinguishable to the player. The differences exist in edge cases, and for most people, those edge cases are irrelevant.
The Real Cost-Benefit Analysis
Let’s talk about practical considerations: which approach makes sense for which use case?
Original hardware
Pros: Absolute authenticity. No software interpretation. Works exactly as designed. Cultural and historical significance. Many people enjoy using the actual artifact.
Cons: Requires ongoing maintenance and component replacement. $100-400 to acquire a working system (more for rarer consoles). Risk of further degradation. Requires specialized knowledge for repairs (or expensive repair services). Limited storage for games—you’re physically swapping cartridges. You’ll need appropriate cables and adapters to connect to modern displays.
Best for: Collectors. People who enjoy the ritual and tactile experience of the original hardware. Those with technical skills for maintenance. Situations where you want the absolute original artifact.
Software emulation
Pros: Extremely affordable (free to $15). Access to thousands of games. Runs on any modern hardware. Rapid iteration and compatibility improvements. Easy to set up on platforms like RetroPie. Highly portable (phone, tablet, laptop). Community support is enormous.
Cons: Depends on host system performance. Potential for latency spikes under load. Legal gray area around ROM distribution (though emulation itself is legal). Some edge cases and undocumented behaviors aren’t perfectly replicated. Display quality depends on your TV and cable quality.
Best for: Budget-conscious hobbyists. People who want access to large libraries. Those without technical skills for hardware maintenance. Casual players for whom latency and edge cases don’t matter.
FPGA
Pros: Hardware-level accuracy with modern convenience. Deterministic timing (lower and more consistent latency). Can output both digital (HDMI) and analog signals. No host OS interference. Excellent for quality-focused enthusiasts.
Cons: More expensive ($150-600+ depending on platform). Smaller library than software emulation (though growing). Requires more technical knowledge to set up and configure. Accuracy depends on quality of reverse engineering. Less portable than software emulation.
Best for: Enthusiasts with technical knowledge and budget. Competitive players who care about precise latency. People who want hardware-level performance with modern convenience. Those who appreciate the engineering behind the emulation.
The Honest Recommendation
If you’re asking “which should I choose?” the answer depends on why you’re playing.
If you want to understand the retro gaming landscape, own all three approaches isn’t unreasonable. Software emulation on a RetroPie ($150-400) gives you access to thousands of games. An original NES ($100-300) gives you the artifact. An FPGA system if your budget allows ($200-600) gives you the best of both worlds for the supported platforms.
If you have to choose one: software emulation is the practical choice for most people. It’s affordable, accessible, and accurate enough for 99% of use cases.
If you have technical skills and budget: FPGA is the most impressive option technically. It demonstrates superior engineering and provides measurably lower latency and higher compatibility on edge cases.
If you’re a collector or historian: original hardware has irreplaceable value, but understand that maintenance is required and it’s not passive ownership.
The important realization is that none of these is objectively “best.” They optimize for different goals. Original hardware prioritizes authenticity and artifact preservation. Software emulation prioritizes accessibility and library breadth. FPGA prioritizes accuracy and performance within hardware constraints.
Each approach is legitimate. Each has real engineering trade-offs. Understanding those trade-offs helps you make a choice aligned with your actual priorities—not with nostalgia, gatekeeping, or marketing narratives.