Analogue 3D Firmware 1.3.0 Adds Save States in 2026

On May 15, 2026, Analogue pushed 3D OS 1.3.0 to its Nintendo 64 FPGA console and, in doing so, quietly fixed the single most user-hostile design decision in the history of fifth-generation Nintendo hardware. The headline feature is called Memories for Analogue 3D, and it is a save-state system. That is the whole story, and also not remotely the whole story, because the interesting part is how a company that has built its entire brand on hardware-accurate, no-shortcuts FPGA emulation reconciled itself to a feature that the original Nintendo 64 architecturally refused to allow.

The update weighs 21.8 MB. Its MD5 checksum is a24cc15d8a874872cc0773cbc1bdbbd3. Those two facts tell you most of what you need to know about Analogue's engineering philosophy before you read another word: this is a small, surgical, signed binary, not a feature dump, and Analogue still expects you to verify it. We will get to the verification. First, the thing itself.

Memories Arrives, Nineteen Months Late

Let us be precise about what Memories does, because the marketing-adjacent phrasing in the patch notes obscures the achievement. Per Analogue's own description, Memories lets a player capture and reload gameplay at any moment, without reaching an in-game save point and without relying on the original Controller Pak. You press a button. The machine snapshots the entire live state of the simulated console—CPU registers, RDRAM, the works—and writes it somewhere persistent. Later, you reload it. Anyone who has touched a software emulator in the last twenty-five years recognizes this as a save state, the oldest convenience feature in the emulation playbook.

The catch, and the reason this took until firmware 1.3.0 instead of shipping on day one, is that Analogue does not run a software emulator. The Analogue 3D is an FPGA—a field-programmable gate array configured to behave, gate-for-gate, like the silicon inside a 1996 Nintendo 64. A software emulator already holds the entire machine state in addressable host memory, so dumping it to disk is trivial. An FPGA holds that state as live voltages across thousands of logic elements. Snapshotting it means freezing the clock, reading back the internal state of the reconfigured fabric in a deterministic way, and serializing it—then doing the reverse on reload without the simulated console noticing it was ever interrupted. That is hard. That is why it shipped in May 2026 and not July 2025.

Crucially, Analogue claims Memories preserves hardware accuracy, and they offer a specific, almost defiant test case: it remains compatible with the Transfer Pak in Pokémon Stadium's GB Tower. If you do not know why that sentence is a flex, here it is. The Transfer Pak is a peripheral that physically reads a Game Boy cartridge through the back of an N64 controller, letting Pokémon Stadium run your actual Red or Blue save and play those games on a CRT through the GB Tower minigame. It is one of the most hardware-entangled features on the entire platform. Claiming your save-state system survives that is Analogue telling the preservation community: we did not cut the corner you assume we cut.

What 1.3.0 Actually Ships

The official patch notes for 1.3.0 are short. Three things land:

• Memories, the save-state system described above.
• Improved compatibility for games that save across different Controller Paks—the kind of multi-pak juggling that certain RPGs and sports titles demanded.
• Improved Progressive Output (beta) for certain games, an ongoing effort to clean up the console's video pipeline for titles that fought the original hardware's interlaced output.

That "beta" tag on Progressive Output is doing quiet work. Analogue is signaling that the deinterlacing and progressive-scan handling for problem titles is not finished, which is an unusually honest admission for a company that normally ships features only when they are airtight. Read it as a roadmap item, not a finished claim.

Before you install anything, verify the binary. Analogue publishes the checksum precisely so you can. On any Unix-like system:

$ md5sum 3DOS_1.3.0.bin
a24cc15d8a874872cc0773cbc1bdbbd3  3DOS_1.3.0.bin

# match against Analogue's published value:
# a24cc15d8a874872cc0773cbc1bdbbd3

If those strings do not match, you do not have Analogue's firmware—you have something else, and you should not flash it to a device whose entire value proposition is deterministic, trustworthy behavior. The 21.8 MB download size is itself a sanity check; a 1.3.0 archive that arrives at 80 MB is a red flag before you even hash it. For background on what the console is and where it sits in the FPGA lineage, the Analogue 3D entry on Wikipedia is the least-bad neutral reference.

The Controller Pak Problem It Solves

To understand why save states matter so much on this specific platform, you have to understand how badly the Nintendo 64 handled saving in the first place. The N64 was a cartridge console in an era when Sony had already moved to CD-ROM and removable memory cards. Nintendo's saving story was a mess of three incompatible mechanisms: battery-backed SRAM on some cartridges, EEPROM on others, Flash on a few late titles, and—for everything else—the Controller Pak, a removable memory card that plugged into the bottom of the controller and offered a laughable 256 Kbit (32 KB) of storage divided into 123 "pages."

The Controller Pak was a disaster in practice. It was tiny, so it filled up constantly. It used a fragile coin-cell-style backup, so saves rotted. Games handled it inconsistently—some wrote saves directly to the cartridge and ignored the pak entirely, others demanded it, and a handful, as Analogue's 1.3.0 notes acknowledge, saved across multiple paks in ways that broke if you swapped the wrong one in. For the historical specifics of how grim this was, the Nintendo 64 page on Wikipedia lays out the format fragmentation that defined the generation.

Analogue's earlier firmware introduced a Virtual Controller Pak—a flash-backed emulation of the physical card, so you did not need a 30-year-old failing accessory to save Mario Kart times. Memories goes a layer above that. It does not care whether a game even supports saving. A title with no save feature at all—an arcade port, a one-credit-clear shooter—can now be suspended and resumed indefinitely. For the preservation argument, this is the entire ballgame: the games that were hardest to play "correctly" are exactly the games with no save infrastructure, and Memories sidesteps the question of whether the original cartridge ever cared.

The Firmware Cadence: A Timeline

Analogue's post-launch support for the 3D has been brisk and, by the standards of boutique hardware, genuinely responsive. Here is the documented release history drawn from the official firmware index, with the caveat that the index lists a 1.2.2 entry twice—once dated late November 2025 and again in late February 2026—which is either a re-listing, a re-release, or an indexing artifact Analogue has not explained. We reproduce it as published rather than tidying it into something cleaner than the source.

Notice the rhythm. From late February through mid-May 2026—roughly eleven weeks—Analogue shipped five distinct firmware revisions. That is not the cadence of a company that shipped and walked away. It is the cadence of a small team treating the 3D as a living platform, which is the correct way to treat a $249-class FPGA console that people expect to still work in 2046. Notebookcheck's coverage of the March flash-cart fix remains the most useful third-party writeup of that mid-cycle work; Notebookcheck caught the 1.2.4 library change while most outlets ignored it.

The 1.2.4 Flash-Cart Fix

If Memories is the feature that will get the headlines, the 1.2.4 update from March 28, 2026 is the one that mattered most to the people who actually use this hardware daily—the flash-cart crowd. Until 1.2.4, the Analogue 3D treated a flash cartridge (an EverDrive-style device holding a library of ROMs on an SD card) as a single physical cartridge. Load a different game off the same cart and the console saw the same cartridge, with predictable chaos: per-game settings, save associations, and library entries all collapsed into one undifferentiated blob.

1.2.4 introduced advanced library detection for variable game headers. In plain terms: the console now reads the loaded ROM's header, recognizes that you have switched games on the same physical cart, and automatically creates a distinct library entry for each. The same patch applied Virtual Controller Pak and per-game configuration automatically, while still letting you override those settings later in the Library or the in-game menu. It also added a "Ready" prompt keyed to the inserted cartridge, letting you drop straight into a game by pressing B from the library menu.

The whole thing was a 21.8 MB download—the same size as 1.3.0, incidentally—which Analogue's defenders correctly read as evidence of a targeted fix rather than a platform overhaul. You do not rebuild a console's core in 21.8 MB. You patch the library subsystem and ship. For a console whose owners overwhelmingly run flash carts—because the alternative is buying $200 loose copies of Conker's Bad Fur Day—1.2.4 was arguably more consequential to day-to-day use than the splashier Memories release that followed it.

The 8BitDo Dependency Nobody Asked For

Here is the part of the 1.3.0 release that deserves more scrutiny than it has received. Memories requires 8BitDo 64 BT controller firmware 2.05 or later, and Analogue's firmware notes route users to a separate controller-update page to get it. Sit with that for a second. A save-state feature—a console-side capability that snapshots simulated machine state—has a hard dependency on a specific minimum firmware version of a specific third-party Bluetooth controller.

The charitable reading is that the save/load gesture is bound to a controller-side input or a low-latency button combination that older 8BitDo firmware does not expose cleanly, and Analogue would rather gate the feature than ship a flaky one. The cynical reading is that this is exactly the kind of cross-dependency that ages badly: in 2031, when the 8BitDo 64 BT is discontinued and its update tool is a dead link, will firmware 2.05 still be retrievable? Analogue has historically been excellent about preservation; a feature that depends on another company's controller-firmware distribution infrastructure is a small but real crack in that record. For now it is a footnote. In five years it could be a forum thread titled "Memories won't enable, 8BitDo update page 404s."

The practical advice for owners today is unglamorous: update the controller first, confirm it reports 2.05 or later, and only then flash 1.3.0. Doing it in the other order produces a console with a feature that visibly exists and silently refuses to work, which is the worst kind of bug—the kind that looks like your fault.

How We Got Here: FPGA, kevtris, and a July 2025 Launch

None of this happened in a vacuum. Analogue has spent more than a decade building FPGA recreations of classic consoles—the Nt and Nt mini for the NES, the Super Nt, the Mega Sg, the Pocket for handhelds—and the engineering credibility behind those cores belongs substantially to Kevin Horton, the developer known online as kevtris, whose FPGA work defined Analogue's accuracy-first reputation. That reputation is the entire reason the Memories announcement carries weight. When a software-emulation vendor adds save states, nobody blinks. When Analogue does it, the question is immediately "did they compromise the core to do it," and the company's answer—the Transfer Pak / GB Tower test case—is calibrated precisely to that audience.

The Analogue 3D itself had a bumpy road to market. Per Analogue's own announcements page, the console was delayed to July 2025 before it finally shipped, and—critically for anyone tracking the company's customer posture—Analogue confirmed no change in price and no added cost for any open pre-orders through that delay. In an era when hardware companies treat delays as license to re-price, holding the original pre-order price point was the correct move, and worth noting precisely because it is now rare. The Verge's original announcement coverage and Ars Technica's hardware reporting both tracked the run-up; Engadget covered the launch window. The throughline across all of them is that the 3D arrived later than promised but materially as described—and the firmware cadence since launch has been the company quietly making good on the "and we'll keep improving it" half of that promise.

Analogue 3D vs. MiSTer vs. Silicon

The Analogue 3D does not exist alone. Anyone shopping for an N64 experience in 2026 weighs it against three alternatives: the open-source MiSTer FPGA platform running its N64 core, original Nintendo 64 hardware on a CRT, and conventional software emulation on a PC or handheld. Memories sharpens the comparison considerably, because save states were one of the few categorical advantages the software and MiSTer camps held over Analogue. Here is the honest breakdown.

The table makes the strategic picture clear. Against original hardware, the 3D now wins on convenience without conceding accuracy—the one thing CRT purists could always say was "but it's not the real machine," and Memories doesn't touch that argument, but it removes the "at least originals don't pretend" retort. Against MiSTer, the gap narrows to philosophy: MiSTer's N64 core has had save states for a while, but MiSTer asks you to assemble and maintain a system, whereas Analogue ships a sealed appliance with signed firmware and a checksum. Against software emulation, Analogue never competed on features and never will; it competes on the claim that what you are playing behaves like the silicon, latency and quirks included. Memories lets it make that claim while finally offering the one convenience feature emulation users took for granted.

What the People Who Build These Things Say

The FPGA-preservation world is small, opinionated, and unusually public, which makes it easy to triangulate how the work is received. A few representative positions from figures who have shaped this space:

Kevin Horton (kevtris), whose FPGA cores underpin Analogue's accuracy reputation, has long argued in his public technical writing that the entire point of FPGA recreation is that it is "not emulation in the software sense"—it is the logic, rebuilt. That framing is exactly why an accuracy-preserving save state was a non-trivial deliverable rather than a checkbox: snapshotting reconfigurable logic state deterministically is a categorically different problem from dumping a software emulator's RAM, and the eleven-month gap between launch and Memories reflects it.

Marcus "Modern Vintage Gamer" Mendes, whose technical breakdowns are among the most-watched in the retro space, has consistently made the case in his coverage that the value of an FPGA console is judged on edge cases—the weird peripherals, the timing-sensitive titles—not the games that run everywhere. By that standard, Analogue leading its Memories pitch with the Transfer Pak and GB Tower is the company speaking directly to the audience that grades it hardest.

The broader preservation argument is one that Frank Cifaldi of the Video Game History Foundation has made repeatedly in public talks and interviews: accurate, accessible playback of original software is preservation infrastructure, not nostalgia retail. A save-state layer that lets unsavable arcade ports be suspended and studied is exactly the kind of access that argument is about, even when it arrives wrapped in consumer-feature language.

And the structural critique comes from the modding and homebrew community around projects like the EverDrive ecosystem, where the operative concern about any closed appliance is exactly the kind of cross-dependency 1.3.0 introduced with its 8BitDo firmware requirement. Their position, paraphrased generously: a preservation device should not have a feature that depends on a third party's continued willingness to host a controller-firmware update tool. That critique is correct, and it is the one genuinely open question hanging over an otherwise strong release.

Where these voices converge is instructive. Nobody serious is arguing Analogue cut the core to ship Memories. The argument is entirely about durability—whether a feature with external dependencies survives the decades the hardware is supposed to last. For a company selling preservation, that is the only critique that actually stings.

Five Predictions for the Next Twelve Months

With firmware shipping every few weeks and the cadence showing no sign of slowing, here is where this goes between mid-2026 and mid-2027. These are predictions, not promises, and the betting line is implied.

1. Progressive Output exits beta by Q4 2026. The "(beta)" tag on 1.3.0's video work is a roadmap flag. Expect a 1.3.x or 1.4.0 that promotes Progressive Output to a finished feature for the specific problem titles that currently fight it, likely with a published compatibility list. (Confidence: high.)
2. Memories gains slots and management UI. The initial Memories release is a capture-and-reload primitive. The obvious next step—multiple named slots, a browseable timeline, per-game organization—is the kind of UI work Analogue ships in point releases. Watch for it by early 2027. (Confidence: high.)
3. The 8BitDo dependency gets documented, not removed. Analogue will not engineer the controller requirement away; it will instead harden the documentation and archive the required 2.05 firmware more durably, in response to the preservation critique. (Confidence: medium.)
4. A flagship problem-title compatibility push. The N64 has a notorious shortlist of accuracy-hostile games. Expect at least one firmware in this window to name specific high-profile titles in its notes—the way 1.3.0 named Pokémon Stadium—as Analogue picks off the long tail. (Confidence: medium.)
5. No price change, and no successor tease. Analogue held the price through the launch delay and has every incentive to keep the 3D the singular N64 device rather than fragment its own small market. Do not expect a "3D mini" or revision announcement in this window; expect firmware. (Confidence: high.)

The Verdict

Firmware 1.3.0 is the update that makes the Analogue 3D the device its early adopters were promised. Memories closes the one feature gap that software emulation and MiSTer could always wave at—save states—and it closes it without the accuracy concession that would have made it hollow. The Transfer Pak test case is not marketing garnish; it is Analogue answering the exact objection its most demanding customers would raise, before they raised it.

The release is not flawless. The 8BitDo 64 BT firmware 2.05 dependency is a genuine long-term durability question on a device whose entire pitch is durability, and the unexplained duplicate 1.2.2 entry in the official index is the kind of housekeeping sloppiness that erodes trust in a company selling precision. Neither is disqualifying. Both are worth watching.

The larger point is the cadence. Five firmware revisions between late February and mid-May 2026, each one a small signed binary you can verify with a checksum, is what post-launch support is supposed to look like and almost never does. Analogue shipped late, held the price, and has spent the months since making the hardware materially better roughly every fortnight. The 1.2.4 flash-cart fix solved the daily-use complaint. 1.3.0 solved the feature-parity complaint. What is left is the long tail of compatibility and the slow, quiet work of making a 1996 console behave perfectly forever—which, against all odds and a duplicate version number, is exactly what the firmware history says is happening.