Retrode 2 in 2026: Dump a Cart in 12 Steps, 20 Min

You typed "retrode" into a search bar in 2026 expecting a tidy little how-to, and you have walked straight into a semantic trap. There are two Retrodes. One of them you can hold in your hand and use tonight. The other is a MIPS-based, Linux-booting, Wi-Fi-having promise that, by its maker's own admission, has finished hardware, unfinished software, and a target availability of "the end of the year." This tutorial is about the one that exists, because a tutorial about a device you cannot buy is not a tutorial — it is a press release with steps.

So here is the deal. Over the next several thousand words you will learn how to dump SNES and Sega Genesis cartridges to headerless ROM images, back up and restore their battery saves, drive original controllers as plain USB gamepads, verify your dumps against community hash sets, and write a configuration file for behaviour the defaults get wrong. First run, including setup and verification, is roughly twenty minutes. Every subsequent cartridge is under two. At the very end, once you have a working preservation pipeline, we will talk honestly about the Retrode3 — what is genuinely new, what is still vapour, and whether you should wait for it. Spoiler: mostly not.

The State of Play: Retrode 2 vs Retrode3

Two devices, one name

The official Retrode site opens 2026 with a blunt line: "The Retrode3 is the successor to the Retrode2." It keeps the original concept — read cartridges, expose original controllers, over USB, on a modern computer — but rebuilds the guts around a MIPS processor running Linux that boots from an SD card, adds built-in Wi-Fi, and goes fully open source at both the hardware and software level. That is a genuine architectural leap. It is also, right now, unavailable. The same page states plainly that "the Retrode3 cannot be ordered yet" and that the software is still being written. The company is "aiming for availability by the end of the year," the final price is unconfirmed with a "target: under EUR 100," and the only thing you can do today is register for a notification through DragonBox.

The Retrode2, meanwhile, is a shipping product with a decade of firmware behind it. It is an 8-bit AVR microcontroller — an AT90USB646 — wearing a pair of cartridge slots and controller ports, and it does exactly one thing extremely well: it turns a physical cartridge into files. No Linux, no Wi-Fi, no SD card, no romantic notions about being a "platform." It is an accessory, and it knows it. That humility is precisely why it works.

What you can actually buy

The Retrode began life as a 2009 hobby project, was stewarded for years by Retrode UG, passed to OpenPandora GmbH in 2015, and today is sold and supported through DragonBox, the same shop named as the Retrode3's notification partner. Its suggested retail price landed around EUR 65 / USD 85, it is made in Germany with proper video-game-grade connectors, and the box is deliberately sparse: the unit, a USB cable, an instruction sheet. Plug-in adapters for other systems were sold separately at roughly the price of a new indie game.

The catch in 2026 is stock. With the 2 effectively at end-of-life and the 3 not yet born, new units are scarce, and you will increasingly find yourself staring at secondhand listings where sealed examples ask well north of the old MSRP. That is the tax on waiting a decade to preserve your library. Pay it or don't, but do not pay a scalper thinking you are buying the Retrode3 — you are not, because nobody is, because it isn't for sale.

Why any of this matters in 2026

A retro-gaming industry roundup from Retrolize frames 2026 as the year retro gaming became "infrastructure": hardware, software, legal access, physical media, online play, save states, display options, input fidelity and archival workflows all maturing at once. The Retrode sits squarely on the archival side of that ledger. It is not a novelty nostalgia gadget; it is access tooling for original media. If you care that the actual bytes on your actual cartridge survive the eventual death of its battery and the slow rot of its mask ROM, this device — unglamorous, ancient, 8-bit — is the least sentimental and most useful thing you can own. Once the bytes are off the cart, they can live anywhere: a Batocera install, a RetroPie box, or a pocketable like the Miyoo Mini Plus. The Retrode is the on-ramp.

Prerequisites: Hardware, Firmware, Software

The hardware you need

Assemble this before you start, because nothing is more irritating than discovering a later step requires something you don't have:

• A Retrode 2 unit. That is the whole event. If you have the SNES/Genesis combo model, you can dump both families out of the box.
• A genuine data USB cable. Mini-B on the Retrode's end for the classic units. This is the single most common failure and we will return to it, hard: a charge-only cable will power the device and mount nothing.
• The cartridges you own. Clean ones dump; filthy ones produce garbage. Have isopropyl alcohol (90%+) and lint-free swabs on standby.
• Optional: a powered USB hub. The Retrode draws its power from the bus, and some cartridges — particularly Genesis carts and anything with an adapter stacked on top — pull enough current to make a marginal port flake out.
• Optional: plug-in adapters. Historically DragonBox sold adapters that let the Retrode read Nintendo 64, Game Boy / Game Boy Advance, and Sega Master System cartridges, at roughly USD 40 each. Only the Sega 32X adapter is confirmed in the current FAQ, so treat older adapters as compatible-but-verify.

The firmware target

The Retrode 2 runs a single monolithic firmware image on its AT90USB646. As of 2026 the firmware is effectively frozen — this is mature, finished software, not a rolling project — and you will choose between two branches. 0.18c is the last stable release and the correct default for almost everyone. 0.18d-beta3 is the last beta, carrying incremental fixes and broader cartridge coverage that never graduated to stable. If a specific cartridge misbehaves on 0.18c, the beta is the first thing to try; otherwise, stay on stable. Older 0.17x builds exist and you should ignore them.

You do not need to reflash a working unit that already dumps your carts correctly. Firmware updates exist to fix specific compatibility gaps, not to chase version numbers. "If it dumps, don't flash it" is a rule that will save you a bricking scare.

The host software

Here is the good news, and it is the reason the Retrode is beloved: on a modern OS you install nothing to dump a cartridge. The device presents itself as a standard USB mass-storage volume, so Windows, macOS and Linux all mount it like a flash drive with zero drivers. The FAQ's language is precise — it "wraps whatever memory chips there are on the cartridge into virtual files on a USB drive." You only need extra software for two optional things:

• Firmware flashing. Windows uses Atmel's FLIP; Linux and macOS use dfu-programmer. Both talk to the AVR's DFU bootloader. You will only touch these if you decide to update.
• Playing or verifying the dumps. An emulator or front end — RetroArch is the obvious pick — plus a checksum tool (sha1sum/md5sum on Unix, or any GUI hasher on Windows). The libretro documentation covers core installation and save-file locations, both of which we use later.

How the Retrode Actually Works

Mass storage plus HID, at the same time

The Retrode enumerates as a composite USB device: it is simultaneously a mass-storage disk and a Human Interface Device. Insert a cartridge and its contents appear as files on a tiny virtual drive. Plug a controller into the Retrode's ports and, in the FAQ's words, the device "makes the gamepads appear as USB HID-class controllers" — meaning your operating system sees a bog-standard USB joypad, no proprietary driver required. One cable carries both. This is why the Retrode feels less like specialised dumping equipment and more like a weird flash drive that also happens to be a gamepad.

Virtual files, not an emulator

Internalise this or half the rest will confuse you: the Retrode is not an emulator and contains no games. It is an interface. When you open its drive and see SUPERMET.SFC, that file does not exist as bytes on a chip inside the Retrode; it is a live window onto the mask ROM in the cartridge currently seated in the slot. Reading the file reads the cartridge in real time. Pull the cart and the file vanishes. Retrode's own FAQ stresses that the system exposes cartridge contents and controllers to a computer — it is "a USB interface for vintage video game cartridges and controllers" — which is a preservation posture, not an emulation one. You are not downloading a game; you are transcribing the one you own.

What it can and cannot touch

The mask ROM is read-only, full stop. There is no firmware setting, no config key, no clever trick that lets the Retrode write to a game's program ROM — the hardware simply cannot. What it can write is battery-backed SRAM. The FAQ notes you can "change the savegames (SRAM) on many cartridges," which is the entire basis of save backup and restore. And there is a hard compatibility wall: cartridges whose special chips sit between the console and the ROM/RAM — Nintendo's SA-1 and S-DD1, and Sega's Virtua Processor — act, in the FAQ's framing, "as sort of a copy protection mechanism" and are "currently not supported." Know which of your carts carry those chips before you blame yourself for a bad dump.

The 12-Step Dump: SNES, Genesis, SRAM

Twelve numbered steps, each with the reasoning behind it, because a step you don't understand is a step you'll perform wrong. Setup and firmware first, then the actual read, then verification and control. Linux commands are shown; Windows and macOS map cleanly (the drive mounts either way, only the shell differs).

Setup and firmware (steps 1–3)

1. Confirm your hardware and pick a firmware target. Identify your unit (SNES/Genesis combo is the common one) and decide on 0.18c unless a specific cart forces the beta. Why: the firmware determines cartridge compatibility, and choosing before you start means you don't discover a gap mid-dump and have to reflash with a cart already seated.
2. Install prerequisites — which is to say, almost nothing. For plain dumping, install zero drivers; the OS mounts the Retrode natively. Only if you intend to flash firmware, install Atmel FLIP (Windows) or dfu-programmer (Linux/macOS) now, while your hands are free. Why: the Retrode's mass-storage design is the whole appeal — don't overcomplicate a driverless device by hunting for drivers that don't exist.
3. Update firmware only if you have a reason. To flash, enter DFU mode before connecting USB: hold HWB, tap RESET while still holding HWB, then release HWB. Then run the flash. Why: the AVR only accepts new firmware from its bootloader; the button dance is how you summon it. Skip this entire step if your unit already dumps correctly.

# Enter DFU mode BEFORE connecting USB:
#   hold HWB, tap RESET while holding HWB, then release HWB.

# Confirm the AT90USB646 bootloader enumerated:
lsusb | grep -i atmel
# Bus 001 Device 014: ID 03eb:2ff9 Atmel Corp. AT90USB646 DFU bootloader

# Erase, flash the 0.18c image, then relaunch into the new firmware:
sudo dfu-programmer at90usb646 erase
sudo dfu-programmer at90usb646 flash retrode-0.18c.hex
sudo dfu-programmer at90usb646 launch

On Windows the FLIP equivalent points its "Select Communication Medium" at USB, opens the .hex, then runs Erase / Program / Verify / Start Application. When Windows first asks for a driver in DFU mode, point it at the usb subfolder inside your FLIP installation directory. That folder is the entire reason people think firmware updates are hard; they are not.

Reading the cartridge (steps 4–8)

4. Clean and seat the cartridge. If contacts look dull or the cart has lived in an attic, swab the edge connector with 90%+ isopropyl and let it dry. Seat it firmly and fully into the correct slot. Why: the number-one cause of corrupt or zero-byte dumps is dirty or under-inserted contacts. The Retrode reads exactly what the pins touch — grime reads as garbage.
5. Connect the Retrode and confirm it enumerates. Plug in with a real data cable and watch the OS mount a small removable volume, typically labelled RETRODE. Why: if nothing mounts, you have a cable, power or seating problem, and every later step is moot until the drive appears.
6. Locate the ROM and SRAM virtual files. Open the drive. You should see a ROM image named from the cartridge's internal header, a matching .SRM save file, and a RETRODE.CFG. Why: these files are your live view of the silicon; confirming they exist and are non-zero tells you the read is healthy before you copy anything.
7. Copy the ROM off the device. Drag the ROM image to your disk, or cp it. It is read-only on the Retrode, so you are only ever reading. Why: you want a stable local copy to hash and archive; working off the live virtual file is slower and pointlessly risky.
8. Back up the SRAM save. Copy the .SRM to the same folder. This is your battery-save insurance. Why: cartridge save batteries are decades old and dying; the moment that CR2032 goes flat, an unbacked save is gone forever. Copy it now, not later.

$ dmesg | tail -3
usb 1-2: new full-speed USB device using ehci-pci
usb 1-2: Product: Retrode
sd 6:0:0:0: [sdb] Attached SCSI removable disk

$ ls -la /media/$USER/RETRODE
total 3072
-r--r--r-- 1 you you 3145728 Jan  1  2000 SUPERMET.SFC   # 3 MB SNES ROM, read-only
-rw-rw-rw- 1 you you    8192 Jan  1  2000 SUPERMET.SRM   # 8 KB battery save, writable
-rw-rw-rw- 1 you you     512 Jan  1  2000 RETRODE.CFG    # config, edit on the host

mkdir -p ~/dumps
cp "/media/$USER/RETRODE/SUPERMET.SFC" ~/dumps/
cp "/media/$USER/RETRODE/SUPERMET.SRM" ~/dumps/

# Verify the ROM against a known-good hash (No-Intro / redump DAT):
sha1sum ~/dumps/SUPERMET.SFC
# da957f2f...b1c9   /home/you/dumps/SUPERMET.SFC   <-- compare to the DAT entry
md5sum  ~/dumps/SUPERMET.SFC

Verify, configure, control (steps 9–12)

9. Verify the dump with a checksum. Hash the local ROM and compare against a community set (No-Intro for cartridges, redump for disc systems). Why: a file that copies without error can still be subtly wrong — a flaky contact, a header, an interleave. A matching hash is the only proof your dump is bit-perfect.
10. Restore a save when you need to. To push a save back onto a cart, copy the .SRM back onto the virtual file, keeping the identical name and byte size, then sync before removing the cartridge. Why: the firmware writes SRAM in place; a renamed, padded or truncated file will be rejected or will corrupt the save. This is the sharpest footgun in the whole workflow.
11. Edit RETRODE.CFG for behaviour the defaults get wrong. Copy the config to your host, edit it, copy it back — to force a file extension, strip a header, or lock SRAM to read-only. Why: defaults suit the median user; if you are batch-dumping for a specific hash set or protecting a fragile save, the config is where you assert control. (Keys are firmware-dependent — see the complete config section.)
12. Use your original controllers as USB gamepads. Plug a pad into the Retrode's port and it appears as a USB HID controller you can map in any emulator or front end. Why: it closes the loop — the same box that preserved the game lets you play it with the exact hardware it was designed for, no adapter dongle chain required.

# Restore a save by copying it BACK onto the virtual file.
# Keep the SAME filename and the SAME byte size the Retrode created.
cp ~/dumps/SUPERMET.SRM "/media/$USER/RETRODE/SUPERMET.SRM"
sync                 # flush the write before you pull the cartridge
# Never rename, pad, or truncate the .SRM. The firmware writes it in place.

Controllers and Cartridge Adapters

Pads as plain USB HID

The controller ports are not an afterthought; for a lot of owners they are half the point. Because the Retrode presents pads as generic HID devices, a real SNES controller or a 3- or 6-button Sega pad shows up in your OS exactly like a cheap third-party USB joypad — the FAQ confirms support for "standard SNES and Sega (3- and 6-button) gamepads." No calibration ritual, no vendor tool. Map the buttons in RetroArch (or your front end of choice) once and you are playing your dumped ROM with the genuine article in your hands, latency and feel intact. It is the least glamorous input-fidelity solution in retro gaming and one of the most honest.

The SNES Mouse and the left-port rule

If you want to use the SNES Mouse — for Mario Paint, or because you are a completist — it must go in the left (player-one) port. This is not a suggestion; the firmware expects the mouse there and will not recognise it in the right port. It is the kind of undocumented-until-you-hit-it detail that turns a fifteen-minute session into an hour of swearing at hardware that is behaving exactly as designed. Left port. Write it on the case.

Plug-in adapters and their limits

The Retrode's expansion system historically extended it to Nintendo 64, Game Boy / Game Boy Advance, and Sega Master System cartridges through separate plug-in adapters, and the FAQ specifically confirms the Sega 32X adapter works. Two caveats keep you honest. First, adapters draw extra power — stack one on a marginal USB port and you invite flaky reads; a powered hub fixes it. Second, adapter support has always been more variable than the native SNES/Genesis path, so verify any adapter dump against a hash set rather than assuming. If your interest is specifically N64 preservation, note that dedicated FPGA hardware like the Analogue 3D now handles playback and save states from original carts — a different job than dumping, but a complementary one.

Verifying Your Dumps

Headered vs headerless: the 512-byte lie

The oldest trap in SNES dumping is the copier header. Ancient backup devices prepended a 512-byte header to ROM images, and some tools still expect or emit it. A headered dump and a headerless dump of the same cartridge are byte-for-byte different and therefore hash differently, even though both play fine. Modern reference sets — No-Intro in particular — are catalogued headerless. So if your Retrode dump is 512 bytes larger than the DAT entry and the hash is off, you almost certainly have a header. Strip it (a one-line operation, or a config toggle) and rehash. The dump was never wrong; the framing was.

Hashing against No-Intro and redump

Verification is not optional if you care about preservation. Compute SHA-1 (and MD5, for older sets) of your local ROM and compare it to the corresponding cartridge database entry. A match means bit-perfect; a mismatch means investigate. This is exactly why the verification step exists and why you copy the ROM to disk before hashing — you want a stable file, not a live read that could hiccup mid-hash. Once a cart's hash matches a known-good entry, you can retire the physical cartridge to a drawer with genuine confidence, and load the verified image onto whatever you actually play on.

When a good dump looks "wrong"

Not every mismatch is a bad dump. Regional variants, revision numbers (a Rev 1 versus Rev 0 board), and the header issue above all produce legitimate files that simply don't match the first DAT line you glanced at. Before you reseat and re-dump in a panic, check whether your mismatch corresponds to a different known entry — a different region or revision — rather than corruption. The community sets are exhaustive precisely because cartridges are not monolithic. A dump that matches some canonical entry is a good dump of whatever specific board you own.

Common Pitfalls (and Fixes)

The five that get everyone

• The charge-only cable. The Retrode powers up, its light comes on, and nothing mounts. You spend forty minutes suspecting the firmware. It was the cable. Use a known-good data cable, ideally one you have proven with another device.
• Dirty or under-seated contacts. Zero-byte files, truncated ROMs, or hashes that never match. Clean the edge connector with 90%+ isopropyl, dry it, and seat the cart firmly and fully. Blowing on it is a superstition; alcohol is chemistry.
• Expecting SA-1 / S-DD1 / SVP carts to dump. Certain Kirby, Star Ocean and Virtua Racing-class cartridges carry chips the Retrode explicitly does not support. This is a documented wall, not a defect. Check your cart's chip before blaming your technique.
• Assuming the Retrode3 is buyable. It is not. Late 2026 target, price unconfirmed, notify-only through DragonBox. Do not overpay a reseller under the impression you're getting the new model.
• Treating it as an emulator. It plays nothing on its own. If you want to actually run the game, that is RetroArch's job, or a Batocera/RetroPie box, or a handheld. The Retrode only hands you the file.

The SRAM-restore footgun

This one deserves its own paragraph because it destroys saves. When you write an .SRM back to a cartridge, the file must keep the exact name and exact byte size the Retrode originally created. Do not rename it to match some emulator's convention. Do not pad it to a "round" size. Do not let a text editor or archive tool silently alter it. The firmware maps the write onto the physical SRAM in place; a size mismatch is at best rejected and at worst writes nonsense over a save you can never recover. Copy back, sync, then remove the cart. In that order.

Thinking newer firmware is always better

Version-number chasing is a PC-hardware reflex that does not apply here. 0.18c is stable for a reason; 0.18d-beta3 is a beta for a reason. Flashing the beta onto a unit that already dumps everything you own gains you nothing and introduces the small but nonzero risk of a failed flash. Update to fix a specific named problem, verify the fix, and otherwise leave the firmware exactly where it is. This is preservation gear, not a gaming rig; boring and stable is the entire brief.

Troubleshooting Table

Read the table, then the notes

Ten failures you will actually hit, and what fixes them. Work top to bottom; the common causes are near the top for a reason.

If all else fails

When you have exhausted the table, cycle the three fundamentals in order: reseat (cart and cable), reflash (0.18c clean, or try 0.18d-beta3 for a stubborn cart), and re-clean (contacts on both the cart and, if accessible, the Retrode's slot pins). Ninety percent of "my Retrode is broken" reports resolve to one of those three. The device has almost no moving parts and almost nothing to go wrong; when it misbehaves, the problem is nearly always at the physical interface, not in the silicon.

Advanced Tips

Batch dumping and DAT verification

If you are preserving a whole shelf, build a loop instead of dragging files by hand. Insert a cart, run a small script that copies the ROM and SRM into a per-title folder and immediately hashes the ROM, then swap carts. Feed the hashes to a No-Intro-aware verifier (a ROM manager that reads DAT files) and let it flag mismatches for re-dumping. The discipline that matters: verify as you go, not at the end. Discovering that cart number forty was a bad read after you have boxed up the first thirty-nine is a special kind of misery, and it is entirely avoidable.

Save migration into emulators and FPGA hardware

A backed-up cartridge save is more useful than it looks. RetroArch, for instance, expects a battery save as ROMNAME.srm in its save directory; drop your Retrode-dumped .SRM there and your decades-old cartridge progress continues in the emulator. The reverse also works — finish a game in emulation, then write the emulator's .srm back onto the real cartridge through the Retrode, and your physical copy remembers it. This bidirectional save bridge is the quiet superpower here; it makes the boundary between original hardware and modern playback almost disappear.

# Play the freshly-dumped ROM with the Snes9x core:
retroarch -L cores/snes9x_libretro.so ~/dumps/SUPERMET.SFC

# Make RetroArch see the battery save (it looks for ROMNAME.srm in its save dir):
cp ~/dumps/SUPERMET.SRM ~/.config/retroarch/saves/SUPERMET.srm

Firmware branches and the open-source future

Keep both firmware images on hand — 0.18c and 0.18d-beta3 — and treat them as a compatibility toggle rather than a linear upgrade. Some awkward carts read on one and not the other. Looking further out, the Retrode3 goes fully open source, and its dumping brains are a Linux command-line adaptation of Sanni's Open Source Cartridge Reader, published as retrode3-oscr. If you are the kind of person who would rather build than buy, that ecosystem — and the broader FPGA-preservation scene around devices like the MiSTer Multisystem 2 — is where the interesting work is happening. The Retrode 2 is the appliance; the Retrode3's codebase is the invitation to tinker.

A Complete RETRODE.CFG

The file, annotated

Below is a complete, working-shape configuration you can adapt. One honest caveat first: the RETRODE.CFG key set is sparsely documented and firmware-dependent, so the exact key names your unit honours may differ. Treat this as a template and confirm each key against the readme bundled with your firmware (0.18c or 0.18d-beta3). The structure and intent are correct; the spellings are illustrative.

; RETRODE.CFG  — plain-text config read from the Retrode's virtual drive.
; Edit on your host, copy back onto the drive, replug to apply.
; Keys are firmware-dependent; confirm against YOUR firmware's readme.

; ---- ROM output ----
snes_extension    = .sfc    ; .sfc | .smc  (.smc implies a 512-byte header)
genesis_extension = .bin    ; .bin | .gen | .md
strip_header      = 1       ; 1 = headerless dump, matches No-Intro sets

; ---- Saves ----
enable_sram       = 1       ; expose battery SRAM as a writable file
sram_readonly     = 0       ; 1 = never write back to the cartridge

; ---- Controllers ----
enable_hid        = 1       ; expose gamepads as USB HID devices
snes_mouse        = 1       ; SNES Mouse must live in the LEFT (P1) port

; ---- File naming ----
use_internal_name = 1       ; name files from the cart header, not SNES####

What each block does

The ROM output block controls the file you get. Setting strip_header = 1 and choosing .sfc is the combination that produces headerless images matching No-Intro, which is what you want for verifiable preservation. The Saves block governs SRAM: leave enable_sram on to back up and restore, and flip sram_readonly to 1 when handling a fragile cart you refuse to risk writing to. The Controllers block keeps HID active and reminds you — in the config itself — about the left-port mouse rule. The naming block decides whether files inherit the cartridge's internal title or fall back to generic names, which matters enormously when you are batch-dumping and don't want forty files called SNES0001.

Caveats worth repeating

Because the config format is under-documented, the safe workflow is incremental: change one key, copy the file back, replug, and confirm the behaviour changed before touching the next key. Do not paste an entire unfamiliar config and hope. If a key your firmware doesn't recognise causes odd behaviour, delete that line and let the default reassert. And keep a copy of the original RETRODE.CFG the device shipped with, so you always have a known-good baseline to fall back to — the same reflex that makes you back up saves before touching them.

The Retrode3: Finished Hardware, Unfinished Software

What is actually new

Now the successor, honestly. The Retrode3's headline is that it no longer needs a PC at all. Where the Retrode 2 is a dumb-but-reliable USB interface, the 3 is a small Linux computer — a MIPS processor booting Debian from an SD card — whose stated purpose is to "dump a video game's ROM and save file to an SD card without the need of a PC." Add built-in Wi-Fi for network dumping and online database updates, and native support that expands to SNES, Mega Drive and NES (the 2's native pairing was SNES and Genesis, with everything else on adapters), and you have something that is genuinely more of a standalone platform than an accessory. The design goal, per DragonBox, is to "combine the plug-and-play simplicity of the Retrode2 with the flexibility of Sanni's Cart Reader." That is an ambitious target and, as of mid-2026, an unfinished one.

Open source, top to bottom

The most consequential 2026 detail is that the Retrode3 is open at every layer, which positions it directly against the closed, proprietary retro devices flooding the market. The code lives in the open across four repositories under the DragonBox-Shop organisation: retrode3-oscr (the CLI adaptation of Sanni's cartreader plus the retrode.lib), retrode3-kernel, retrode3 (the Debian-based OS user space), and retrode3-hardware (design files for new plugins and boards). Because it shares a plugin philosophy with Sanni's reader, fixes can flow in both directions between the projects — patch the Retrode3 and the wider cartreader community benefits, and vice versa. Retrode's FAQ has long promised that the system "offers plenty of room for new features," and the open repositories are the first time that promise is backed by publicly auditable code rather than a marketing line.

The 2026 market it walks into

The Retrode3 is arriving into a crowded, maturing retro-hardware year. The same Retrolize roundup that called 2026 the year nostalgia "became infrastructure" flags an Evercade Nexus expected in October 2026 — a cartridge-based handheld with a 5.89-inch 16:9 screen, dual analogue sticks, wireless headphone support, a larger battery, and a wireless multiplayer feature called EverSync — alongside planned October 2026 portable versions of The C64 and The Spectrum from Blaze Entertainment and Retro Games Ltd. The market is expanding across both cartridge and home-computer nostalgia at once. Against that backdrop, the Retrode3's pitch is not flash but principle: preservation-grade, PC-free, open source, and "target: under EUR 100." You cannot order it yet — the site is explicit that it "cannot be ordered yet" and directs you to register for notification through DragonBox — but the positioning is coherent. It is the anti-gadget: infrastructure, not novelty.

Verdict: Buy the 2, Watch the 3

Buy the 2

If you have a shelf of cartridges and a reason to preserve them — dying save batteries, aging mask ROMs, or simply the desire to play your own games on modern hardware — buy the Retrode 2 and start today. It is a finished, mature, driverless device that does exactly what it claims: cartridges become verifiable files, saves become recoverable backups, and original controllers become plain USB gamepads. Its suggested retail price was about EUR 65 / USD 85 through DragonBox, new stock is thin in 2026, and secondhand units carry a scarcity premium — but the alternative is a library that quietly decays while you wait for a device that isn't for sale. Twenty minutes and one cable stand between you and a preserved cartridge. That is a good trade.

Watch the 3

The Retrode3 is real, it is interesting, and it is not ready. Finished hardware, unfinished software, a late-2026 target that could slip, and a sub-EUR-100 price that isn't locked. Its no-PC, Wi-Fi, NES-native, fully open-source design is the correct evolution of the concept and worth genuine anticipation — particularly if you value open hardware over closed convenience. But anticipation is not a dumping workflow. Register for the DragonBox notification, star the four GitHub repos if you like watching a project take shape in the open, and in the meantime let the decade-old 8-bit accessory do the unglamorous work of saving your games. When the 3 ships, your library will already be safe — and you will be able to judge the successor on what it does, not on what its landing page promises.