FPGA or emulation: what's the difference, and can you see it?

Two machines display the same Game Boy game, with the same colours and the same sound. One costs €90, the other €240 when it is in stock. The first runs a program that imitates the original console. The second reconfigures a chip so that it behaves, circuit by circuit, like the original console. That is the whole difference between emulation and FPGA, and a great deal of ink has been spilled over a gap most players will never see. What remains is to work out exactly when it does become visible, what the machines involved cost, and why everything changes if you still own your cartridges.

Two ways of running a game from 1990

Emulation: imitation in software

An emulator is a program. It reads the game's instructions one by one and works out what the original processor would have produced at each cycle, then does the same for the graphics chip, the sound chip and the memory.

All of this is sequential, and shared with the operating system and the display. The quality depends on the care put into the program: the more closely the emulator reproduces the original cycles, the more power it demands.

FPGA: a circuit that reconfigures itself

An FPGA (field-programmable gate array) is a chip made of thousands of logic blocks and programmable connections. You do not write a program for it: you describe a circuit to it, and it wires itself up to become that circuit, with its real parallelism.

That is the approach Analogue claims, describing an implementation "at the transistor level": where the emulator imitates a behaviour in software, the FPGA recreates the hardware at circuit level. The chip does, at the same time, what the various original chips did at the same time.

What it changes in practice

Latency

This is the argument put forward most often. On an FPGA machine, a button press enters a circuit that processes the signal at the same time as it computes the image; Analogue announces that the hardware registers it "almost instantly". On a Linux or Android console, the controller goes through the driver, the system, the emulator, then the display queue, and each stage adds its own delay.

The gap is counted in frames, not in tenths of a second. And there is a serious counter-measure: RetroArch's Run-Ahead feature computes frames in advance and rewinds the action as close as possible to the input, to the point of going below the original console's latency, since it removes the game's internal delay. The project's documentation states the price: the more frames of lead, the more processor load, and possible sound artefacts in single-instance mode. On a small Linux machine, that budget is sometimes missing. See our essential RetroArch settings.

Compatibility

Here the advantage changes sides. A well-written core runs the entire catalogue of its system, including titles with a special chip in the cartridge, because the circuit is reproduced rather than worked around. But a core does not exist for everything: the open MiSTer project, built on a DE10-Nano board with a Cyclone V FPGA, lists PlayStation, Saturn, SNES, NES and Megadrive cores. Beyond that, the chip's capacity becomes a wall. Emulation, for its part, goes as high as the processor allows, which is why Android consoles reach the GameCube or the PlayStation 2 when no consumer FPGA machine comes close.

Special behaviours

Some games exploit details of the hardware that emulation has to guess at: effects changed mid-scan of the image, transparency obtained by flickering every other frame, tight audio timings, cartridges with built-in hardware (a clock, a tilt sensor, rumble). A reconstituted circuit reproduces these cases by construction; an emulator reproduces them if it was written to, which the most mature ones were.

Can you really see it?

The honest answer: on the vast majority of games, no. With a Game Boy Color Zelda on the sofa, nobody will tell the difference between a good, well-tuned emulator and an FPGA machine. The gaps are measurable, not perceptible. There are, however, cases where they do become noticeable.

In other words: the FPGA wins on fidelity to old hardware, emulation on the breadth of the catalogue.

The machines involved, and what they cost

The FPGA market is narrow, produced in small runs and regularly out of stock. Official manufacturer prices in dollars, excluding tax and import charges, at the time of writing.

Two clarifications. The Analogue Pocket reads other formats through a set of official adapters at $99.99 (Game Gear, Neo Geo Pocket, Atari Lynx, PC Engine), and its openFPGA platform opens core publishing to third-party developers. The MiSTer is not a finished product: it is a development board to be completed with memory, a USB hub and an input/output board, assembly included.

The case of original cartridges

This is the strongest argument in favour of the FPGA. A machine with a cartridge slot reads your cartridge: not a copy, not a file, the cartridge you bought back then, with its save battery and its internal clock if it has one. The question of game files no longer arises, since there is no file.

Real comfort if your collection is still around, a real handicap if it has gone: with no cartridge, such a machine is of no use.

On copies, the line is simple. Making a backup copy of your own cartridge falls under article L122-6-1 of the French Intellectual Property Code, but video games have been a "complex work" since the Cour de cassation ruling of 25 June 2009, and no French case law settles this point. Downloading a ROM, on the other hand, remains an infringement, even if you own the cartridge. We are retailers, not lawyers: information, not legal advice. The detail is on our Where to play legally page, the method in our guide to copying cartridges and the hardware in the cartridge readers section.

Who the FPGA makes sense for

The FPGA makes sense if you still own your cartridges, if you play genres that are demanding on timing, if period accessories and the link cable matter to you, or if hardware accuracy interests you. Add to that a tolerance for buying in dollars and for waiting.

Emulation is more than enough everywhere else, and it does things the FPGA does not: save at any moment, rewind, filters, several dozen systems on a single machine, and a budget that starts under €100. A Linux console covers the 8-bit and 16-bit era, the PlayStation and often the Nintendo DS or the Nintendo 64 depending on the model; an Android console reaches the PSP, the GameCube and the PlayStation 2 on the most powerful ones.

The two approaches are not mutually exclusive: many collectors keep an FPGA machine for their cartridges and an emulation handheld for everything else. For that second part, our comparison tool filters by emulated system and by budget, and our models are in the handheld consoles section.