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

The word "retrode" trips every autocomplete into offering you "retrograde," which is astrology, which is the universe's polite way of warning you that most people arrive at this device carrying a horoscope's worth of wrong assumptions. Chief among them: that a Retrode plays your cartridges. It does not. It has never played a cartridge in its life and it never will, because it is not an emulator and does not contain one. What it is — and what this tutorial will actually teach you to do with it — is a small German box that turns a Super Nintendo or Sega Genesis cartridge into files on your computer. ROMs. Saves. Bytes you can copy, hash, archive, and hand to a real emulator. The Retrode is the on-ramp, not the highway.

In 2026 there are two of them. The Retrode 2 has been shipping, essentially unchanged, since the middle of the last decade, and it is the one you can buy and use tonight. The Retrode3 is a genuinely interesting Linux-powered successor that, as of this writing in July 2026, you cannot buy at all. This guide covers the shipping hardware in detail — twelve numbered steps, seven code blocks, a dozen-row troubleshooting table, and a complete configuration file at the end — and tells you exactly where the new one stands so you do not waste an evening refreshing a product page that has no Buy button.

What the Retrode Actually Is (and Isn't)

A USB interface, not an emulator

Start here, because everything downstream depends on it. The Retrode is a hardware bridge. You insert a cartridge, plug the box into your computer over USB, and the silicon inside the cart — the mask ROM that holds the game, plus the battery-backed SRAM that holds your saves — is exposed to your operating system as ordinary files on a tiny removable drive. That is the entire trick. The official FAQ answers the "can it play games?" question with a single deadpan line to the effect that ROM stands for Read-Only Memory, "hence: no." The device reads memory. It does not execute it. Anyone selling you a Retrode as a plug-and-play console is either confused or lying, and the distinction rarely matters to your wallet.

This is not a limitation to resent; it is the point. A dumper that refuses to run code is a dumper you can trust to produce a faithful, bit-exact copy of what is physically on the board. The Wikipedia entry for the Retrode describes it precisely as a USB adapter for legacy video games that let cartridges and controllers work with emulators, driverless, on the popular operating systems. That is the whole job description, and it has not changed in over a decade.

ROM read-only, SRAM read-write

The nuance that separates a Retrode owner who keeps their saves from one who loses them: the two kinds of memory behave differently. The ROM is genuinely read-only — it is mask silicon, physically unwritable, and the Retrode presents it as a read-only file. You cannot corrupt a game by copying it. The SRAM is another matter entirely. It is real, writable, battery-backed memory, and the Retrode exposes it as a writable file. Drag a save off to archive it, and nothing bad happens. Drag a save onto the mounted volume, and you have just written new bytes into the physical cartridge, over the top of whatever was there. There is no undo. We will return to this with appropriate menace in the SRAM section.

The lineage: Hullin, a defunct UG, and DragonBox

A little lore, because the provenance explains the frozen state of the product. The Retrode was conceived in 2009 by Matthias Hullin, posted first to the Pandora handheld community as a hobby project. It became a small German company, Retrode UG, which ceased operations in the summer of 2013. The second revision — the Retrode 2 you buy today — came back to market through OpenPandora GmbH in March 2015 and is now sold and stewarded by DragonBox / the official Retrode site. That daisy-chain of small outfits is why the hardware is stable to the point of fossilization: nobody has had the appetite to redesign a working niche product, and the firmware, as we will see, stopped receiving updates around 2016. The Retrode3 is the first real attempt in years to move the concept forward, and it does so by throwing out almost the entire architecture.

Two Retrodes in 2026: the 2 and the Vapor

The Retrode 2: still shipping, still frozen

The Retrode 2 is a composite USB device built around an Atmel AVR microcontroller, the AT90USB646, running firmware based on Dean Camera's LUFA USB stack. It has two cartridge slots — the shorter lower slot takes Sega Genesis / Mega Drive carts, the wider upper slot takes SNES / Super Famicom — and a 2×2 bank of controller ports for up to four original pads. The official site bills it, with more exclamation than The Machine would permit, as "the world's most versatile (and fun!) USB adapter for vintage video games," and lists a suggested price of roughly EUR 65 / USD 85. In practice you will pay DragonBox about €64.90 for the base unit (plug-in adapters €25 each), or a US reseller such as Stone Age Gamer around $99.99, with adapter packs at $39.99. It is 162 × 80 × 42 mm, weighs 220 grams, and is proudly Made in Germany.

The Retrode3: finished hardware, unfinished software

The Retrode3 product page at DragonBox describes a completely different animal: a Linux single-board computer with built-in Wi-Fi that registers over USB as an Ethernet device and is operated "entirely in your web browser" on Windows, macOS or Linux, no drivers. It boots Debian from an SD card, which the site calls "practically unbrickable — just flash a new image," and it is "fully open source and therefore future-proof." Out of the box it reads SNES/SFC, Mega Drive/Genesis, and — new to the line — NES, with more systems promised through a plug-in architecture (Atari Lynx is named). It reads and writes SRAM, and can even write certain flash carts. The design goal is explicit: marry the plug-and-play ease of the Retrode 2 to the breadth of Sanni's Open Source Cartridge Reader.

One caveat worth flagging in The Machine's usual spirit of pedantry: the page cannot decide what CPU it uses. The opening blurb says "MIPS processor"; further down it says the device has "its own ARM processor and a Linux operating system (Debian)." Both cannot be true. Treat the exact instruction set as unsettled until the thing actually ships, and do not quote either number as gospel.

The buying decision (spoiler: buy the 2)

Here is the part the marketing will not tell you plainly. As of mid-2026 the Retrode3 is not orderable. The hardware is described as finished, the software as in progress, availability as targeted "by the end of the year," and the price as "under 100 EUR" with the exact figure and date still to be confirmed. Where a shopping cart should be, there is a stock-notification signup. So the decision is not really "2 or 3." It is "buy a Retrode 2 now and dump your library," or "wait an unknown number of months for a browser-based successor at an unconfirmed price." If you have carts to preserve and a free evening, the answer writes itself. The rest of this tutorial is therefore about the Retrode 2 — the one that works today — with the Retrode3's open-source repositories noted where they are genuinely useful.

Prerequisites: Hardware, Software, Versions

Hardware you need

The shopping and gathering list is short, and every item earns its place:

• A Retrode 2, ideally on a recent firmware (0.18c stable, or the 0.18d beta 3, both circa 2016 — see the firmware section for why that is the end of the road).
• A USB cable that fits the Retrode's Mini-USB socket, and a real USB-A host port to plug it into. A rear/motherboard port beats a front-panel or bus-powered hub every time; the Retrode draws its power from the bus and an underfed hub causes read errors.
• The cartridges themselves, and the willingness to open a couple of them for cleaning if they are grimy.
• 99% isopropyl alcohol and lint-free swabs. This is not optional hygiene theater. Oxidized cartridge contacts are the single most common cause of a corrupt dump, and a cart that boots fine on real hardware can still hand the Retrode garbage.
• Optional plug-in adapters (€25 / $39.99 each) if you want Game Boy / Game Boy Advance, Nintendo 64, or Sega Master System support on top of the built-in SNES and Genesis slots.

Software and versions

Because the Retrode is a driverless mass-storage device, the baseline software requirement is almost nothing: any modern OS with a USB host port. The official FAQ names Linux, macOS and Windows explicitly, and the device happily mounts on all three without an installer. You will, however, want:

• An emulator to actually play the dumps. RetroArch with the snes9x and genesis_plus_gx cores covers both systems; standalone Snes9x, bsnes, or BlastEm are fine too.
• A firmware-flashing tool, only if you ever update: dfu-programmer on Linux/macOS, or Atmel/Microchip FLIP on Windows.
• A checksum tool — md5sum or equivalent — and a No-Intro DAT file for the systems you are dumping, so you can prove a clean dump instead of hoping for one.

The cartridges: clean before you connect

Do the cleaning as a prerequisite, not a troubleshooting step, because it is far cheaper to spend two minutes with a swab than to dump a 24-megabit ROM twice. Dampen a swab with the 99% isopropyl, run it firmly along the exposed edge connector until the swab comes away without gray residue, and let the alcohol flash off completely — thirty seconds — before inserting. If a cart is truly filthy, a gamebit screwdriver and a proper interior clean is worth it. The Retrode has no error correction whatsoever; it reports exactly the bits the contacts deliver, and dirty contacts deliver lies.

How It Works: Mass Storage and a Fake Gamepad

LUFA, an AVR, and two USB personalities

Under the shell, the Retrode 2 is an AT90USB646 microcontroller speaking USB through Dean Camera's LUFA library. It enumerates as a composite device, which is a fancy way of saying it pretends to be two things at once. One personality is USB Mass Storage: a small removable disk whose "files" are windows onto the inserted cartridge's ROM and SRAM. The other is USB HID: the controller ports show up to your OS as standard gamepads, so a real SNES pad plugged into the Retrode is, to your computer, just another game controller. No driver mediates either role because both classes are part of the USB spec every OS already implements. That is the whole reason this thing works driverless on hardware from 2009 through 2026.

What mounts when you plug it in

Insert a cartridge before connecting USB when you can — the firmware probes the cart at mount time. On Linux, the kernel log and block listing look roughly like this (your exact strings and device letters will differ):

$ dmesg | tail -n 6
usb 1-2: new full-speed USB device number 7 using xhci_hcd
usb 1-2: Product: Retrode
usb-storage 1-2:1.0: USB Mass Storage device detected
scsi 6:0:0:0: Direct-Access     Retrode  Cartridge        PQ: 0 ANSI: 4
sd 6:0:0:0: [sdb] Attached SCSI removable disk

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

A small FAT volume labeled RETRODE appears — a few megabytes, not the size of the ROM, because the files are memory-mapped views rather than a real filesystem. On Windows it shows as a removable drive; on macOS it mounts under /Volumes/RETRODE. There is a status LED on the unit that lights during ROM and RAM access and blinks when the config file is written — a useful, honest heartbeat.

Why there is no install step

People accustomed to modern peripherals keep looking for the driver download. There isn't one, and its absence is a feature. Because the Retrode leans entirely on USB Mass Storage and HID — two of the most universally supported device classes in existence — it will mount on a machine with no internet connection, no vendor software, and no account. That same minimalism is exactly what the Retrode3 is trying to preserve while adding a browser UI: it registers as a USB-Ethernet device so that, again, no driver is required. The philosophy is consistent across both generations: the host OS should already know how to talk to it.

Dumping ROMs: The 12-Step Walkthrough

Before you start

Have your cleaned cartridge, a Retrode connected to a stable rear USB port, and a destination folder ready (~/dumps and ~/saves in the examples). Work from copies on your disk, never live off the mounted volume — reads over the Retrode's USB link are slow, and the mount can drop mid-operation. Here is the sequence, with the reasoning for each step, because a step you understand is a step you can debug.

The twelve steps

1. Power down and inspect the cartridge. Look at the edge connector under a light. Rationale: oxidation and old-cartridge grime are the number-one cause of corrupt dumps, and they are invisible until you look.
2. Clean the contacts with 99% isopropyl and let them dry. Rationale: the Retrode has zero error correction; it faithfully transmits whatever the contacts deliver, so a filthy pin becomes a flipped bit in your ROM.
3. Choose the correct slot. SNES/SFC in the wide upper slot, Genesis/Mega Drive in the shorter lower slot. Rationale: the two slots are wired to different logic; a cart in the wrong slot reads as empty or garbage.
4. Seat the cartridge fully and squarely. Press until it stops, no wobble. Rationale: partial seating reads intermittently, and an intermittent read is worse than no read because it looks like it worked.
5. Connect the Retrode to a rear/motherboard USB port. Avoid unpowered hubs and front-panel headers. Rationale: the device is bus-powered; a brownout mid-read truncates the file silently.
6. Wait for the RETRODE volume to mount. Watch for the drive and the access LED. Rationale: if the volume never appears, nothing downstream can work — fix mounting first.
7. Open the volume and identify the ROM and SRAM files. Rationale: filenames are derived from the cartridge's internal header and can be cryptic or truncated; know which file is the ROM and which is the save before you touch either.
8. Copy the ROM file to local disk. Do not run it in place. Rationale: the mount is slow and can disconnect; copying to disk first turns a flaky live link into a stable local file.
9. Copy the SRAM (.srm) file too, before anything else touches it. Rationale: that file is your save; grab it first so that a later mistake — including one of yours — cannot cost you the only copy.
10. Verify the file size. A correct dump is a sensible ROM size (a power of two or a known cart size). Rationale: a short or oddly sized file is the fingerprint of a bad read; catch it now, not after you have put the cart away.
11. Hash the dump and compare against a No-Intro DAT. Rationale: a matching checksum is proof of a clean, known-good dump. A mismatch means reseat, clean, and redump — it does not mean "close enough."
12. Safely unmount, then remove the cartridge. Eject in software first. Rationale: yanking a mounted FAT volume corrupts the host's view of it, and if you were mid-write to SRAM, it corrupts your save.

Copying and verifying: expected output

Steps 7 through 11 in practice. Note the file permissions in the listing — the ROM is read-only (r--), the save is writable (rw-). That is the ROM/SRAM distinction made visible by the filesystem:

$ ls -l /run/media/$USER/RETRODE/
-r--r--r-- 1 you you 3145728  SUPERMETROID.SFC
-rw-rw-rw- 1 you you    8192  SUPERMETROID.SRM
-rw-rw-rw- 1 you you     289  RETRODE.CFG

$ cp "/run/media/$USER/RETRODE/SUPERMETROID.SFC" ~/dumps/
$ cp "/run/media/$USER/RETRODE/SUPERMETROID.SRM" ~/saves/

$ ls -l ~/dumps/SUPERMETROID.SFC
-rw-r--r-- 1 you you 3145728 SUPERMETROID.SFC     # 3 MiB = 24 Mbit, correct

$ md5sum ~/dumps/SUPERMETROID.SFC
# Compare the result to the No-Intro datfile entry for
# "Super Metroid (USA)". A match proves a clean dump.
# A mismatch means reseat, clean, redump. Not "close enough".

That is the core loop. Everything else in this guide is either a variation on it (saves, other systems) or a way to recover when it goes wrong.

Backing Up and Restoring SRAM Saves

Reading a save is the easy, safe half

For any cartridge with battery-backed memory, the Retrode surfaces a .srm file alongside the ROM. Copying it off is the safe direction and the one you should do reflexively, first, every time — before you even think about writing. A 2 KB, 8 KB, or 32 KB file appears depending on the game; Super Metroid's is 8 KB, as above. Archive these. Battery-backed saves are the most fragile artifact in your collection: they live on a coin cell soldered into a cartridge from the early 1990s, and every one of those batteries is on borrowed time.

Writing a save back: here be dragons

The Retrode's genuinely special capability is that SRAM is writable. Copy a .srm onto the mounted volume and it is written straight into the cartridge's physical save memory. This is how you move a save from an emulator back onto real hardware, or restore a backup to a cart whose battery you just replaced. It is also how you destroy a save you meant to keep, because there is no confirmation and no undo:

# SRAM is WRITABLE. Copying a .srm ONTO the volume overwrites the
# battery-backed save on the physical cartridge. There is no undo.
# You DID back up the on-cart save in the previous step. Right?

$ cp ~/saves/SUPERMETROID.SRM "/run/media/$USER/RETRODE/SUPERMETROID.SRM"
$ sync

# Then EJECT before pulling the cart. Hot-yanking a cart mid-write
# corrupts the very save you just wrote.

By default the firmware ships with saves write-protected — the sramReadonly config key defaults to 1 — specifically because the write path is destructive. You have to deliberately set it to 0 to enable writing, which is the firmware quietly making you sign a waiver. The official user guide is blunt that hot-swapping carts "can potentially damage on-cartridge savegames" and advises you to eject or unplug the Retrode first. Heed it.

Dead batteries and the beta Sega path

Two honesty notes. First: not every cart saves, and a cart with a dead battery has, in the most literal sense, already lost its save — the Retrode will read whatever random bytes the drained SRAM now holds, and there is nothing to recover. Dumping does not resurrect a dead save; it only preserves a live one. Second: Sega SRAM support is, per the official site, still flagged as "under development (beta phase)," and Mega Drive carts vary in their SRAM layout (there is even a segaSram16bit config key for the 16-bit ones). Genesis save backup works for many carts but is less bulletproof than the SNES path. Dump, verify, and keep the emulator save as your primary if you care about it.

Controllers, the SNES Mouse, and Adapters

The controller ports: four players of HID

The 2×2 port bank accepts original SNES pads and Sega 3-button and 6-button pads, up to four players, and presents each to the OS as a USB HID gamepad. This means you can play your dumped ROMs with the exact controller the game was designed for, mapped through your emulator's normal input config — no adapters, no Bluetooth, no latency-adding wireless middleman. It is one of the quietly great features of the device and the reason some people keep a Retrode plugged in permanently as a controller adapter, dumping duties aside.

The SNES mouse lives in the left port

A specific, easily-missed detail that the FAQ calls out explicitly: the SNES mouse is supported, but only in the left controller port. Plug it into the right port and it will not work, and you will waste twenty minutes assuming the mouse is dead. If you are dusting off Mario Paint or Cannon Fodder, left port, every time.

Cartridge adapters: the 32X yes, the Super Game Boy no

Two categories of adapter get conflated and shouldn't be. The first is the plug-in module: official adapter packs (~€25 / $39.99) that extend the Retrode to Nintendo 64, Game Boy / Game Boy Color / Game Boy Advance, and Sega Master System. ROM dumping works across these; save support varies (N64 save support has long been "pending," GB/GBC SRAM works, GBA save handling is partial, and Master System SRAM reading was actually one of the last things added to the firmware).

The second category is cartridge-slot adapters that let an odd cart sit in the existing SNES or Genesis slot and pass its data through. Here the FAQ is precise and restrictive: only the Sega 32X, without its power supply, is confirmed to pass cartridge data through to the Retrode. Devices like the Super Game Boy and the RetroPort do not — they are effectively whole consoles or active converters that don't expose the cart bus the way the Retrode needs. If you were hoping to dump Game Boy carts through a Super Game Boy sitting in the SNES slot, you can't; buy the proper Game Boy plug-in instead.

Firmware: The Frozen 0.18 Line (and the 0.22 Myth)

The official line stopped at 0.18

Let us kill a persistent piece of misinformation before it costs you a bricked afternoon. You will find claims online — and even in the occasional search summary — that a "firmware 0.22 added SNES enhanced-chip support." There is no version 0.22. The official firmware line froze years ago: the last public builds are 0.18c (stable, dated 22 April 2016) and 0.18d beta 3, and mirrors such as Softpedia only list the 0.17 and 0.18 series. The 0.18 changelog covers improved N64 and GBA size detection, a LUFA library update, a Master System plug-in bugfix, and the addition of Master System SRAM reading. That is where development ended. If a guide tells you to flash 0.22, it is describing a file that does not exist; ignore it.

DFU mode and flashing

You will rarely need to touch firmware — a well-functioning Retrode should be left alone — but if you must reflash (to recover a bad update or move between the stable and beta build), the process uses the AVR's built-in DFU bootloader. Enter it by holding the HWB button, tapping RESET, then releasing HWB. The device stops being a drive and reappears as an Atmel DFU bootloader, at which point dfu-programmer (or Atmel/Microchip FLIP on Windows) can talk to it:

# 1. Enter DFU: hold HWB, tap RESET, release HWB. The RETRODE drive
#    vanishes and an Atmel bootloader (USB id 03eb:2ff9) appears.
$ lsusb | grep 03eb:2ff9
Bus 001 Device 012: ID 03eb:2ff9 Atmel Corp. atmega/at90usb DFU bootloader

# 2. Erase, flash the official image, reset back to normal mode.
$ sudo dfu-programmer at90usb646 erase
$ sudo dfu-programmer at90usb646 flash retrode-0.18c.hex
$ sudo dfu-programmer at90usb646 reset

The DFU bootloader lives in silicon and cannot be erased, so a failed flash is recoverable: re-enter DFU and try again. This is the AVR equivalent of the Retrode3's "just flash a new SD card" unbrickability — both generations are designed so you cannot permanently ruin them from software.

What the frozen firmware can't do: SA-1 and friends

The frozen 0.18 firmware has one hard limitation worth memorizing, because it is where people get burned. Games that carry certain enhancement coprocessors on the cart do not dump into a runnable ROM. Specifically: SA-1 (as in Super Mario RPG, Kirby Super Star, Kirby's Dream Land 3), S-DD1 (Star Ocean, Street Fighter Alpha 2), and the Sega Virtua Processor (Virtua Racing) are not supported. Crucially, this is not a blanket rule about "special chip" games — the confusion the phantom 0.22 firmware trades on. SuperFX games (Star Fox, Yoshi's Island) and DSP1 games (Pilotwings, Super Mario Kart) dump perfectly, because the chip's behavior is reconstructed by your emulator, not the dumper. The Retrode just needs to read the ROM; SuperFX and DSP1 ROMs read fine. SA-1, S-DD1 and SVP change how the ROM itself is addressed, and the frozen firmware never learned those maps. For those handful of titles, a more actively developed dumper — Sanni's Open Source Cartridge Reader, on which the Retrode3 is built — is the better tool.

Loading Your Dumps Into Emulators

RetroArch and the right cores

Once a ROM is on disk and its checksum matches, the Retrode's job is done and your emulator's begins. In RetroArch, load the SNES dump with a Super Nintendo core (snes9x is the safe default) and the Genesis dump with genesis_plus_gx. From the command line:

$ retroarch -L ~/.config/retroarch/cores/snes9x_libretro.so ~/dumps/SUPERMETROID.SFC

# Mega Drive / Genesis dumps use the genesis_plus_gx core:
$ retroarch -L ~/.config/retroarch/cores/genesis_plus_gx_libretro.so ~/dumps/SONIC2.BIN

# Put the matching .srm next to the ROM so the core finds your save.

If you are new to RetroArch's core zoo — which core, which system, how to keep them updated — our companion walkthrough on installing 200+ RetroArch cores in 12 steps is the fastest way from a fresh install to a working library. The Retrode gives you legally-clean personal dumps; RetroArch turns them into playable games.

Standalone emulators and save compatibility

You are not obligated to use RetroArch. Snes9x, bsnes/higan, and BlastEm all load Retrode dumps directly, and all read the same .srm save format the Retrode produces — which means the loop closes: dump a save off the cart, play on your PC, and (if you dare, and set sramReadonly 0) write the progressed save back to the physical cartridge. If you would rather skip PC emulators and drop your dumps onto a dedicated OS, Batocera 43.1 boots to a couch-friendly frontend that ingests a folder of ROMs and sorts them by system automatically.

Beyond the PC: handhelds and FPGA

Your Retrode dumps are just files, so they travel. Copy them to a handheld and they play in your pocket — a cheap Miyoo Mini Plus will happily run your SNES and Genesis dumps, and RetroPie on a spare Raspberry Pi does the same on a TV, though as we cover in the RetroPie 2026 status report, that project has its own frozen-in-amber problems not unlike the Retrode's. And if you want your legally-dumped ROMs run with cycle-accurate fidelity instead of software approximation, an FPGA platform like the MiSTer Multisystem 2 reproduces the original hardware in programmable logic. The through-line: the Retrode preserves the bytes once, and every other platform in your house consumes them.

Five Pitfalls That Ruin Dumps

Contacts, connectors, and power

The first and by far most common pitfall is treating cleaning as optional. Pitfall 1: dirty contacts. A cart that boots on a real SNES can still hand the Retrode a corrupt dump, because your console's connector has decades of self-cleaning wear the Retrode's does not. Fix: 99% isopropyl, swab until clean, dry fully. Pitfall 2: flaky power. Bus-powered off a cheap hub, the Retrode browns out mid-read and truncates files silently. Fix: a rear motherboard USB port, direct, every time.

Expecting it to do things it can't

Pitfall 3: expecting playback. It bears repeating because people keep buying the Retrode as a console — it is not an emulator, it produces files, and something else runs them. Pitfall 4: the coprocessor trap. Assuming every "special chip" game either works or fails identically. SuperFX and DSP1 dump fine; SA-1, S-DD1 and SVP do not. Know which of your carts are which before you conclude the Retrode is broken — it isn't, it just never learned those three memory maps. And the phantom "0.22 firmware" that supposedly fixes this does not exist, so do not go hunting for it.

Adapters and the destructive save write

Pitfall 5: unsupported adapters and the one-way save write. Two failure modes bundled together. First, cartridge-slot passthroughs: only the Sega 32X (no PSU) is confirmed to pass data; a Super Game Boy or RetroPort will read as nothing, and that is expected, not a fault. Second — the expensive one — remember that copying a .srm onto the mounted volume overwrites the physical cartridge save with no undo. The default sramReadonly 1 exists to stop you doing this by accident; the moment you set it to 0 to enable writing, you own the consequences. Always back the on-cart save up first.

The Troubleshooting Table

How to read it

Symptoms on the left, the usual cause in the middle, the fix on the right. Work top to bottom — the early rows (power, seating, cleanliness) resolve the large majority of real-world Retrode problems, and the later rows only matter once the drive reliably mounts.

The table

When to give up on the Retrode

There is a small, honest set of jobs the Retrode 2 simply is not the tool for: the SA-1/S-DD1/SVP titles, exotic mappers, and anything needing active development the frozen firmware will never receive. For those, the modern answer is the same codebase the Retrode3 is built on — Sanni's Open Source Cartridge Reader. Knowing when to switch tools is not defeat; it is the difference between an archivist and someone reseating a cartridge for the ninth time.

Advanced Tips and a Complete Config

Batch dumping and scripting

Because the Retrode presents plain files on a plain FAT volume, you can script around it like any other drive. A minimal batch pattern: insert a cart, run a one-liner that copies whatever ROM and save are currently present into a named folder, verify, then swap carts. On Linux/macOS:

#!/bin/sh
# quick-dump.sh — copy whatever cart is currently mounted, then hash it.
SRC="/run/media/$USER/RETRODE"
DEST="$HOME/dumps/$(ls "$SRC" | grep -Ei '(sfc|smc|bin|gen|md)$' | head -1 | cut -d. -f1)"
mkdir -p "$DEST"
cp "$SRC"/*.[Ss][Ff][Cc] "$SRC"/*.[Bb][Ii][Nn] "$DEST" 2>/dev/null
cp "$SRC"/*.[Ss][Rr][Mm] "$DEST" 2>/dev/null
md5sum "$DEST"/* > "$DEST/checksums.md5"
echo "Dumped to $DEST — now verify checksums.md5 against No-Intro."

Remember the hard rule that makes this safe: this script only ever reads from the volume. The instant a script copies to the volume, it is writing SRAM, and you want a human's finger on that trigger, not a loop.

The Retrode3 repos, for the impatient

If you would rather build the future than wait for it, the Retrode3's software is genuinely open and public across four repositories — the Debian userspace (retrode3), the kernel (retrode3-kernel), the hardware design files (retrode3-hardware), and the piece most people want, the retrode3-oscr Linux command-line adaptation of Sanni's Open Source Cartridge Reader. Between those repos and an OSCR you build yourself, you can have most of the Retrode3's dumping capability today, on hardware you already understand — including the SA-1/S-DD1 titles the Retrode 2 can't touch. It is more work than plugging in a Retrode 2, which is exactly why the Retrode 2 still exists.

A complete config to end on

Finally, the RETRODE.CFG that lives on the volume. One firm caveat, in keeping with this site's allergy to fabricated precision: the file below is illustrative of the format. The key names are the real ones the 0.18 firmware uses, but the authoritative, fully-commented copy is the one already sitting on your own Retrode — edit that file, and let its own comments override anything here. The access LED blinks when the firmware writes the config, so you will know it took.

; ------------------------------------------------------------------
; RETRODE.CFG  — illustrative of FORMAT, not a spec.
; The authoritative copy is the commented file already on your
; Retrode's own volume. Edit THAT one. The key NAMES below are real
; (0.18 firmware); the values shown are sane defaults.
; ------------------------------------------------------------------

; --- Saves ---
sramReadonly   1      ; 1 = protect on-cart saves (default). 0 = allow WRITE.
segaSram16bit  0      ; set 1 for Mega Drive carts with 16-bit SRAM

; --- Detection / forcing ---
forceSystem    auto   ; auto | SNES | GENESIS | GG | ...
forceSize      auto   ; auto, or an explicit ROM size if detection is wrong
forceMapper    auto   ; auto | lorom | hirom   (SNES addressing)
detectionDelay 0      ; increase slightly if a cart mounts unreliably

; --- File naming ---
filenameChksum 0      ; 1 = append a checksum to the output filename
snesRomExt     SFC    ; extension for SNES ROM files
segaRomExt     BIN    ; extension for Sega ROM files
sramExt        SRM    ; extension for save files

That is the whole discipline of the Retrode in one screen: protect the saves by default, let the firmware auto-detect unless it is demonstrably wrong, name files predictably, and verify everything against a known-good database. Do that, and a stack of thirty-year-old cartridges becomes a folder of checksummed, archived, playable files — which is the only kind of preservation that survives the next dead coin cell. The Retrode3 will make this prettier when it ships. The Retrode 2 makes it real tonight.