/// FIELD NOTES FROM A SELF-AWARE GAME SITE
Retrode 2026: Dump a Cart in 12 Steps, 20 Minutes
The Retrode is one of those objects that makes retro gaming feel briefly honest. It does not stream anything. It does not phone home. It does not arrive pre-loaded with twenty-five thousand ROMs of anonymous provenance. You push a cartridge into a slot, run a USB cable to a computer, and a drive appears with your game on it as a file. That is the entire pitch, and it has not meaningfully changed in fifteen years.
What has changed is the weather around it. The shipping product is still the Retrode2, an Atmel-based adapter that reads Super Nintendo and Sega Genesis cartridges and presents them as a USB flash drive. The much-teased Retrode3 has spent 2026 in the same place it spent much of its pre-history: hardware finished, software unfinished, availability promised for the end of some year. This guide is a working tutorial for the hardware you can use today, with an honest accounting of the hardware you cannot. By the end you will have dumped a cartridge, verified it against a known-good database, restored a save, and understood exactly why your copy of Super Mario RPG refuses to cooperate.
If you want a companion piece that stays narrowly on the Super Nintendo path, we keep a separate SNES-only Retrode2 walkthrough. This one is the whole device: both slots, the config file, the firmware, the plugins, and the law.
What the Retrode Actually Is
Before the steps, understand the thing on your desk, because half of all Retrode failures are conceptual rather than mechanical.
A USB adapter, not an emulator
The Retrode does not play games. It contains no emulation, no CPU core pretending to be a 65C816 or a 68000, and no library of anything. It is a bridge. On one side is a physical cartridge with real memory chips; on the other side is a USB port. The Retrode reads the silicon and exposes it to your operating system. Wikipedia describes it plainly as a USB adapter for legacy video games that let people use cartridges and controllers with emulators, and that framing is exactly right. The emulator is somebody else's software running afterward. The Retrode's only job is to hand you an accurate file.
This matters because it sets your expectations correctly. A Retrode cannot make a bad cartridge good. It cannot resurrect a game whose ROM chip has died. It will not clean your contacts, patch a translation, or convert a region. It reads what is physically present and reports it. If the cartridge is healthy and seated, you get a byte-perfect dump. If it is filthy or damaged, you get filth or damage, faithfully transcribed.
Retrode2 versus Retrode3 at a glance
The Retrode2 is the unit that has shipped for years. Its brain is an Atmel AT90USB1287, an 8-bit AVR microcontroller with native USB. It connects over a USB mini-B port, draws power from the bus, and needs no drivers on any modern operating system because it speaks two standard USB classes that every OS already understands. It has a Super Nintendo/Super Famicom slot, a Sega Genesis/Mega Drive slot, and controller ports, plus an expansion connector for plugin adapters.
The Retrode3 is a different animal on paper: a MIPS system-on-chip running Linux, with built-in Wi-Fi, a browser-based interface, and fully open hardware and software. It is meant to be reachable either over USB like its predecessor or over your network. The official site now leads with it under the tagline "The Open-Source Retro Cartridge Reader, Reinvented." That is the future. The present is still the Retrode2, and the rest of this tutorial assumes a Retrode2 unless stated otherwise.
What it reads, and what it refuses to
Out of the box the Retrode2 handles Super Nintendo and Super Famicom cartridges and Sega Genesis and Mega Drive cartridges. The official welcome page positions it exactly this way, as a USB adapter for vintage games supporting Sega Genesis/Mega Drive and Nintendo SNES/SFC carts. With plugin adapters the family reaches further, into Nintendo 64, Game Boy and Game Boy Advance, Sega Master System, Game Gear, and even a Sega 32X adapter, each of which slots into the expansion header and gets its own file extension in the config.
What it refuses is narrower but important. Certain enhancement-chip cartridges, most notably titles using the SA-1 coprocessor, resist a stock Retrode2 dump. It reads regular controllers but not light guns or multitaps. And it cannot magically know a cartridge's true size or mapper if the header lies, which is why the config file exists. We will return to every one of these edges.
The Retrode3 Situation in 2026
Let us deal with the elephant, because you will otherwise spend an hour on the store page wondering why there is no "Buy" button.
What the Retrode3 promises
The Retrode3 is a genuine redesign rather than a cosmetic refresh. Swapping the little AVR for a MIPS SoC running Linux turns the dumper from a fixed-function gadget into a small computer, which is what enables the Wi-Fi, the browser UI, and the promise of dumping over the network instead of only over a cable. The whole thing is pitched as fully open, hardware and software both, which is the correct spirit for a device whose entire value proposition is trust and transparency. On paper it is the Retrode done properly for the 2020s.
The "by the end of the year" problem
On paper. As of the official site's mid-August 2026 update, the maker's own words were that the hardware is finished and the team is still working on the software, with availability targeted "by the end of the year." The exact quote on the official Retrode homepage reads: "We are aiming for availability by the end of the year; an exact date and the final price (target: under EUR 100) are still to be confirmed." That is a carefully hedged sentence. The price is a target, not a number. The date is a quarter, not a day. Software is the part that is not done, and software is always the part that is not done.
None of this is an accusation of bad faith. Small open-hardware projects run on nights and weekends, and "finished the board, still writing the firmware" is the most believable status update in the entire hobby. But a tutorial owes you clarity, so here it is: as of this writing you cannot order a Retrode3, the price is unconfirmed under a hundred euros, and the shipping date is a hope. Treat the Retrode3 as the perpetually end-of-year tease it currently is, and buy a Retrode2 if you need to dump a cartridge this month.
How you actually get on the list
The official site does not sell the Retrode3 directly; it points you at DragonBox to register for a notification. DragonBox is the established retail channel for the Retrode line, and its store has continued merchandising the Retrode2 into 2026, so the distribution pipeline is real even while the new product is not orderable. If you want a Retrode3 the day it ships, the honest move is to put your email on the DragonBox notification and then forget about it, because a watched vaporware pot never boils. For real cartridge-dumping work in the meantime, the Retrode2 is the tool, and everything below assumes it. For historical context, early retail coverage recorded the original device at a pre-order price of $84.99, which remains a useful anchor for what "under EUR 100" is meant to undercut.
Prerequisites
A cartridge dumper has short requirements, which is the nicest thing about it. There is no toolchain to install and no account to create.
Hardware you need
- A Retrode2 with at least one cartridge slot you intend to use (SNES/SFC or Genesis/Mega Drive), and the appropriate plugin adapter if you are dumping N64, Game Boy/GBA, Master System, Game Gear, or 32X.
- A known-good USB data cable, mini-B to whatever your computer takes. This is the single most common point of failure. Charge-only cables and frayed bargain-bin cables produce phantom problems that look like dead cartridges.
- A host computer with a spare USB port. The Retrode's FAQ puts the requirement about as loosely as it can be put: "Anything with a USB host port that runs a modern operating system (Linux, Mac OS X, Windows, you name it)."
- The cartridges themselves, ideally cleaned. A cotton swab, 90%-or-higher isopropyl alcohol, and five minutes of patience prevent most bad dumps before they happen.
- Optional but wise: a small tube of contact cleaner and a bright-light loupe for inspecting edge connectors on carts you suspect are corroded.
Software (there is none)
There is no Retrode driver to install, because the Retrode2 is class-compliant. It presents itself as a USB Mass Storage device and a USB HID device, both of which your operating system has supported natively since the George W. Bush administration. On Linux the volume auto-mounts under /run/media or /media; on macOS it appears on the desktop and under /Volumes; on Windows it gets a drive letter. That is it. You will want an emulator or FPGA platform later to actually play the dumps, but for the dumping act itself, your file manager and a terminal are the whole software stack.
The reference database
The one piece of external data worth having on hand is a verification database. The No-Intro DAT-o-MATIC project maintains checksums for clean, header-free cartridge dumps of the SNES, Genesis, and every other library the Retrode touches. Download the relevant DAT files before you start. Without them you have a file; with them you have proof that your file matches every other correct dump of that exact cartridge revision on earth. That distinction is the entire reason to dump your own carts instead of trusting a random download.
How It Works Under the Hood
Understanding the mechanism turns troubleshooting from guesswork into deduction. The Retrode does two clever things at once.
Mass Storage: the cartridge as a flash drive
When you insert a cartridge and connect the Retrode, its firmware reads the cartridge header, works out the system, the ROM size, and the memory layout, and then synthesizes a tiny FAT filesystem in real time. The Retrode FAQ describes the trick exactly: it "wraps whatever memory chips there are on the cartridge into virtual files on a USB drive, and makes the gamepads appear as USB HID-class controllers." Those virtual files do not exist on any flash chip inside the Retrode. When your computer reads the file, the Retrode reads the cartridge on demand and streams the bytes back as if they had always been sitting on a disk. Copying the file is the dump. There is no separate "rip" button because the copy operation is the rip.
Here is what a healthy connection looks like on Linux, reading a 32-megabit SNES cartridge. Your device node and timings will differ, but the shape is diagnostic:
$ dmesg | tail -n 8
usb 1-3: new full-speed USB device number 9 using xhci_hcd
usb 1-3: New USB device found, Manufacturer=Retrode, Product=Retrode2
usb-storage 1-3:1.0: USB Mass Storage device detected
scsi 6:0:0:0: Direct-Access Retrode Retrode2 0.18 PQ: 0 ANSI: 2
sd 6:0:0:0: [sdb] 8192 512-byte logical blocks: (4.19 MB/4.00 MiB)
sd 6:0:0:0: [sdb] Write Protect is off
input: Retrode2 Gamepad as /devices/pci0000:00/.../input/input21
sd 6:0:0:0: [sdb] Attached SCSI removable disk
$ lsblk -o NAME,SIZE,LABEL,MOUNTPOINT /dev/sdb
NAME SIZE LABEL MOUNTPOINT
sdb 4.0M RETRODE /run/media/user/RETRODENote two things in that output. The volume label is RETRODE, and the reported size tracks the cartridge, not some fixed capacity, because the filesystem was invented to fit this specific game. If you ever see the label but a size of zero, the header read failed and the cartridge is not seated, which we cover in troubleshooting.
HID: your controllers as gamepads
The second trick is the controller ports. The Retrode exposes the cartridge's native controller ports as standard USB HID gamepads. Plug an original SNES or Genesis pad into the Retrode and your operating system sees a generic joystick, no driver required, which you can then map inside RetroArch or any other emulator. This is genuinely useful: it means the same box that preserves your ROM also lets you play it on the original directional pad your thumbs remember. The caveat from the manual is that only regular controllers work. Light guns and multitaps are out, and the SNES mouse is supported only on the left port. Do not plan a Mario Paint session on the wrong side.
Why there are no drivers
People raised on modern peripherals keep asking where the Retrode software is, and the answer keeps disappointing them: there isn't any, on purpose. By implementing only the two oldest, most universal USB device classes, the Retrode inherited three decades of built-in operating-system support and sidestepped the entire driver-signing, kernel-module, install-a-daemon circus. This is also why it will still work in ten years when today's fashionable dumper apps have bit-rotted. A device that needs no software cannot be abandoned by its software. It is the single best engineering decision in the whole product, and it is why the Retrode FAQ can honestly promise it is "not soon to be outdated."
Dump a Cartridge in 12 Steps
This is the core procedure. It takes about twenty minutes the first time, most of which is cleaning and verification, and under five minutes once it is muscle memory. Each step includes the reason it exists, because a step you understand is a step you will not skip.
Steps 1 to 4: clean, inspect, seat, connect
- Clean the cartridge contacts. Dampen a cotton swab with high-percentage isopropyl alcohol and wipe the edge connector until the swab comes away clean. Rationale: the Retrode reads whatever the metal presents; oxidation and grime cause intermittent bits, which produce dumps that differ every time you copy them. Cleaning is not optional ceremony, it is the difference between a verified dump and a coin flip.
- Inspect for damage and correct region shell. Look at the board through the slot if you can, and confirm the cartridge is intact. Rationale: a cracked trace or a lifted pin reads as missing data, and no amount of re-seating fixes silicon rot. Better to know now than after three failed hashes.
- Seat the cartridge fully and squarely. Push it into the correct slot until it stops, without forcing a crooked entry. Rationale: the Retrode's header read happens on insertion; a half-seated cart yields a zero-byte or truncated virtual file. Firm and straight, not violent.
- Connect the Retrode to the host with a data cable. Use a rear port or a powered hub, straight to the machine. Rationale: the Retrode is bus-powered and reads large ROMs; an underpowered front port or a charge-only cable causes dropouts that masquerade as cartridge faults. This one cable is responsible for a startling share of all Retrode support threads.
Steps 5 to 8: mount, identify, read the config, copy
- Confirm the volume mounted. Wait for the RETRODE drive to appear in your file manager, or run the lsblk check from earlier. Rationale: if the label never shows, stop and fix detection before touching anything else; a missing mount is a hardware/seating problem, not a software one.
- Open the drive and confirm the game was identified. You should see a file named after the cartridge's internal title, plus RETRODE.CFG. On a healthy SNES read it looks like this:
Rationale: the filename comes from the cartridge header, so a garbled name is your first warning that the header read is flaky. A 32-megabit game should read as 4,194,304 bytes exactly.$ ls -l /run/media/user/RETRODE total 4100 -rwxr-xr-x 1 user user 512 Jan 1 2016 RETRODE.CFG -rwxr-xr-x 1 user user 4194304 Jan 1 2016 CHRONO TRIGGER.sfc -rwxr-xr-x 1 user user 8192 Jan 1 2016 CHRONO TRIGGER.srm - Note the file sizes against expectations. A 4-megabit game is 512 KB; 8 megabits is 1 MB; 16 is 2 MB; 32 is 4 MB. Rationale: the fastest sanity check in the whole process is arithmetic. If Chrono Trigger reads as 2 MB instead of 4, autodetection guessed wrong and you will fix it in the config before copying.
- Copy the ROM file to your computer. Drag it off, or use the shell. Rationale: reading in place works, but you want a local copy you own, on storage that will not vanish when you pull the cartridge. Do the copy now, before you touch saves.
$ mkdir -p ~/roms/snes ~/saves/snes $ cp "/run/media/user/RETRODE/CHRONO TRIGGER.sfc" ~/roms/snes/ $ cp "/run/media/user/RETRODE/CHRONO TRIGGER.srm" ~/saves/snes/
Steps 9 to 12: saves, verify, repeat, eject
- Back up the on-cartridge save. If a .srm file exists, it is your real battery-backed save from the cartridge; copy it too (done above). Rationale: those saves are decades old and the batteries that hold them are dying. The Retrode is the only easy way to rescue a save before the CR2032 finally quits. Some carts have no SRAM and thus no .srm; that is normal.
- Verify the dump against a checksum. Hash the file and compare it to the No-Intro DAT for that game and revision:
Rationale: a dump you have not verified is a rumor. If your hash matches the database, your read was perfect; if it does not, you have a dirty-contact problem or a special-chip cartridge, and you re-dump rather than trust it.$ cd ~/roms/snes $ sha1sum "CHRONO TRIGGER.sfc" a2bc9f1e...e41d CHRONO TRIGGER.sfc $ stat -c '%s bytes' "CHRONO TRIGGER.sfc" 4194304 bytes - If verification fails, re-clean and re-dump. Wipe the contacts again, reseat, and copy a second time; compare the two copies' hashes to each other. Rationale: two independent reads that agree byte-for-byte are almost certainly correct even if you lack a DAT entry. Two reads that disagree localize the fault to the physical connection.
- Safely unmount, then remove the cartridge. Eject the volume in your OS before pulling the USB cable or the cart. Rationale: because the filesystem is synthesized live, yanking mid-read can leave a copy operation half-finished and, if you were writing a save back, can corrupt the on-cart SRAM. Eject, wait for the all-clear, then remove.
The RETRODE.CFG File
The single most underused feature of the Retrode is the plain-text config file living on the virtual drive. Open RETRODE.CFG in any text editor, change a value, save it back to the RETRODE volume, and re-insert the cartridge to apply. It is how you fix nearly every autodetection mistake.
The safety keys
Two keys keep you from hurting yourself. sramReadonly defaults to 1, which write-protects the on-cartridge save so a stray copy or a confused sync tool cannot overwrite thirty years of progress. Leave it at 1 unless you are deliberately restoring a save. detectionDelay controls how long the firmware waits before reading the header, which you raise if a cartridge is slow to settle in the slot. Here is a minimal, safe starting config:
; RETRODE.CFG -- re-read on every cartridge insertion
; Delete any line to reset that parameter to its firmware default.
sramReadonly = 1 ; 1 = protect on-cart save (default), 0 = allow writes
detectionDelay = 3 ; raise if carts are detected intermittently
segaSram16bit = 0 ; set 1 only for Sega carts with 16-bit SRAM
snesRomExt = sfc ; extension for SNES dumps
segaRomExt = bin ; extension for Sega dumps
sramExt = srm ; extension for save filesThe override keys
When autodetection guesses wrong, three force keys take control: forceSystem, forceSize, and forceMapper. They override the header-based detection of the console, the ROM size, and the memory mapper respectively. If a 32-megabit cartridge reads as 16, set forceSize to the correct value and re-insert. If a Super Famicom cart is misidentified, forceSystem straightens it out. The exact accepted values are defined by your firmware revision, so treat the numbers as firmware-specific and consult the documentation for your version rather than copying a stranger's magic constant. The important concept is that these keys exist and that they are the correct tool for a wrong-size or wrong-system dump.
Extensions, and reset-by-deletion
The *RomExt family of keys sets the file extension per system: snesRomExt, segaRomExt, and, once you add plugin adapters, n64RomExt, gbRomExt, gbaRomExt, smsRomExt, and ggRomExt. Change these if your preferred emulator wants a particular extension. The one behavior that surprises everyone: deleting a line does not disable a feature, it resets that parameter to the factory default. So if you have made a mess of the config, you do not need to remember the defaults, you just delete the offending lines and let the firmware refill them. It is the most forgiving config format in the hobby, which suits a device whose users are mostly not programmers.
Verifying Your Dumps
A dump you cannot verify is worthless for preservation, because you have no way to know whether bit 4,000,000 flipped during a marginal read. Verification is not paranoia, it is the point.
Internal checksum versus No-Intro
There are two layers of verification, and you want both. The internal checksum is a value stored in the cartridge header that the console itself once used as a sanity check; many emulators will display whether it matches, and a mismatch flags an obviously bad read. But the internal checksum is weak and can pass on a subtly wrong dump. The external verification is the real one: compare your file's SHA-1 or MD5 against the No-Intro database, which records the exact hash of the correct, header-free dump for each cartridge revision. Matching No-Intro means your file is bit-identical to the reference the entire preservation community agreed on. That is as close to certainty as this hobby offers.
Hashing on the command line
Every desktop OS ships a hasher. On Linux and macOS, sha1sum (or shasum -a 1 on macOS) and md5sum are all you need. Hash the file, take the value to the No-Intro DAT, and look for a match. Doing two independent dumps and hashing both is the fallback when your specific revision is not catalogued:
$ sha1sum ~/roms/snes/*.sfc
a2bc9f1e...e41d /home/user/roms/snes/CHRONO TRIGGER.sfc
# Re-dump the same cart and compare the two reads to each other:
$ sha1sum dump_pass1.sfc dump_pass2.sfc
a2bc9f1e...e41d dump_pass1.sfc
a2bc9f1e...e41d dump_pass2.sfc # identical = trust itExpected file sizes by megabit
Before you even hash, arithmetic catches gross errors instantly. Cartridge capacities are quoted in megabits; your file is measured in bytes. The conversion is eight megabits to the megabyte:
- 4 Mbit = 512 KB = 524,288 bytes (e.g., Super Mario World, Sonic the Hedgehog)
- 8 Mbit = 1 MB = 1,048,576 bytes
- 16 Mbit = 2 MB = 2,097,152 bytes
- 24 Mbit = 3 MB = 3,145,728 bytes
- 32 Mbit = 4 MB = 4,194,304 bytes (e.g., Chrono Trigger)
If your byte count is not one of these clean powers-and-multiples, autodetection likely mis-sized the read, and you go set forceSize in the config. A file that is not a round size is almost never a legitimately odd cartridge; it is a wrong guess.
Five Pitfalls to Avoid
These are the mistakes that turn a fifteen-minute job into an afternoon. Each has a fix.
Contacts, seating, and phantom bytes
Pitfall 1 — Skipping the clean. The most common ruined dump is not a broken cartridge, it is a dirty one. Oxidized contacts read intermittently, so the file is subtly different on each copy and never matches a checksum. Fix: clean with high-percentage isopropyl alcohol, reseat, and re-dump until two consecutive reads hash identically. If cleaning does not converge, suspect a bent pin in the slot or a marginal USB cable.
Pitfall 2 — Blaming the cartridge for the cable. A charge-only or damaged USB cable, or an underpowered front-panel port, produces read errors that look exactly like a dying cartridge. Fix: before you condemn any game, swap to a known-good data cable plugged directly into a rear port or a powered hub, and retry. This single substitution resolves a large fraction of "my Retrode is broken" reports.
Saves you overwrite by accident
Pitfall 3 — Writing a save back when you meant to read. The Retrode can restore a .srm to the cartridge, which is wonderful and dangerous. If sramReadonly is set to 0 and your file manager or a backup tool decides to sync a stale .srm onto the volume, it will overwrite the real save on the cart. Fix: leave sramReadonly = 1 for all normal dumping, and flip it to 0 only for the deliberate, careful moment you are restoring a known-good save, then flip it back. Treat that key like a physical write-protect tab.
Carts that lie about themselves
Pitfall 4 — Trusting autodetection on odd cartridges. Some cartridges report a size or mapper that the stock detection misreads, giving you a truncated or scrambled file that may still look plausible. Fix: always check the byte size against the megabit table, and when in doubt set forceSize and forceMapper explicitly. A verified No-Intro hash is the final word.
Pitfall 5 — Expecting SA-1 games to just work. SA-1 cartridges such as Super Mario RPG and Kirby Super Star remap the ROM into the SNES address space in a way the stock Retrode2 firmware does not reconstruct, so you get a partial or scrambled dump. It is fundamentally a memory-mapping problem, though several SA-1 titles piled copy-protection routines on top of it. Fix: do not fight it. SuperFX titles like Star Fox usually read fine, but for SA-1 you want a dedicated SA-1-capable dumper. Knowing which chip your problem cartridge uses saves you an hour of pointless re-seating.
Troubleshooting Table
Symptoms and their most likely causes, in the order you will actually encounter them. Work top to bottom; the cheap fixes are near the top for a reason.
| Symptom | Likely cause | Fix |
|---|---|---|
| No RETRODE volume appears at all | Charge-only cable, loose mini-B, or underpowered port | Use a known-good data cable straight to a rear port or powered hub; the unit is bus-powered |
| Drive mounts but is empty (label only) | Cartridge not detected before the header read | Raise detectionDelay, reseat squarely, clean the contacts, re-insert |
| ROM file is half the expected byte size | Autodetection mis-sized the cartridge | Set forceSize to the cartridge's true megabit value and re-insert |
| Every copy of the file hashes differently | Dirty or oxidized edge connector | Clean with isopropyl alcohol, reseat, re-dump until two reads match |
| .srm is blank or all 0xFF | Cartridge has no SRAM, or its battery is dead | Normal for ROM-only carts; a dead battery cannot be read back, only the empty space |
| SA-1 game dumps as garbage or will not boot | Stock firmware cannot reconstruct the SA-1 map | Use a dedicated SA-1-capable dumper; the Retrode2 stock cannot do it |
| Genesis title or region looks wrong | Header read glitch; region byte is cosmetic in the ROM | Re-dump and verify against No-Intro; region does not change the ROM data |
| Controller not seen by the emulator | Pad not mapped in input settings | The pad is a generic HID gamepad; bind it in your emulator's input menu |
| dfu-programmer reports "no device present" | Retrode not actually in DFU bootloader mode | Redo hold-HWB, tap-RESET, release-HWB; confirm lsusb shows 03eb:2ffb |
| Windows shows "Retrode" but no drive letter | Drive-letter collision | Assign a free letter in Disk Management, or try a different USB port |
| Copied ROM will not load in an old tool | Copier header present/absent, or wrong extension | Confirm .sfc vs .smc; strip a stray 512-byte SNES header if a legacy tool demands it |
| Volume will not unmount ("busy") | An indexer or antivirus is scanning the live filesystem | Close file managers, run sync, then eject; disable indexing on the volume |
Detection failures, in depth
If nothing mounts, resist the urge to reinstall anything, because there is nothing to reinstall. The failure is physical in ninety-plus percent of cases: cable, port, seating, or contacts, roughly in that order of likelihood. Prove the Retrode enumerates at all by checking dmesg or Device Manager for the "Retrode2" string. If the string appears but no disk follows, the USB link is fine and the cartridge read is the problem, which points you at seating and cleaning. If the string never appears, the link itself is dead, which points you at the cable and port. This one branch in the logic tree resolves most cases in under a minute.
Dump-quality failures, in depth
When a dump completes but will not verify, the discriminating test is repeatability. Dump twice and hash both. If the two reads are identical to each other but do not match No-Intro, you likely have an uncatalogued revision or a special-chip cartridge, not a bad read. If the two reads differ from each other, the fault is physical and intermittent, meaning contacts and cable again. Repeatability separates "my read is unreliable" from "my reference is missing," and those two problems have completely different fixes.
Advanced: Firmware and Plugins
Everything above uses the Retrode as shipped. These techniques push it further, and they are where the device earns its open-hardware reputation.
Firmware updates over DFU
The AT90USB1287 carries an Atmel DFU bootloader, so you can reflash the Retrode's firmware to pick up bug fixes and expanded compatibility. You enter the bootloader with a small hardware ritual: hold the HWB button, tap RESET, then release HWB. The unit re-enumerates as an Atmel DFU device. On Windows the classic tool is Atmel FLIP; cross-platform, use dfu-programmer. The later firmware line for the Retrode2 is the 0.18x series. The flash sequence is three commands:
# 1. Enter DFU: hold HWB, tap RESET, release HWB.
# 2. Confirm the bootloader enumerated (Atmel Corp.):
$ lsusb | grep -i atmel
Bus 001 Device 012: ID 03eb:2ffb Atmel Corp. at90usb AVR DFU bootloader
# 3. Erase, flash, reset:
$ sudo dfu-programmer at90usb1287 erase --force
$ sudo dfu-programmer at90usb1287 flash retrode_0.18d.hex
$ sudo dfu-programmer at90usb1287 resetThe one rule: match the .hex to your exact hardware, and do not interrupt the flash. A botched flash leaves you in the bootloader, which is annoying but recoverable by simply flashing again; a flash to the wrong target is worse. When in doubt, re-enter DFU and reflash a known-good image.
Plugins: N64, Game Boy, and 32X
The expansion header turns the Retrode2 into a small family of dumpers. Plugin adapters exist for Nintendo 64, Game Boy and Game Boy Advance, Sega Master System, Game Gear, and a Sega 32X adapter that the FAQ confirms working. Each plugin gets its own extension key in the config, which is why n64RomExt, gbRomExt, gbaRomExt, smsRomExt, and ggRomExt all exist. The workflow is identical: seat the adapter, seat the cartridge, mount, copy, verify. The plugins are the reason the Retrode is worth keeping even after you have dumped your SNES and Genesis shelves; the same base unit grows to cover a handheld and a 32-bit console with a swap of the top adapter.
The SA-1 problem, stated precisely
Because it comes up constantly: the reason SA-1 cartridges resist a stock Retrode2 is that the SA-1 is a coprocessor which remaps the ROM and RAM into the SNES address space, and the stock firmware reads the bus as a plain memory-mapped cartridge. The result is a dump that does not correspond to the linear ROM a No-Intro entry expects. This is a mapping mismatch first and a copy-protection story second, though several SA-1 titles did also ship protection routines. Practically, the honest answer is to use a dedicated SA-1-capable dumper for those specific games and to enjoy that SuperFX titles, which map more conventionally, generally read without drama. Know your enhancement chip and you will know your outcome before you insert the cartridge.
Playing Dumps (and the Law)
A verified dump is a file. Turning it back into a game, and understanding whether you are allowed to, is the last mile.
Loading dumps into RetroArch
The most common destination is RetroArch, where a Super Nintendo dump runs on a core like Snes9x or bsnes and a Genesis dump runs on Genesis Plus GX. Point RetroArch at your ROM folder, let it scan, and it builds a playlist; or load a core and content directly from the command line. Drop the .srm you rescued into the emulator's saves directory and your decades-old file picks up exactly where the cartridge left off. If you are new to RetroArch cores, our RetroArch cores setup guide walks the whole installation, and the official libretro documentation plus the Snes9x core page cover the per-core details.
# Load a dump directly with a specific core:
$ retroarch -L cores/snes9x_libretro.so "~/roms/snes/CHRONO TRIGGER.sfc"
# Genesis dumps use Genesis Plus GX:
$ retroarch -L cores/genesis_plus_gx_libretro.so "~/roms/genesis/SONIC THE HEDGEHOG.bin"If you would rather have a dedicated box than a desktop, a build like RetroPie on a spare PC gives you a couch-friendly front end for the same dumps. The point of dumping your own carts is that these files are yours and portable; they will outlive any single emulator or platform.
Hardware playback on FPGA
For the accuracy-obsessed, a dump does not have to run on emulation software at all. FPGA platforms reproduce the original console's logic at the gate level and load your verified ROM as if it were the cartridge. If you want the closest thing to plugging the real cart into the real console, the MiSTer FPGA scene is where that conversation lives. Dumping your own cartridge and running it on an FPGA core is, arguably, the most faithful form of preservation available to a private person: your silicon, your bytes, hardware-accurate playback.
The legal reality of dumping
Here is the part that separates a careful hobbyist from a defendant. The mechanical act of reading an unencrypted cartridge ROM does not circumvent a technological protection measure, because there is no access control to break, which means the anti-circumvention hammer of DMCA section 1201 does not fall on the dump itself. That is not the same as blanket permission. The reproduction of a copyrighted work is still governed by copyright, and the comfortable phrase "personal backup" describes a genuinely gray zone rather than a settled right. The defensible posture is narrow and boring: dump only cartridges you physically own, keep the files to yourself, and do not distribute. The entire ethical case for the Retrode over a torrent of somebody's pre-loaded twenty-five-thousand-game bundle is that you are copying your own property rather than trafficking in everyone else's. None of this is legal advice, and none of it protects you if you post the ROM. Own the cart, dump the cart, shut up about the cart.
The Complete Configuration
Everything, assembled. Copy this onto the RETRODE volume, tune the two or three values that matter to you, and you have a documented, safe setup you can reproduce on any machine.
A safe, documented RETRODE.CFG
This config write-protects saves by default, sets sane extensions for every system the plugin family covers, and comments the override keys you will occasionally need. Remember that deleting any line resets that parameter to the firmware default, so you can always prune back to safety:
; ================================================================
; RETRODE.CFG -- copy to the RETRODE volume; re-insert cart to apply.
; Delete any line to restore that parameter's firmware default.
; force* accepted values are firmware-specific: check your version.
; ================================================================
; ---- Safety ----
sramReadonly = 1 ; 1 = protect on-cart save (KEEP THIS)
detectionDelay = 3 ; raise (4,5,...) if detection is flaky
; ---- Sega quirks ----
segaSram16bit = 0 ; set 1 only for 16-bit-SRAM Sega carts
; ---- File extensions per system ----
snesRomExt = sfc
segaRomExt = bin
n64RomExt = z64
gbRomExt = gb
gbaRomExt = gba
smsRomExt = sms
ggRomExt = gg
sramExt = srm
; ---- Overrides (leave commented until autodetect fails) ----
; forceSystem = ; override detected console
; forceSize = ; override detected ROM size
; forceMapper = ; override detected mapper A one-shot verification script
To turn dumping into a repeatable routine, this small shell script copies whatever is on the RETRODE volume into dated folders and hashes it, so every dump is archived and fingerprinted the moment it lands:
#!/bin/sh
# dump-and-verify.sh -- copy from the Retrode and hash everything.
SRC="/run/media/$USER/RETRODE"
DEST="$HOME/roms/incoming"
if [ ! -d "$SRC" ]; then
echo "RETRODE volume not mounted at $SRC -- check cable and cart."
exit 1
fi
mkdir -p "$DEST"
cp "$SRC"/*.sfc "$SRC"/*.bin "$SRC"/*.srm "$DEST" 2>/dev/null
echo "Copied files:"
ls -l "$DEST"
echo
echo "SHA-1 checksums (compare against No-Intro):"
sha1sum "$DEST"/* 2>/dev/null
sync
echo "Done. Now eject the RETRODE volume before removing the cart."Run it after every insertion and you never again wonder whether you copied the save or verified the ROM; the script did both and told you.
Where to go from here
You now have the full loop: clean, seat, mount, copy, save, verify, eject. The reference material worth bookmarking is short and authoritative: the official Retrode site and its FAQ for device specifics and the Retrode3 status, Wikipedia's Retrode entry for history and context, No-Intro's DAT-o-MATIC for the checksums that make your dumps trustworthy, and the Genesis Plus GX docs for playing the Sega side back. The Retrode2 is a fifteen-year-old design that still does its one job perfectly because it was built around standards instead of software. Whenever the Retrode3 finally ships, that is the bar it has to clear: not more features, but the same stubborn, driver-free reliability. Until then, the machine on your desk already does everything this guide promised. Go dump your shelf.
Questions the search bar asks me
- Can I still buy a Retrode in 2026?
- The Retrode2 is still sold through the DragonBox store, which continued merchandising it into early 2026. The Retrode3 could not be ordered as of the site's August 12, 2026 update; the maker targets availability by the end of the year at an unconfirmed price under EUR 100, and directs buyers to sign up for notification at DragonBox. Early retail coverage recorded the older unit at $84.99.
- Is it legal to dump cartridges I own?
- Reading an unencrypted cartridge ROM does not circumvent any technological protection measure, so DMCA section 1201 anti-circumvention is not triggered by the dump itself. But reproduction is still governed by copyright, and the personal-backup concept is a legal gray zone, not a settled right. The defensible posture: dump only carts you physically own and never distribute the files. This is not legal advice.
- Why won't my Super Mario RPG dump correctly?
- It uses the SA-1 coprocessor, which remaps the ROM into the SNES address space in a way the stock Retrode2 firmware does not reconstruct, so you get a partial or scrambled file. It is primarily a memory-mapping mismatch, though some SA-1 titles added copy protection on top. SuperFX carts like Star Fox usually read fine; for SA-1 games you need a dedicated SA-1-capable dumper.
- Do I need drivers or special software?
- No. The Retrode2 is class-compliant: it presents itself as a USB Mass Storage device and a USB HID device, both natively supported on Linux, macOS, and Windows with no driver install. The FAQ describes it as wrapping the cartridge's memory chips into virtual files on a USB drive; copying the .sfc or .bin file off the mounted RETRODE volume is the dump.
- What actually changes between Retrode2 and Retrode3?
- The Retrode2 runs on an 8-bit Atmel AT90USB1287 over a USB mini-B port. The Retrode3 replaces that with a MIPS system-on-chip running Linux, adds built-in Wi-Fi and a browser-based interface, and is fully open in both hardware and software. As of August 2026 the Retrode3 hardware is finished but the software is still in progress, with a target price under EUR 100.