Retrode 2026: Dump Carts & Saves in 12 Steps, 30 Min

You searched for a Retrode tutorial dated 2026, and the honest answer has to come first, because the rest of this only makes sense once it's on the table: there is no 2026 Retrode. Not in the sense some aggregator implied when it sent you here. The device you can actually push a cartridge into today — the Retrode 2 — is a relaunch of hardware that stopped being manufactured in the summer of 2013, brought back to market in March 2015, running firmware that has not meaningfully moved since roughly 2016. The device that is genuinely new — the Retrode3 — you cannot buy. You can sign up to be told when you might be able to buy it. Its stated target is availability by the end of the year, a phrase doing a great deal of load-bearing work in the middle of 2026.

So this is a tutorial for the Retrode 2, because that is the one that dumps a cartridge. It is also a tutorial that declines to pretend the Retrode 2 is younger, faster, or better supported than it is. It is an 8-bit AVR microcontroller in a plastic shell, reading address lines off a mask ROM at USB Full Speed, and it happens to be one of the last honest tools for getting your own save files off a coin cell that has been quietly dying since the Clinton administration. Judged as what it is, it is excellent. Judged as a current product, it will disappoint you, and that is not the Retrode's fault.

What follows is the whole job: the real prerequisites, the twelve steps that put a headerless .sfc or .bin on your disk, the actual keys in RETRODE.CFG rather than the invented ones you'll find elsewhere, the firmware-flash procedure for when curiosity gets ahead of you, a troubleshooting table with thirteen entries, and a clear-eyed read on the Retrode3 so you can decide whether waiting is rational. The law gets a paragraph, because someone always asks.

The Two Retrodes, and 2026's False Premise

The Retrode line is two objects wearing one name, and most of the confusion online comes from treating them as one continuous, actively-developed product. They are not. One ships and hasn't changed in years; one is a promissory note. Sorting out which is which is the first technical decision you make.

The Retrode 2 is the one you can buy

The Retrode 2 is the shipping device and the entire subject of the how-to below. It carries an Atmel AVR AT90USB646 microcontroller with integrated USB, and its firmware is built on Dean Camera's LUFA stack. Its case has four controller ports (two SNES-style, two Sega-style) and two cartridge slots: the wide upper slot for SNES / Super Famicom, the shorter lower slot for Mega Drive / Genesis. It is bus-powered over USB, feeding 5 volts to the cartridge, and it presents itself to your computer as a plain USB drive. There is no application to install. You bought hardware, not a subscription, and the hardware does exactly one clever thing very reliably.

Origin, for the record, because a persistent myth credits the wrong person and the wrong year: the Retrode was conceived in 2009 by Matthias Hullin in a discussion on the Pandora handheld forums, not by a “Peter Lück” in 2007. It was built and sold by Retrode UG in Germany, which ceased manufacturing in the summer of 2013; the design was then picked up by OpenPandora GmbH and returned to shelves in March 2015, which is the lineage DragonBox still sells under today.

The Retrode3 is a promissory note

The Retrode3 is the actual 2026 news, and it is not a product you can hold. It abandons the AVR-and-USB-drive model entirely for a Linux single-board computer that boots Debian from an SD card, adds built-in Wi-Fi, and drives everything from a web browser over a USB-Ethernet link. It adds an NES slot to the SNES and Mega Drive pair, and — the genuinely new capability — it can write flash carts, not merely read them. It is, per DragonBox, fully open source, Made in Germany, and priced under €100. It also, as of this writing, exists as ten prototypes with unfinished software and no order button. We'll come back to it in detail near the end; for now, understand that a tutorial titled for 2026 has to be a Retrode 2 tutorial, because the Retrode3 has nothing you can plug a cartridge into.

Why “2026 Retrode news” is mostly a mirage

If a page promised you fresh 2026 Retrode developments and specific dollar figures, it was pattern-matching a search trend, not reporting facts. There is no new Retrode 2 firmware version — the line froze at 0.18c stable, with a 0.18d beta 3 that never graduated. There is no v0.22, no “SNES Enhanced Cart Support” update, no relaunch SKU. The only real forward motion is the Retrode3, and it is pre-release. Anyone quoting you a firm Retrode3 date or final price is quoting a target, not a fact. Here is the split, cleanly:

Prerequisites: Hardware, Software, Versions

The Retrode's whole pitch is that it needs almost nothing, and that pitch is true. But “almost nothing” is not “nothing,” and the small list of things you do need is exactly the list people skip before wondering why a dump came out wrong.

Hardware you actually need

• A Retrode 2. The unit ships with a USB cable and a paper instruction sheet. Use the bundled cable; a marginal cable is a classic source of flaky enumeration.
• The cartridges themselves. SNES/SFC and Mega Drive/Genesis work in the built-in slots. Anything else waits for an adapter (see that section).
• 99% isopropyl alcohol and a lint-free swab. Cartridge edge connectors are thirty years old and oxidized. This is the single highest-value item on the list.
• A real USB port. The Retrode draws its cartridge's 5 volts from the bus. Use a rear/root port or a powered hub, never a bus-powered hub daisy-chained off a laptop.
• A live coin cell, if you care about saves. SRAM saves survive only while the cartridge's battery holds them. If you intend to pull a save, do it before that CR2032 quits; if you intend to inject one, a dead battery means it won't stick.

Software and firmware versions

To dump, you need no software at all — the operating system's built-in file manager copies files off a USB drive, which is all the Retrode is. Windows, macOS, and Linux all mount it driverless. To update firmware, you need Atmel FLIP on Windows, or dfu-programmer on Linux/macOS, plus the firmware .hex. The relevant versions to know: the shipping firmware line ends at 0.18c (stable) and 0.18d beta 3 (the last beta); the configurable RETRODE.CFG feature has existed since 0.17g. For playing and verifying your dumps you'll want an emulator — a set of RetroArch cores installed the sane way covers essentially every system the Retrode touches — plus a checksum tool and a No-Intro DAT.

What you do not need (any driver)

You do not need a driver, a bundled installer, a cloud account, or a specific OS. This bears stating because it is the Retrode's actual innovation and the reason it still works flawlessly on a 2026 machine that has never heard of it: the device speaks the USB Mass Storage and HID classes that every OS has supported for two decades. The same trait means it survived its own developer's departure. When the company stopped, the hardware kept working, because it never depended on anything you'd have to keep updated. Contrast that with a software-defined preservation stack like a RetroPie image that froze at v4.8 while its Pi kept getting more expensive — same era, same freeze, but the Retrode's freeze costs you nothing because the interface is timeless.

How the Retrode Works: Mass Storage, No Drivers

Understanding the mechanism prevents about half of the mistakes in the troubleshooting table, so spend ninety seconds here before you copy anything. The Retrode does not “rip” a cartridge the way a program rips a disc. It exposes the cartridge as files, and then you copy files. That is a meaningfully different model with meaningful consequences.

USB Mass Storage plus HID gamepad

The Retrode enumerates as a composite USB device: one USB Mass Storage endpoint (the little drive you'll copy from) and one or more USB HID game controllers (the physical controller ports on the case, passed through as standard gamepads). The mass-storage side wraps whatever memory chips are on the inserted cartridge — the ROM, and the save SRAM if present — into virtual files on a FAT volume labeled RETRODE. The AT90USB646 is a USB 2.0 Full Speed part, which is the honest reason dumps aren't instant: Full Speed tops out at 12 Mbit/s in theory and far less in practice through mass-storage overhead on an 8-bit MCU. A large cartridge takes a couple of minutes, not a couple of seconds. That's not a defect; it's physics on a 2011-class controller.

The volume it presents

On Linux you'll see the removable disk appear and auto-mount under something like /run/media/you/RETRODE; on macOS it's /Volumes/RETRODE; on Windows it's a drive letter. Here's what a plug-in looks like from the kernel's side, so you can confirm the three roles registered correctly. Device numbers, bus paths, and the reported size will vary — what matters is that you see a mass-storage disk and an input device appear:

$ dmesg | tail
usb 3-2: new full-speed USB device number 9 using xhci_hcd
usb 3-2: New USB device found, Manufacturer=Retrode, Product=Retrode2
usb 3-2: SerialNumber: RETRODE2
usb-storage 3-2:1.0: USB Mass Storage device detected
scsi 7:0:0:0: Direct-Access     Retrode  Retrode2         .18  PQ: 0 ANSI: 2
sd 7:0:0:0: [sdb] 2048 512-byte logical blocks: (1.05 MB/1.00 MiB)
sd 7:0:0:0: [sdb] Attached SCSI removable disk
input: Retrode Retrode2 as /devices/pci0000:00/.../input/input31

$ lsblk -o NAME,RM,SIZE,RO,TYPE,MOUNTPOINT /dev/sdb
NAME   RM SIZE RO TYPE MOUNTPOINT
sdb     1  1M   0 disk
`-sdb1  1  1M   0 part /run/media/you/RETRODE

On that volume you'll find the ROM file, the save file if the cartridge has SRAM, and RETRODE.CFG. A small status LED on the unit lights during ROM/RAM access and blinks when the configuration file is written — useful confirmation that the device is actually reading, not just mounted.

ROM is read-only; SRAM is not

This is the rule that governs everything. The ROM file is genuinely read-only — it's mask ROM; the Retrode cannot write it, and neither can you. The SRAM save file is writable on most cartridges, which is how you both back up and restore game saves. The config file is writable too, because editing it is how you change the device's behavior. Filenames are derived from the cartridge's internal header, so they arrive UPPERCASE and often ugly; the extension comes from the config (.sfc for SNES, .bin for Sega, .srm for saves). A directory listing after inserting an SNES cart with a battery save looks like this:

$ ls -l /run/media/you/RETRODE
-r-xr-xr-x 1 you you 1048576 Jan  1  2016 ZELDA3.sfc
-rwxr-xr-x 1 you you    8192 Jan  1  2016 ZELDA3.srm
-rwxr-xr-x 1 you you     512 Jan  1  2016 RETRODE.CFG

Note the permissions telling the story: the ROM is read-only (r-x), the save and the config are writable (rwx). The size of the .sfc should match the cartridge's known ROM size — 1,048,576 bytes is 8 Mbit, which is right for A Link to the Past. When a size looks wrong, stop and read the pitfalls section before you trust the dump.

Dumping a Cartridge in 12 Steps

Here is the full procedure, twelve steps, each with the reason it exists. Skipping the rationale is how you end up in the troubleshooting table. The whole thing takes about half an hour the first time and closer to ten minutes once it's muscle memory.

Seating, copying, verifying

1. Power down and clean the contacts. With the Retrode unplugged, wipe the cartridge edge connector with 99% isopropyl on a lint-free swab and let it dry. Rationale: oxidized pins cause partial reads that look like a successful dump until the game crashes in an emulator. Do not blow into the cartridge; you're depositing moisture, which is the opposite of the goal.
2. Seat the cartridge fully in the correct slot. SNES/SFC goes in the wide upper slot; Mega Drive/Genesis in the shorter lower slot. Press it home. Rationale: a half-seated cartridge either doesn't detect or reads garbage, and garbage is worse than nothing because it's silent.
3. Connect the Retrode to a real USB port. Cable into the Retrode first, then into a rear or root port (or a powered hub). Rationale: the cartridge is powered from the bus at 5 volts; an underpowered hub browns out the read.
4. Wait for the RETRODE volume to mount. Give it a second or two to enumerate. Rationale: it's mass storage, so there's no driver to wait on, but the FAT volume still needs to appear before you touch it.
5. Open RETRODE.CFG and confirm firmware and settings. The config file reports the running firmware and your extension/override settings. Rationale: knowing you're on 0.18c versus something ancient explains half of any weird behavior, and it confirms the device is talking, not just powered.
6. Confirm the ROM file, and sanity-check its size. A 4 Mbit SNES cart should be 524,288 bytes; an 8 Mbit cart 1,048,576; and so on. Rationale: a size that doesn't match a known power-of-two cartridge capacity is your earliest warning of a bad read or a misdetected mapper.
7. Copy the ROM file to your disk in one pass. Drag it off, or use cp. Do not open it in place from an editor or emulator. Rationale: Full-Speed reads are slow, and applications that seek around the file mid-read can produce inconsistent data; a single sequential copy is reliable.
8. Wait for the copy to finish completely. Watch for it to actually reach 100%, then flush. Rationale: interrupting a copy from a slow device yields a truncated dump that's the wrong size — which is exactly the failure step 6 taught you to catch.
9. Copy the .srm save too, if one is present. If the cartridge has battery SRAM, grab the .srm now. Rationale: the battery is on borrowed time; the save is the one thing on that cartridge that is genuinely irreplaceable, and it's decaying whether you act or not.
10. Eject/unmount before removing the cartridge. Use the OS's safe-eject, then pull the cartridge. Rationale: the Retrode's own guide warns that hot-swapping a cartridge “can potentially damage on-cartridge savegames” — eject first, every time.
11. Verify the dump. Checksum it against a No-Intro DAT, or at minimum boot it in an emulator past the title screen. Rationale: an unverified dump is a rumor. Two minutes of checking now saves you re-dumping a cartridge you've already reshelved.
12. Rename and file it sanely. Replace the ugly internal-header name with a human one and note the region. Rationale: ZELDA3.sfc tells you nothing in a folder of two hundred dumps; do this once, at capture time, or never do it.

Expected output

Steps 7 and 9 in a terminal look like the block below. The exact filename comes from the cartridge header, so yours will differ:

$ cp -v /run/media/you/RETRODE/ZELDA3.sfc ~/dumps/
'/run/media/you/RETRODE/ZELDA3.sfc' -> '/home/you/dumps/ZELDA3.sfc'
$ cp -v /run/media/you/RETRODE/ZELDA3.srm ~/dumps/
'/run/media/you/RETRODE/ZELDA3.srm' -> '/home/you/dumps/ZELDA3.srm'
$ ls -l ~/dumps
-rw-r--r-- 1 you you 1048576 Jul 18 11:02 ZELDA3.sfc
-rw-r--r-- 1 you you    8192 Jul 18 11:02 ZELDA3.srm

Where the dumps go from here

Once verified, your headerless .sfc and .bin files are the clean, canonical form that modern emulators and preservation databases expect. Drop them into a Batocera install for a couch setup, or feed them to RetroArch on the desktop. If you want cartridge-accurate playback rather than emulation, an FPGA route like the MiSTer Multisystem 2 will run the same dumps at the hardware level. The Retrode's job ends at a verified file; what you do with the file is a separate, larger conversation.

Pulling and Restoring SRAM Saves

Dumping ROMs is a convenience — the ROM is mask-programmed and, barring a cracked trace, it isn't going anywhere. Saves are the emergency. Battery-backed SRAM is the one part of a retro cartridge that is actively, chemically dying, and the Retrode is the least destructive way to rescue it. This section is the part of the tutorial that actually matters in ten years.

Where the .srm lives and why it matters

If a cartridge has battery-backed SRAM, the Retrode exposes it as a .srm file next to the ROM. That file is a raw image of the save RAM — your file slots, your cleared bosses, the name you entered in 1996. It exists only as long as the coin cell keeps the SRAM powered. When the cell dies, the save is gone in a way no dump can recover after the fact, which is why step 9 above is not optional for anything you care about. Copy the .srm off the same way you copied the ROM: one sequential copy, verify the size looks sane (saves are small — 2 KB, 8 KB, 32 KB are typical), then eject.

Injecting a save back onto the cartridge

The Retrode can also write SRAM back, which lets you restore a rescued save or move a save between two copies of a game. This is guarded by a config flag, deliberately, so you don't clobber a save by accident. Saves are write-protected by default. To enable writing, open RETRODE.CFG, set [sramReadonly] to 0, save the file, and press the RESET button so the firmware re-reads the config. Then copy your .srm onto the RETRODE volume, overwriting the one there. If you try to write with the flag still at 1, the copy fails with an Access denied-style error — that error is the single most common “why won't it let me” question, and it's always this flag.

Format gotchas

Two things bite people. First, sizes must match: the SRAM chip is a fixed size, so the .srm you inject must be the same length the Retrode expects for that cartridge. An emulator's save may be padded or trimmed differently; pad or truncate to match before injecting. Second, and bluntly: writing a save to a cartridge whose battery is dead is pointless. The SRAM won't hold it without power. If the goal is a cartridge that remembers your progress, you replace the CR2032 first (a soldering job on most carts) and then inject. The Retrode moves the bytes; it cannot resurrect a battery.

Updating Firmware via DFU Mode

Most readers should not update firmware, and the most useful thing this section can do is talk you out of it. But the procedure is worth documenting precisely, because when you do need it, doing it wrong is how a working Retrode becomes a paperweight for an afternoon.

Why you probably won't (and when you must)

The firmware line is frozen at 0.18c stable and 0.18d beta 3. There is no newer version coming; the Retrode3 is where development went. So the only real reasons to flash are: you bought a used unit stuck on something ancient like 0.17-something and want the accumulated fixes, or you specifically want a change that landed in the 0.18 line. That line's changelog is genuinely useful — it improved N64 and GBA size detection, refreshed the LUFA library, fixed a Master System plug-in bug, and added SMS SRAM reading — so if you work with those adapters, 0.18c is worth being on. Beyond that, if your Retrode dumps correctly, leave it alone. Firmware is not a loyalty program.

Entering DFU mode

The AT90USB646 has an on-chip DFU bootloader. You enter it with the two buttons: hold HWB (the rear button, normally reserved for custom firmware functions), then press and release RESET (the front button) while still holding HWB, then release HWB. The device re-enumerates as an Atmel DFU bootloader. On Linux you can confirm you're in the right mode with lsusb — the bootloader has a well-known, documented ID:

$ lsusb | grep -i atmel
Bus 003 Device 011: ID 03eb:2ff9 Atmel Corp. atmega/at90usb DFU bootloader

If you don't see 03eb:2ff9, you're not in DFU mode; repeat the button dance. FLIP cannot see it either until this shows up.

Flashing: FLIP vs dfu-programmer

On Windows, use Atmel FLIP: launch it, choose AT90USB646 from the device menu, open the USB connection (Ctrl+U), load the firmware .hex (Ctrl+L), and run the program/verify sequence, then reset. One landmine that has cost people real time: FLIP chokes on file paths containing special characters like é or ã — put the .hex somewhere plain-ASCII like C:\retrode. On Linux or macOS, use dfu-programmer:

# 1) Enter DFU mode:  hold HWB (rear) -> press & release RESET (front) -> release HWB
# 2) Confirm the chip answers:
$ dfu-programmer at90usb646 get product-revision

# 3) Erase, flash the .hex you downloaded, then reset:
$ sudo dfu-programmer at90usb646 erase
$ sudo dfu-programmer at90usb646 flash retrode2-0.18c.hex
$ sudo dfu-programmer at90usb646 reset
# (or press the front RESET button to leave the bootloader)

The one unforgivable mistake is flashing the wrong hardware's firmware — never put Retrode 1 firmware on a Retrode 2 or vice versa; that's the classic way to brick it. After flashing, the device re-mounts as a normal RETRODE volume; open RETRODE.CFG to confirm the version updated. A community shell script by ssokolow wraps the Linux flow if you want the detection-and-flash steps chained together.

Adapters: Game Boy, N64, and the Odd Ones

The built-in slots are SNES and Mega Drive, full stop. Everything else the Retrode can touch arrives through plug-in adapters that seat into the cartridge slots and pass a different pinout through to the AVR. They are sold separately — roughly €25 each at DragonBox, or $39.99 at US resellers — and they are not all equal in what they can pull off.

The plug-through adapters

The adapters that matter in 2026 are the current three: N64, Game Boy (the family), and Master System. Historically the Retrode ecosystem also had exotic adapters for the likes of Virtual Boy, Neo Geo Pocket, TurboGrafx/PC Engine, and others, but those are long discontinued — the connectors became unobtainable — and you should treat any listing for them as a collector's curiosity, not a buying plan. The table below is the honest current state:

Game Boy, GBA, and the SNES mouse quirk

Two practical notes. The N64 and GBA adapters run at 3.3 volts and, per the Retrode's own documentation, want to be connected before you plug in the USB cable; N64 and GBA save handling stayed partial even on the final firmware, so treat those saves as best-effort. And the perennial peripheral gotcha: the SNES mouse must go in the LEFT controller port (port 1). It will silently do nothing in the right port, and people burn twenty minutes on that before checking. It's in the manual; nobody reads the manual.

What refuses, and why

The Sega 32X works as a pass-through as long as you don't try to power it — it's just a connector in that context. What flatly does not work is anything containing a full console: the Super Game Boy adapter, the Retro-Bit RetroPort series, and similar. Those aren't passive pin adapters; they're small computers, and the Retrode has no idea how to talk to a computer sitting between it and a cartridge. If your “adapter” has its own logic chips, it isn't a Retrode adapter.

Five Pitfalls That Waste an Afternoon

Every one of these has cost someone an evening, and every one is avoidable if you know it's coming. Read this before your first dump, not after your first bad one.

Contacts, mappers, and the read-only flag

1. Dirty contacts producing silent-garbage dumps. This is the number-one cause of bad dumps that look fine. A partially-oxidized connector reads most of the ROM correctly and corrupts the rest, so the file is the right size and boots to the title screen before dying in level three. Fix: clean with 99% isopropyl, reseat, re-dump, and always verify against a checksum rather than trusting the title screen.

2. Coprocessor carts that can't be dumped at all. The Retrode reads address and data lines directly, so any cartridge whose chip remaps or decompresses the ROM defeats it. That's SA-1 (Super Mario RPG, Kirby Super Star, Kirby's Dream Land 3), S-DD1 (Star Ocean, Street Fighter Alpha 2), and Sega's Virtua Processor (Virtua Racing). Crucially, do not lump Super FX and DSP-1 in with these — those coprocessors add computation without remapping the ROM, so their carts (Star Fox, Super Mario Kart) dump perfectly. Knowing which chip is in your cartridge tells you in advance whether the Retrode can help.

3. [sramReadonly] blocking your save injection. Covered above, but it belongs here too because it presents as a baffling permissions error. Saves are read-only by default; set [sramReadonly] 0, press RESET, and only then copy the .srm on.

Firmware and peripheral traps

4. FLIP failing on a non-ASCII path. If FLIP throws an error loading your .hex and you've triple-checked the file, look at the folder path. A stray accented character anywhere in it — é, ã, a smart-quote — makes FLIP fail obscurely. Move the file to a plain path and it works.

5. Cross-flashing the wrong firmware. Flashing Retrode 1 firmware onto a Retrode 2 (or the reverse) is the reliable way to brick the unit. The two are different hardware revisions with different firmware images; the DFU bootloader survives a bad application flash, so you can recover by re-entering DFU and flashing the correct image — but the cleaner move is to not do it. Confirm the image matches your hardware revision before you type flash.

Troubleshooting Table

Symptom on the left, the cause that's actually behind it in the middle, the fix on the right. If your problem isn't here, it's almost always a variant of the dirty-contacts or wrong-flag entries.

The thirteen most common failures

When it's the cartridge, not the reader

The fastest diagnostic is a second cartridge. If several different carts all fail the same way — nothing mounts, or every dump is truncated — suspect the shared component: the cable, the port, the power, or the Retrode itself. If one cartridge misbehaves while others dump clean, the problem is that cartridge: dirty contacts nine times out of ten, a coprocessor the tenth. Don't reflash firmware or replace the unit to chase a fault that a cotton swab and a known-good second cart would have localized in ninety seconds.

Advanced: Batch Dumps, Checksums, Headers

Once the basic loop is automatic, the interesting work is doing it at scale and doing it verifiably. None of this is required; all of it makes a large collection trustworthy instead of merely large.

Batch dumping and scripting the copy

If you're working through a box of cartridges, you don't want to drag files by hand forty times. A tiny shell loop copies every dump off the volume as it mounts, checksums each file, and flushes before you eject. Insert a cartridge, run it, eject, repeat:

#!/bin/sh
# Pull every dump off the Retrode into a local folder, with checksums.
SRC=/run/media/$USER/RETRODE
DEST=$HOME/dumps
mkdir -p "$DEST"
for f in "$SRC"/*.sfc "$SRC"/*.bin "$SRC"/*.srm; do
  [ -e "$f" ] || continue          # skip a glob that matched nothing
  cp -v "$f" "$DEST/"
  sha1sum "$DEST/$(basename "$f")"
done
sync                                # flush before you unmount

Verifying against No-Intro and redump

A dump you didn't verify is a rumor, so make verification mechanical. Compute the SHA-1 and CRC32 of each ROM and compare against the No-Intro database, which catalogs known-good, headerless cartridge dumps by region. A match is proof of a clean read; a mismatch means clean the contacts and try again, or means you're holding a revision the database has under a different hash.

$ sha1sum ~/dumps/ZELDA3.sfc
<40-hex-sha1>  /home/you/dumps/ZELDA3.sfc
$ crc32 ~/dumps/ZELDA3.sfc
<8-hex-crc>
# Compare <40-hex-sha1> / <8-hex-crc> against the No-Intro DAT for your region.
# A match means a good, headerless dump. Rename the file only after it matches.

Headers, forceSize, and oddball mappers

The Retrode outputs headerless ROMs, which is exactly what modern emulators and No-Intro expect — do not “fix” this by adding a 512-byte copier header from some 1990s utility; you'll only make the file mismatch every database. For genuinely misbehaving cartridges, the config exposes overrides: [forceSize] to pin a size when the header lies, [forceMapper] when detection picks the wrong mapper, [detectionDelay] to slow down detection for a flaky cartridge, and [segaSram16bit] for the 16-bit-wide Sega saves that would otherwise read scrambled. [forceSystem] takes values like auto, snes, sega, and adapter systems such as GG — the 0.18d beta specifically fixed a case where forceSystem GG wasn't being recognized. Change these only to solve a specific misread; the defaults are right for essentially every normal cartridge. And remember the controller ports are live HID gamepads — handy for testing a dump with the original pad in an emulator the moment you've pulled it.

The Retrode3: What Late 2026 Brings

Now the part you came for if you're deciding whether to wait. The Retrode3 is a real project with real prototypes and a real chance of shipping — and also a moving target you cannot currently buy. Here's what's known, and where the manufacturer's own page can't keep its story straight.

MIPS, Debian, Wi-Fi, browser — and a CPU it can't agree on

The Retrode3 replaces the AVR-and-USB-drive model with a Linux single-board computer running Debian off an SD card. Because the OS lives on a swappable card, DragonBox calls it practically unbrickable — a bad update means you flash a fresh image, not bin the device. It has built-in Wi-Fi, so you can dump over the network and drop ROMs straight onto a server, and it presents a driverless browser UI over a USB-Ethernet link. Here's the caveat The Machine is contractually obligated to point out: DragonBox's own product page contradicts itself on the processor. The opening description says MIPS; further down the same page says the device has its own ARM processor. Both cannot be true. Until the shipping unit exists, treat the CPU as “a Linux SoC, architecture unconfirmed,” and be skeptical of anyone quoting one or the other as settled fact — they're quoting half a page.

Open source and Sanni's OSCR

The genuinely exciting part, if you care about longevity, is that the Retrode3 is fully open across four GitHub repositories — the Debian userspace, the kernel, the hardware design files, and the CLI. That last one, retrode3-oscr, is a Linux command-line adaptation of Sanni's Open Source Cart Reader wrapped around a retrode.lib that exposes the cartridge slots through Linux syscalls. The stated goal is to marry the Retrode 2's plug-and-play simplicity with the Cart Reader community's enormous breadth of supported systems — and because both projects share the OSCR lineage, DragonBox says hardware plugins will be cross-compatible in both directions. The licensing is properly free: GPLv3 for software, CC BY 4.0 for hardware, CC0 for docs. This is the anti-Retrode-2 in one respect that matters: when its maker eventually moves on, the design won't freeze in a vault the way the closed AVR firmware effectively did.

Price, timeline, and not getting scammed

The numbers, with the appropriate hedging: target price under €100, explicitly not final because of component lead times; availability targeted for the end of 2026, no firm date; status Out-of-Stock with a notify-me signup, not a pre-order. DragonBox has described ten fully working prototypes and put out a call for developers, which tells you exactly where it is: hardware essentially done, software the long pole. Flash-cart writing is partly live — the MegaDrive DragonDrive works today; SNES and Lynx writing are promised for launch. So: if you own SNES and Genesis cartridges and want to dump them now, buy the Retrode 2 and don't wait. If you specifically need NES, Wi-Fi, flash-cart writing, or an open platform you can hack, the Retrode3 is worth watching — but treat any listing with a firm date and a final price as fiction until DragonBox itself posts an order button. “End of the year” is a hope with a timestamp, not a delivery promise.

The Complete Working retrode.cfg

Here is the whole configuration file, annotated. The key names below are the verified ones the firmware actually reads; the layout is format-accurate. One honest caveat: retrode.org's dedicated config-file page now redirects to the current retrode.com site, so the canonical published reference is effectively offline — treat the arrangement here as a faithful reconstruction of the format, with the key names confirmed against firmware behavior and community documentation. The exact set present varies slightly between 0.18c and 0.18d-beta3.

The annotated file

; ============================================================
;  RETRODE.CFG  --  complete annotated reference
;  Edit on the mounted RETRODE volume, save, then press RESET
;  so the firmware re-reads the file. ';' starts a comment.
;  The configurable CFG has existed since firmware 0.17g.
; ============================================================

; ---- Extensions assigned to each dumped file ----
[sramExt]        srm     ; battery-backed save (SRAM) image
[snesRomExt]     sfc     ; SNES / Super Famicom ROM (headerless)
[segaRomExt]     bin     ; Mega Drive / Genesis ROM

; ---- Filename behaviour ----
[filenameChksum] 0       ; 1 = append the ROM's internal checksum to the name

; ---- Autodetect overrides (defaults are right for almost every cart) ----
[forceSystem]    auto    ; auto | snes | sega | GG ...  force the slot's system
[forceSize]      0       ; 0 = read size from header; else force size (KiB)
[forceMapper]    0       ; 0 = detect; override only for a misread mapper
[detectionDelay] 0       ; raise if a flaky cart is detected inconsistently
[segaSram16bit]  0       ; 1 = treat Sega save RAM as 16-bit wide

; ---- Save-injection guard ----
[sramReadonly]   1       ; 1 = SRAM read-only (safe); 0 = allow writing .srm back

; Notes:
;  * Exact key set varies by firmware (0.18c stable / 0.18d-beta3).
;  * Dumps are headerless by design -- never add a 512-byte copier header.
;  * After any edit, press the front RESET button to reload this file.

Notes on what's illustrative

Use that file as a working template, but treat two things as conventions rather than gospel: the precise formatting the parser tolerates, and the full list of keys present in your specific firmware build. If a key above does nothing on your unit, you're likely on a build that predates it — which is another argument for being on 0.18c. Everything else in this guide is the durable part: clean the contacts, copy in one pass, verify by checksum, eject before you pull the cartridge, and rescue the saves before the batteries do you the favor of deciding for you.

Where to read further

The primary sources worth your time are the manufacturer's Retrode FAQ (the definitive word on which coprocessors are and aren't supported, and the project's stance that “the Retrode is not for pirates”), the Wikipedia entry for the hardware and ownership history, the full Retrode user guide on the Internet Archive, and — for the argument that any of this matters — the University of Maryland's account of using Retrodes for SNES preservation. That last one is the point. A dead battery is a small tragedy that happens quietly, at scale, across every shelf of cartridges on Earth, and a $100 AVR device from 2015 is still the most honest tool for stopping it. The Retrode3 may be better. The Retrode 2 is here.