Retrode 2026: Dump a Cartridge in 12 Steps, 20 Min

There is a specific kind of person who owns a cartridge they have not been able to play since a CRT died in 2006, and who assumes that getting the game off the plastic and onto a hard drive requires a soldering iron, a logic analyzer, and a working knowledge of the 65816 instruction set. That person is wrong, and has been wrong since roughly 2009. The tool that proves it is the Retrode.

This is a tutorial. By the end of it you will have taken a Super Nintendo or Sega Genesis cartridge you legally own, plugged it into a plastic box the size of a stapler, and copied a byte-perfect image of the game — plus a save file older than some of the people reading this — onto your computer without installing a single driver. It takes about twenty minutes the first time and closer to five once you stop reading the manual. We will also deal with the Retrode3, announced for the end of 2026, because you are going to hear about it and you should know precisely what it changes and, more importantly, what it does not.

Why Bother With a Retrode in 2026

The honest answer is that your cartridges are dying and you have not noticed yet. The mask ROM that holds the game code is one of the most stable storage media humanity has ever produced; it will likely outlast the concrete it is stored in. The coin cell soldered next to it, quietly backing up the SRAM that holds your saved game, is not. It has been leaking a few microamps since the Clinton administration, and when it finally quits, your seventy-hour Chrono Trigger file goes with it. The Retrode is the least dramatic way to get that data out before physics gets a vote.

The device that refuses to be obsolete

Retrode's own FAQ describes the platform as a USB interface for vintage video game cartridges and controllers — a box that turns cartridge memory chips into virtual files on a USB drive while exposing the gamepads as USB HID-class controllers. The same FAQ makes the faintly defiant claim that the system is "not soon to be outdated" and that there is "plenty of room for new features." Every hardware company says something like this. The Retrode is one of the few where the claim has aged into fact: the design from over a decade ago still does exactly what a 2026 buyer needs, which is to say it reads a cartridge and hands you a file.

Preservation stopped being a hobby

Retrolize argued in May 2026 that retro gaming has quietly become infrastructure — licensed handhelds, FPGA recreations, dedicated preservation tools, serious emulator progress, and archival workflows that look less like nostalgia and more like logistics. That is the correct frame. The romance of the hobby is largely gone; what remains is a supply-chain problem in which the failing component is a battery-backed static RAM chip and the fix is a twenty-euro USB adapter. Dumping a cart is not sentimental. It is data recovery from a medium that was never engineered for a forty-year retention window.

What this guide actually covers

Precision matters here, because there are two devices with nearly the same name. The hardware you can hold in your hand today is the Retrode2. The Retrode3 is announced but not orderable, targeting availability by the end of 2026. This tutorial is written against the Retrode2, because that is the unit that will dump your carts this afternoon. Everything transfers to the 3 conceptually — same slots, same file model — so nothing here goes stale when the successor ships. If you want the condensed version, we have already run a shorter Retrode 2 walkthrough; this is the long form, with the config file, the failure modes, and the firmware.

How the Retrode Actually Works

Understanding the mechanism is not optional trivia. Nearly every problem you will hit is explained by the fact that the Retrode is doing something far dumber, and far more elegant, than people assume. It is not an emulator. It does not "read the game." It reads memory.

Two USB devices wearing one plastic shell

Plug the Retrode into a computer and the operating system enumerates two separate things. The first is a USB Mass Storage device — as far as your OS is concerned, you plugged in a flash drive. The second is one or more USB HID devices — human interface devices, meaning gamepads. Both classes are standard, which is the entire point. Windows, macOS, and Linux have shipped class-compliant drivers for both since before the Retrode existed. There is no installer, no kernel extension, no signed driver package, no "unknown device" in Device Manager. This is why the Retrode still works flawlessly on an operating system released fifteen years after the hardware was designed: it never asked the OS for anything special.

Cartridge memory becomes a file

When you insert a cartridge, the Retrode reads its address and data lines and presents the contents as ordinary files at the root of that virtual drive. Insert a SNES cart and a .sfc file appears, named from the cartridge's internal header. Insert a Genesis cart and you get a .bin. The on-cartridge save RAM shows up as a separate .srm file, and there is a plain-text RETRODE.CFG at the root for configuration. Copying the ROM file off that drive is the dump. There is no "extract" step, no proprietary format, no ceremony. A representative listing looks like this:

E:\> dir
 Volume in drive E is RETRODE

 SUPER METROID.SFC      3,145,728  bytes
 SUPER METROID.SRM          8,192  bytes
 RETRODE.CFG                  348  bytes

Those numbers are not arbitrary. Super Metroid is a 24-megabit cartridge, and 24 megabits is exactly 3,145,728 bytes. The save file is 8,192 bytes because the cart carries 8 KB of battery-backed SRAM. When the sizes match what the game is supposed to be, the read almost certainly went clean. When they do not, you have a problem to diagnose before you trust the file — which is the whole reason the later sections exist.

What it can and cannot read

The Retrode2 reliably handles standard mask-ROM cartridges for the SNES and Super Famicom, the Sega Genesis, Mega Drive, and — with the right slot — Master System, plus their on-cartridge SRAM saves and original controllers. What it struggles with is anything that fights back. SNES cartridges built around certain enhancement chips, particularly the SA-1 with its anti-piracy behavior, resist a stock dump. Light guns and multitaps are unsupported. There is exactly one charming exception documented in the manual: the SNES mouse works, but only on the left controller port. Plug-in adapters extend the hardware to the Nintendo 64, Game Boy, and Game Boy Advance, which we cover under advanced tips.

Prerequisites: Hardware and Software

You need less than you think. The dump itself requires nothing but the adapter and a computer. The full workflow — verify, tune, preserve — adds a handful of free tools, all of which you may already have.

The hardware you need

• A Retrode2. This is the shipping unit; the 3 cannot be ordered yet.
• A USB-A to USB mini-B cable that carries data, not just power. The Retrode2 uses a mini-B port, not micro and not USB-C, and this trips up more first-timers than any other single thing. A charge-only cable will power the LED and mount nothing.
• A computer with a real USB port. Prefer a port on the machine itself or a powered hub. The Retrode is bus-powered, and a large or electrically hungry cartridge can brown out on an unpowered hub, which manifests as intermittent, maddening read errors.
• The cartridges you own, plus optional plug-in adapters for N64, Game Boy, or GBA.
• 99% isopropyl alcohol and a lint-free swab or cloth. Not 70%, which is 30% water. Contacts, not conversation, are where dumps live or die.

The software you need, with versions

Strictly, nothing — it is a flash drive. For the real workflow:

• A terminal or file manager, both built into your OS.
• A checksum tool. Windows ships certutil; macOS and Linux ship shasum, md5, or sha1sum.
• A No-Intro DAT and a verifier. Grab the reference database from No-Intro and feed it to clrmamepro or the cross-platform RomVault.
• An emulator to confirm the dump boots. The current 2026 stable build of RetroArch with the Snes9x and Genesis Plus GX cores is the pragmatic choice; the core documentation lives in the libretro docs.
• For firmware, Microchip's FLIP on Windows or the cross-platform dfu-programmer. You will not need this to dump a cart, only to update the adapter.

The legal footnote nobody reads

Since this is The Machine writing, we will be precise rather than cheerful. The Retrode does not circumvent a technological protection measure in the DMCA sense — it reads the same memory the console reads, and a standard cartridge exposes no access control to break, so the anti-circumvention provisions generally are not triggered by the act of dumping. What remains is copyright itself. Making a personal archival copy of software you physically own sits in a genuine gray area: 17 U.S.C. § 117 permits certain copies as an "essential step" in using a program, a clause courts have read narrowly, and there is no broad statutory right to back up your games the way § 1008 shields personal audio copying. Distributing a dump is straightforward infringement. Keeping a copy of a cart on your own shelf is the sort of thing that is technically unsettled and practically ignored. Dump your own carts. Do not upload them. The distinction is the whole of the law that will ever matter to you.

The 12-Step Dump Workflow

Here is the procedure, start to finish, with the reasoning attached to each step, because a step you perform without understanding is a step you will skip at exactly the wrong moment. Nothing here requires more dexterity than inserting a cartridge, which you have done before.

Before you plug anything in (steps 1–3)

1. Clean the cartridge contacts. Wipe the edge connector with a swab dampened in 99% isopropyl alcohol and let it dry completely. Rationale: the single most common cause of a bad dump is a dirty edge connector. One flaky data line does not throw an error — it silently flips bits, and you get a file that looks the right size and fails a checksum for reasons you cannot see. And no, do not blow into the cartridge; the 1990s were wrong. Moisture accelerates the oxidation you are trying to remove.
2. Inspect the slot and seat the cart firmly. Push the cartridge fully home and confirm it does not wobble. Rationale: the manual itself warns that smaller carts can fit loosely. A partially seated cart leaves address lines floating, and floating lines produce either garbage or a truncated dump that ends early with no warning.
3. Connect the Retrode to a powered port. Use a port on the computer or a powered hub, not a bus-powered one daisy-chained off your keyboard. Rationale: the adapter draws its power from USB, and a marginal supply causes reads that succeed on a small cart and fail on a large one, which is the most confusing failure mode there is because it looks like the cart's fault.

The dump itself (steps 4–8)

4. Wait for the drive to mount, then open it. Confirm the operating system shows a new removable volume named RETRODE. Rationale: if the Mass Storage device never appears, nothing downstream can work, and the fix is almost always the cable or the port — not the software. Diagnose here, not three steps later.
5. Read the filename to confirm detection. The Retrode derives the file's name from the cartridge's internal header. A correct game name means the header read cleanly. Rationale: a generic name, a garbled name, or the wrong region is your first smoke alarm. The header lives in the same memory as the game, so a header the adapter cannot parse implies a read it cannot trust.
6. Check the file size against the known ROM size. A 4-megabit game should be 512 KB; a 24-megabit game, 3,145,728 bytes. Rationale: a size that is wrong — especially a too-small power of two — signals a detection or mapper misread, which you fix in the config file, not by copying a corrupt image and hoping.
7. Copy the ROM file to a working folder. Do not open it in place. Drag the .sfc or .bin onto your local disk. Rationale: reading over USB from the cartridge is slow, and opening the file directly in an emulator streams it live from the plastic, locking the drive and risking a crash if the cart shifts. A stable local copy is also what you will hash.
8. Copy the .srm save file, if it exists and you care about it. Rationale: that save lives on the dying, coin-cell-backed SRAM described earlier. This copy may be the only surviving record of a file created in 1997, and there is no second chance once the battery goes.

Closing out (steps 9–12)

9. Eject or unmount before removing the cartridge. Rationale: standard flash-drive hygiene. Pulling a cart mid-read can leave you a half-written copy, and if you enabled SRAM writing (covered later), it can corrupt the save you just tried to preserve.
10. Hash the copied ROM. Compute an MD5 or SHA-1 of your local copy. Rationale: the hash is a fingerprint. A dump you cannot fingerprint is a dump you cannot compare against anything, which means a dump you cannot trust.
11. Match the hash against a No-Intro DAT. Rationale: this confirms byte-for-byte identity with a known-good dump. A mismatch narrows the cause immediately — a bad read, an overdump, a different revision, or a ROM hack — and tells you whether to re-dump or celebrate.
12. Load it in an emulator and actually play it for a minute. Boot the game, watch the title screen, load the save. Rationale: checksums catch bit errors; they do not catch "you dumped the PAL revision and expected NTSC." Only after the game runs and the save loads is the cartridge genuinely backed up. Until then you have a file, not a preservation.

Verify the Dump, Then Load It

Step 10 and 11 above deserve their own section, because verification is the difference between an archive and a folder of hopeful guesses. USB reads over a corroded connector fail quietly. The adapter will not tell you a data line glitched. Something has to, and that something is a hash compared against a reference.

Why a checksum is not optional

The No-Intro project exists precisely to be that reference: it maintains databases — DAT files — of cryptographic hashes for known-good, verified dumps of cartridge software. When your file's SHA-1 matches a No-Intro entry, you have mathematical proof that your dump is bit-identical to a copy the preservation community has already vetted. When it does not match, you have learned something specific rather than nothing. This is not paranoia; it is the only mechanism that distinguishes a clean read from a subtly broken one, and the two look identical in a file browser.

Computing the hashes

Every desktop OS can do this without extra software. Use whichever line matches your platform:

# Windows (PowerShell or cmd)
certutil -hashfile "your-rom.sfc" SHA1

# macOS
shasum -a 1 your-rom.sfc

# Linux
sha1sum your-rom.sfc

The output is a 40-character hexadecimal string — your fingerprint. It looks like this, and the exact value is whatever your specific dump produces:

SHA1 hash of your-rom.sfc:
da39a3ee5e6b4b0d3255bfef95601890afd80709
CertUtil: -hashfile command completed successfully.

Paste that string into RomVault or clrmamepro loaded with the matching No-Intro DAT. A green result is the end of the story. A red one sends you back to step 1 with clean contacts and a powered port.

Loading into RetroArch

Once verified, the dump is just a ROM. For SNES content, load the Snes9x core (or bsnes for accuracy at the cost of CPU); for Sega, use Genesis Plus GX. RetroArch keys its save files to the ROM's base name, so if you place your dumped .srm where the emulator expects it, your original cartridge save loads intact:

RetroArch/
  saves/
    Super Metroid.srm      # your dumped save, named to match the ROM
  system/
  cores/

# Snes9x loads "Super Metroid.sfc" and reads the
# matching .srm from the saves folder automatically.

If you would rather not manage folders by hand, the verified ROMs drop cleanly into a turnkey front-end — a Batocera build will scrape and organize them without you touching a config, which is a reasonable trade if you value your evening.

Tuning RETRODE.CFG

The RETRODE.CFG file at the root of the virtual drive is where the adapter stops being a black box and starts being yours. Most people never open it, which is fine, because the defaults are sane. But when a cart misbehaves, this file is usually the fix, and it is worth ten minutes of your attention.

How the file works

It is a plain-text file. Open it in any editor, change a value, save it back to the drive, and re-seat the cartridge (or replug the adapter) so the new settings take effect. The one rule worth memorizing: deleting a line resets that parameter to its factory default. So there is no way to permanently break it — if you get lost, delete the line you were editing and the adapter reverts to shipped behavior. Your firmware version may differ slightly in spacing or comment style; edit the values, not the key names.

The parameters that matter

A handful of keys carry most of the useful behavior. A minimal, sensible block looks like this:

filenameChksum=1     # append a checksum to the ROM filename
detectionDelay=200   # settle time after a cart is inserted or pulled
sramReadonly=1       # 1 = write-protect the on-cart save (safe default)
segaSram16bit=0      # use 16-bit words for Sega SRAM when set to 1
snesRomExt=sfc       # extension for SNES dumps
segaRomExt=bin       # extension for Sega dumps
sramExt=srm          # extension for save files

The filenameChksum flag is quietly the best one: with it on, the checksum rides along in the filename, so you can eyeball whether two dumps of the same cart agree without hashing them. The extension keys exist because different emulators are opinionated — some want .smc instead of .sfc, some want .gen or .md instead of .bin for Sega — and rather than rename files forever, you set the adapter to emit what your toolchain expects.

Forcing detection for stubborn carts

When autodetect misreads a cartridge — wrong size, wrong system, no detection at all — three override keys take control. Accepted values are firmware-defined, so consult the official RETRODE.CFG documentation for the exact vocabulary your firmware understands, and change one field at a time:

# Override autodetect ONLY when a cart misreads.
# Accepted values are firmware-defined; leave blank to autodetect.
forceSystem=snes     # e.g. snes | sega | n64 ...
forceSize=           # blank = let the adapter decide
forceMapper=         # blank = let the adapter decide

The discipline here is non-negotiable: forcing the wrong size gives you an overdump (padded with junk) or an underdump (truncated), both of which fail No-Intro. So set one field, re-dump, re-hash, and only move to the next field if the hash is still wrong. Treat it like a bisection, not a lottery.

Saves and Original Controllers

The Retrode is two tools pretending to be one: a dumper and an input adapter. We have spent most of this guide on the dumping. The other half is why the box has controller ports on its flanks, and why the save file is arguably the more urgent thing to rescue than the ROM.

Backing up the SRAM (the part that is actually dying)

Say it again, because it is the thesis of the whole exercise: the ROM is effectively immortal, and the save is not. The .srm file is your saved game, held in static RAM that a coin cell has been keeping alive for decades. Copy it the moment you dump the cart. If you own a shelf of RPGs, dump their saves first and their ROMs second, because the ROMs will still be readable in fifty years and the saves might not survive the summer.

Writing a save back to the cartridge

The Retrode can also write a save back onto a cart — restore a backup, or inject a save edited on a PC. By default the config ships with sramReadonly=1, which write-protects the cartridge so a stray file operation cannot clobber a decades-old file. To write, you flip the flag, copy the save on, and flip it back:

# 1) In RETRODE.CFG, disable write-protection:
sramReadonly=0

# 2) Copy your backup onto the cart's save file:
cp "Super Metroid.srm"  /Volumes/RETRODE/

# 3) Re-seat the cart, confirm the save in-game, then
#    immediately restore protection:
sramReadonly=1

Leave it at 0 only while you are actively writing. A writable SRAM is a save you can destroy by accident — a drag-and-drop misfire, an OS that decides to "clean up" the drive — so the safe state is protected, and you visit the unsafe state deliberately and briefly.

Original pads as USB controllers

The controller ports on the sides of the adapter expose original SNES and Genesis gamepads to the computer as standard USB HID devices. This is not a gimmick; it is the correct way to play your freshly dumped ROMs, with the actual pad the game was designed around, latency and all. In RetroArch you may need a joypad autoconfig profile so the buttons map sanely — the community maintains these in the libretro retroarch-joypad-autoconfig repository, and there has been a standing request to add a canonical Retrode profile there. Remember the hardware limits from earlier: regular controllers only, no light guns, no multitaps, and the SNES mouse works exclusively on the left port.

Common Pitfalls That Ruin Dumps

Most Retrode failures are not exotic. They are the same five or six mistakes, made in the same order, by everyone. Here they are with their fixes, so you can make different mistakes instead.

Contacts, power, and patience

• Dirty contacts producing intermittent bytes. Symptom: the same cart hashes differently on repeated dumps. Fix: 99% isopropyl on the edge connector, dry fully, re-dump twice, and trust the result only when two consecutive dumps produce identical hashes.
• An unpowered hub causing brownouts. Symptom: small carts dump fine, large ones fail or truncate. Fix: move to a rear-panel port or a powered hub. This is not the cartridge's fault, however much it looks like it.
• Opening the ROM directly from the Retrode drive. Symptom: sluggish loading, and an emulator crash if the cart shifts a millimeter. Fix: always copy to local disk first. The virtual drive is a reading window, not a hard drive.

Trust, chips, and expectations

• Trusting a dump without a hash. Symptom: a corrupt ROM that boots to a title screen and then glitches an hour later, deep in the game. Fix: verify against No-Intro every single time. A file that boots is not a file that is correct.
• Fighting an enhancement-chip cart. Symptom: an SA-1 title (Super Mario RPG, Kirby Super Star) that will not dump or dumps to a file that fails verification. Fix: recognize the limitation. The stock Retrode2 cannot beat the SA-1's anti-piracy behavior, and forcing a size only manufactures a corrupt file. These need dedicated hardware, discussed below.
• Expecting it to be a cart writer. Symptom: disappointment that you cannot burn a downloaded ROM onto a blank cartridge. Fix: adjust the expectation. The Retrode reads ROM and reads/writes SRAM; it is not a flasher for arbitrary game code. Reproduction carts are a different tool entirely.

Troubleshooting

When something goes wrong, work the table top to bottom. The failures are ordered roughly from "most common and most trivial" to "actual hardware limitation," so the first match is usually the real cause.

The diagnostic table

Advanced Tips

Once the basic workflow is muscle memory, three topics separate people who dump a few carts from people who dump a collection: knowing which cartridges will fight you, keeping the firmware current, and extending the adapter to systems it did not ship supporting.

The enhancement-chip reality check

Some SNES cartridges carry a coprocessor, and the coprocessor changes everything about how the memory is addressed. SuperFX titles (Star Fox, Yoshi's Island) often read acceptably. The wall is the SA-1 — the chip in Super Mario RPG and Kirby Super Star — whose anti-piracy behavior the stock Retrode2 was never designed to defeat. Others in this family include the S-DD1, SPC7110, CX4, and the various DSP variants. When you hit one, do not force a size and pretend the resulting file is real; a corrupt dump that passes as valid is worse than an honest failure. The dumping community has documented the electrical requirements in detail — clocking, refresh, and reset timing on specific pins — and people have built dedicated Arduino-based dumpers that handle these chips. For a shelf that is mostly ordinary carts with a handful of enhancement-chip exceptions, dump the ordinary ones on the Retrode and set the exceptions aside for the right tool.

Firmware updates via FLIP or dfu-programmer

The Retrode2 is built around an Atmel AT90USB1287 microcontroller, and its firmware is field-updatable. You enter the bootloader with a button sequence — hold HWB, tap RESET, release HWB — after which the adapter enumerates as a DFU device. On Windows you flash the firmware .hex with Microchip's FLIP; everywhere else, use the command-line dfu-programmer:

# Put the Retrode in DFU mode first:
#   hold HWB, tap RESET, release HWB
dfu-programmer at90usb1287 erase
dfu-programmer at90usb1287 flash retrode-0.18d.hex
dfu-programmer at90usb1287 reset

The later firmware sits in the 0.18x line (0.18d beta 3 is a real, circulated build). Two cautions: keep a copy of your current firmware before you flash, because an interrupted write can leave the adapter unresponsive until you re-flash it; and if you are on the shipped firmware and everything already dumps and verifies, there is no prize for updating. Firmware is a fix for a problem, not a chore to perform on a schedule.

Plug-in adapters for other systems

The Retrode2's expansion connector accepts plug-in modules that route entirely different cartridge pinouts through the same USB machinery. With the right plug-in, the box dumps Nintendo 64, Game Boy, and Game Boy Advance carts, all exposed through the identical file model: insert cart, copy file. N64 dumps are larger and correspondingly slower over the mini-B connection, and GBA saves come in several flavors (SRAM, flash, EEPROM) that you will want to verify individually. The elegance is that nothing about your workflow changes — the same clean-contacts, copy-locally, hash-against-No-Intro discipline applies whether the cart is a 4-megabit Genesis game or a 256-megabit GBA release.

The Retrode3 and the 2026 Market

You did not come here to be sold the next thing, and I am not going to sell it to you. But the Retrode3 is real, it is coming, and understanding it is the difference between a smart purchase and a regretted one.

What the Retrode3 actually changes

Per the company's own site, the Retrode3 is the official successor to the Retrode2, described as a device for reading original cartridges and using original controllers on a modern computer. The new model adds a MIPS processor running Linux, built-in Wi-Fi, and fully open software and hardware. The company says the hardware is finished, the software is still in progress, and availability is targeted for the end of 2026, at a target price under EUR 100 — though the final price and exact date remain unconfirmed as of the latest site copy. You cannot order one yet; the site directs interested buyers to register for notification through DragonBox, which places the product firmly in the pre-announcement phase rather than at retail. The 2012 Sega-16 interview with creator Matthias Hullin and the 2011 Hackaday write-up on the Retrode II's added controller ports are useful reminders that this is a project with a fifteen-year track record, not a crowdfunding cold start; the basic timeline is also on Wikipedia.

The Machine's read: a MIPS core, Linux, and Wi-Fi turn an elegantly dumb Mass Storage bridge into a networked appliance. In principle you could dump straight to a NAS with no host PC babysitting the transfer — the adapter becomes the computer. Pricing it under EUR 100 keeps it a preservation tool rather than a collector's trophy, which is consistent with the FAQ's insistence that the platform is built to last. Open hardware means it outlives the company that made it, which for a preservation device is not a marketing bullet but the entire point.

Why cartridge dumping still matters

Return to Retrolize's "infrastructure" framing, and look at what the rest of the market is doing in 2026. The handheld segment is industrializing: Time Extension reported in January 2026 that Retroid had purchased a parallel demura calibration system for the Retroid Pocket 6, able to calibrate up to twelve OLED panels at once, with screen-production capacity expected to rise roughly tenfold and mass shipments anticipated to begin on 21 January 2026. Notebookcheck added that the first batch of pre-orders would start shipping in early January 2026 with a new batch in March, and that Retroid's official account was signaling at least one more handheld — an iXBT-reported dual-screen device — for the second half of the year. That is what maturity looks like: not one hero product, but calibration rigs and shipping cadences. Your dumps have somewhere to go, whether that is a Retroid Pocket in your pocket or a Miyoo Mini Plus stuffed with your own legally-dumped library.

Should you wait for the 3?

If you already own carts and a computer, no. The Retrode2 works today, and the 3 is a convenience-and-openness upgrade, not a capability leap for basic dumping — a MIPS core does not read a mask ROM any more correctly than an AVR does. If you are buying fresh, have no urgent saves to rescue, and can wait until the end of 2026 for built-in Wi-Fi, an open Linux platform, and open hardware under EUR 100, the 3 is the better long-term bet — with the standing caveat that the company itself calls the software "in progress," and unfinished software has a way of slipping past year-end targets. The pragmatic move is the one we have argued before: dump your carts now, before the 3 ships, because the coin cells in your cartridges do not care about product roadmaps.

A Complete Working RETRODE.CFG

Here is a full, annotated configuration you can drop onto the drive as a sane baseline for a dump-and-verify workflow. Every key is one the firmware recognizes; the force-detect fields are left blank so autodetect stays in charge until a specific cart forces your hand. Remember the escape hatch: delete any line and that parameter reverts to its factory default.

# ------------------------------------------------------------
# RETRODE.CFG - dump-and-verify baseline
# Edit values, not keys. Delete a line to restore its default.
# ------------------------------------------------------------

# --- Filenames and detection ---
filenameChksum=1     # carry the checksum in the filename
detectionDelay=200   # settle time after insert/remove

# --- Save (SRAM) handling ---
sramReadonly=1       # 1 = protect on-cart save (safe default)
segaSram16bit=0      # set 1 only if a Sega save loads wrong

# --- File extensions (match your emulator) ---
snesRomExt=sfc       # some tools prefer smc
segaRomExt=bin       # some tools prefer gen or md
sramExt=srm
n64RomExt=z64        # for the N64 plug-in
gbRomExt=gb          # for the Game Boy plug-in
gbaRomExt=gba        # for the GBA plug-in
smsRomExt=sms
ggRomExt=gg

# --- Autodetect overrides (leave blank normally) ---
# Fill these ONLY when a specific cart misreads, one at a time,
# re-dumping and re-hashing after each change.
forceSystem=
forceSize=
forceMapper=

That is the whole platform in a text file: a naming convention, a save-protection switch, a set of extensions, and three manual overrides for the rare cartridge that will not identify itself. Notice what is not here — no accounts, no cloud, no license check, no telemetry. The point of the Retrode has never been features. It is that a plastic box designed over a decade ago still turns a dying cartridge into a file you can actually keep, verify, and play, on an operating system its designers never saw. The Retrode3 will add Wi-Fi and Linux and openness, and it will be welcome. But the job — get the data off the plastic before the battery dies — is the same job it has always been, and you can do it today.