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

There is a specific anxiety that comes from owning a shoebox of Super Nintendo cartridges and knowing the battery-backed save on each one is quietly dying. The Retrode exists for that anxiety. It is not an emulator, it is not a flashcart, and it is not — despite a decade of forum threads insisting otherwise — a piece of software you download. It is a small grey box with two cartridge slots that turns a physical cartridge into files on a USB drive. That is the entire pitch, and it is a very good one.

This tutorial walks the whole process end to end on the shipping hardware, the Retrode 2: prerequisites, a twelve-step dump you can finish in about half an hour, rescuing the SRAM save without destroying it, the RETRODE.CFG file that nobody documents anymore, the firmware that stopped moving in 2016, the co-processor chips that will quietly ruin your day, and the browser-driven Retrode 3 that is still, as of this writing, vaporware with a GitHub account. Everything here is traceable to the official site, the FAQ, the archived user guide, or Wikipedia. Where the internet lies to you — and on this subject it lies confidently — the lie is named and buried.

What the Retrode Actually Is

Before you plug anything in, understand what you bought, because half the support threads on the internet are people misunderstanding the premise.

A USB interface for cartridges and controllers

The Retrode is, in the manufacturer's own words, a USB interface for vintage video game cartridges and controllers. You insert a cartridge, and the device reads the mask-ROM and the battery-backed save RAM off the physical silicon and presents them as files on a virtual drive. It also has four controller ports — two SNES, two Sega — and exposes anything plugged into them as a standard USB HID gamepad. That second function is genuinely useful: your original SNES pad becomes a plug-and-play controller for an emulator with zero configuration, and the analog feel of the real hardware comes along for free.

The lower, shorter slot takes Sega Mega Drive / Genesis cartridges. The upper, wider slot takes SNES / Super Famicom cartridges. There is no region lock in the electrical sense — the Retrode reads the chip, it does not care what territory pressed it — though physical cartridge shells and the header data differ, and you will see that difference in filenames later.

What "not an emulator" means, legally and technically

The FAQ is blunt: "The Retrode is not an emulator. An emulator is a piece of software that runs the program code ('ROM') contained on the cartridge." The Retrode runs nothing. It copies. This distinction is not pedantry — it is the whole legal posture of the device. It ships with no copyrighted code, it decodes no protection, and it makes a backup of media you physically possess. That is the cleanest corner of an otherwise messy area of law. The University of Maryland's Maryland Institute for Technology in the Humanities used a Retrode in its SNES preservation project precisely because it produces an archival-grade, byte-for-byte copy without touching the software's execution. What you do with the resulting file afterward is your problem and no longer the hardware's.

Two products share one name

This trips up almost everyone. "Retrode" refers to two devices. The Retrode 2 is the shipping product — an Atmel AVR microcontroller presenting a USB mass-storage device, driverless, frozen firmware, available right now. The Retrode 3 is an unreleased successor built on a Linux single-board computer with a browser interface, targeting late 2026 at under 100 EUR. When a tutorial or a Reddit reply says "the Retrode," ask which one, because almost nothing about the workflow transfers between them. This guide is about the Retrode 2 unless the section explicitly says otherwise. If you want the fast version of this same process, we keep a condensed 25-minute Retrode 2 walkthrough that skips the lore and gets straight to the copy.

Prerequisites: Hardware, Software, Versions

A dump fails for boring reasons far more often than exotic ones. Get the prerequisites right and you eliminate most of the troubleshooting table before you ever reach it.

The hardware bill of materials

You need, at minimum:

• A Retrode 2 unit. Official pricing is EUR 65 / USD 85 direct from the manufacturer; through DragonBox the base unit is EUR 64.90. In North America the common reseller is Stone Age Gamer at roughly $99.99, with each plug-in adapter (N64, Game Boy, Master System) at $39.99. The retail box is spartan: the unit, a USB cable, and an instruction sheet.
• A USB cable — the classic unit uses USB Mini-B. Use a data cable, not a charge-only cable; if the drive never mounts, this is the first thing to rule out.
• The cartridges you want to dump. Clean ones. A cartridge that has sat in a garage since 1996 has oxidized contacts, and oxidized contacts produce truncated or garbage dumps, not error messages.
• 99% isopropyl alcohol and a lint-free wipe for cleaning contacts. Not water, not a household spray, not a fiber-shedding cotton swab.
• Optional: the plug-in adapters if you are dumping N64, Game Boy / Color / Advance, or Sega Master System / Game Gear carts.

Software and operating-system requirements

The headline feature is that there is almost no software requirement. Wikipedia's entry notes the Retrode can be used without drivers or special software on the popular operating systems, because it enumerates as two device classes every modern OS already understands: USB Mass Storage and USB HID. Concretely:

• Windows 10 or 11, macOS (Intel or Apple Silicon), or a mainline Linux distribution — anything with a 4.x-or-newer kernel handles it without a thought. The historical curiosities (OpenPandora, Caanoo, even a jailbroken iPad) worked too, but you do not need them.
• For checksum verification: md5sum / sha1sum on Linux/macOS, or a tool like the Windows built-in certutil -hashfile. Optional but strongly recommended.
• For firmware flashing only (you will rarely need this): Atmel FLIP on Windows, or dfu-programmer (version 0.7.2 or newer) on Linux/macOS. Skip this entirely unless a dump is failing in a way that points at firmware.
• An emulator or frontend to actually play the results — that is a separate project. Once you have clean ROMs, loading them into the correct core is its own discipline; our RetroArch core-selection walkthrough covers which core to point at an SNES versus a Mega Drive dump, and if you would rather drop the files onto a dedicated build, the RetroPie state-of-play piece explains why that image is stuck where it is.

A word on price, because the internet gets it wrong

You will see stale figures everywhere: "$84.99," "$89.99," pre-order prices from a decade ago. The current, verifiable numbers are EUR 65 / USD 85 official, EUR 64.90 at DragonBox, and about $99.99 at Stone Age Gamer with $39.99 adapters. If a listing quotes something dramatically lower, it is either old stock, a clone, or a scam. The Retrode is a niche, small-batch, made-in-Germany device; it is not going to be cheap, and it is not supposed to be.

How It Presents Itself: Mass Storage + HID

Understanding the enumeration model turns most "it doesn't work" moments into thirty-second fixes, because you learn to read what the OS is telling you.

The composite USB device

When you connect a Retrode 2, it enumerates as a composite USB device: one mass-storage endpoint (the virtual drive) and up to four HID endpoints (the controller ports). No driver installs. The OS sees a removable FAT volume and some gamepads, exactly as if you plugged in a thumb drive and a couple of joysticks at once. Here is what that looks like on Linux when you connect the unit with a cartridge seated:

$ dmesg | tail -n 6
usb 1-2: new full-speed USB device number 7 using xhci_hcd
usb 1-2: New USB device found, Manufacturer: Retrode, Product: Retrode 2
usb-storage 1-2:1.0: USB Mass Storage device detected
scsi host6: usb-storage 1-2:1.0
sd 6:0:0:0: [sdb] 512-byte logical blocks: removable disk
sd 6:0:0:0: [sdb] Attached SCSI removable disk

$ lsblk -o NAME,LABEL,SIZE,FSTYPE | grep -i retrode
sdb     RETRODE   4.0M  vfat

That small FAT volume labeled RETRODE is the whole interface. Note the size: it is tiny, because it is not real storage — it is a window onto whatever cartridge is currently seated.

The virtual drive and its files

Mount the RETRODE volume and you will find the cartridge decomposed into files. A SNES cart produces a .SFC ROM and, if it has a battery save, a matching .SRM. A Mega Drive cart produces a .BIN and its own .SRM. A configuration file, RETRODE.CFG, always sits in the root. The filename is drawn from the internal cartridge header, which is why it sometimes looks like a shouting fragment of the real title:

$ ls -la /media/$USER/RETRODE
total 3072
-rwxr-xr-x 1 user user     512 Jan  1  2016 RETRODE.CFG
-rwxr-xr-x 1 user user 3145728 Jan  1  2016 'SUPER MARIOWORLD.SFC'
-rwxr-xr-x 1 user user    2048 Jan  1  2016 'SUPER MARIOWORLD.SRM'

The 3,145,728-byte ROM is a 3 MB (24 Mbit) image — correct for Super Mario World. The 2 KB SRM is the save. The dates are fixed and meaningless; the Retrode has no clock. Copy those two files off the drive and you have preserved the cartridge.

The LED and the two buttons

There is one status LED and two buttons. The LED lights during ROM or RAM access and blinks when the RETRODE.CFG file is written — a useful confirmation that your config edit took. The buttons are numbered in the documentation: button (7) is HWB, which triggers custom firmware functions and is used to enter the flashing bootloader, and button (8) is RESET, which re-mounts the drive after you swap a cartridge. You will press RESET constantly and HWB almost never.

The 12-Step Dump: Cartridge to ROM

This is the core procedure. It works for SNES and Mega Drive / Genesis carts out of the box; adapters extend it to other systems (covered later). Each step has a reason attached, because a step you understand is a step you can debug.

1. Clean the cartridge contacts. Dampen a lint-free wipe with 99% isopropyl alcohol and wipe the edge connector until it is bright. Rationale: oxidation is the single most common cause of truncated or garbage dumps, and it produces no error — just a corrupt file. Clean first, debug never.
2. Seat the cartridge fully in the correct slot. SNES/SFC goes in the upper, wider slot; Genesis/Mega Drive in the lower, shorter slot. Rationale: a half-seated cart makes intermittent contact, and intermittent contact during a read is worse than no contact — it yields a file that looks complete but is wrong.
3. Connect the Retrode to the computer with a data-capable USB cable. Rationale: the device is bus-powered; a charge-only cable gives you a lit LED and no data lines, and therefore no drive. If nothing mounts, swap the cable before anything else.
4. Confirm the RETRODE volume mounted. Check for a removable FAT drive labeled RETRODE (see the lsblk / File Explorer / Finder view). Rationale: if the OS never sees the mass-storage device, no amount of copying will help; you have a hardware or seating problem to solve first.
5. Open the volume and read the filenames. Verify the ROM's name and, critically, its size against what you expect for that title. Rationale: the size is your first, free integrity check. A 4 Mbit file where you expected 24 Mbit means the cartridge did not fully detect — reseat and re-read.
6. If the file size looks wrong, adjust detectionDelay and re-seat. Edit RETRODE.CFG, raise detectionDelay, save, and press RESET. Rationale: some carts need a few milliseconds to settle before the controller reads the header; too short a delay truncates the dump. This is the fix for "it mounts but the ROM is stunted."
7. Copy the ROM file off the drive to local storage. Drag it, or use the shell. Rationale: never work off the virtual drive — it is not real storage, and reading a ROM straight into an emulator from the Retrode ties up the device and risks a mid-read cartridge bump.
8. Copy the matching .SRM save if one exists and you want it. By default it is read-only (see the SRAM section). Rationale: the save is the irreplaceable part. The ROM you can re-dump or find in a verified set forever; the save on your specific cartridge exists nowhere else.

# Steps 7 and 8, on the command line:
$ mkdir -p ~/roms/snes ~/saves/snes
$ cp "/media/$USER/RETRODE/SUPER MARIOWORLD.SFC" ~/roms/snes/
$ cp "/media/$USER/RETRODE/SUPER MARIOWORLD.SRM" ~/saves/snes/
$ sync

9. Generate a checksum of the copied ROM. Run sha1sum or md5sum against your local copy. Rationale: a hash is the only way to know a dump is byte-perfect. Two dumps of the same clean cartridge produce identical hashes; a mismatch means dirt, a bad seat, or an unsupported chip.
10. Compare the hash against a No-Intro DAT. Rationale: No-Intro is the community's canonical set of known-good cartridge hashes. A match is proof your dump equals the reference dump the archival community trusts. A miss is not automatically failure — your region or revision may simply differ — but it is a flag worth investigating.
11. Eject the RETRODE volume through the OS before removing the cartridge. Rationale: this flushes any pending writes and, more importantly, builds the habit that protects your saves. Hot-swapping carts is the number-one way to corrupt an on-cartridge battery save (see Pitfalls).
12. Swap the next cartridge and press RESET. Rationale: RESET re-mounts the drive against the new cartridge. Without it, you are staring at the previous cart's files and will happily "back up" the wrong game. Watch the LED confirm the re-mount, then return to step 5.

That is the full loop. In practice, once the first cart is done, each subsequent cartridge is steps 1, 2, 5, 7–12 — a couple of minutes each. A stack of a dozen carts is a comfortable half-hour, which is where this tutorial's title comes from. If you would rather off-load the resulting library onto something pocket-sized afterward, sideloading a verified set onto a Miyoo Mini Plus is a natural next step.

Backing Up SRAM Without Corrupting It

The ROM is easy. The save is where people lose data, because the Retrode's defaults are protective and its warnings are quiet.

Why saves are write-protected by default

The .SRM file that appears on the RETRODE volume is, out of the box, write-protected. The user guide states the RAM files are "by default write-protected," and the mechanism is the sramReadonly key in RETRODE.CFG, which ships set to 1. This is deliberate and correct. The save RAM on a 30-year-old cartridge is backed by a coin cell that is often at the very end of its life; the last thing you want is your file manager writing a stray byte back to it and corrupting a save you cannot recreate. Read-only-by-default means you can copy the save off the cartridge freely, but nothing writes back to it by accident.

Copying the save, and writing it back if you must

To simply archive a save, you do nothing special — read-only does not prevent reading. Copy the .SRM off the drive exactly as you copied the ROM. That covers 95% of use cases: you are preserving, not modifying.

If you genuinely need to write a save back to a cartridge — restoring a backup, or transplanting a save — you flip the switch:

; In RETRODE.CFG, change the default:
sramReadonly    0     ; 0 allows writes back to on-cart save RAM

Save the file, wait for the LED to blink (confirming the config was written), press RESET, and the SRM becomes writable. Copy your save onto the drive, eject cleanly, and the data lands on the cartridge's RAM. Then — and this is the part people forget — set sramReadonly back to 1. Leaving writes enabled is an accident waiting for a slip of the mouse.

The hot-swap trap that eats saves

Here is the exact wording from the user guide, because it is the most important sentence in this article: hot-swapping is "possible, but it can potentially damage on-cartridge savegames... prefer to eject/unplug the Retrode first." Translated: if you yank a cartridge out and jam the next one in while the drive is live, you risk corrupting the battery save on the cartridge you just removed. The device cannot always finish what it was doing mid-swap. Always eject the volume (step 11) before you pull a cart. It costs three seconds and it is the difference between a preserved save and a dead one. The ROM survives a hot-swap; the save is the casualty.

RETRODE.CFG: Every Key That Matters

The configuration file is the least-documented, most-useful part of the device. The official documentation page for it now 302-redirects to the front page — the docs are effectively dead — so what follows treats the file as illustrative-of-format. The key names are verified; the exact values you use depend on your cartridge.

Where the file lives and how it applies

RETRODE.CFG sits in the root of the RETRODE volume. You edit it in place with any plain-text editor, save it, and the change takes effect on the next mount — press RESET (or re-plug) to apply. The LED blinks when the file is written back, which is your confirmation the edit was accepted. The config feature has existed since firmware 0.17g, so any 0.18-series unit supports every key here.

The keys, one by one

These are the verified keys and what each does:

• sramReadonly — 1 protects saves (default), 0 allows writes back to the cartridge.
• forceSystem — override auto-detection when the Retrode guesses the console wrong. Accepts values like SNES, SEGA, GG (Game Gear).
• forceSize — override the detected ROM size when header detection fails and produces a truncated or oversized file.
• forceMapper — override the detected mapper/board layout on carts the heuristics misread.
• detectionDelay — add milliseconds before the header read, for carts that mount before they settle.
• segaSram16bit — set 1 for Sega carts whose SRAM is stored as 16-bit words rather than 8-bit.
• filenameChksum — append a checksum to the output filename, handy when batch-dumping many carts.
• sramExt, snesRomExt, segaRomExt — the file extensions used for save files, SNES ROMs, and Sega ROMs respectively.

forceSystem, Game Gear, and manual overrides

The override keys exist because auto-detection is a heuristic, and heuristics miss. The canonical case is Game Gear: a Game Gear cartridge, read through the Master System adapter, is electrically close enough to a Master System cart that the Retrode can misidentify it. Setting forceSystem GG resolves it — and, as a piece of trivia that tells you how mature this firmware is, the recognition of the GG value was specifically fixed in the 0.18d beta 3 build. If a cart dumps as the wrong system or at the wrong size, reach for forceSystem, forceSize, and forceMapper in that order before you conclude the cartridge is unsupported.

Firmware: Frozen at 0.18, and the v0.22 Myth

You will probably never flash the firmware. But you should understand its state, because misinformation about it drives people to "fix" a device that is working exactly as designed.

Why the firmware stopped in 2016

The Retrode 2 runs firmware built on Dean Camera's LUFA USB stack for AVR, and the last builds are 0.18c stable, dated 22 April 2016, with 0.18d beta 3 as the final beta. That is the end of the line. The firmware is frozen — not abandoned in the pejorative sense, but complete for the hardware it runs on. The AVR microcontroller has finite room and the mainstream cartridge cases are all handled. Development energy long ago moved to Sanni's Cart Reader and, more recently, the Retrode 3. A frozen firmware is not a bug to be patched; it is a device that reached its ceiling.

This produces a persistent piece of internet nonsense: the claim that a version 0.22 "added enhanced chip cart support for SNES." It did not, because 0.22 does not exist. The real version line runs 0.17-series to 0.18d beta 3 and stops. Anyone quoting a 0.22 is either confused or repeating someone else's confusion. Do not go hunting for it. Flash the 0.18c build for the AT90USB646 and move on.

The DFU flash procedure

If you ever do need to reflash — a corrupted firmware, or moving from an ancient build to 0.18c — the process uses the AVR's built-in DFU bootloader. The microcontroller is an Atmel AT90USB646. You enter the bootloader physically: hold the HWB button, tap RESET, then release HWB. The device re-enumerates as the well-documented Atmel DFU bootloader, identifiable in lsusb by the ID 03eb:2ff9. On Windows you flash with Atmel FLIP; on Linux and macOS you use dfu-programmer:

# 1. Enter DFU: hold HWB (button 7), tap RESET (button 8), release HWB.
# 2. Confirm the bootloader enumerated:
$ lsusb | grep 03eb
Bus 001 Device 012: ID 03eb:2ff9 Atmel Corp. atmega/at90usb DFU bootloader

# 3. Erase, flash, reset (Linux / macOS):
$ dfu-programmer at90usb646 erase
$ dfu-programmer at90usb646 flash Retrode2_0.18c.hex
$ dfu-programmer at90usb646 reset

Always erase before flash, and make sure the .hex you are writing is the AT90USB646 build. Flashing the wrong target, or skipping the erase, is how a working device becomes a paperweight until you redo it correctly.

What 0.18 actually changed

For the record, so you know what the final firmware brought over its predecessors: the 0.18 line improved N64 and GBA ROM size detection, updated the LUFA library, fixed a Master System plug-in bug, and — the notable one — added SMS SRAM reading, so Master System battery saves finally came off the cartridge. That is the actual changelog. Nothing about "enhanced chip carts," because that is not a thing that happened.

Adapters and Co-Processor Chips

The Retrode 2 dumps two systems natively. Everything else is an adapter, and some cartridges will not dump at all regardless of adapter — for reasons of silicon, not effort.

The three surviving adapters

The current official adapter set is three plug-ins, documented on the manufacturer's plug-in adapters page:

• N64 — reads the ROM fine; save support (EEPROM / FlashRAM / SRAM) is listed as firmware-pending, so treat it as ROM-only. It runs at 3.3V, supports up to two controllers, and must be connected before you plug the Retrode into USB.
• Game Boy / Color / Advance (GBx) — reads ROMs for all three; GB and GBC SRAM saves read fine, while GBA SRAM and flash saves are pending. GB/GBC run at 5V, GBA at 3.3V.
• Sega Master System (SMS) — reads the ROM; SRAM reading was added in the 0.18 firmware. Note the header often lacks a title field, so filenames come out generic and need manual renaming.

Older, exotic adapters existed but were discontinued because their connectors became unobtainable. If you see a Virtual Boy or similar adapter referenced, it is historical. The three above are what you can actually get.

Super FX and DSP1 dump fine — SA-1, S-DD1, and SVP do not

This is the single most misunderstood point about the Retrode, and getting it wrong wastes hours. The FAQ draws the line precisely. Some enhancement chips "simply offer additional processing capability that is included in most emulators" — those dump perfectly, because the Retrode copies the ROM and the emulator supplies the chip. That group includes Nintendo's Super FX (Star Fox, Yoshi's Island, Doom) and DSP1 (Pilotwings, Super Mario Kart). They are fine. Dump them normally.

Other chips "sit between console and ROM/RAM chips and act as sort of a copy protection mechanism." These the Retrode cannot read through, and the FAQ names them: Nintendo's SA-1 and S-DD1, and Sega's Virtua Processor (SVP). In practice that means:

If you try to dump Super Mario RPG and it comes out wrong, the Retrode is not broken and your cartridge is not dirty. SA-1 is simply not readable this way. Do not lump Super FX into that failure set — it is the exact mistake the FAQ is written to prevent.

The 32X adapter works; the Super Game Boy adapter does not

Two edge cases worth committing to memory. The FAQ confirms that "only the Sega 32X (without power supply) has been confirmed to work" as a cartridge adapter — you can dump a 32X cart through it, minus its power brick. The Super Game Boy adapter, by contrast, does not work, because it is effectively a full console rather than a passive passthrough, and the Retrode cannot drive it. Controller-wise, standard SNES and Sega 3- and 6-button gamepads are supported, and the one asymmetry to remember is that the SNES mouse works only on the left port. Plug it into the right port and it does nothing, and you will spend twenty minutes assuming the mouse is dead.

Six Pitfalls That Wreck a Dump

Every failure below is self-inflicted and every one is avoidable. Read these once and you will sidestep the entire troubleshooting table.

Data-loss pitfalls

1. Hot-swapping cartridges. Pulling a cart while the drive is live can corrupt that cartridge's battery save. Fix: eject the RETRODE volume through the OS, then swap. The user guide is explicit about this and it is the only pitfall that destroys irreplaceable data.
2. Assuming your save didn't dump because it's read-only. The .SRM is write-protected by default, but read-only does not mean it failed — it means it is protected. Fix: just copy it off; read-only blocks writes, not reads. Only touch sramReadonly 0 if you need to write a save back.

Wrong-expectation pitfalls

3. Expecting SA-1, S-DD1, or SVP titles to dump. They will not, ever, on this hardware. Fix: know the chip list before you blame the device. For those specific carts you need a different dumper.
4. Trusting the auto-generated filename. The name comes from the cartridge header, which is sometimes wrong, generic, or (on Master System) absent. Fix: verify by ROM size and by hashing against No-Intro, then rename to a sane convention. Do not curate a library on the strength of a shouting header string.
5. Hunting for firmware that does not exist. There is no v0.22, no "enhanced chip cart" update, no secret build. Fix: accept that 0.18c is the end and stop searching. Flashing a random "newer" hex you found on a forum is how devices die.

Physical pitfalls

6. Cleaning contacts with the wrong thing. Water leaves residue, household sprays leave films, and fiber-shedding swabs leave fibers across the connector. Fix: 99% isopropyl alcohol on a lint-free wipe, nothing else. A clean contact is the prerequisite for every clean dump, and it is the fix for the majority of "corrupt file" reports.

Troubleshooting: 13 Failure Modes

When a dump misbehaves, work down this table before you conclude the hardware is faulty. Ninety percent of the time the cause is seating, cleanliness, or a config default.

The failure-mode table

Verification is the real test

The table above tells you how to fix symptoms, but the definitive test that a dump is good is a checksum that matches a known reference. A dump that mounts, has the right size, and hashes to the No-Intro value is correct — full stop. A dump that mounts and looks right but hashes wrong is a subtle failure you would otherwise ship into your archive unnoticed. Hash every dump. It is the one step that separates "I copied a file" from "I preserved a cartridge."

Advanced: Batch Dumps, Verification, Retrode 3

Once the single-cart loop is muscle memory, the interesting work is scaling it, proving it, and looking at what replaces it.

Scripted batch dumping

Because the Retrode is a plain mass-storage device, you can automate the copy with nothing more than a shell script. There is no API, no SDK — it is a removable drive, so treat it like one. This POSIX script pulls every ROM and save off the volume and files them, so your only manual job is swapping carts and pressing RESET:

#!/bin/sh
# batch-dump.sh - copy each ROM/SRAM off the Retrode as carts are swapped.
# The Retrode is a mass-storage device; treat it like any removable drive.
SRC="/media/$USER/RETRODE"
DST="$HOME/roms/incoming"
mkdir -p "$DST"

for f in "$SRC"/*.SFC "$SRC"/*.BIN "$SRC"/*.SRM; do
  [ -e "$f" ] || continue          # skip when a pattern matches nothing
  cp -v "$f" "$DST/"
done
sync
echo "Copied. Swap the next cart, press RESET, run again."

Enable filenameChksum in RETRODE.CFG first and each output file carries a checksum in its name, which makes deduplicating a large run trivial.

Verifying against a No-Intro DAT

To turn a pile of files into a verified set, hash them all and reconcile against a DAT. The workflow is: compute a SHA-1 for every ROM, then look each hash up in the No-Intro database (or feed the folder to a ROM manager that does it for you).

$ cd ~/roms/incoming
$ sha1sum *.SFC *.BIN
# Each line is: <40-hex-digit SHA-1>  <filename>
# Paste each hash into your No-Intro DAT / ROM manager.
# A match  = byte-perfect dump, safe to archive.
# A miss   = investigate: region/revision variant, dirty cart, or
#            an unsupported chip (SA-1 / S-DD1 / SVP).

A hash that matches the reference is the strongest claim you can make about a dump: it is identical to the copy the preservation community has agreed is correct. A hash that misses is not automatically bad — you may simply own a rarer revision — but it deserves a second look before it goes into your permanent library.

The Retrode 3: browser UI, Debian, and still unreleased

The successor changes the model entirely. Where the Retrode 2 is an AVR presenting a USB drive, the Retrode 3 is a Linux single-board computer that registers as a USB-Ethernet device and hands you a web browser interface — no drivers, no mounted drive, just a local page where you dump carts, back up SRAM, and even write flash carts. Verified against DragonBox's product page in July 2026: it targets availability "by the end of the year" at a price "under 100 EUR," it runs Debian, it has built-in Wi-Fi, and it adds a third native slot — NES — alongside SNES and Mega Drive. Flash-cart writing already works for Mega Drive (DragonDrive), with SNES and Lynx "available when the Retrode3 ships." The OS lives on an SD card, making the device "practically unbrickable - just flash a new image."

One honest caveat, because The Machine does not paper over primary-source contradictions: the same product page describes the processor as "an MIPS processor" in one place while other DragonBox copy has referred to "its own ARM processor." Treat the exact SoC as unsettled until the hardware ships — "a Linux SoC" is the safe description. The software is genuinely open: the project spans four public repositories, and the OS is built atop Sanni's Cart Reader via the retrode3-oscr repository (GPLv3 software, CC BY 4.0 hardware). DragonBox has publicly stated it has "10 fully working prototypes" and is "looking for developers." Until it actually ships, though, it remains notify-me vaporware — the Retrode 2 is the device you use today.

Where the Retrode fits versus a MiSTer or a flashcart

A closing bit of perspective. The Retrode's job is extraction — getting the bits off the silicon. It is not a playback device. If you want cartridge-accurate playback of the games you dump, that is a job for FPGA hardware like the MiSTer Multisystem 2, which recreates the console at the logic level rather than emulating it in software. The pipeline is clean and complementary: dump with the Retrode, verify against No-Intro, then play back through an emulator, a flashcart, or an FPGA core. Each tool does one thing; the Retrode does the irreplaceable first step.

The Complete, Annotated RETRODE.CFG

Here is a full configuration file assembled from the verified key names. The official CFG documentation page is dead (it redirects to the front page), so treat this as illustrative-of-format: the keys are real and confirmed, the values are sane examples you adapt per cartridge and per system.

The full file

; ============================================================
; RETRODE.CFG - complete annotated reference
; Place in the root of the RETRODE volume. Edit, save, then
; press RESET (or re-plug) to apply. LED blinks when written.
; Keys verified; values are examples - adapt per cartridge.
; ============================================================

; --- Save-RAM handling ------------------------------------
sramReadonly    1        ; 1 = protect saves (DEFAULT). 0 = allow writes.
segaSram16bit   0        ; 1 for Sega carts storing SRAM as 16-bit words
sramExt         SRM      ; extension for the save file (SRM, SAV, ...)

; --- System detection and overrides -----------------------
forceSystem     auto     ; auto | SNES | SEGA | GG | N64 | GB | SMS
forceSize       0        ; 0 = auto-detect ROM size; else force it
forceMapper     0        ; 0 = auto; override board/mapper on misreads
detectionDelay  0        ; add ms if a cart mounts before it settles

; --- File naming ------------------------------------------
filenameChksum  0        ; 1 = append a checksum to the output filename
snesRomExt      SFC      ; extension for SNES / SFC ROM dumps
segaRomExt      BIN      ; extension for Mega Drive / Genesis ROM dumps

How to adapt it per system

Start from the file above unchanged — the defaults are correct for a routine SNES or Genesis dump. Then make targeted edits only when a specific cartridge misbehaves:

• Restoring a save to a cart: set sramReadonly 0, do the write, set it back to 1.
• A Game Gear cart read as Master System: set forceSystem GG.
• A ROM that dumps truncated: raise detectionDelay first; if that fails, set forceSize to the known size.
• A scrambled Genesis save: try segaSram16bit 1.
• A large batch run: set filenameChksum 1 so duplicates are obvious at a glance.

Change one key at a time, cycle RESET, and re-hash. That discipline — one variable, one test, one checksum — is the difference between a config you understand and a config you cargo-culted off a forum.

Where to go from here

You now have the full workflow: clean, seat, mount, copy, verify, eject, repeat, with the firmware and config knowledge to handle the awkward carts. For the canonical documentation, the manufacturer's official FAQ is the primary source on chip support and controllers; the full archived user guide is the definitive reference on hot-swap behavior and the CFG file; the Wikipedia entry covers the AT90USB646 and the driverless enumeration model; and once you are ready to actually play what you have preserved, the libretro documentation is where you learn which core to point at each dump. The Retrode does the extraction. Everything downstream is your choice — but it all starts with a byte-perfect copy off the silicon, and now you know how to make one.