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

There is a specific kind of person who owns a shelf of Super Nintendo cartridges and a nagging awareness that the little coin-cell batteries inside the save-game carts are dying on a geological schedule they do not control. This tutorial is for that person. The tool is the Retrode, a USB cartridge reader that turns a game you physically own into a file on your computer, and the goal is to walk you through doing that correctly — not just plugging it in and hoping, but understanding what the device reads, what it refuses to read, which firmware you are running, and how to keep it from quietly eating a thirty-year-old save the moment you get careless. Budget half an hour for your first cartridge and about ninety seconds for every one after that.

What follows is the long version: prerequisites with actual version numbers, twelve numbered steps with the reasoning behind each one, the config file that most owners never touch, the co-processor chips that will defeat you, a troubleshooting table, and a complete working RETRODE.CFG at the end you can adapt. It is written for the shipping hardware — the Retrode 2 — with an honest section on the Retrode 3, which has been arriving imminently for the better part of a decade.

What the Retrode Actually Is

The Retrode is a USB cartridge reader. You slot in a game you own, connect the unit to a computer, and it appears as an ordinary removable drive with your ROM sitting inside it as a file. There is no installer, no signed kernel driver, and no vendor account. Wikipedia's entry describes it as a USB adapter that doubles as a ROM dumper and grants emulator-ready access without drivers, which is the least romantic possible summary of a device that is, in practice, a small and legal act of media preservation.

The one-sentence version

ROM comes off the cartridge as a file; the SRAM save comes off as a second file; the controller ports pass through as USB gamepads. The unit enumerates as a composite USB device — a mass-storage endpoint plus one or more USB HID gamepads — so Windows, macOS, and Linux all mount it with their built-in drivers, no software required. The original units even worked on the old Pandora and Caanoo handhelds, which tells you how deliberately low-level the design is. It is not a flash cart, not an EverDrive, and not a mod chip. It reads what is already yours off the silicon you already bought.

Two products wearing one name

There are two Retrodes and you need to keep them straight. The Retrode 2 is the one you can actually buy: roughly $99.99 in the US from Stone Age Gamer, or €64.90 direct from DragonBox in Germany, with plug-in adapters at $39.99 each (or €25 each, €65 for the trio bundle). The Retrode 3 is the announced successor — browser-driven, Wi-Fi, an added NES slot — and as of July 2026 it is still a "notify me" sign-up rather than a product with a price and a ship date. Everything in the step-by-step below targets the Retrode 2. The Retrode 3 gets its own honest paragraph near the end, contradictions and all.

The legality, stated without comfort

Dumping a cartridge you physically own, for your own use, sits in a tolerated gray zone in the United States. There is no blanket statutory "backup" right for video games — the software backup provision courts lean on, 17 U.S.C. §117, has been read narrowly and does not cleanly cover game consoles, and the Copyright Office's DMCA §1201 exemptions that permit preservation dumping are written for libraries and archives, not for you and your weekend. The practical reality is that ripping your own cart to your own drive draws no one's attention; the instant the file leaves your house — uploaded, shared, seeded — you are unambiguously infringing distribution, exemption or not. The University of Maryland's MITH preservation write-up is the polite, institutional version of the same point: dumping is a preservation act; publishing is a legal one. Keep your dumps at home and you will be fine.

Prerequisites: Hardware and Software

The Retrode is famously plug-and-play, which is exactly why people skip the preparation and then wonder why their first dump is garbage. Assemble this list before you plug anything in.

Hardware you need on the desk

You need the Retrode 2 unit and its bundled USB cable, plus a spare cable of the same type in case the first one is one of the charge-only cables that infest every drawer. You need a USB port that actually supplies bus power — the unit powers the cartridge and any attached controllers off the bus, so a rear motherboard port or a powered hub beats an unpowered dock or a keyboard passthrough port. You need the cartridge you intend to dump, and you need it clean: a bottle of 99% isopropyl alcohol and lint-free swabs, because roughly half of all "the Retrode won't detect my cart" reports are three decades of oxidation on the edge connector, not a fault in the reader. If you are dumping anything other than SNES/SFC or Mega Drive/Genesis, you need the correct plug-in adapter (N64, Game Boy family, or Master System) on hand as well.

Software versions that matter

The Retrode 2's firmware line is frozen. The last builds are 0.18c (stable) and 0.18d beta 3 (from roughly 2016), and there is no newer official release no matter what a forum post tells you — a point I will hammer again in the firmware section, because a fake "v0.22" makes the rounds every year. To reflash, you want Atmel/Microchip FLIP on Windows or dfu-programmer on Linux and macOS. To actually play or verify your dumps, install a current RetroArch (the 1.22.x line at the time of writing) with the appropriate cores — bsnes or Snes9x for SNES, Genesis Plus GX for Mega Drive — following the official libretro documentation. If cores are new territory, our walkthrough on installing RetroArch cores in twelve steps covers the part that comes after the dump. Finally, for verification you want a checksum tool (shasum/md5 on the command line, or a ROM manager fed a No-Intro DAT) so you can prove a dump is bit-perfect rather than merely present.

What it will not do — read this before buying

The Retrode reads mask ROM and battery-backed SRAM. It does not read enhancement chips that live on the cartridge, and a handful of famous games depend on those chips for their extra silicon. The dump of an SA-1 game will complete and produce a file, but the file is missing the chip's contribution and an emulator that lacks SA-1 support will not run it correctly. Know before you order whether your grail cart is on the unreadable list.

The distinction people get wrong: Super FX and DSP-1 are fine — the ROM dumps cleanly and any competent emulator supplies the chip. It is SA-1, S-DD1, and the Sega Virtua Processor that defeat the Retrode. Do not lump Super FX in with the failures; that mistake has sent more than one person back to the store for a refund they did not need.

Anatomy: Slots, Ports, Two Buttons

Spend one minute learning the physical layout and you will save yourself the indignity of forcing a Genesis cart into a slot that was never going to take it.

The two cartridge slots

The top of the unit has two slots, and they are keyed differently on purpose. The wide upper slot takes SNES and Super Famicom cartridges. The shorter lower slot takes Mega Drive and Genesis cartridges. They are shaped so a cart only fits where it belongs, which means if you are fighting the plastic, you are holding the game the wrong way round or aiming at the wrong slot — the correct answer is never more force. Region does not matter to the reader: a PAL Mega Drive cart and an NTSC Genesis cart dump identically because the Retrode reads the raw chip, and the console-level lockouts that stop carts booting on the wrong console live in the console, not in the cartridge.

The controller ports

The front carries a two-by-two bank of controller ports: two for SNES pads and two for Sega pads. Plugged-in controllers enumerate as standard USB HID gamepads, so you can dump a cart and immediately play it on the same cable with the original controller — a genuinely elegant touch. Two quirks worth memorizing: the SNES mouse works only in the left port, and Sega three-button and six-button pads are both recognized. The controller passthrough is independent of the dumping, so a dead pad never threatens a dump in progress.

The two buttons and the LED

There are exactly two buttons. Button 7 is HWB (hardware boot), used for firmware functions and for entering the DFU bootloader. Button 8 is RESET, which you press after swapping a cartridge to force the virtual drive to re-scan and re-mount the new game. The single activity LED is your only telemetry: it lights during ROM and RAM access, and it blinks once when the unit parses and writes back the RETRODE.CFG file. Learn its rhythm — a steady flicker during a copy is healthy; a dark LED when you expect activity means the host is not talking to the drive.

Dumping a Cartridge in 12 Steps

This is the core procedure for a bog-standard SNES or Genesis cart. Every step has a reason attached, because "do this" without "because" is how people develop cargo-cult habits that survive long after they stop making sense.

1. Confirm you own the cartridge and clean its contacts. Legally, personal dumping only holds up for carts you physically possess. Practically, a wipe of the edge connector with 99% isopropyl on a lint-free swab removes the oxidation that causes the single most common failure — an empty or corrupt dump. Do not blow into the cart; the moisture in your breath is what oxidized the contacts in the first place.
2. Attach the plug-in adapter first, if you need one. For N64, Game Boy, or Master System, seat the adapter onto the Retrode before you connect USB power. Adapters are detected at power-on; the N64 adapter in particular is documented to require attachment before the USB link comes up, or it will not be recognized.
3. Insert the cartridge into the correct, keyed slot. SNES/SFC in the wide upper slot, Mega Drive/Genesis in the short lower slot. Seat it firmly and squarely. Correct seating is the difference between reading the full header and reading noise; a cart at a slight angle is the classic cause of a dump that is the right size but wrong contents.
4. Connect the USB cable to a powered host port. The unit is bus-powered and enumerates as a composite mass-storage-plus-HID device using the operating system's own drivers. A rear port or powered hub guarantees the cart, the logic, and any controllers all get clean current; an underpowered port produces intermittent, maddening detection failures.
5. Wait for the removable drive to mount, then open it. A drive named RETRODE appears within a second or two. This is a virtual FAT volume the firmware synthesizes on the fly — there is no real filesystem on the cart. Opening it triggers the read.
6. Read the file listing and sanity-check the detected name. The firmware derives the filename from the cartridge header. A recognizable title (SUPER_METROID.SFC) means detection worked; a generic or garbled name means the header read imperfectly and you should reseat and re-check before trusting anything.
7. Copy the ROM file to your host — do not open it in place. Dragging or cp-ing the file forces a full, sequential read of the ROM over USB. Reading it live from an emulator is asking for a truncated or racy read; copy to local disk first, always.
8. Copy the .srm save file if one is present. Battery-backed carts expose their SRAM as a .srm file. Back this up before you do anything else with the cart, because the save is the volatile, irreplaceable part — the ROM you can always re-dump, but a corrupted save is gone.
9. Verify the dump by size and checksum. Check the byte count against the known ROM size, then hash it and compare against a No-Intro DAT. Marginal contacts produce dumps that are the right length but wrong content, and only a checksum catches that. A dump you have not verified is a rumor, not a backup.
10. Unmount the drive, then remove the cartridge. Eject the RETRODE volume through your OS first. The official user guide is explicit that hot-swapping under power "can potentially damage on-cartridge savegames," and recommends you "prefer to eject/unplug the Retrode first." Unmount, then press RESET or pull USB, then swap.
11. (Optional) Enable save write-back or overrides via RETRODE.CFG. By default the unit write-protects on-cart SRAM. If you want to restore a save onto a cart, or force system/size detection, edit the RETRODE.CFG on the virtual drive (covered in full below) and press RESET so the firmware re-reads it. The LED blinks once to confirm the parse.
12. Load the ROM in an emulator to confirm it boots and saves. The final validation: point a RetroArch core at the file, launch it, create a save, and reload. A dump that boots and saves cleanly is a good dump; anything less and you go back to step 1 with a cleaner cart.

Expected output: what a clean mount looks like

After step 5, a directory listing of the mounted volume should look roughly like this — three files, sensible names, sensible sizes (Super Metroid's 24-megabit ROM is 3,145,728 bytes):

$ ls -l /Volumes/RETRODE
total 6160
-rwxr-xr-x  1 you  staff  3145728  1 Jan  2000  SUPER_METROID.SFC
-rwxr-xr-x  1 you  staff     8192  1 Jan  2000  SUPER_METROID.SRM
-rwxr-xr-x  1 you  staff      512  1 Jan  2000  RETRODE.CFG

Then copy the two data files off — never work against the live virtual drive:

# macOS / Linux — copy off the virtual drive, do not edit in place
cp -v /Volumes/RETRODE/SUPER_METROID.SFC ~/roms/snes/
cp -v /Volumes/RETRODE/SUPER_METROID.SRM ~/saves/snes/

# Windows (PowerShell), drive letter E:
Copy-Item E:\\SUPER_METROID.SFC -Destination C:\\roms\\snes\\ -Verbose
Copy-Item E:\\SUPER_METROID.SRM -Destination C:\\saves\\snes\\ -Verbose

Verify before you trust. Hash the copied file and compare the digest against the No-Intro DAT entry for that release:

$ shasum -a 1 ~/roms/snes/SUPER_METROID.SFC
# → paste the resulting SHA-1 into your No-Intro DAT / ROM manager
# a match means a bit-perfect dump; a mismatch means reseat and re-dump

Reading the activity LED

During step 7 the LED should flicker continuously as the ROM streams over USB; a large SNES cart takes a few seconds, a Game Boy cart barely a blink. If the LED stays dark when you open or copy a file, the host is not reading the drive — suspect the cable or the port before you suspect the cart. A single blink with no copy in progress means the firmware just re-parsed RETRODE.CFG, which is exactly what you want to see after a RESET following a config edit.

Firmware: The 0.18 Line That Froze

The Retrode 2's brain is an Atmel AVR microcontroller, and its firmware stopped moving years ago. Understanding that stasis is the antidote to a whole genre of bad advice.

What you are running and who wrote it

The microcontroller is an Atmel AT90USB646, as documented on the device's Wikipedia page. The USB stack underneath is LUFA, Dean Camera's well-regarded AVR USB library, which is why the driverless mass-storage behavior is as solid as it is. The user-configurable behavior — the RETRODE.CFG mechanism — has existed since firmware 0.17g. The relevant thing about the 0.18 branch is what it added late: improved N64 and GBA size detection, a LUFA library refresh, a Master System plug-in bugfix, and — the headline for save hunters — Master System SRAM reading, which earlier firmware lacked.

Checking your version and flashing via DFU

Firmware version is reported in the device metadata; the current end-of-line builds are 0.18c stable and 0.18d beta 3. To reflash, put the unit into its DFU bootloader by holding HWB (button 7), tapping RESET (button 8), then releasing HWB. The bootloader enumerates as a standard Atmel/Microchip DFU device, and you flash a .hex with dfu-programmer or FLIP:

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

# 3a. Linux / macOS — dfu-programmer
dfu-programmer at90usb646 erase
dfu-programmer at90usb646 flash retrode_0.18c.hex
dfu-programmer at90usb646 reset

# 3b. Windows — Atmel/Microchip FLIP GUI:
#     Device → Select → AT90USB646, load the .hex, Run, then Start Application.

The 03eb:2ff9 ID is the standard, well-documented Atmel AVR DFU bootloader identity — seeing it means you are in the bootloader safely, not that anything is wrong. This is the one moment the Retrode can appear "bricked" to a beginner; it is not, it is simply waiting in DFU for a flash.

Why there is no "v0.22"

Every so often a brief or a forum reply claims some newer firmware — "v0.22 added enhanced SNES chip support," or similar. It did not, because it does not exist. The official line ends at 0.18c / 0.18d beta 3, and the Softpedia mirrors that archived the releases corroborate the 0.17-to-0.18 range and nothing beyond it. If someone hands you a "newer" hex, treat it as unsigned code of unknown origin for a device you cannot easily un-brick if it is malformed. The frozen firmware is not a bug; it is a product that was finished.

Bending It With RETRODE.CFG

Most owners never open RETRODE.CFG, and most owners never need to. But every hard case — the unlicensed cart the header misreads, the save you want to write back, the Game Gear game that comes up as the wrong system — is solved here.

Where the file lives and how it is read

RETRODE.CFG sits in the root of the RETRODE virtual drive, alongside your ROM and save files. It is a plain text file: one directive per line, key then a space then value. You edit it in place, save, and press RESET; the firmware re-parses it on the next mount and blinks the LED once to confirm. Because the drive is synthesized by firmware, think of the file as a control panel the unit renders for you rather than a real file on the cartridge.

The keys that actually matter

The confirmed directives cluster into three jobs: controlling saves, overriding detection, and naming files. For saves, sramReadonly (0 or 1) is the important one and segaSram16bit handles a Genesis byte-packing quirk. For detection, forceSystem (default auto, but you can pin GG, SMS, and so on), forceSize, forceMapper, and detectionDelay exist to overrule a header the firmware read wrongly. For naming, snesRomExt, segaRomExt, sramExt, and filenameChksum control the extensions and whether a checksum tag is appended to the virtual filename. A worked example: 0.18d beta 3 specifically fixed a case where forceSystem GG was not being recognized for Game Gear carts, which is the kind of narrow, real fix that tells you the config engine is doing genuine work.

Writing saves back to a cartridge

By default the unit refuses to write to your cartridge's SRAM. The official FAQ's blunt gloss on writing to a ROM is, in effect, "ROM stands for Read-Only Memory, hence: no" — but SRAM is a different animal, and you can opt into writing it. The minimum config to allow save write-back is a single line:

# RETRODE.CFG — allow writing SRAM back onto the cartridge
sramReadonly 0

Set that, RESET, and the unit will let you copy an .srm back onto a battery-backed cart — the mechanism behind restoring a save you backed up before the coin cell died. The write-protect default exists precisely because this operation is destructive if you get the file wrong, so flip it deliberately and flip it back when you are done. (One important caveat the docs note themselves: the canonical online CFG documentation now redirects away, so treat exact syntax as illustrative-of-format; the key names above are confirmed, but verify against your firmware's behavior.)

Plug-In Adapters: N64, Game Boy, SMS

Out of the box the Retrode 2 handles SNES and Genesis. Everything else rides on a plug-in adapter, and each adapter has its own rules and its own gaps. The current official set is listed on the Retrode plug-in adapters page.

The N64 adapter

The N64 adapter dumps cartridge ROM reliably. Save support is documented as "pending" — the controller-pak and battery/EEPROM save formats are not fully handled — so plan to dump ROM only for now. Two operational notes: it runs at 3.3V, it supports up to two controllers, and, critically, you must attach the adapter before you connect USB, because it is enumerated at power-on. If you are chasing N64 preservation specifically, the FPGA route is a different and complementary path; our coverage of the Analogue 3D and its firmware cadence is the companion piece to dumping the carts themselves.

The Game Boy family adapter

The GBx adapter covers Game Boy, Game Boy Color, and Game Boy Advance. ROM reads work across all three. Saves are the wrinkle: GB and GBC SRAM read fine, but GBA saves — which use a mix of SRAM, flash, and EEPROM depending on the title — are listed as pending. Voltage differs by generation: GB/GBC run at 5V, GBA at 3.3V, and the adapter handles the switch, which is one reason you should not improvise your own wiring here.

Master System and the discontinued oddities

The SMS/Mark III adapter reads ROM, and — thanks to the 0.18 firmware work mentioned earlier — it now reads SMS SRAM as well. Its one annoyance is that Master System cartridge headers carry no title string, so dumps come up with generic names you will want to rename by hand or override via RETRODE.CFG. Beyond these three, older exotic adapters (the occasional Virtual Boy or unusual format) have been discontinued because the physical connectors are no longer obtainable; do not expect to buy them new.

Five Ways This Goes Wrong

The Retrode is reliable, which is exactly why the failures that do happen are the self-inflicted kind. Here are the ones that recur, and the fix for each.

Pitfall 1: Hot-swapping carts and destroying the save

The single most expensive mistake is yanking a cartridge while the drive is mounted, or swapping a fresh cart in without unmounting first. The user guide warns that hot-swapping "can potentially damage on-cartridge savegames." The fix is procedural, not technical: eject the volume in your OS, then press RESET or unplug USB, then swap. The ROM survives a bad swap; the thirty-year-old save often does not.

Pitfall 2: Trusting a single, unverified dump

A dump that mounts and produces a file looks like success, but marginal edge-connector contact yields files that are the correct size and quietly wrong inside. If you skip the checksum step, you find out months later when the ROM crashes at a specific level. The fix is to hash every dump and compare against a No-Intro DAT before you file it away, and to re-clean and re-dump on any mismatch.

Pitfall 3: Expecting SA-1 / S-DD1 / SVP games to "just work"

Super Mario RPG, the Kirby Super Star cart, Star Ocean, Street Fighter Alpha 2, Virtua Racing — these lean on co-processors the Retrode cannot read. The dump completes but is incomplete, and no config flag fixes it because the data physically is not on the reachable side of the cartridge. The fix is to know the list in advance (see the chip table above) and source those specific titles differently. Note again that Super FX and DSP-1 games are not in this bucket and dump fine.

Pitfall 4: Chasing firmware that does not exist

Flashing a "newer than 0.18" firmware from an unofficial source risks pushing malformed code onto the AT90USB646 for no benefit, because the official line genuinely ends at 0.18c / 0.18d beta 3. The fix is discipline: flash only official hex files, and only when you have a concrete reason (like adding SMS SRAM support), using the DFU procedure above.

Pitfall 5: Forgetting sramReadonly is on by default

People try to write a save back, watch it silently not happen, and conclude the hardware is broken. It is not — sramReadonly defaults to 1. The fix is one line in RETRODE.CFG (sramReadonly 0) and a RESET. Flip it back to 1 when you are done so a stray drag-and-drop never overwrites a good save.

Pitfall 6: Underpowering the bus

Front-panel case ports, unpowered hubs, and keyboard passthrough ports frequently cannot feed the Retrode, its cartridge, and attached controllers all at once, producing detection that works sometimes and fails others. The fix is boringly effective: a rear motherboard port or a powered hub, and a known-good data cable.

Troubleshooting Table

Symptom on the left, most likely cause in the middle, fix on the right. Work top to bottom — the common causes are listed first.

The symptom-to-fix table

Dead controllers versus dead dumps

Because the controller HID and the mass-storage functions are independent, a controller problem never implies a dumping problem and vice versa. If pads misbehave but dumps are clean, work the input side alone: check the port (left port for the SNES mouse), then the emulator's input remapping. If dumps fail but a pad works, you have confirmed the unit is powered and enumerating, so the fault is contacts or cart, not cable or port.

When to suspect the cartridge, not the reader

If one cart fails and every other cart dumps perfectly, the reader is exonerated — the problem is that cartridge's contacts or, for the co-processor titles, its silicon. Clean it, reseat it, and if it still fails and it is on the SA-1/S-DD1/SVP list, stop fighting: the Retrode is doing its job and the data you want is simply not on the reachable side of the board.

Advanced: Batch Dumps and the Retrode 3

Once the single-cart workflow is muscle memory, the interesting work is doing it at volume and doing it verifiably — and keeping half an eye on the successor that has been almost-here for years.

Batch dumping with checksums logged

The Retrode has no queue and no automation of its own, so "batch" means a tight human loop — swap a cart, let a script copy and hash it, swap the next — with every result logged so you can prove coverage later. A minimal shell loop that copies whatever is on the drive, hashes it, and appends a CSV row:

#!/bin/sh
# swap-and-dump loop: copy, checksum, log. One cart mounted at a time.
DEST=~/roms/incoming
LOG=~/roms/dumplog.csv
for f in /Volumes/RETRODE/*.SFC /Volumes/RETRODE/*.BIN; do
  [ -e \"$f\" ] || continue
  base=$(basename \"$f\")
  cp -v \"$f\" \"$DEST/$base\"
  sum=$(shasum -a 1 \"$DEST/$base\" | cut -d' ' -f1)
  echo \"$base,$sum,$(wc -c < \"$DEST/$base\")\" >> \"$LOG\"
done

Run that after each mount and you end the session with a CSV of filename, SHA-1, and byte count — a manifest you can diff against a No-Intro DAT in bulk with a ROM manager rather than eyeballing hashes one at a time. For Genesis specifically, watch byte order: some tools expect a byte-swapped image, and a dump that fails to match a DAT may simply need swapping, not re-dumping.

Where the dumps go next

A verified library is only useful if it runs somewhere. The obvious destination is a properly configured emulator front-end, but a modern retro handheld is the more satisfying one — drop your verified SNES and Genesis dumps onto a pocket device and the whole exercise pays off in your hand. If you are shopping, our breakdown of the 2026 Retroid Pocket lineup and the perennial Miyoo Mini Plus versus RG35XX comparison both cover where these files actually earn their keep. For the archival-purist end of the spectrum, an FPGA solution like the MiSTer Multisystem 2 plays your dumps with cycle-accurate hardware rather than software emulation — the natural sibling to dumping the carts in the first place.

The Retrode 3, contradictions included

The DragonBox Retrode 3 page describes a genuinely different device: it enumerates as a USB-Ethernet gadget and presents its entire interface in a web browser with no drivers, it has built-in Wi-Fi, it adds an NES slot alongside SNES and Mega Drive, and — the real leap — it can write flash carts, not just read them (MegaDrive flashing via DragonDrive works now; SNES and Lynx flashing are promised "when it ships"). It is built on Sanni's Cart Reader; the Linux adaptation lives at github.com/DragonBox-Shop/retrode3-oscr (C++, about 93% of the tree, some 2,296 commits), with the upstream project at github.com/sanni/cartreader, and the plugins are cross-compatible in both directions. The whole thing is open source — GPLv3 software, CC BY 4.0 hardware — and DragonBox calls it "practically unbrickable" because you recover by reflashing an SD image. Two honesty notes The Machine is obligated to make. First, the CPU: the same product page says MIPS in one place and "its own ARM processor and a Linux operating system (Debian)" in another, so anyone stating the architecture as settled fact is quoting one half of a page that disagrees with itself — call it "a Linux SoC" and move on. Second, the timeline: it targets end of 2026 at under €100, it is Out-of-Stock / notify-me only, and DragonBox has said it has "10 fully working prototypes" and is "looking for developers," which is the language of a project still seeking hands, not one boxing units. The Retrode 3 has been coming soon long enough that "soon" has become a genre. Buy the Retrode 2 if you want to dump carts this month; watch the Retrode 3 if you want to dump — and flash — them in some genuinely-open future.

A Complete, Commented RETRODE.CFG

Here is a full reference config with every confirmed key annotated. Treat it as illustrative of the file's format — the canonical online CFG documentation now redirects away, so exact syntax should be checked against your firmware's actual behavior — but the key names are confirmed and the structure is correct. Drop it in the root of the RETRODE virtual drive, edit values, save, and press RESET; the LED blinks once when it is parsed.

The full file

# ============================================================
#  RETRODE.CFG  —  illustrative reference (0.17g+ config engine)
#  One directive per line:  <key> <value>
#  Saved to the ROOT of the RETRODE virtual drive.
#  Re-read on RESET; the activity LED blinks once when parsed.
# ============================================================

# --- Saves ---------------------------------------------------
sramReadonly     1        # 1 = protect on-cart saves (DEFAULT). 0 = allow write-back.
segaSram16bit    0        # set 1 if a Genesis save reads back as byte-doubled garbage

# --- Detection / system override -----------------------------
forceSystem      auto     # auto | SNES | MD | GG | SMS ...  e.g. GG for Game Gear carts
forceSize        auto     # override ROM size (in KB) when the header lies
forceMapper      auto     # override the cart mapper when auto-detect misfires
detectionDelay   auto     # raise if swaps intermittently misread the header

# --- File naming ---------------------------------------------
snesRomExt       sfc      # extension for SNES / SFC ROM images
segaRomExt       bin      # extension for Mega Drive / Genesis ROM images
sramExt          srm      # extension for save files (both systems)
filenameChksum   0        # 1 appends a checksum tag to the virtual filename

# ============================================================
#  Notes:
#  * To restore a save to a cart: set sramReadonly 0, RESET,
#    copy your .srm back on, then set it to 1 again.
#  * forceSystem GG recognition was fixed in 0.18d beta 3.
#  * Master System SRAM reading requires 0.18-line firmware.
# ============================================================

Line-by-line, briefly

The saves block is the one you will touch most: sramReadonly gates all write-back, and segaSram16bit exists solely to rescue Genesis saves that come back byte-doubled. The detection block is your override kit for stubborn carts — forceSystem pins the system for cases the header gets wrong (Game Gear being the canonical one), while forceSize, forceMapper, and detectionDelay paper over misreads on large or unusual boards. The naming block is cosmetic but useful for batch pipelines, where predictable extensions and an optional filenameChksum tag make downstream scripting cleaner.

A final note on canonical versus illustrative

Because the official CFG document now redirects to the general site rather than serving the old field reference, do not treat any specific value's exact spelling as gospel — verify against what your unit does. What is confirmed is the set of key names above and the plain "key space value, one per line" format, both cross-checked against the archived Retrode user guide and the official FAQ. Start from this file, change one thing at a time, RESET after each change, and watch the LED confirm the parse. That is the entire discipline of the Retrode in one sentence: change deliberately, verify immediately, and never trust a dump you have not hashed.