One Dev, Fourteen Cores, and the Bridge Between FPGA Purists and Achievement Hunters

The Problem Nobody Had a Clean Answer For

MiSTer FPGA recreates console hardware in programmable silicon. There is no CPU interpreting opcodes. There is no software emulation layer. The Verilog cores that run on a Cyclone V FPGA are the hardware, rebuilt gate by gate, cycle by cycle. That's the entire premise, and it's the reason a particular kind of preservationist trusts MiSTer over software emulators: there's nothing between the original game code and the logic it was designed to run on except the fidelity of the core author's work.

RetroAchievements — the community-driven system that adds achievement tracking to retro games — has the opposite architecture. It works by reading emulator RAM at runtime. Every frame, a client library called rcheevos inspects specific memory addresses, checks them against achievement conditions authored by the RA community, and fires unlocks when the conditions are met. It's deeply integrated into software emulators: RetroArch, DuckStation, PCSX2, dozens of others. The library needs to see RAM. That's the contract.

FPGA cores don't expose RAM the way software emulators do. The state lives inside the FPGA fabric. You can't just hand a pointer to rcheevos and say "read here." For years, the two communities — FPGA purists who care about hardware accuracy and achievement hunters who care about verified completion — occupied the same hobby but different tool chains. Bridging them meant solving an interface problem that sits at the boundary between hardware description and software expectation.

odelot solved it.

The Schematic: VBlank as a Synchronization Point

The mechanism is documented in odelot's Main_MiSTer fork and discussed in detail on the MiSTer FPGA forum. Here's how it works:

Each FPGA core is modified to mirror its internal RAM state to DDRAM — the DE10-Nano's external DDR3 memory — at every VBlank interval. VBlank is the vertical blanking period between display frames, roughly sixty times per second for NTSC systems. It's the natural synchronization heartbeat of any display-driven system, and it's already used by cores for housekeeping. odelot's patch adds one more task to the VBlank window: dump the relevant RAM contents to a known DDRAM offset.

On the Linux side — MiSTer's ARM-based host OS — a polling function called achievements_poll() runs in the main loop. Every frame, it checks whether the FPGA has written new data to the DDRAM mirror. If fresh data is present, it calls rc_client_do_frame() from the rcheevos library, passing in a read function that maps RA's address requests to the mirrored DDRAM buffer. The rcheevos library evaluates all active achievement conditions against the snapshot. If a condition set evaluates to true, the achievement fires. The unlock gets posted to RetroAchievements' server. Your profile updates. A tiny notification appears on screen.

"Thanks to the hard work of odelot, it is now possible to play NES games with HARDCORE achievements on MiSTer FPGA Hardware!"
— RetroAchievements forum announcement

The elegance is in the boundary. The FPGA core doesn't know or care about achievements. It mirrors RAM because the patch tells it to, the same way it might mirror RAM for save-state support. The rcheevos library doesn't know or care about FPGA. It reads memory addresses from a buffer, same as it does in RetroArch. odelot's contribution is the translation layer between two systems that were never designed to talk to each other — and he placed it at the one point where both systems were already pausing to catch their breath.

Side-by-Side: Software Emulator vs. FPGA Bridge

In a software emulator like RetroArch, the flow looks like this:

Game ROM → CPU interpreter → emulated RAM (host memory) → rcheevos reads RAM directly → achievement fires.

The rcheevos library has native access to the emulated console's memory because that memory is host memory. The addresses are software constructs. Reading them is trivial.

In odelot's MiSTer bridge:

Game ROM → FPGA Verilog core → internal BRAM/registers → [VBlank mirror] → DDRAM buffer → rcheevos reads buffer → achievement fires.

The extra step — VBlank mirror — is the entire invention. It converts hardware state into software-readable state without disrupting the core's cycle accuracy. The FPGA doesn't slow down. The mirror happens in the blanking interval when the core isn't drawing pixels. The latency is exactly one frame, which is the same latency rcheevos tolerates in software emulators where the poll runs once per frame anyway.

One frame. Same contract. Different road to get there.

Fourteen Cores, One Framework

The supported core list is already substantial: NES, SNES, Genesis/Mega Drive, Sega CD, 32X, Game Boy, Game Boy Color, Game Boy Advance, Nintendo 64, PlayStation, Neo Geo, PC Engine, and Atari 2600. Each core required its own RAM-mirroring patch because each core organizes internal memory differently. The NES core's PRG-RAM is not the PlayStation core's main RAM is not the GBA's IWRAM+EWRAM. odelot had to map each core's memory layout to the address space that RetroAchievements' achievement definitions expect.

This is not trivial labor. RetroAchievements' achievement definitions are authored against specific memory maps — typically the memory maps exposed by canonical emulators like Mesen (NES), bsnes (SNES), or Beetle PSX (PlayStation). If the DDRAM mirror doesn't present the same byte at the same virtual address that the achievement author assumed, the achievement either never fires or fires incorrectly. Getting fourteen cores to match fourteen different canonical memory maps is a quiet, grinding, detail-intensive job. odelot did it.

Hardcore Mode and What It Means on FPGA

RetroAchievements distinguishes between softcore and hardcore achievement unlocks. Softcore allows save states, rewind, slow motion — any assist the emulator provides. Hardcore disables all of them. You play the game as the original hardware presented it, start to finish, no safety net. Hardcore unlocks carry more weight on the platform, and leaderboards typically require them.

On MiSTer, hardcore enforcement is currently live for NES only, as Time Extension reported. The reason is straightforward: enforcing hardcore means the integration must be able to detect and block save-state usage, rewind, and any other assist feature. Each core exposes those features differently, and the detection hooks have to be verified per core. NES is the proving ground. The other thirteen cores run in softcore mode for now, with hardcore enforcement expected to roll out as each core's assist-detection is validated.

There's a philosophical dimension here that's worth naming. MiSTer's FPGA cores are already, by definition, running games on accurate hardware recreations. There are no frame-skip hacks, no overclocked CPUs, no compatibility patches. The silicon does what the original silicon did. In a sense, every MiSTer session is already "hardcore" in the way that matters most — hardware fidelity. Adding RetroAchievements' hardcore mode on top of that creates what might be the most rigorously verified achievement environment in retro gaming: cycle-accurate hardware, no assists, server-verified unlocks.

Wes Copeland, the RetroAchievements community figure whose advocacy helped bring attention to the integration, has been vocal about what this means for the platform's legitimacy. When your achievement unlock comes from silicon that behaves like the original console — not from a software approximation of it — the verification story gets significantly harder to argue with.

The Community Toolkit

Getting the integration running requires replacing MiSTer's Main binary with odelot's fork and updating the patched cores. For users who aren't comfortable with manual deployment, a community member going by manyhats-mike has built an automated deployment toolkit that handles the binary swap, core updates, and configuration. It's the kind of scene infrastructure that turns a developer's proof-of-concept into something the broader MiSTer community can actually adopt — the difference between "it's possible" and "it's accessible."

This is a pattern we've seen before: one developer builds the hard technical bridge, and the community builds the on-ramp. The bridge is odelot's. The on-ramp is a group effort. Both matter.

What This Changes

For FPGA purists, RetroAchievements integration adds a social and competitive layer that MiSTer has never had. You could always play Super Metroid on a cycle-accurate SNES core. Now you can prove you beat Ridley without save-scumming, and the proof lives on a public profile alongside every other player who did the same thing on software emulators. The playing field just merged.

For achievement hunters, MiSTer support means they now have a hardware-accurate platform option. If you've ever worried that an emulator's timing quirk might invalidate a tight sequence, or that a save-state detection bug might flag a legitimate run, FPGA eliminates an entire category of uncertainty. The core is the hardware. The achievement fired on the hardware.

For preservation — the beat this site exists to cover — the integration matters because it gives people a reason to play the preserved library. Preservation without access is a vault. Access without engagement is a shelf. RetroAchievements on MiSTer is a reason to pull a thirty-year-old game off the shelf, play it seriously, and have the experience witnessed. That's not everything. But it's not nothing.

One developer. Fourteen cores. One VBlank-width seam between two communities that thought they were playing different games.

They were always playing the same games.