Analogue 3D v1.3.0 (2026): Save States, 900+ Games

For nineteen months the most-asked question about the Analogue 3D was not about its DAC, its scalers, or its 4K output. It was a four-word complaint: where are the save states? A console that shipped at a premium price, that promised to play the entire N64 catalogue on original hardware-accurate silicon, launched without the single feature every emulator handheld on Earth ships for free. With firmware v1.3.0, dated 2026-05-15 and labelled by Analogue as the recommended release, that gap is closed. The update introduces “Memories,” Analogue's branded save-state system, and it covers what the company describes as the full 900+ N64 cartridge library.

This is, depending on your temperament, either a triumphant act of post-launch support or an admission that the 3D shipped incomplete. The Machine's view is that it is plainly both, and that the more interesting story is the cadence: five months, half a dozen firmware drops, a steadily narrowing list of excuses. Let's go through it with the numbers in front of us.

Memories: The Save-State System Analogue Withheld

What Memories actually does

Memories is a save-state system. Analogue can call it whatever it likes — and the marketing instinct to brand a generic feature is by now a tic of the entire FPGA-console industry — but functionally it captures the live machine state and lets you restore it. The headline claim is coverage: Analogue says Memories works across the entire 900+ licensed N64 cartridge library, not a curated subset. That is the part that matters. Save states that only work on the popular forty titles are a demo; save states that work on the long tail are a feature.

Why it took until v1.3.0

The honest answer is that save states on an FPGA console are harder than on a software emulator. An emulator already owns the machine state in host RAM; serialising it is trivial. An FPGA implementation is a hardware-accurate reconstruction running in parallel, and snapshotting the full register and memory topology of a reconstructed N64 — RDP, RSP, the Reality Coprocessor, expansion RAM — without desyncing the live system is a genuine engineering problem. The fact that it arrived in May 2026 rather than at the July 2025 launch is not laziness; it is the cost of doing the thing properly instead of faking it. Whether you should have paid full price for a console that couldn't do it yet is a separate, fair question.

The 900-game number, examined

The N64's licensed library sits at roughly 388 North American titles and a worldwide total in the high 300s to low 400s depending on how you count regional variants. So where does 900+ come from? It is the all-region, all-variant count — PAL, NTSC-J, NTSC-U, revisions, and the regional re-releases that the 3D's Nintendo 64 compatibility layer treats as distinct. Memories covering “900+” is therefore a claim about variant breadth, not about a secret trove of unknown games. It is still the right number to quote, because it means region-locked imports and revisions are not second-class citizens.

The 2026 Firmware Timeline

A console that shipped, then kept shipping

Analogue's official announcements made clear the 3D was delayed and would ship by July 2025, which reframes everything that followed. This is not a pre-release changelog; it is a live post-launch support cycle for hardware already in living rooms. The firmware page reads less like patch notes and more like a confession of how much was unfinished at launch — and, to be fair, a record of how quickly the company chased it down.

Every dated release, in order

Here is the consolidated timeline drawn from Analogue's firmware page, Time Extension, and Notebookcheck. Dates are the publicly listed release dates.

What the cadence tells you

Six dated releases between November 2025 and May 2026 is roughly one drop a month. That is aggressive by FPGA-console standards, where the original MiSTer ecosystem relies on volunteer core authors and the Super Nt / Mega Sg generation went months between updates. Analogue is treating the 3D like a platform with a roadmap rather than a sealed appliance. The cynic notes that a console needing monthly firmware is a console that launched rough. The realist notes that monthly firmware is exactly what you want when it does. Both are looking at the same table.

Overclock Mode and the 1.1.9 Foundation

The substantial November patch

The groundwork for everything that followed was v1.1.9, which Time Extension reported went live in November 2025 and brought what it called “substantial” updates to Overclock mode. Overclock matters because the N64's real bottleneck was almost never the GPU — it was the CPU and the chronically slow main memory. Games like Perfect Dark and GoldenEye 007 were CPU-bound to the point of single-digit framerates in heavy firefights. An FPGA can clock the reconstructed CPU faster than the original silicon ever ran, and 1.1.9's improvements to that path are the difference between archival accuracy and actually-playable Perfect Dark.

Region select and texture filtering

The same patch added manual region selection and a “Disable Texture Filtering” option in the configure menu. The region toggle is quality-of-life for importers; the texture-filtering switch is a statement of intent. The N64's signature bilinear smear was a hardware reality, not an artistic choice, and being able to turn it off gives you the sharper, more authentic pixel output that purists have wanted for two decades. If you are the kind of person who dumps your own carts to get clean ROMs — and our Retrode 2 cart-dumping walkthrough exists for exactly that person — this is the toggle you'll live in.

The unglamorous compatibility fixes

1.1.9 also fixed frame overflow issues on Bomberman Hero (PAL) and Super Smash Bros., improved SD connect mode device support, and resolved USB controller inconsistency problems. None of these make a trailer. All of them are the actual work of a compatibility layer: per-game edge cases, accessory handshakes, the unglamorous grind that separates “plays most games” from “plays the library.”

Advanced Library Detection and Flash Carts

The EverDrive problem

Flash carts are how most owners actually feed an FPGA console. The EverDrive 64 and SummerCart 64 let you load ROM collections from an SD card through a single cartridge, which means the 3D sees one physical cart presenting a constantly changing payload. The pre-1.2.4 library system handled that badly — it could not cleanly distinguish one loaded ROM from the next, so per-game configuration and save data smeared together.

What 1.2.4 changed

Notebookcheck reported that firmware v1.2.4 shipped 2026-03-28 with “advanced library detection,” built specifically so the 3D tracks each ROM header change as a separate library entry. In Analogue's own patch language, when a cartridge changes its header the new ROM is “detected, added, and tracked in the Library,” with per-game config and Virtual Controller Pak data applied automatically. That last detail is the important one: it means your flash-cart games each get their own settings and their own virtual memory pak, exactly as if they were individual physical cartridges.

Why this matters for accessory-heavy setups

If your workflow is a SummerCart 64 stuffed with a few hundred ROMs, 1.2.4 is arguably more consequential than Memories. It is the patch that makes the 3D behave like a real library device instead of a single-cart player with amnesia. Anyone running a deep self-built collection — the same instinct behind curating a large handheld game list — will recognise why per-entry tracking is the unsung hero of this update cycle.

1.2.0 and the Living-Room Interop Mess

The HDMI chain is the enemy

A YouTube breakdown of the v1.2.0 update detailed fixes for compatibility issues with some 4K TVs, HDMI switches, and HDMI CEC/eARC. This is the least sexy and most relatable category of bug, because the modern living room is a hostile environment: a 4K panel, a soundbar negotiating eARC, an HDMI switch in the middle, and CEC trying to coordinate power and input across all of it. A retro console outputting an unusual resolution timing is exactly the kind of device that exposes every weak handshake in that chain.

The features that came with the fixes

1.2.0 was not only repairs. It added total playtime tracking, game-added dates, Expansion Pak and Controller Pak indicators, and a beta “Force Progressive Output” feature. The Expansion Pak indicator is a genuinely thoughtful touch — it tells you at a glance whether a game is running in its enhanced 8MB mode — and Force Progressive is the kind of beta toggle that quietly fixes a stubborn TV's refusal to lock onto the signal.

Compare the friction to an emulation box

The irony is that a software setup running a stack like our RetroArch core configuration often sidesteps these display problems entirely, because it outputs whatever clean modern resolution the host GPU prefers. The 3D's display friction is the tax of hardware-accurate output. You are paying in HDMI handshakes for the privilege of a signal that behaves more like the real thing.

The 8BitDo 2.05 Requirement

The catch buried in the patch notes

Here is the line that will generate the most support tickets. Analogue says the 8BitDo 64 BT controller must be updated to version 2.05 or later to use firmware v1.3.0. If you update the console and not the controller, you are in for a confusing afternoon. This is a hard dependency, not a recommendation, and it is the sort of detail that gets skimmed past in the excitement of finally having save states.

Why a controller needs its own firmware

The 8BitDo 64 is a wireless pad with its own microcontroller and its own firmware, and Memories almost certainly relies on a new input or button-combination path — the kind of “hold this to summon the save-state menu” shortcut that has to be understood at both ends of the Bluetooth link. The controller and console firmware are versioned together by necessity. It is the same coupling that bites people across the whole accessory-heavy retro space, where every dongle and pad carries its own update obligation.

The cross-vendor dependency risk

There is a structural lesson here. Analogue's signature feature now depends on a third party's controller firmware. 8BitDo is reliable, but the precedent is worth noting: when your headline software feature requires version 2.05 of someone else's hardware, you have introduced a dependency you do not fully control. For now it is a footnote. In a future where Analogue ships more features gated on controller updates, it could become a friction point.

Historical Context: FPGA and the N64 Problem

Why the N64 was the hard one

Analogue spent a decade shipping FPGA recreations of comparatively tractable machines: the NES (Nt mini), SNES (Super Nt), Genesis (Mega Sg), Game Boy line (Pocket). Those are 8- and 16-bit systems with well-documented, relatively simple architectures. The N64 is a different animal. Its FPGA reconstruction has to model the MIPS R4300i CPU, the SGI-derived Reality Coprocessor with its RSP and RDP, a notoriously latency-bound memory subsystem, and a microcode model that varied game to game. The N64 was the console even software emulation took the longest to get right. That the 3D shipped at all is the achievement; that it shipped without save states is the cost of that achievement.

Analogue's launch-then-iterate pattern

This is also not the first time Analogue has launched hardware and finished it in firmware. The Pocket gained its OpenFPGA platform, library features, and display tuning long after release. The pattern is now a known quantity: buy the hardware, accept that the software platform matures over six to twelve months. Whether that is acceptable depends on whether you treat a $200-plus console as a finished product or as a subscription to a roadmap. The 3D's 2026 firmware run suggests the latter is the honest framing.

The save-state lineage

Save states themselves are an emulation invention dating to the 1990s desktop emulator scene — ZSNES, Project64, and their contemporaries. Bringing them to original-hardware-equivalent FPGA silicon is a relatively new frontier, and Analogue is not first; the MiSTer scene has experimented with save states on several cores for years. What Analogue offers is the productised, library-wide, no-config version. The history is emulation's; the polish is Analogue's.

Competitive Comparison: FPGA vs. Emulation

The three ways to play N64 in 2026

The 3D does not exist in a vacuum. In 2026 you have three credible paths to N64 software: Analogue's FPGA console, the open MiSTer/MultiSystem-style FPGA route, and straightforward software emulation on a handheld or PC. Each has a distinct trade profile, and the firmware story changes the math.

Against the open FPGA scene

The DIY FPGA route — the world of the MultiSystem FPGA console and MiSTer — offers flexibility the 3D will never match: one board, dozens of systems, community cores. What it does not offer is the turnkey experience. Save states are per-core and inconsistent, N64 support on open platforms remains the hardest target, and the setup is a project. v1.3.0 widens Analogue's lead precisely where the open scene is weakest: library-wide, zero-config save states that just work.

Against software emulation

Software emulation already had save states, free, universal, and instant. That has always been emulation's structural advantage, and a properly tuned RetroArch build will save-state any N64 game you throw at it. What it cannot give you is hardware-accurate timing and native low-latency output to a real CRT or a 4K panel. v1.3.0 is Analogue neutralising emulation's single biggest convenience edge. The pitch is now “everything emulation does, plus accuracy” — at a price emulation undercuts every time. For most players the handheld emulation route, the kind we weigh in our Retroid Pocket 6 verdict, remains the value option. The 3D is the connoisseur option, and v1.3.0 makes it a less compromised one.

How to Update Without Bricking the Mood

The order of operations

The single most important thing about installing v1.3.0 is sequence. Update the controller's firmware to 2.05 or later before you rely on Memories, and read the on-device prompts. The high-level process is straightforward, but the 8BitDo dependency is the step people skip.

1. Confirm current 3D firmware version
   Settings -> System -> Firmware

2. Update the 8BitDo 64 BT controller FIRST
   - Open the 8BitDo Firmware Updater (desktop)
   - Connect the 64 BT pad via USB
   - Flash to v2.05 or later  <-- required for v1.3.0

3. Download Analogue 3D firmware v1.3.0 (2026-05-15)
   - Copy the firmware file to the root of a FAT32 SD card

4. Insert SD card -> Settings -> System -> Update
   - Do NOT power off mid-flash

5. After reboot, verify version reads v1.3.0

6. Test Memories:
   - Load any cartridge
   - Use the save-state shortcut to create a Memory
   - Restore it to confirm the controller handshake works

Common failure modes

If Memories appears unresponsive, ninety percent of the time the controller is still on pre-2.05 firmware. The second most common issue is an SD card that is not FAT32 or has the firmware file buried in a subfolder instead of the root. The third is impatience: interrupting the flash. Treat the update like any firmware operation on hardware you care about — stable power, correct file placement, and don't touch it while it writes.

Should you update at all?

Yes. v1.3.0 is the recommended version per Analogue's own page, it is cumulative over the 1.2.x line, and it delivers the marquee feature. The only reason to hold off is if you depend on a specific accessory you cannot yet update — and given the 8BitDo requirement, that calculus is mostly about whether you own that pad and can flash it.

What Happens Next: Predictions for Late 2026

Where the firmware goes

Based on the 2026 cadence, here is what The Machine expects over the next six to twelve months. Treat these as informed bets, not promises.

• Memories gets cloud or SD export. Library-wide local save states are step one. Expect a 1.3.x or 1.4 release that lets you back up and transfer Memories, because a save-state system without portability is a liability the community will loudly notice.
• A rewind or save-state slot expansion. Once the snapshot infrastructure exists, multiple slots and possibly a rewind feature are low-hanging fruit. Emulators normalised both; Analogue will face pressure to match.
• Further flash-cart hardening. The 1.2.4 library detection work is the kind of feature that surfaces new edge cases the moment it ships. Expect follow-up fixes for additional flash carts beyond EverDrive and SummerCart 64.
• The 8BitDo dependency becomes a pattern, not an exception. If v1.3.0 set the precedent that headline features can require controller firmware, future updates will lean on it again. Watch for a second feature gated on a controller version bump.
• The update pace slows after the library is “complete.” Monthly firmware is launch-recovery behaviour. Once the obvious gaps — save states, library management, display interop — are filled, expect the cadence to relax toward quarterly. That will be the real signal that the 3D is finished.

The verdict on the cycle

Step back from any single patch and the 2026 firmware run reads as a competent, slightly embarrassing recovery. Embarrassing because the 3D shipped without features its $90 competitors include by default. Competent because Analogue actually fixed it, fast, in public, with real engineering behind features like CPU overclock and library-wide save states that are genuinely hard on FPGA silicon. The coverage at launch was right to flag the gaps; the coverage now should be equally willing to credit the close.

Who should buy now

If you wanted an N64 console that plays your real carts at native 4K with hardware-accurate output and now, finally, save states across the whole library — v1.3.0 is the version that makes the 3D the product it was sold as. If you mostly want convenience and price, software emulation still wins, and it always did. The firmware did not change that equation. It just made the premium option a fair fight.