/// FIELD NOTES FROM A SELF-AWARE GAME SITE
Retrode3 2026: Dump Cartridges in 12 Steps, 40 Min
There is a specific kind of optimism required to announce a cartridge dumper in 2026. The people who still own Super Nintendo cartridges have owned them for thirty years; the people who merely want the ROMs downloaded them a decade ago from sites that never asked where the cartridge was. Into that narrow, principled gap walks the Retrode3 — DragonBox's open-source, browser-driven successor to a device that has quietly been the correct answer to "how do I dump my own carts" for the better part of a decade.
This is a tutorial, so here is the first honest thing: you cannot buy a Retrode3 yet. DragonBox is targeting the end of 2026, at a price under €100, and at the time of writing the only interactive element on the product page is the button that signs you up to be told when there is a button worth pressing. What you can do is learn the workflow cold — because it is nearly identical to the Retrode2 that ships today, and because the Retrode3's headline change (a web browser instead of a USB drive) does not alter the physics of pulling data off a mask ROM. Learn it on the hardware that exists; apply it to the hardware that's coming. That is what the next 40 minutes of reading, and the roughly 40 minutes of first-dump labour, are for.
What the Retrode3 Actually Is
Strip away the marketing and a Retrode is a very literal object: a plastic shell with a couple of cartridge slots on top, a USB port on the back, and just enough silicon inside to read the address and data lines of a game cartridge the way the original console would have. You put a cartridge in. The data comes out. Everything else is packaging around that one trick.
The original premise: cartridges as files
The Retrode2 — the device the Retrode3 replaces — sold the world's simplest mental model. You plugged it in and it appeared on your computer as a USB flash drive. Open the drive, and the game inside the inserted cartridge was sitting there as a file. Copy the file to your desktop and you had a dump. No dumping software, no timing parameters, no soldering. That plug-and-play simplicity is exactly why it outlived a dozen fancier tools, and it is the first half of what DragonBox says the Retrode3 keeps.
What DragonBox rebuilt for the Retrode3
The second half is flexibility, and here DragonBox has borrowed openly from the DIY world's best cartridge tool, Sanni's open-source Cart Reader. Instead of a fixed-function microcontroller, the Retrode3 is built around a MIPS processor running Debian Linux, with built-in Wi-Fi and fully open-source hardware and software. That is a startling amount of computer for a cartridge slot, and it exists so the device can grow: new console support, new checksum logic, new export formats are all just software on a general-purpose Linux box rather than a firmware respin. The slots themselves cover Sega Mega Drive/Genesis, Nintendo SNES/SFC, and — the genuinely new addition this generation — Nintendo NES. In every case you get access to both the ROM (the program and data) and the SRAM (your save games) from the original vintage cartridge.
The catch: it isn't for sale yet
None of which you can hold in your hands. DragonBox — a German outfit, and the Retrode3 is proudly Made in Germany — is aiming for availability by the end of 2026, at a target price under €100 (about $108), with both the date and the final figure explicitly unconfirmed. The official Retrode site cannot take an order; the actual channel is a pre-registration page at the DragonBox partner store where you leave an email and wait. So treat this article as a field manual written slightly ahead of the equipment. The specifics that follow are grounded in the Retrode2 you can buy now and the published Retrode3 architecture — not in a review unit, because there isn't one.
Prerequisites: Hardware and Software
Dumping cartridges is unusual among retro-hobby tasks in that the software is trivial and the physical preparation is where every failure lives. Budget your attention accordingly. Here is everything you need before you connect a single wire.
Hardware checklist
- A Retrode unit. Today that means a Retrode2. When the Retrode3 ships, the workflow below carries over almost unchanged; the differences are flagged as we go.
- A data-capable USB cable. This is the single most common cause of "it doesn't work." Many cables — especially the ones bundled with chargers — carry power but not data. Use one you know transfers files.
- The cartridges you legally own. Genesis/Mega Drive, SNES/SFC, or (on the Retrode3) NES. That ownership is not a moral flourish; it is the entire legal basis for what you are about to do.
- Isopropyl alcohol, 99% (not 70%), and lint-free swabs. Contact cleaning is step two for a reason. The higher the purity, the faster it flashes off and the less residue it leaves.
- Optional adapters. The Retrode FAQ confirms the Sega 32X cartridge adapter works — without its power supply attached — while the Super Game Boy adapter does not. Do not assume every adapter you own is supported; check the list.
- Optional: a CR2032 battery and a soldering iron, only if you intend to preserve saves from carts whose backup battery has died.
Cartridges, adapters, and what won't work
Compatibility on a Retrode is refreshingly boring for the mainline slots and fiddly at the edges. Standard SNES/SFC and Genesis/Mega Drive carts read directly. The 32X works through its adapter. Peripheral oddities — the Super Game Boy passthrough, various region converters, cartridges with exotic mapper chips — are where the exceptions cluster. On the controller side, the ports accept SNES pads and Sega 3- and 6-button pads, and the SNES mouse is explicitly supported on the left port (a detail worth remembering the first time your mouse does nothing in the right one). None of this matters for a pure dumping session, but it matters if you plan to use the Retrode as a USB controller adapter as well, which it happily is.
Software and versions
You need almost nothing, which is the point. The list, with versions where a version matters:
- An operating system with a file manager. Windows 10/11, macOS 12+, or any current Linux. The Retrode2 is USB mass-storage class, so it needs no driver; the Retrode3 registers as USB-Ethernet, which also needs no driver.
- A checksum tool. On Linux/macOS,
sha1sum/shasumship with the OS. On Windows,CertUtilis built in. For bulk verification, clrmamepro (any current build) or RomVault reads No-Intro datfiles directly. - No-Intro DAT files, downloaded from DAT-o-MATIC. These are the reference fingerprints that tell you whether your dump is byte-perfect.
- An emulator or emulation OS to actually play the results. A current RetroArch build (1.19 or newer) with the Snes9x and Genesis Plus GX cores is the flexible choice; if you would rather not assemble cores by hand, our clean 11-step RetroArch core setup gets you there without the usual guesswork.
- Optional developer tooling if you want to build the Retrode3 stack yourself: git and a standard cross-compile toolchain, pointed at the retrode3-oscr and retrode3-kernel repositories.
How Cartridge Dumping Works
You do not need to understand this section to dump a cartridge, but understanding it is the difference between someone who copies a file and someone who knows why a checksum failed. Two minutes of theory saves an hour of confusion.
ROM vs SRAM: what you're actually copying
A cartridge contains, at minimum, a mask ROM — a read-only chip holding the game's code and assets, fixed at the factory and unchanged for the life of the cart. Dumping the ROM is a pure read: the Retrode walks the address lines, records what comes back on the data lines, and writes it to a file. This is deterministic. Dump the same healthy cart twice and you get two identical files, byte for byte. That property is what makes verification possible at all.
Many carts also carry SRAM — static RAM, kept alive by a small coin-cell battery, holding your saved games. This is where the emotion lives. The ROM is Chrono Trigger; the SRAM is your Chrono Trigger, the 40-hour file with the party you assembled. The Retrode reads SRAM as a separate file (conventionally a .srm), and unlike the ROM, its contents are unique to your cartridge and irreplaceable. When the backup battery dies, the SRAM forgets, and no dumper on earth can recover what is no longer there.
The Retrode2 mass-storage model
The Retrode2 presents itself to your computer as a USB mass-storage device — a flash drive. Insert a cartridge and the drive's contents update to expose that game's ROM and SRAM as files sitting in the root of a small FAT volume, alongside a plain-text configuration file. "Dumping" is then just copying those files off the drive. There is no capture button, no progress bar in the classic sense; the read happens as your OS reads the file. It is elegant precisely because it hides the machinery.
The Retrode3 USB-Ethernet and web model
The Retrode3 throws out the flash-drive metaphor and replaces it with a tiny web server. Because it runs Debian on a MIPS core, it can register itself over USB as an Ethernet device — your computer thinks you plugged in a small network — and serve a control panel that you open in any browser. No drive letter, no mount point, no drivers on any of the three major operating systems. You point a browser at the device's local address and drive everything from there: select the slot, read the ROM, pull the SRAM, download the files. The physics underneath are identical to the Retrode2; only the interface changed, from "a folder" to "a web page." Everything this tutorial says about seating carts, cleaning contacts, and verifying dumps applies verbatim to both.
The 12-Step Dumping Workflow
Here is the whole job, start to finish, with the reasoning attached to each step so you can adapt it rather than memorise it. On a Retrode2 the file operations are drag-and-drop; on the Retrode3 the equivalents are browser clicks. The logic does not change.
- Confirm you own the cartridge and gather it. This is not filler. The legal footing for what follows is that you are backing up media you physically possess. Establish that first, then set the cartridge on the desk in front of you.
- Clean the cartridge contacts. Dampen a lint-free swab with 99% isopropyl and wipe the exposed edge connector until the swab comes away clean. Thirty-year-old carts wear a film of oxidation and grime that causes partial reads and mismatched checksums. This one step prevents the majority of "bad dump" reports.
- Update the firmware (Retrode2) or reflash the OS image (Retrode3). Newer firmware carries better cartridge maps and bug fixes; on the Retrode3, because the whole device is "practically unbrickable," you can flash a fresh image without fear. Do this before your first dump, not after a problem.
- Connect the device and confirm it enumerated. Plug in with a known-good data cable and verify your OS sees the device before inserting a cartridge. On the Retrode2 you are looking for a new drive; on the Retrode3, a new network interface. Confirming enumeration first isolates cable and port problems from cartridge problems.
- Seat the cartridge firmly in the correct slot. SNES/SFC carts go in the SNES slot, Genesis in the Genesis slot, and — on the Retrode3 — NES in the NES slot. Press until fully home; a cartridge that is 90% seated reads as garbage or not at all. Orientation matters, so match the label direction to the silkscreen.
- Mount the volume or open the web UI. On the Retrode2, open the drive that appeared in step 4. On the Retrode3, open a browser and load the device's control panel at its local address. Either way, you should now see the inserted game exposed as readable data.
- Copy the ROM file off the device. Drag the ROM to a working folder on your computer (or click Download in the web UI). This is the dump. It should complete quickly; a read that stalls or errors points back at seating or contacts, not at software.
- Copy the SRAM file off separately. If the cart has saves you care about, pull the
.srmnow and store it apart from the ROM. Saves are irreplaceable and battery-dependent — treat the SRAM as the more precious of the two files, because it is the only one that cannot be re-downloaded from anywhere on Earth. - Eject or unmount safely before removing anything. On the Retrode2, unmount the drive so any pending FAT writes finish. Yanking mid-operation is the classic way to corrupt a file or, worse, an SRAM write-back to the cart. Patience here costs seconds and saves saves.
- Verify the dump's size and checksum against No-Intro. Run
sha1sumon the ROM and match it against the No-Intro datfile for that system. A match means byte-perfect; a mismatch means clean the cart and dump again. Skipping this step is how silent bad dumps end up in your library for years. - Rename to the No-Intro convention and organise. Give the file its canonical name — for example,
Chrono Trigger (USA).sfc— and file it by system. Consistent naming is what lets RetroArch, Batocera, and scrapers identify your games automatically instead of showing you a wall of "unknown." - Back up to at least two locations. Follow the preservationist's 3-2-1 instinct: the dump on your working drive, a copy on external storage, and a copy somewhere offline. You cleaned a thirty-year-old cartridge to make this file; do not let a single dead SSD undo the work.
That is the entire loop. Once it is muscle memory, a cartridge takes a couple of minutes, and the 40-minute figure in the title is almost entirely the one-time setup: cleaning your first cart, flashing firmware, downloading datfiles, and reading this far.
RETRODE.CFG and the Web UI
The Retrode is not a black box. Both generations expose their behaviour to you — the Retrode2 through a plain-text file, the Retrode3 through settings in the browser panel — and knowing where those knobs live turns a fixed appliance into something you can bend to a stubborn cartridge.
Where the configuration lives
On the Retrode2, the mounted drive contains a file named RETRODE.CFG. It is human-readable, you edit it in any text editor, and the device re-reads it on the next power cycle. That is the whole mechanism — no app, no registry. On the Retrode3, the equivalent settings live behind the web control panel, backed by ordinary Debian config on the device's filesystem; because the OS is open source, nothing about it is hidden from you.
Key options, explained
The exact keys evolve with firmware, so treat the block below as an illustration of the format and check the current names against the official documentation before relying on any single line. The shape, however, is stable — a set of key=value pairs governing how the device presents itself and how aggressively it reads:
# RETRODE.CFG - illustrative format, confirm keys against current docs
# Lines beginning with '#' are comments.
# How the device labels the mounted volume
VOLUME_LABEL=RETRODE
# Expose SRAM (save data) as a writable file (1) or hide it (0)
SRAM_ENABLE=1
# Force the ROM file extension by system (helps emulators auto-detect)
SNES_EXT=sfc
GENESIS_EXT=bin
# Read speed / retries for marginal cartridge contacts
# Lower speed and higher retries help dirty or aging carts.
READ_RETRIES=3
# Act as a USB controller adapter as well as a dumper
GAMEPAD_ENABLE=1
The two options worth internalising are the save-data toggle and the read-retry count. Turning SRAM off is how you avoid accidentally overwriting a cartridge's saves when you only meant to read the ROM; raising retries is your first software response to a cartridge that dumps inconsistently despite a clean edge connector.
The Retrode3 web interface equivalent
On the Retrode3 you will not edit a file on a drive, because there is no drive. You will open the browser panel, find the same concepts under settings — volume/label, SRAM read/write, per-system export options, controller pass-through — and toggle them there. The advantage of the web model is that the device can show you what it sees in real time: which cartridge is detected, how large the ROM measured, whether SRAM is present. The disadvantage is that you are trusting a pre-release interface that, as of this writing, no reviewer outside DragonBox has published screenshots of. When it ships, verify the panel's address and layout against the shipping documentation rather than against anyone's guess, including this one.
Verifying Dumps Against No-Intro
An unverified dump is a rumour. It might be perfect; it might be missing a byte from a flake of oxidation you did not see. The only way to know is to compare your file's fingerprint against a known-good reference, and the retro-preservation world has spent two decades building exactly that reference for you.
Why checksums matter
Because a healthy cartridge dumps deterministically, every good copy of, say, the US release of Super Metroid has the identical SHA-1 hash. No-Intro catalogues those hashes for cartridge-based systems (its sibling project Redump does the same for discs). If your dump's hash appears in the datfile, your dump is byte-for-byte identical to the community's verified reference — full stop. If it does not, something is off: a dirty contact, a region mismatch, an overdump padding the file with extra bytes, or a genuinely rare variant. Checksums do not tell you the game is fun; they tell you the file is correct, which is the only thing a dumper is responsible for.
Running the check
The manual approach uses nothing but tools already on your machine. Hash the file, then search the datfile for that hash:
$ sha1sum "SNES ROM.sfc"
da3d...c1f9 SNES ROM.sfc
# Compare that hash against the No-Intro datfile for SNES.
# A match in the .dat means a byte-perfect, verified dump.
$ grep -i "da3d...c1f9" "Nintendo - Super Nintendo Entertainment System.dat"
<rom name="Super Metroid (USA).sfc" size=3145728 crc="..." sha1="DA3D...C1F9"/>
For more than a handful of games, do not do this by hand. Point clrmamepro or RomVault at your folder and the datfile, and it will scan everything at once, flag mismatches, and even rename verified files to their canonical No-Intro names in bulk. Expected output from a clean batch is quietly satisfying — a list of green "correct" rows and nothing in the "unneeded" or "missing" columns.
What a bad dump looks like
Failures have a grammar you learn to read. A file that is a tidy power-of-two size but hashes wrong usually means dirty contacts or a marginal read — clean and re-dump. A file that is slightly larger than expected, often by a round number of kilobytes, is frequently an overdump, where the reader ran past the real ROM into mirrored or empty space. A file that is a fraction of the expected size means the cartridge was not fully seated or the reader gave up early. And a dump that produces a different hash every single time you read it is the signature of a failing cartridge or genuinely filthy contacts — the read is not deterministic because the electrical contact is not stable. In every case the fix is physical first, software second.
Playing Your Dumps
A verified ROM sitting in a folder is preservation; getting it onto a screen is the reward. The good news is that a No-Intro-named SNES or Genesis file is the single most universally supported thing in all of emulation, so you have an embarrassment of options.
Loading into RetroArch cores
RetroArch is the flexible default because one interface fronts dozens of emulator cores. For SNES you want Snes9x (or bsnes for accuracy); for Genesis, Genesis Plus GX. From the command line the pattern is blunt and worth knowing when the GUI misbehaves:
# Launch a specific core with a specific ROM, no menus
$ retroarch -L cores/snes9x_libretro.so \
"roms/snes/Super Metroid (USA).sfc"
# Genesis example
$ retroarch -L cores/genesis_plus_gx_libretro.so \
"roms/genesis/Sonic the Hedgehog 2 (World).md"
Point RetroArch's playlist scanner at your verified, correctly named folders and it will match each file against its internal database and build browsable lists with box art. That auto-matching is the entire payoff for the naming discipline back in step 11. The authoritative reference for any core's quirks — which chip a given SNES game needs, why an accuracy core runs slower — is the libretro documentation, worth a bookmark before you go deep.
Dropping ROMs into an emulation OS
If you would rather not manage cores at all, an appliance-style emulation OS swallows your dumps whole. Drop the files into the right per-system folder and the frontend scrapes, sorts, and presents them. Batocera 43.1 is the low-friction choice — copy your SNES and Genesis dumps into /roms/snes and /roms/megadrive, rescan, and you are playing. The Raspberry Pi crowd's long-standing option is RetroPie, though be aware its main image has sat at v4.8 for years while newer boards moved on — a caveat worth reading before you commit a Pi 5 to it.
FPGA accuracy for the purists
Software emulation is superb, but some people dump cartridges precisely because they distrust approximation. For them the endgame is FPGA hardware that reimplements the original console's logic in gates rather than code. The MiSTer ecosystem will run your verified SNES and Genesis dumps on cycle-accurate cores, and dedicated boxes like the Analogue 3D chase the same fidelity for other systems. It is a fitting destination: you used original hardware to read an original cartridge, and now you can feed the result to hardware that behaves like the original console. The cartridge, the dump, and the FPGA form a closed loop of authenticity that pure emulation never quite claims.
Common Pitfalls and Fixes
Nearly every Retrode problem is one of a small set of recurring mistakes. Learn the shape of them here and you will diagnose your own failures faster than any forum thread can.
Physical-contact failures
- Pitfall: dirty or oxidised contacts. By far the most common cause of failed or mismatched dumps. A cartridge that visibly works in a real console can still dump wrong, because the Retrode's read is less forgiving than a console's. Fix: clean the edge connector with 99% isopropyl and a lint-free swab, let it flash off completely, and reseat. Never use an abrasive — you are cleaning the contacts, not sanding them.
- Pitfall: a cartridge that is not fully seated. A partial insertion produces a truncated file or pure garbage. Fix: press the cart fully home, confirm orientation against the silkscreen, and re-read. If it wobbles, the slot or the cart's shell may need attention.
Save-data and battery traps
- Pitfall: a dead SRAM battery. If the coin cell that preserves a cartridge's saves has already died, the save is already gone — the Retrode will dump empty or garbage SRAM, and no tool can conjure back data the chip no longer holds. Fix: recognise this is a preservation loss, not a Retrode bug. If you must keep the cart usable for future saves, replace the CR2032 (a soldering job on most carts), but understand you are enabling new saves, not recovering old ones.
- Pitfall: accidentally overwriting a cartridge's saves. Because SRAM can be written as well as read, a careless drag can clobber a save. Fix: disable SRAM writing in the configuration when you only intend to read, and always copy the SRAM off before doing anything else with it.
Compatibility and legal misconceptions
- Pitfall: assuming every adapter and peripheral works. The Retrode FAQ is explicit that the 32X adapter works only without its power supply, and that the Super Game Boy adapter does not work at all. Controller expectations trip people too — the SNES mouse only works on the left port. Fix: check the compatibility list before assuming, and match ports deliberately.
- Pitfall: believing a dump is a licence to distribute. Making a personal backup of a cartridge you own is the device's intended purpose; uploading that ROM for strangers to download is a separate act and, in most jurisdictions, plain copyright infringement. Fix: keep the distinction clean in your head. The Retrode's legitimacy rests entirely on the word "personal."
- Pitfall: trusting an unverified dump. A file that copied without an error message can still be wrong. Fix: verify every dump against No-Intro before you file it. A silent bad dump discovered three years later is a preservation failure you inflicted on yourself.
Troubleshooting Table
When something misbehaves, work down this table from the top — it is ordered roughly from most common and easiest to rarest and hardest. The overwhelming majority of real-world failures are resolved in the first four rows.
| Symptom | Likely Cause | Fix |
|---|---|---|
| Device not detected at all | Power-only USB cable or dead port | Swap to a known data cable; try a rear/motherboard USB port |
| Enumerates but no drive/panel appears | OS didn't auto-mount (Retrode2) or interface is down (Retrode3) | Mount the volume manually; check dmesg or ip link for the interface |
| ROM file is 0 bytes or truncated | Cartridge not fully seated or dirty contacts | Reseat firmly; clean the edge connector with 99% isopropyl |
| Checksum doesn't match No-Intro | Dirty contacts, wrong-region datfile, or an overdump | Clean and re-dump; confirm you're matching the correct region's DAT |
| SRAM file is empty or garbage | Dead save-backup battery | Recognise the save is already lost; replace the CR2032 only for future saves |
| One system reads but another doesn't | Wrong slot or reversed orientation | Use the correct slot; match label direction to the silkscreen |
| 32X game won't dump | Missing or wrongly-configured 32X adapter | Use the 32X cartridge adapter without its power supply attached |
| Game Boy / Super Game Boy cart won't read | Unsupported adapter | The Super Game Boy adapter is not supported; there is no fix beyond different hardware |
| Web UI won't load (Retrode3) | USB-Ethernet interface down or wrong address | Check ip link for the gadget interface; use the device's documented address |
| Controller not recognised | Wrong port or unsupported pad | Use a SNES or Sega 3/6-button pad; put the SNES mouse on the left port |
| Firmware/OS update seems to have killed it | Interrupted flash | Reflash a fresh image — the Retrode3 is designed to be practically unbrickable |
| Dump differs on every read | Marginal contacts or a failing cartridge | Clean thoroughly, reseat, dump several times and compare; suspect the cart if it persists |
Advanced Tips
Once the basic loop is automatic, the Retrode rewards a little scripting and a little curiosity about what is actually inside the box. This section is for the reader who has already dumped a shelf of carts and wants the process to scale and the tooling to be theirs.
Batch dumping and scripting
If you are working through a large collection, wrap the verify-and-rename tail of the workflow in a script so the only manual act is swapping cartridges. A minimal Linux example that copies whatever the Retrode currently exposes, hashes it, and files it away:
#!/usr/bin/env bash
# dump-one.sh - copy and hash the currently inserted cart
set -euo pipefail
SRC="/media/$USER/RETRODE" # Retrode2 mount point
DEST="$HOME/dumps/incoming"
mkdir -p "$DEST"
# Copy every ROM the device is currently exposing
for f in "$SRC"/*ROM*; do
[ -e "$f" ] || continue
base="$(basename "$f")"
cp "$f" "$DEST/$base"
sha1sum "$DEST/$base" | tee -a "$DEST/hashes.txt"
done
echo "Done. Now verify hashes.txt against your No-Intro DAT."
Run it, swap the cart, run it again. Feed hashes.txt to clrmamepro at the end of the session and you have a verified, named library with almost no keystrokes per game.
Wi-Fi and headless workflows on the Retrode3
The Retrode3's built-in Wi-Fi and full Debian userland open a door the Retrode2 never had: dumping without a directly attached computer. Because it is a networked Linux box, there is every reason to expect you will be able to reach it over the LAN, pull dumps to a NAS, and drive it from a phone browser — a genuinely different ergonomic for anyone digitising a large collection on a workbench with no PC. Treat the specifics as forthcoming until the shipping documentation confirms them, but the architecture — MIPS, Debian, Wi-Fi, a web control panel — is exactly the architecture you would build if headless operation were the goal.
Building and contributing to the open-source project
The most future-proof advanced tip is also the most in keeping with the project's spirit: the whole thing is open. The OS adaptation lives at retrode3-oscr and the kernel at retrode3-kernel, with hardware schematics published alongside. That means "unbrickable" is not marketing — a broken device is a git clone, a build, and a reflash away from working — and it means new cartridge support or a bug fix can come from you rather than from a vendor's roadmap. If you have ever wanted a preservation tool whose longevity does not depend on a company staying interested, this is the closest the category has come. Star the repos, read the issues, and when the hardware ships, you will already know the codebase that runs it.
A Complete Working Configuration
To close, here is everything assembled into a form you can copy: an annotated configuration, a reusable verification script, and the one-paragraph verdict on whether any of this is worth your late-2026 attention.
The annotated RETRODE.CFG
A complete, commented Retrode2-style configuration for a read-only preservation workflow — SRAM readable but not writable, extensions forced for clean emulator detection, retries raised for aging carts. Confirm the exact key names against the current official documentation before deploying; the structure is what to internalise.
# ============================================================
# RETRODE.CFG - preservation-oriented, read-only workflow
# Illustrative of the documented format. Verify keys vs docs.
# ============================================================
# --- Volume presentation ---
VOLUME_LABEL=RETRODE
# --- Save data ---
# Read SRAM but never write it, so a stray drag can't clobber
# a cartridge's original saves.
SRAM_ENABLE=1
SRAM_WRITE=0
# --- Per-system export extensions ---
# Forcing extensions makes RetroArch/Batocera auto-detect cleanly.
SNES_EXT=sfc
GENESIS_EXT=bin
NES_EXT=nes
# --- Read behaviour for aging cartridges ---
# Raise retries before you lower speed; most bad reads are contacts.
READ_RETRIES=3
# --- Controller pass-through ---
# Leave the device usable as a USB gamepad adapter.
# Remember: SNES mouse works on the LEFT port only.
GAMEPAD_ENABLE=1
# --- Adapter notes (not settings, just reminders) ---
# 32X adapter: use WITHOUT its power supply.
# Super Game Boy adapter: NOT supported.
A verification script you can reuse
And the companion script that turns a folder of raw dumps into a verified, reportable set. It hashes everything, writes a manifest, and leaves the No-Intro matching to clrmamepro — deliberately, because the datfile is the authority and you should not reinvent it:
#!/usr/bin/env bash
# verify-dumps.sh - hash a folder of dumps and emit a manifest
set -euo pipefail
DIR="${1:-$HOME/dumps/incoming}"
OUT="$DIR/manifest.sha1"
cd "$DIR"
: > "$OUT"
shopt -s nullglob
for f in *.sfc *.smc *.bin *.md *.nes; do
sha1sum "$f" >> "$OUT"
done
count=$(wc -l < "$OUT")
echo "Hashed $count file(s) -> $OUT"
echo "Next: load $DIR into clrmamepro with the matching No-Intro DAT."
echo "Green 'correct' rows = byte-perfect dumps. Anything else re-dump."
Expected output on a clean run is undramatic and reassuring:
$ ./verify-dumps.sh ~/dumps/incoming
Hashed 7 file(s) -> /home/you/dumps/incoming/manifest.sha1
Next: load /home/you/dumps/incoming into clrmamepro with the matching No-Intro DAT.
Green 'correct' rows = byte-perfect dumps. Anything else re-dump.
The honest verdict
So: is the Retrode3 worth waiting for? If you own cartridges and want byte-perfect backups without soldering or a computer-science degree, yes — cautiously, and with the calendar in mind. The architecture is the right one: open hardware and software, a real Linux computer instead of a locked appliance, a driverless browser interface that will still work when today's operating systems are three versions gone, and a reflash-to-recover design that makes obsolescence a choice rather than a fate. The additions that matter — NES support, Wi-Fi, the web UI — are genuine improvements over the Retrode2, not spec-sheet padding. But it does not exist for sale yet, the price and date are both officially soft, and no independent reviewer has touched a unit. Until late 2026, the correct move is the one this tutorial was built around: learn the workflow on a Retrode2, verify everything against No-Intro, and put your email on the pre-registration list. The machine that reads your childhood off a plastic cartridge should outlast the childhood. This one is built, at last, to try.
Questions the search bar asks me
- Can I buy a Retrode3 right now?
- No. DragonBox is targeting the end of 2026 at a price under €100 (roughly $108), and the exact date and price are both unconfirmed. The only thing you can do today is sign up for a launch notification through the DragonBox partner store; retrode.com itself cannot take orders yet.
- Which cartridges and controllers does the Retrode3 support?
- It has slots for Sega Mega Drive/Genesis, Nintendo SNES/SFC, and — new for this generation — Nintendo NES, reading both ROM and SRAM. The controller ports accept SNES and Sega 3- and 6-button pads, with the SNES mouse working only on the left port. The Sega 32X cartridge adapter works (without its power supply); the Super Game Boy adapter does not.
- Do I need to install drivers?
- No. The Retrode3 registers as a USB-Ethernet device and runs entirely in a web browser, so Windows, macOS and Linux all see it without any driver install. The shipping Retrode2 is also driverless, but uses the older USB mass-storage model where the cartridge mounts as a drive.
- Is dumping my own cartridges legal?
- The intended, defensible use is making a personal backup of a cartridge you physically own — that is literally what the hardware exists for. Distributing those ROMs to other people is a separate act and is copyright infringement in most jurisdictions. This is not legal advice; the law varies by country and changes over time.
- Can the Retrode3 be bricked?
- DragonBox markets it as "practically unbrickable" because it runs Debian Linux on a MIPS processor and can be reflashed from a fresh OS image if the software is corrupted. The full OS and kernel source live on GitHub (retrode3-oscr and retrode3-kernel), so a failed update is recoverable rather than fatal.