Retrode 2026: Dump SNES & Genesis Carts in 12 Steps

There is a specific kind of person who owns a Super Nintendo cartridge, a working copy of that cartridge, and a low-grade dread that the battery-backed save inside it is going to die sometime around the heat death of the universe or next Tuesday, whichever arrives first. The Retrode was built for that person. It is not an emulator. It is not a flash cart. It is a small grey box with cartridge slots on top that pretends to be a USB thumb drive, and when you slot a game into it, the ROM shows up as a file you can copy. That is the entire trick, and it is a genuinely good trick.

In 2026 the situation around this device is, to use a technical term, a mess. The original creator has stepped back from direct sales. A forum post dated June 26, 2026 in the long-running "Retrode in the news!" thread says flatly, "I no longer sell the Retrode." Meanwhile the German retro shop DragonBox still lists the Retrode2 for sale, so the hardware is orphaned to a reseller rather than dead. And looming over all of it is the Retrode3, announced as a ground-up redesign around a MIPS processor running Linux with built-in Wi-Fi, hardware finished as of August 12, 2026, software still cooking, and a ship target of "end of 2026" that you should read with the same skepticism you apply to every crowdfunded release window since the invention of the calendar.

This guide is about the hardware you can actually buy and use today: the Retrode2. We will cover what it is, how it works, the twelve-step workflow for dumping your first cartridge, the RETRODE.CFG file that controls its behavior, the special-chip games that will fight you, and the firmware flashing you will eventually need. If you only want the fast version, we already published a twenty-minute quick-dump walkthrough. This is the long version, with the footnotes and the failure modes.

What the Retrode Actually Is in 2026

Before you buy anything or plug anything in, understand the category error most people make. The Retrode is not a way to play games. It is a way to get games off the physical media you already own, and to use the original controllers while you are at it. Confuse those two jobs and you will spend an afternoon angry at a device that is doing exactly what it was designed to do.

An interface, not an emulator

The single most important sentence in the entire Retrode FAQ is that the Retrode is not an emulator. It is an interface. The official description is refreshingly literal: 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." No emulation happens on the box. When you plug it into a PC over USB it enumerates as a standard USB Mass Storage device, the same device class as a flash drive, and it exposes the cartridge's ROM and save memory as ordinary files. You copy those files. Then you feed the ROM to a software emulator, which is where the actual playing occurs. The Wikipedia entry classifies it simply as a USB adapter for legacy video games, and that is exactly the right altitude to think about it.

This distinction also settles a legal question people tiptoe around. The Retrode circumvents nothing. It does not break copy protection, it does not decrypt anything, it reads the unprotected address and data lines that any console reads when the cart is inserted. Whether backing up a game you physically own is legal where you live is a separate matter and not something a grey box can answer for you, but the tool itself is not a DRM-cracking device. It is a card reader for silicon that happens to be shaped like a Genesis slot.

The 2026 status report

Here is the state of play, because it changes how you shop. The Retrode2 is the shipping hardware. Its official suggested retail was EUR 65 / USD 85, and third-party coverage confirms that price held remarkably steady: Uncrate still listed it at $85 as of December 1, 2025. The creator, Matthias Hullin, stopped selling directly, and the forum record puts that transition around June 26, 2026. DragonBox continues to carry it, which is currently the sane retail channel for a new unit. The official Retrode2 page still bills it, with no false modesty, as the "world's most versatile (and fun!) USB adapter for vintage video games."

The Retrode3 is vaporware until it is not. The Retrode homepage now headlines it under the tagline "The Open-Source Retro Cartridge Reader, Reinvented," with the exact promise that "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." You cannot order one. You can register interest through DragonBox and wait. We will come back to the Retrode3 at the end, but for the next several thousand words assume you have a Retrode2 in your hands, because that is the only version you can put a cartridge into today.

What it reads and what it refuses

Out of the box the Retrode2 handles two families of cartridge natively: Nintendo SNES / Super Famicom and Sega Genesis / Mega Drive. The two slots on top accept both regional shell shapes for their respective systems, because the pinouts are identical even when the plastic is not. It also exposes controller ports on the sides, so a real SNES or Genesis pad becomes a USB gamepad. Plug-in adapters extend the reach: there is an adapter that adds support for N64 cartridges and up to two controllers, and the FAQ confirms a working Sega 32X adapter, among others that appeared over the device's life for handheld carts and Master System media.

What it refuses, or refuses to do cleanly, is the interesting part, and it is mostly about enhancement chips. Games that carry the SA-1 coprocessor resist the stock firmware because those carts drive the bus themselves and layer on anti-piracy behavior. SuperFX carts generally read. Certain Genesis carts with unusual save hardware or bank-switching mappers need coaxing. And the controller support is deliberately basic: standard pads yes, light guns and multitaps no, with the SNES mouse working only on the left port. File all of that away; it becomes the difference between an afternoon of clean dumps and an afternoon of swearing.

Prerequisites: Hardware and Software

A dump is only as trustworthy as the setup that produced it. Skimp here and you will produce files that boot but corrupt a save three hours into a playthrough, which is the worst possible time to learn that your read was marginal. Assemble the following before you slot a single cartridge.

Hardware you actually need

The list is short and unglamorous. You need a Retrode2, sourced new from DragonBox or clean from the used market. You need a USB mini-B cable, because that is the port the Retrode2 uses, and no, it is not micro-B, and yes, the difference matters when you are rummaging in a cable drawer. You need the cartridges themselves, ideally the ones you own and want to preserve. You need a host computer with a real USB port; a powered hub is wise if you are dumping many carts in a session, because the Retrode draws its power over that bus and a flaky port produces flaky reads.

Optional but recommended: the relevant plug-in adapter if you intend to dump N64 or 32X media, a soft brush and isopropyl alcohol for cleaning contacts, and a controller or two if you want to use the HID feature. Do not buy a third-party charger-only USB cable; some of those omit the data lines entirely and will leave you convinced the device is broken when it is merely mute. The Retrode2 is built around an Atmel AT90USB1287 microcontroller, an 8-bit AVR with native USB, which is why it is class-compliant and why it does not need a driver on any modern operating system.

The software stack and versions

Because the Retrode is class-compliant USB Mass Storage, the "software" you need on the host is mostly software you already have: a file manager and a terminal. The official OS support statement is characteristically broad: "anything with a USB host port that runs a modern operating system (Linux, Mac OS X, Windows, you name it)." On Linux you want the standard usb-storage and vfat kernel modules present, which they are on every mainstream distribution. On macOS and Windows the drive simply mounts.

For the parts that go beyond copying files you will want three more things. First, a checksum tool, which every platform ships (sha1sum and crc32 on Linux, the equivalents elsewhere). Second, a verification database, namely a current No-Intro DAT for SNES and Genesis so you can confirm a dump is byte-perfect. Third, if you plan to update firmware, dfu-programmer on Linux and macOS or Atmel FLIP on Windows, which talk to the AVR's DFU bootloader. The latest firmware line for the Retrode2 sits around 0.18x, with 0.18d shipping as a public beta; note the version before you flash anything so you can roll back.

Cartridge condition matters more than you think

The Retrode reads through the physical edge connector, which means thirty-year-old oxidation on the contacts is your enemy. A cart that boots on a real console can still produce a bad dump, because a console has generous timing tolerances and a bit-banged reader does not. Before dumping anything valuable, clean the contacts: a cotton swab dampened, not soaked, with high-percentage isopropyl alcohol, wiped along the contact fingers until the swab comes away clean. Let it dry fully. Skip abrasive erasers and metal polish; they remove the plating you are trying to preserve.

Seat the cartridge firmly and squarely. A cart that sits at an angle bridges the wrong pins and produces a read that looks plausible and is quietly wrong. If you are dumping a batch, clean them all first so you are not context-switching between chemistry and computing. This is the least exciting paragraph in the guide and the one most likely to save you from a corrupt dump you do not notice for weeks.

How the Retrode Works Under the Hood

You do not strictly need to understand the internals to dump a cart, the same way you do not need to understand a lock to use a key. But every failure mode in the troubleshooting table below is an internal detail leaking into your afternoon, so ten minutes here pays for itself.

Mass Storage plus HID

The Retrode presents itself as two USB devices at once through a single cable. The first is a Mass Storage device, the class that flash drives use, which is how the ROM and save appear as files in a mounted volume with no driver installation. The second is a HID device, the class that keyboards and gamepads use, which is how the controllers plugged into the side ports show up to your emulator as standard USB pads. This composite design is the whole reason the thing is driverless: your operating system already knows how to talk to both classes.

Practically, that means when you plug in the Retrode you should expect to see a new removable drive appear and, if a controller is attached, a new game controller in your input settings. If only one of those shows up, you have learned something specific about what failed, which is more than most malfunctions offer you.

The AT90USB1287 and the cartridge bus

Inside, the AT90USB1287 drives the cartridge's address lines and reads back its data lines through general-purpose I/O, effectively walking the entire ROM address space and recording what each address returns. It then serves those bytes as a file over USB. This is why dumping is not instantaneous: the AVR runs at full-speed USB, not high-speed, and it is bit-banging a parallel bus one address window at a time. A small SNES ROM copies in well under a minute; a large one takes a few minutes. Patience here is normal and is not a fault.

It is also why timing matters. The detectionDelay configuration value exists precisely because a freshly inserted cartridge needs a moment to settle before the reader trusts what it sees. Insert a cart while the drive is mid-read and you will get partial nonsense. The correct rhythm is: insert cart, wait for the drive to remount, then copy.

Why mappers and headers matter

A ROM is not just a flat blob. SNES cartridges use memory mappers, chiefly LoROM and HiROM, that determine how the cartridge address space maps into the console's. The Retrode autodetects the mapper and size from the cartridge header, and most of the time it is right. When the header is unusual, or the cart uses an enhancement chip that rearranges the memory map, autodetection can guess wrong, and you get a dump that is the wrong size or has its banks interleaved incorrectly. That is what the forceSystem, forceSize, and forceMapper overrides in RETRODE.CFG are for: they let you tell the reader what you know that the header does not say clearly. We will use them in anger in the special-chips section.

Dumping Your First Cartridge in 12 Steps

Here is the full workflow, with a reason attached to every step, because a step you do not understand is a step you will skip at the worst moment. The examples assume Linux with the drive mounted at /media/$USER/RETRODE; on macOS it lands in /Volumes and on Windows it gets a drive letter, but the logic is identical.

Preparation: steps 1 through 4

1. Clean the cartridge contacts. As covered above, oxidation causes marginal reads that pass a casual glance and fail a checksum. Do this first so the rest of the process is trustworthy.
2. Connect the Retrode to the host with a data-capable USB mini-B cable, with no cartridge inserted yet. Powering the reader before inserting media lets it initialize cleanly and lets you confirm it enumerates at all before a cart complicates the picture.
3. Confirm the device enumerated. Check that the host sees the Retrode as a Mass Storage device. If this fails, nothing downstream will work, so verify it before touching a cartridge.

$ dmesg | tail
usb 1-2: new full-speed USB device number 14 using xhci_hcd
usb 1-2: Manufacturer: Retrode
usb 1-2: Product: Retrode2
usb-storage 1-2:1.0: USB Mass Storage device detected
sd 6:0:0:0: [sdb] Attached SCSI removable disk

4. Insert the cartridge squarely and wait for the drive to mount. The detectionDelay exists because the reader needs the cart to settle. Rushing this is the single most common cause of a partial dump. Give it a second or two after insertion before you do anything.

The dump: steps 5 through 8

5. List the mounted drive and confirm the expected files appear. You should see a ROM file, a save file if the cart has battery-backed SRAM, and the RETRODE.CFG. If the ROM filename or size looks absurd, stop, because that is autodetection telling you something is wrong before you waste time copying garbage.

$ ls -la /media/$USER/RETRODE/
total 520
-r--r--r-- 1 user user 524288 Jan  1  2000 SUPERMARIOWORLD.SFC
-rw-rw-rw- 1 user user   2048 Jan  1  2000 SUPERMARIOWORLD.SRM
-rw-rw-rw- 1 user user    512 Jan  1  2000 RETRODE.CFG

6. Copy the ROM file to a working directory on your disk. Never work off the mounted Retrode volume directly; copy to local storage first so the source is never at risk and so your emulator is not reading over USB. The -v flag echoes what happened so you have a record.

$ mkdir -p ~/dumps
$ cp -v /media/$USER/RETRODE/SUPERMARIOWORLD.SFC ~/dumps/
'/media/user/RETRODE/SUPERMARIOWORLD.SFC' -> '/home/user/dumps/SUPERMARIOWORLD.SFC'

$ ls -l ~/dumps/
-rw-r--r-- 1 user user 524288 Aug 22 14:03 SUPERMARIOWORLD.SFC

7. Copy the save file too, if one exists. The .SRM holds the on-cart battery-backed save. Preserving it captures your actual progress, not just the game. If there is no .SRM, the game may use EEPROM or no save at all, which is information, not necessarily a fault.
8. Verify the copied file size matches the ROM's real capacity. A 4 Mbit SNES game is 524288 bytes; an 8 Mbit game is 1048576. A size that is not a clean power-of-two megabit is a red flag for a bad read or a misdetected mapper. Catch it here, not after you have deleted the source.

Verify and eject: steps 9 through 12

9. Compute the checksum of your local copy. A SHA-1 or CRC32 is the only objective proof that a dump is good. Eyeballing a title screen is not verification; a marginal read can corrupt data far from anything you would notice in the first menu.

$ sha1sum ~/dumps/SUPERMARIOWORLD.SFC
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  SUPERMARIOWORLD.SFC

10. Compare the checksum against a No-Intro DAT entry for that exact game and region. If your hash matches the verified good dump, you are done and certain. If it does not, you have a bad dump or a rare revision, and either way you need to know before you trust it.
11. Unmount or eject the Retrode volume before removing the cartridge. Pulling media without unmounting risks leaving the filesystem view in a bad state on some hosts, and if you have SRAM writing enabled it risks the save. Eject cleanly.
12. Remove the cartridge and store it properly, then repeat for the next cart. Log the checksum somewhere. A dump you cannot later prove is good is a dump you will re-do in two years when you no longer trust your past self.

That is twelve steps. Nine of them are about not fooling yourself, which is the correct ratio for any preservation task. For the ROMs you produce, the natural next stop is a software emulator; our rundown of the current libretro core landscape covers which SNES and Genesis cores to actually load.

The RETRODE.CFG Configuration File

The RETRODE.CFG is the closest thing the device has to a control panel. It is a plain text file living on the Retrode's own virtual drive, stored in the microcontroller's memory and presented back to you as an editable file. Change a value, save the file back to the Retrode volume, then unplug and replug so the firmware reloads it. This is where you fix most autodetection problems.

Where RETRODE.CFG lives and how to edit it

The file sits in the root of the mounted Retrode drive, alongside whatever ROM and save the current cartridge produced. You edit it in place with any text editor and save. The critical operational detail, the one people miss, is that changes do not take effect until the device re-reads the file, which happens on replug. A second, genuinely useful behavior: deleting an entire line resets that parameter to its factory default. So if you have tinkered yourself into a corner, you do not need to remember the original value; you delete the line and the firmware restores its own default on the next boot.

The keys that matter

You will not touch most keys most of the time, but knowing the set saves you from guessing. The ones that earn their keep: sramReadonly controls whether the cart's save is write-protected, with 1 as the protected default and 0 making it writable, which you almost never want unless you are deliberately restoring a save to a cart. detectionDelay sets how long the reader waits before trusting a freshly inserted cart, in milliseconds; raise it if inserts are flaky. filenameChksum appends a checksum to generated filenames so you can tell dumps apart. segaSram16bit handles Genesis carts whose SRAM is wired 16-bit rather than 8-bit; flip it if a Genesis save reads as garbage. A family of extension keys, snesRomExt, segaRomExt, sramExt, and the handheld-oriented n64RomExt, gbRomExt, gbaRomExt, smsRomExt, and ggRomExt, let you choose the file extension the reader assigns. And the override trio, forceSystem, forceSize, and forceMapper, lets you overrule autodetection when a header lies. The exact accepted values for the force keys are firmware-defined, so read the comments in your own file rather than trusting any value you saw on the internet, including this article.

A representative config

Here is a sane starting point. Match the delimiter and formatting already present in your unit's file, because the syntax has varied across firmware revisions, and treat this as illustrative rather than a file to paste blindly.

# RETRODE.CFG -- edit a value, save back to the RETRODE drive, then replug.
# Delete an entire line to reset that key to its factory default.
# Keys and accepted values are firmware-defined: read this file's own header.

sramReadonly=1         # 1 = cart save is write-protected (recommended)
detectionDelay=1000    # ms to wait after a cart is inserted before reading
filenameChksum=1       # append a checksum to generated filenames
segaSram16bit=0        # set 1 for Genesis carts with 16-bit SRAM
snesRomExt=sfc         # extension for SNES dumps
segaRomExt=bin         # extension for Genesis/Mega Drive dumps
sramExt=srm            # extension for save-RAM files
# forceSystem=snes     # override autodetect: snes or genesis
# forceSize=...        # override detected size (firmware-defined values)
# forceMapper=...      # override detected mapper (firmware-defined values)

Verifying and Playing Your Dumps

A dump you have not verified is a rumor. This section is about turning a rumor into a fact, and then about actually using the result. It is short only because the tools do the work; the discipline is in doing it every time rather than the once you feel motivated.

Checksums against No-Intro and Redump

The preservation community maintains databases of known-good dumps, each identified by CRC32, MD5, and SHA-1. For cartridge systems the relevant one is No-Intro; for disc systems it is Redump, which you will not need here but should know exists. The workflow is mechanical: hash your dump, look up the game in the DAT, and compare. A match is proof. A mismatch means either a bad read or that you have a genuinely different revision, and telling those apart is why the DAT records multiple known revisions per title.

$ sha1sum ~/dumps/SUPERMARIOWORLD.SFC
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  SUPERMARIOWORLD.SFC

# Find the matching entry in a No-Intro DAT and compare the sha1 attribute:
<rom name="Super Mario World (USA).sfc" size="524288" crc="XXXXXXXX" sha1="xxxx..."/>
# If your 40-hex-digit SHA-1 equals the DAT's sha1, the dump is byte-perfect.

Save RAM and .SRM files

The .SRM the Retrode produces is the raw contents of the cartridge's battery-backed SRAM, which is your literal save data. Most emulators read this format directly, though a few expect a specific filename or a slightly different layout, so if a save will not load, the fix is usually renaming the file to match the ROM's base name or checking the emulator's save format setting. Keep the .SRM even if you do not care about the save today; that battery will eventually die, and the .SRM is the only record of the fact that in 1994 someone got to the last castle.

Loading in RetroArch and beyond

Once verified, a ROM is just a ROM. Load it into an SNES or Genesis core and it runs like any other, because as far as the emulator is concerned there is no difference between a dump you made and any other correct dump; a byte-perfect file is a byte-perfect file. For the mechanics of installing cores and pointing them at your dumps, the libretro documentation is the authoritative reference. If you would rather run everything from a single box, our guide to RetroPie on PC covers a full front-end that will happily ingest a folder of freshly dumped carts.

Five Common Pitfalls and Their Fixes

These are the failures that recur, grouped by where they come from. None is exotic. All of them have bitten people who assumed a device this simple could not possibly go wrong, which is precisely the mindset that produces a corrupt dump.

Physical and connection pitfalls

Pitfall 1: the charge-only cable. A USB cable that carries power but not data will leave the Retrode dark to the host or, worse, intermittently visible. The fix is a known-good data cable, and the diagnostic is that dmesg or your OS shows no Mass Storage device appearing at all. Test the cable with any other USB device before blaming the Retrode.

Pitfall 2: dirty or crooked cartridge contacts. This produces the nastiest failures because the dump completes and looks fine but fails a checksum, or corrupts data far from anything you would casually inspect. The fix is cleaning the contacts with isopropyl alcohol and reseating the cart squarely, then re-dumping and re-hashing. If two consecutive dumps of the same cart produce different checksums, contacts are almost always the culprit.

Wrong-size and interleave pitfalls

Pitfall 3: the wrong-size dump. If your ROM is not a clean power-of-two megabit, autodetection likely misread the header or the cart uses an unusual layout. The fix is to set forceSize in RETRODE.CFG to the correct capacity and re-dump. Knowing the game's real size, which the No-Intro DAT records, turns this from guesswork into a lookup.

Pitfall 4: interleaved or scrambled banks. A dump that is the right size but boots to garbage often has its memory banks mapped wrong, typically a LoROM/HiROM mismatch on SNES. The fix is forceMapper, set to the mapper the game actually uses. This is rare on plain carts and common on carts with enhancement chips, which is your cue to read the next section.

Save-data pitfalls

Pitfall 5: overwriting a cartridge save by accident. If sramReadonly is set to 0, the reader can write back to the cart's SRAM, and a stray operation can clobber a decades-old save. The fix is prevention: leave sramReadonly=1, which is the default, and only ever set it to 0 in a deliberate, one-off save-restore session that you undo immediately afterward. A related trap is expecting an .SRM from a game that saves via EEPROM rather than battery SRAM; the absence of a save file there is expected behavior, not a failure.

Special Chips, Firmware, and DFU

The clean carts are easy. The enhancement-chip carts are where the Retrode's limits, and your patience, get tested. This section is the difference between "it dumped most of my collection" and "it dumped my collection."

SA-1: the wall

The SA-1 is a fast coprocessor Nintendo put in a run of late SNES cartridges: Super Mario RPG, Kirby Super Star, Kirby's Dream Land 3, and others. It does not sit quietly on the bus; it drives it, arbitrates access, and includes anti-piracy behavior that assumes it is talking to a real console. The stock Retrode2 cannot clock an SA-1 cart into cooperating, so you get a failed read, a wrong size, or garbage. There is no config flag that reliably fixes this, because the problem is not detection, it is bus control. If you must dump SA-1 titles, the honest answer is a dedicated cartridge dumper built for enhancement chips. This is a known, documented limitation, not a defect in your unit, and no amount of contact cleaning changes it.

SuperFX, DSP, and the rest

Not every special chip is a wall. SuperFX carts, the ones with the GSU that powers Star Fox and Yoshi's Island, generally read on the Retrode, sometimes needing a mapper override. DSP-based games like Super Mario Kart and Pilotwings dump their main program ROM fine; the DSP's own microcode lives inside the coprocessor and is not something the Retrode needs to extract, because emulators supply it separately. The practical rule: if a dump comes out the wrong size or scrambled, try forceMapper and forceSize before concluding the cart is undumpable, and reserve "undumpable on this device" for the SA-1 tier.

Firmware and DFU flashing

New firmware can improve compatibility and fix bugs, and the Retrode2 firmware line reached around 0.18x, with 0.18d as a public beta. Updating means putting the AVR into its DFU bootloader and flashing a .hex file. The physical incantation is hold HWB, tap RESET, release HWB, after which the device re-enumerates as an Atmel DFU bootloader rather than a Retrode. From there, dfu-programmer handles the rest on Linux and macOS; Windows users can use Atmel FLIP. Record your current version before you start so you can roll back, and never interrupt a flash midway.

# DFU mode: hold HWB, tap RESET, release HWB. Unit re-enumerates as a bootloader.
$ lsusb | grep -i atmel
Bus 001 Device 021: ID 03eb:2ffb Atmel Corp. at90usb DFU bootloader

$ sudo dfu-programmer at90usb1287 erase
$ sudo dfu-programmer at90usb1287 flash retrode-0.18d.hex
Validating...
131072 bytes used
$ sudo dfu-programmer at90usb1287 reset

Troubleshooting Table

When something goes wrong, work down this table from the top, because it is ordered roughly from most common and cheapest to fix, toward least common and most annoying. Most of your problems are in the first four rows.

Symptoms, causes, and fixes

When to suspect the hardware itself

Hardware failure is the last thing to suspect, not the first, because the failure modes above are far more common and far cheaper to fix. Suspect the unit only after you have ruled out cable, contacts, config, and firmware. The telltale sign of an actual hardware fault is consistency of the wrong kind: the same specific corruption on multiple different clean carts, across multiple cables and ports, after a known-good firmware flash. Everything else points back to one of the mundane causes in the table.

Advanced Tips: N64, Controllers, Batch

Once you can reliably dump a single SNES or Genesis cart, the device has more to offer. None of this is required, but all of it is where the Retrode earns the "most versatile" tagline.

N64 and the plug-in adapters

The plug-in adapters extend the Retrode past its two native slots. The N64 adapter adds support for N64 cartridges and up to two controllers, and the FAQ confirms a working Sega 32X adapter as well, with other adapters having appeared for handheld and Master System media over the device's life. The workflow is the same as for native carts, with the caveat that N64 has its own size and save-format quirks, so verify against the No-Intro DAT exactly as you would for SNES. Buy the adapter for the system you actually own carts for; there is no point stockpiling adapters for media you do not have.

Controllers as USB gamepads

Because the Retrode exposes attached controllers as USB HID devices, a genuine SNES or Genesis pad plugged into the side ports becomes a standard game controller your emulator can map. This is quietly one of the best features: it lets you play your dumps with the original hardware feel and no adapter dongle. The limits are the ones already noted: standard pads only, no light guns, no multitaps, and the SNES mouse on the left port. If you are building a preservation-grade setup, dumping the cart and using its native controller through the same box is about as authentic as software emulation gets, and it pairs naturally with a good handheld target; our look at where those dumps end up on something like the Miyoo Mini Plus and its curated libraries covers the destination side.

Batch dumping and where the ROMs go

If you are preserving a shelf rather than a single game, script the repetitive part so you are only ever swapping carts. The following copies whatever ROM is present, hashes it into a running log, and grabs the save without ever writing back to the cart. Insert a cart, run it, eject, repeat.

#!/usr/bin/env bash
# dump-cart.sh -- copy the current cart to ~/dumps, log its checksum, never write back.
set -euo pipefail
MNT="/media/$USER/RETRODE"
OUT="$HOME/dumps"
mkdir -p "$OUT"
shopt -s nullglob
for rom in "$MNT"/*.SFC "$MNT"/*.BIN; do
  base="$(basename "$rom")"
  cp -v "$rom" "$OUT/$base"
  sha1sum "$OUT/$base" | tee -a "$OUT/checksums.txt"
done
cp -v "$MNT"/*.SRM "$OUT/" 2>/dev/null || echo "No SRM present (game may use EEPROM)."

The Retrode3 Horizon

Everything above concerns hardware you can hold. The Retrode3 is hardware you can only anticipate, and it is worth understanding what changes and what to do about it.

MIPS, Linux, and Wi-Fi

Where the Retrode2 is an 8-bit AVR pretending to be a flash drive, the Retrode3 is described as a small computer: a MIPS processor running Linux, with built-in Wi-Fi and fully open hardware and software. The pitch, "the open-source retro cartridge reader, reinvented," implies a browser-based interface and the option to talk to it over Wi-Fi rather than only USB. That is a categorical upgrade in flexibility. It also, potentially, changes the enhancement-chip calculus, because a Linux-class controller has vastly more room to handle awkward carts than an 8-bit microcontroller does, though nothing has been demonstrated on that front and you should not buy on the strength of a possibility.

Timeline and price

The official position, quoted verbatim from the homepage, is that "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." The hardware was reported finished as of August 12, 2026, with software still in development. You cannot order one; you register interest through DragonBox and wait. Read "end of the year" the way you read every hardware timeline: as an intention, not a promise, and note that the phrase resets every year until it does not.

Should you wait?

No, if you have carts to dump now, because a device that ships "by the end of the year" with an unconfirmed price is not a plan, it is a hope, and your battery-backed saves are decaying on their own schedule regardless. The Retrode2 works today, is proven, and its limitations are documented and mostly worked-around. Buy the Retrode2, dump your collection, and treat the Retrode3 as a pleasant future upgrade rather than a reason to leave a shelf of aging cartridges unpreserved. If preservation is the goal, the correct time to start is before the hardware you are waiting for exists.

The Complete Working Configuration

To close, here is a complete, annotated RETRODE.CFG and the full dump-and-verify routine in one place, so you have a reference that does not require scrolling back through the guide. Adapt the specifics to your firmware, because the exact keys and accepted values are firmware-defined, but the structure holds.

The annotated RETRODE.CFG

# ============================================================
# RETRODE.CFG -- complete annotated reference
# Edit a value, save the file back to the RETRODE drive, then
# unplug and replug so the firmware reloads it. Delete an
# entire line to reset that single key to its factory default.
# Keys and accepted force* values are firmware-defined: always
# check the comments in your own unit's file before trusting a value.
# ============================================================

# --- Save protection (leave this alone unless restoring a save) ---
sramReadonly=1          # 1 = cart SRAM is write-protected (default, recommended)

# --- Read timing ---
detectionDelay=1000     # ms to wait after insertion before reading a cart

# --- Filenames ---
filenameChksum=1        # append a checksum to generated filenames
snesRomExt=sfc          # SNES ROM extension
segaRomExt=bin          # Genesis / Mega Drive ROM extension
sramExt=srm             # save-RAM extension
n64RomExt=n64           # N64 ROM extension (with the N64 adapter)
gbRomExt=gb             # Game Boy ROM extension (with adapter)
gbaRomExt=gba           # Game Boy Advance ROM extension (with adapter)
smsRomExt=sms           # Master System ROM extension (with adapter)
ggRomExt=gg             # Game Gear ROM extension (with adapter)

# --- Sega save quirk ---
segaSram16bit=0         # set 1 for Genesis carts with 16-bit SRAM

# --- Overrides (uncomment only when autodetect is wrong) ---
# forceSystem=snes      # snes or genesis
# forceSize=...         # real capacity; firmware-defined values
# forceMapper=...       # e.g. lorom/hirom on supporting firmware

The dump-and-verify routine

And the operational loop, condensed. This is the whole job: enumerate, insert, copy, hash, compare, eject.

# 1. Confirm the Retrode enumerated as Mass Storage
dmesg | tail

# 2. Insert cart, wait for the mount, then list it
ls -la /media/$USER/RETRODE/

# 3. Copy ROM and save to local disk (never work off the USB volume)
mkdir -p ~/dumps
cp -v /media/$USER/RETRODE/*.SFC ~/dumps/
cp -v /media/$USER/RETRODE/*.SRM ~/dumps/ 2>/dev/null || true

# 4. Hash the local copy and log it
sha1sum ~/dumps/*.SFC | tee -a ~/dumps/checksums.txt

# 5. Compare each hash to the matching No-Intro DAT entry.
#    Match = byte-perfect. Mismatch = clean contacts and re-dump.

# 6. Eject cleanly before pulling the cart
udisksctl unmount -b /dev/sdb 2>/dev/null || umount /media/$USER/RETRODE

The final word

The Retrode is a narrow tool that does one thing with unusual honesty: it reads the silicon you own and hands you the bytes, no emulation, no theatrics, no DRM to circumvent because there is nothing to circumvent. In 2026 it sits in an awkward spot, discontinued by its creator, kept alive by a reseller, and shadowed by a successor that is perpetually almost here. None of that changes the job. If you have a shelf of cartridges and batteries that are quietly running down, the Retrode2 is a proven, driverless, documented way to get clean, verifiable dumps off them today. Clean the contacts, mind the SA-1 carts, keep sramReadonly at 1, hash everything, and you will end up with a library that outlives the hardware that stored it. Which was the entire point.