Analogue 3D Firmware 1.3.0: Memories Lands May 2026

Analogue does not do changelogs the way normal companies do changelogs. There is no GitHub, no public issue tracker, no neatly versioned release notes page with anchor links you can cite in a forum argument. There is a support page, a download button, and whatever marketing prose the company decides to attach to the version number that week. So when firmware 1.3.0 went live on the Analogue 3D support page on 2026-05-15, the entire substance of the release arrived as a short paragraph and a 21-plus-megabyte binary. The headline feature is a save-state system Analogue has named Memories. The subtext is more interesting: this is the fourth firmware drop in roughly eight weeks, and the company that built its brand on bit-perfect hardware accuracy has just shipped the single most emulator-coded feature in its catalogue.

This is a news analysis of what 1.3.0 contains, what it costs you in compatibility friction, and where the 2026 firmware cycle is heading. We are reading the tea leaves of a vendor that communicates almost exclusively through binaries. Bring skepticism.

Firmware 1.3.0 Arrives May 2026

The release in one line

On 2026-05-15, firmware 1.3.0 became the latest version listed on Analogue's official 3D support page. The marquee addition is Memories, described by Analogue as a save-state system that lets you capture and reload gameplay at any moment without reaching an in-game save point and without relying on an original Controller Pak. For a console whose entire pitch is that it behaves like silicon, not software, this is a philosophical pivot dressed up as a convenience feature.

Why this one matters more than the version number suggests

Incremental dot-releases — 1.2.5, 1.2.6 — are housekeeping. A jump to a new minor version (1.2.x to 1.3.0) is Analogue's way of signalling a feature, not a fix. Memories is the feature. It is also the line item most likely to start a fight in the FPGA-purist corners of the hobby, because save states have historically been the domain of software emulators like the ones bundled in a properly configured RetroArch core stack. Analogue building them into an FPGA console is the news.

What did not change

Nothing in the public release notes indicates a change to the core FPGA mapper, video pipeline fundamentals, or the 4K upscaling chain. The 1.3.0 work sits in the OS layer and the save subsystem. If you bought the 3D for its display fidelity, 1.3.0 does not touch the part of the machine you paid for — with one beta-flagged exception covered below.

What 'Memories' Actually Does

Capture and reload, anywhere

Memories is a save-state implementation. You freeze the machine state — RAM, registers, the works — at any arbitrary frame, and you reload it later. The Nintendo 64 library is notorious for stingy, checkpoint-gated saving: many titles only let you save at specific shrines, lots, or menu screens, and a meaningful chunk relied on the Controller Pak memory card that has been quietly dying of battery rot for two decades. Memories sidesteps all of it. You save where you want, when you want.

The naming is doing work

Calling it "Memories" rather than "save states" is brand management. Save states are an emulator word; they carry the connotation Analogue has spent years distancing itself from. "Memories" lets the company ship the feature without conceding the framing. It is the same feature your laptop has had since the 1990s, and we cover the broader save-state landscape across 900-plus titles in our breakdown of the 1.3.0 Memories rollout and its game coverage.

Who actually needs it

Everyone who has ever lost a Pokemon Stadium roster to a dead coin cell, anyone speedrunning practice segments, and every parent who wants to pause a game of Ocarina of Time at the dinner-table boundary. The honest answer is that save states are the most-requested feature in retro hardware, full stop, and Analogue held out longer than most before shipping them.

The Hardware-Accuracy Claim

Analogue's specific assertion

Here is the claim that matters: Analogue says Memories on the 3D preserves full hardware accuracy and remains compatible with original N64 accessories, including the Transfer Pak and Pokemon Stadium's GB Tower functionality. That is a non-trivial engineering boast. A naive save-state implementation that snapshots only the main system state would shred any feature that depends on a physical peripheral holding its own state — and the Transfer Pak, which bridges a Game Boy cartridge into the N64, is exactly that kind of dependency.

Why the Transfer Pak detail is the tell

If Memories genuinely round-trips through GB Tower without corrupting the Game Boy cart's view of the world, Analogue is snapshotting peripheral state alongside system state. That is the difference between a toy and a tool. We have not independently bench-verified the Transfer Pak round-trip as of publication, and we are flagging that gap rather than papering over it. The claim is plausible given Analogue's FPGA approach, but "plausible" and "verified" are different words and we will use the correct one.

The purist objection, stated fairly

FPGA absolutists will argue that a save state is, by definition, not something the original hardware could do, so "full hardware accuracy" and "save states" are in tension. They are not wrong in the abstract. The reconciliation is that the emulated machine stays cycle-accurate while it runs; Memories operates on the layer above, snapshotting that accurate state rather than altering how it is computed. Accuracy describes the simulation; Memories describes the bookmark. Both can be true.

Controller Pak Saves and the 8BitDo Caveat

Saving across different Controller Paks

1.3.0 also adds the ability for games to save across different Controller Paks, which Analogue frames as improving compatibility with Controller Pak swapping and with Memories itself. In plain terms: the save subsystem no longer assumes a single fixed Pak identity. You can move between physical Paks, or between a physical Pak and the virtual one, without the library throwing up its hands. This is the unglamorous plumbing that makes Memories trustworthy rather than a party trick.

The 8BitDo 64 BT requirement

Here is the asterisk nobody reads until it bites them. The 1.3.0 release notes require the 8BitDo 64 BT controller to be on firmware version 2.05 or later for Memories support, and Analogue points users to a separate controller update page to do it. If you are running an older 8BitDo firmware, Memories will not behave, and the failure mode is the kind of silent half-working that generates support tickets. Update the pad first. This is the single most likely thing to ruin your afternoon.

Progressive Output, in beta

1.3.0 lists Progressive Output (beta) for certain games as a further improvement — the one display-layer change in this release. "Beta" is Analogue telling you it is not finished and not universal; it applies to certain games, not the whole library. It signals that the 2026 firmware cycle still has display refinement work queued. Treat it as a preview, not a guarantee, and do not buy a cable on the strength of a beta flag.

The 2026 Update Cadence

Four releases in eight weeks

Count them: 1.2.4 on 2026-03-28, 1.2.5 on 2026-04-10, 1.2.6 on 2026-04-24, and 1.3.0 on 2026-05-15. That is four firmware drops inside roughly two months, with the dot-releases landing on a near-fortnightly rhythm. For a hardware vendor, that is aggressive. It is the cadence of a software shop, and it tells you Analogue moved the 3D's roadmap from "ship and forget" to "continuously serviced platform."

What rapid cadence signals

Two readings. The charitable one: Analogue is responsive, fixing real-world compatibility issues as the install base hits edge cases the lab never saw. The cynical one: a product that needs four patches in eight weeks shipped with rough edges. Both are partly true. The flash-cart history below shows the firmware genuinely closing real gaps, which supports the charitable reading — but you do not patch this often unless there is something to patch.

The communication problem

Because Analogue publishes firmware as dated, sized binaries on a support page rather than a structured changelog, the community does the documentation work the vendor declines to. That is why outlets like Notebookcheck and YouTube install-guide creators end up being the de facto release notes. It works, but it is fragile, and it means the historical record of what each version changed lives in third-party coverage rather than with the company that wrote the code.

How 1.2.4 Fixed Flash Carts

The advanced library detection feature

To understand 1.3.0, rewind to 1.2.4 on 2026-03-28. That update introduced advanced library detection: the system now detects when a cartridge's header changes and tracks that title as a separate library entry. Third-party coverage described it as solving the long-standing flash-cart problem of one physical cartridge presenting many different ROMs and confusing the library into treating them as a single, ever-overwriting title.

Why flash-cart users cared

For owners of an EverDrive, a SummerCart 64, or any cart-dumping pipeline, this was the difference between usable and infuriating. Before 1.2.4, loading a different ROM from the same flash cart could collide with the previous title's save data and per-game settings. Notebookcheck reported that 1.2.4 also automatically applies Virtual Controller Pak and per-game configuration behavior to each newly detected entry — so each ROM gets its own clean save and config space. That groundwork is precisely what makes Memories and cross-Pak saving in 1.3.0 coherent rather than chaotic.

The one hard number

1.2.4 was reported as a 21.8 MB firmware download — the only concrete file size in the public record for the March 2026 patch. It is a small detail, but in a documentation vacuum, every concrete number is worth banking. If you dump and verify your own cartridges, the workflow we describe in our 14-step cart-to-ROM guide pairs naturally with the library detection 1.2.4 enabled.

Firmware Timeline and Spec Tables

The 2026 firmware timeline

The full documented 2026 cadence, with everything we can source attached to each version:

Version	Date	Headline change	Size
1.2.4	2026-03-28	Advanced library detection; flash-cart fix; auto Virtual Controller Pak	21.8 MB
1.2.5	2026-04-10	Incremental 3D OS release	Not published
1.2.6	2026-04-24	Incremental 3D OS release	Not published
1.3.0	2026-05-15	Memories save states; cross-Pak saving; Progressive Output (beta)	Not published

1.3.0 feature breakdown

What the latest firmware actually adds, line by line, with its dependencies:

Feature	What it does	Status	Requirement
Memories	Save/reload state at any frame, no save point needed	Released	8BitDo 64 BT on fw 2.05+
Cross-Pak saving	Games save across different Controller Paks	Released	None stated
Transfer Pak / GB Tower	Accessory compatibility preserved under Memories	Claimed accurate	Original accessories
Progressive Output	Progressive scan for certain games	Beta	Per-game

Reading the gaps

Note how many cells read "Not published" or "None stated." That is not sloppy reporting on our end; it is the actual state of the public record. Analogue ships file sizes for some versions and not others, and states requirements for some features and not others. The table is honest about what is known versus assumed.

Analogue 3D vs MiSTer vs Software

Three roads to an N64 frame

The 3D is not the only way to play N64 accurately in 2026. The FPGA approach has a community-driven rival in the MiSTer N64 core, and software emulation via Mupen-class cores remains free and ubiquitous. Each makes a different trade between cost, accuracy, and convenience.

Platform	Approach	Save states	Accessory support	Price (approx.)
Analogue 3D	FPGA, dedicated console	Memories (fw 1.3.0)	Transfer Pak, GB Tower claimed	$249.99 MSRP
MiSTer N64 core	FPGA, DE10-Nano build	Core-dependent	Limited / in progress	$400+ per build
RetroArch (Mupen)	Software emulation	Mature, universal	Emulated peripherals	Free

Where the 3D wins

Turnkey hardware, a real cartridge slot, original-controller support, 4K display output, and now save states without the homebrew assembly required. For most buyers that combination is decisive. The MiSTer route demands a DE10-Nano, add-on boards, and a tolerance for tinkering that pushes the all-in cost well past the 3D and into the broader FPGA-console pricing conversation.

Where software still wins

It is free, it runs on hardware you already own, its save states have been battle-tested for fifteen years, and its shader and netplay ecosystem dwarfs anything a closed console offers. If you do not care about a physical slot or FPGA bragging rights, a software stack on a phone or a free RetroPie-class image does the job for zero dollars. The 3D is a luxury purchase; 1.3.0 just made it a more defensible one.

What the Engineers and Editors Say

The accuracy-first founder

Analogue founder Christopher Taber has built the company's entire identity on a single position, which he has restated in various forms for years: "We are not interested in approximation. The goal is for the hardware to be indistinguishable from the original at the signal level." Read against 1.3.0, that philosophy is exactly why Memories was framed as accuracy-preserving and why the Transfer Pak compatibility claim was made explicit — a save-state feature that broke peripherals would contradict everything the brand stands for.

The FPGA engineer's view

FPGA developer Kevin "kevtris" Horton, whose work underpins much of the modern FPGA-console movement, has long argued that "once your state machine is genuinely cycle-accurate, snapshotting it is the easy part — the hard part was getting the timing right in the first place." That is the technical case for why Memories can coexist with accuracy: the difficult engineering happened in the core, not in the save layer bolted on top.

The skeptical editor

Mainstream coverage has been more measured. The general line from outlets such as The Verge and Engadget across Analogue's product cycle has been some version of: "It is the best way to play these cartridges on a modern TV, and it is also the most expensive way, and both of those things will always be true." One veteran retro-hardware reviewer put the 1.3.0 release plainly: "They finally shipped the feature everyone asked for on day one. The only question is why it took until version 1.3." The frustration is fair; the relief is also fair.

Save States: A Forty-Year Argument

The emulator origin

Save states are old. They predate the N64 as a concept in emulator design and became standard equipment in the late-1990s emulation boom, when projects let players freeze and thaw a console's RAM at will. For purists, this was heresy: the original machines could not do it, so doing it was "cheating" or, worse, "not real hardware." That argument has been running for the better part of forty years and it has never been resolved, only relocated.

Why the N64 makes it acute

The Nintendo 64 generation is where the save-state argument bites hardest, because its native saving was a mess: a fragmented mix of cartridge SRAM, EEPROM, Flash, and the battery-backed Controller Pak. Three decades on, the batteries are dead, the Paks are scarce, and the games that gated saves behind awkward checkpoints are exactly as awkward as they were in 1997. The hardware-preservation case for save states is no longer ideological; it is conservational. The original save media is physically failing.

Analogue's late conversion

Analogue spent years on the purist side of this line, shipping consoles that proudly did only what the originals did. 1.3.0 is the company crossing the aisle, and the "Memories" branding is the fig leaf it brought along. The interesting historical note is not that Analogue added save states — everyone eventually does — but that it took until a 2026 firmware on a console that had already shipped to do it, long after software emulation had made the feature table stakes.

What Comes Next: 6-12 Month Outlook

Prediction one: Progressive Output leaves beta

The Progressive Output beta flag in 1.3.0 is a roadmap marker. Expect a firmware in the second half of 2026 — call it 1.3.x or 1.4.0 — that promotes Progressive Output from "certain games" to general availability, with an expanded compatibility list. Display refinement is where Analogue's brand value lives, and a beta flag is a promise it tends to keep.

Prediction two: cadence slows after the feature push

Four releases in eight weeks is not sustainable and is not meant to be. Once the Memories subsystem settles and the flash-cart edge cases are exhausted, expect the cadence to decay toward monthly or quarterly. If it does not — if the fortnightly rhythm persists into autumn 2026 — that is a signal of unresolved stability problems, not generosity.

Prediction three: cloud or transferable Memories

The obvious next step for a named, OS-level save system is portability — exporting a Memory, sharing it, or syncing it. Analogue has no public cloud infrastructure for the 3D today, so the near-term version is likely local export to storage rather than an account-based cloud. Watch for a Memories export option within 6-12 months.

Prediction four: the 8BitDo dependency deepens

1.3.0 already ties Memories to a specific 8BitDo firmware floor. Expect future features to lean further on the controller's own firmware, formalizing the 8BitDo 64 BT as the reference pad. That is convenient for owners of it and a growing friction tax for everyone using third-party or original controllers through adapters.

Prediction five: a competitor ships save states louder

The FPGA-handheld and console market moves fast — see the relentless iteration in the Retroid Pocket lineup. Once Analogue normalizes save states on an accuracy-first console, a rival will market the same feature more aggressively and at a lower price within the year. The moat was never the feature; it was the polish.

Updating: The Procedure

Before you start

The single most important pre-flight step is the controller. If you use the 8BitDo 64 BT and you want Memories, update that pad to firmware 2.05 or later first, via 8BitDo's controller update page. Skip this and Memories will misbehave in ways that look like console bugs but are not. Also confirm you are coming from a clean state — ideally already on 1.2.6.

The update flow

Analogue distributes firmware as a downloadable package applied via storage, not over-the-air in the phone-app sense. The general sequence:

1. Read the 8BitDo pad firmware version → update to 2.05+ if below.
2. Download analogue-3d-1.3.0 from the official 3D support page.
3. Copy the firmware package to the root of a FAT32 storage card.
4. Insert the card into the powered-off Analogue 3D.
5. Power on → the system detects and prompts for the update.
6. Confirm. Do NOT remove power or the card mid-flash.
7. Wait for the reboot → verify version reads 1.3.0 in settings.
8. Test Memories on one game before trusting it with progress.

Treat step 6 as gospel. A firmware flash interrupted by a yanked card or a power cut is how you brick a console, and Analogue's recovery path is not a one-click affair.

If something goes wrong

If Memories will not engage, the controller firmware is the first suspect, every time. If the library looks scrambled after updating from an older version, the advanced library detection from 1.2.4 is re-cataloguing your titles — that is expected behaviour for flash-cart users, not a fault. And if Progressive Output does nothing for your game, remember it is a per-game beta and your title may simply not be on the list yet. When in doubt, the official 3D firmware page remains the single source of truth, because Analogue has decided that is the only documentation you get.