Retrode 2026: Dump Your Carts in 12 Steps Before the 3

There is a specific kind of person who owns a shoebox of Super Nintendo cartridges and a low, nagging suspicion that the coin cells inside them are quietly dying. This tutorial is for that person. The tool is a Retrode: a small grey box that turns a thirty-year-old cartridge into a file on a USB drive, and a controller into something your PC recognises without a single driver installed. In 2026 there are two Retrodes worth discussing — the Retrode2 you can actually buy, and the Retrode3 you cannot. We will cover both, in that order of usefulness. By the end you will have a verified, checksummed dump of every cart you own, a RetroArch library that recognises them by name, and a working understanding of why exactly four of your favourite games refuse to cooperate.

This is a hardware tutorial with a legal subtext, written by someone who reads the FAQ so you do not have to. We will not tell you where to download anything. We will tell you how to read the plastic you already paid for.

What a Retrode Actually Is

Before you plug anything in, understand the trick, because the trick is the entire product. The official FAQ defines the Retrode as "a USB interface for vintage video game cartridges and controllers." That sentence is doing a lot of work, and every step below is a consequence of it.

A cartridge, presented as a folder

When you insert a Super Nintendo or Sega Genesis cartridge and connect the Retrode over USB, the device wraps the cartridge's memory chips into what the manufacturer calls "virtual files on a USB drive." Your operating system sees a small removable volume — labelled RETRODE — and on that volume sits a file that is the game's ROM, plus a second file that is the cartridge's battery-backed save (its SRAM). Nothing is stored on the Retrode itself. Every time your computer reads that file, the Retrode reads the physical chips in the cartridge in real time. Pull the cart out and the file vanishes, because there was never a file — there was a cartridge pretending to be one.

A controller, presented as a gamepad

The second half of that definition matters just as much. The Retrode's side ports accept standard SNES and Sega (three- and six-button) controllers, and it makes those gamepads appear to the OS as "USB HID-class controllers." HID — Human Interface Device — is the same generic class your mouse and keyboard use, which is why there is no driver to install on Linux, macOS, or Windows. Plug an original SNES pad into the Retrode, and it becomes a plug-and-play USB gamepad you can bind in RetroArch. The device enumerates as a composite USB peripheral: one mass-storage endpoint for the cartridge, plus one or more HID endpoints for the controllers, up to four pads at once.

What it is not

A Retrode is not an emulator — it runs no games, it only reads them. It is not a flash cart — it does not write new games onto cartridges. It is not a copy-protection defeat device; on the contrary, it is defeated by copy protection, which we will get to. And it is not the only way to do this. The DIY crowd has long used Sanni's open-source Cart Reader, an Arduino-based project that reads far more systems but demands a soldering iron and patience. The Retrode's pitch has always been the opposite: no assembly, no drivers, insert cart, copy file. The Retrode3, as we will see, tries to have both.

Retrode3 vs Retrode2 in 2026

If you searched for "Retrode" in 2026, you were probably chasing the announcement, not the product. Here is the deflating clarification up front: the Retrode3 is not for sale yet, and everything actionable in this tutorial is done with a Retrode2. That out of the way, the 3 is genuinely interesting.

The Retrode3 spec sheet, and the catch

The official Retrode site now carries the tagline "The Open-Source Retro Cartridge Reader, Reinvented." The reinvention is a full computer inside the box: a MIPS processor running Linux (Debian-based, per the project's repositories), with the OS booting from an SD card for updates and, in the company's phrasing, making the thing "practically unbrickable" — worst case, you reflash the card. It adds built-in Wi-Fi to, quote, "dump over the network, store ROMs on a server, and update game databases or the OS online," and both the "software and the hardware design are freely available" on GitHub. It is Made in Germany. Cartridge-wise it keeps SNES/SFC and Mega Drive/Genesis and, new to the family, adds a NES slot, reading both ROM and SRAM. Conceptually it merges the Retrode2's plug-and-play with the flexibility of Sanni's Cart Reader — DragonBox has said it is "pretty straightforward to port Sannis Cart Reader code to the Retrode3 and vice versa," and that it has "10 fully working prototypes" while recruiting developers.

Now the catch, verbatim from the site: "We are aiming for availability by the end of the year; an exact date and the final price are still to be confirmed." The price target is under EUR 100. The hardware is finished; the software is not. And critically: "The Retrode3 cannot be ordered yet — you can sign up to be notified at our friends at DragonBox." That is the whole status: done in silicon, unfinished in code, buyable in theory only.

The USB-Ethernet browser pivot

The most consequential design change is invisible on the spec sheet. A Retrode2 enumerates as USB mass storage, so you interact with it through your file manager. The Retrode3, being a small Linux machine, instead registers as a USB-Ethernet device and serves a web interface — you drive it from a browser, with no drivers and no mounted volume. Point a browser at the address it advertises (something like http://retrode.local; the exact host is defined by the firmware) and dump from there, or over Wi-Fi straight to a server. It is a cleaner model that also means every workflow in this tutorial's Retrode2 sections will change shape when the 3 ships.

What you can actually buy today

The Retrode2 is still sold through the DragonBox store, and it is the device this guide targets, because a tutorial for a product that "cannot be ordered yet" is a press release with delusions of usefulness. If the browser-driven, Wi-Fi, NES-capable Retrode3 is what you want, do the sensible thing: sign up for the notification and buy a 2 in the meantime. Your dumps will be identical files either way.

The Legal Part Nobody Reads

The Machine knows the law, and the law here is less friendly than the retro-hobby forums imply. This is not legal advice, it is US-centric, and it is the part you should read twice.

Dumping what you own

The comforting phrase "you're allowed to back up games you own" does not appear anywhere in US copyright statute as a general right. The archival exception at 17 U.S.C. § 117 covers computer programs, but courts have generally declined to extend it to console game ROMs, and it only ever permitted copies made as an essential step in using the program or for archival purposes tied to the original. There is no bright-line federal "personal backup" right for a Super Nintendo cartridge. What you have is a grey area that is widely tolerated for genuinely personal, non-distributed copies of media you physically own — which is exactly what a Retrode produces — but "tolerated" is not "authorised."

The circumvention question

The DMCA's anti-circumvention rules, 17 U.S.C. § 1201, prohibit defeating technological protection measures. The good news for the Retrode is structural: it does not circumvent anything. It reads the raw cartridge bus and passes the data through. In fact, it is stopped by protection — the official FAQ notes that chips such as the SA-1, S-DD1, and Sega's Virtua Processor are "currently not supported" precisely because they "act as copy protection mechanisms between console and ROM/RAM chips." A device that cannot read your copy-protected carts is a poor candidate for a circumvention lawsuit.

Downloaded ROMs are a different animal

Do not confuse dumping with downloading. A file you pull off your own cartridge sits in the tolerated grey zone; a file you download because you "own the cart anyway" is, in the eyes of the law, ordinary infringement — the ownership of a physical copy does not license a copy from a third party. Distributing your own dumps is infringement, full stop. If you want the long version of how the community rationalises pre-loaded storage, see our breakdown of what happens when a handheld ships with 28,000 games it did not license. The Retrode's entire value proposition is that it keeps you on the defensible side of that line: your plastic, your file, your drawer.

Prerequisites and Gear

Gather this before you start. The list is short because the device is simple, but two items — clean carts and a hash database — separate a good dump from a rumour.

The hardware you need

• A Retrode2, from the DragonBox store. Check whether your unit uses a mini-USB or a later USB connector and grab the matching cable.
• The cartridges themselves, ideally with clean contacts. Budget for a bottle of 99% isopropyl alcohol and cotton swabs — 70% "rubbing" alcohol leaves water behind and is the wrong tool.
• A host computer with a real USB port. Prefer a port on the machine itself over an unpowered hub; the Retrode draws its power from USB and a marginal hub causes mid-dump disconnects.
• Local storage for the dumps — any internal disk is fine; a 4 MB ROM is tiny by modern standards.

The software you need

• Any modern OS. The FAQ's stated requirement is literally "anything with a USB host port that runs a modern operating system (Linux, Mac OS X, Windows, you name it)." No drivers.
• A hashing tool. sha1sum/md5sum ship with Linux and macOS; on Windows use certutil -hashfile. You need this to verify dumps.
• A No-Intro DAT and a manager such as clrmamepro or RomVault, so you can compare your dump's checksum against the canonical database at No-Intro's DAT-o-MATIC.
• RetroArch, current stable (1.22.x as of late 2025), if you intend to play the dumps. Cores discussed later.
• For firmware updates: dfu-programmer on Linux/macOS, or Atmel FLIP on Windows. Optional unless your unit is old.

Optional adapters and what they cover

The Retrode2 accepts three official plug-in adapters that extend it beyond SNES and Genesis: an N64 adapter, a combined Game Boy / Game Boy Advance adapter, and a Sega Master System adapter. Two warnings from the FAQ save you money: the Sega 32X adapter works when used without its power supply, but Super Game Boy, the RetroPort series, and similar pass-throughs do not work at all — they "contain a full console and don't pass the cartridge data through to the Retrode." If you want cartridge-accurate N64 play rather than dumping, that is a different device entirely; see our look at the Analogue 3D and its twelve firmware builds.

The 12-Step Dump

This is the core of the tutorial: twelve steps from a dirty cartridge to a verified file, roughly forty-five minutes for your first one and about ninety seconds per cart once you find the rhythm. Each step has a reason attached, because a step you understand is a step you can debug.

1. Clean the cartridge contacts. Rationale: a thirty-year-old edge connector is the single most common cause of a bad dump. Dampen a cotton swab with 99% isopropyl alcohol, wipe the gold contacts until the swab comes away clean, and let it dry fully. Do not blow into the cartridge — the moisture from your breath is the actual origin of the corrosion you are cleaning off.
2. Confirm or update the firmware first. Rationale: the current public firmware (0.17f) fixes cartridge-detection and filename-handling bugs present in older units. If your unit is new from DragonBox it is likely current; if it has been in a drawer since 2013, jump to the firmware section, flash it, and come back. A stale firmware produces mystifying detection failures you will otherwise blame on the cart.
3. Seat the cartridge firmly. Rationale: the Retrode reads the physical bus, so mechanical contact is the data path. Push the cart fully into the SNES or Genesis slot following the silkscreen orientation on the shell. Order relative to plugging in the USB cable does not matter; seating depth does.
4. Connect USB and confirm enumeration. Rationale: if the OS never sees a mass-storage device and an HID gamepad, nothing downstream can work. On Linux, watch the kernel log:

   $ sudo dmesg --follow
   usb 1-3: new full-speed USB device number 9 using xhci_hcd
   usb 1-3: New USB device found, idVendor=xxxx, idProduct=xxxx
   usb 1-3: Product: Retrode2
   usb-storage 1-3:1.0: USB Mass Storage device detected
   scsi host6: usb-storage 1-3:1.0
   sd 6:0:0:0: [sdb] 8192 512-byte logical blocks: (4.19 MB/4.00 MiB)
   sd 6:0:0:0: [sdb] Attached SCSI removable disk
   input: Retrode2 Gamepad as /devices/pci0000:00/.../input/input25
   hid-generic 0003:XXXX:XXXX.000A: input,hidraw4: USB HID v1.11 Gamepad [Retrode2 Gamepad]

   The vendor and product IDs vary by firmware and are not worth memorising; the two lines that matter are USB Mass Storage device detected and the USB HID v1.11 Gamepad. On Windows a removable drive appears in Explorer; on macOS a volume mounts on the desktop.
5. Open the RETRODE volume and read the listing. Rationale: this confirms the cartridge — not just the device — was recognised, and it teaches you the naming quirk. The Retrode names files from the cartridge's internal header, in uppercase, not from any nice database:

   $ ls -la /media/$USER/RETRODE/
   total 4096
   -r--r--r-- 1 user user 4194304 Aug  7 11:20 'CHRONO TRIGGER.SFC'
   -r--r--r-- 1 user user    8192 Aug  7 11:20 'CHRONO TRIGGER.SRM'
   -r-xr-xr-x 1 user user     512 Aug  7 11:20  RETRODE.CFG

   That 4,194,304-byte .SFC is Chrono Trigger's 32-megabit ROM read live off the cart; the 8,192-byte .SRM is its save; RETRODE.CFG is the settings file we edit later.
6. Copy the ROM off the drive — do not open it in place. Rationale: every access to the virtual file re-reads the cartridge over a slow USB link, so working "live" is both sluggish and fragile. Copy it to local disk once:

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

7. Copy the .SRM save as well. Rationale: the battery that holds that save has been discharging since the Clinton administration. This copy may be the last time that save data is legible. Grab it now:

   $ cp -v '/media/'$USER'/RETRODE/CHRONO TRIGGER.SRM' ~/dumps/

8. Verify the dump against No-Intro. Rationale: a correct dump has a known, canonical checksum; a match is proof, a mismatch is a warning. Hash your file and compare it to the DAT entry:

   $ cd ~/dumps && sha1sum 'CHRONO TRIGGER.SFC'
   <40-hex SHA-1>  CHRONO TRIGGER.SFC   # compare this to the No-Intro DAT; illustrative value

   If the string equals the No-Intro entry byte-for-byte, you are done with this cart. If it does not, do not panic and do not keep it — continue to step 9.
9. Re-seat, re-clean, and dump twice. Rationale: intermittent contact produces different wrong bytes on each read, so the definitive test for a flaky cart is repeatability. Clean again, re-seat, dump a second time, and hash both. Two identical hashes mean you can trust the read even if it does not yet match a DAT (region variants exist); two different hashes mean your contact is bad, not your database.
10. Rename to the No-Intro canonical name. Rationale: CHRONO TRIGGER.SFC is the header name; Chrono Trigger (USA).sfc is what every scraper, playlist, and future version of you expects. Renaming now means box art and metadata later just work.
11. Batch by system and keep a rhythm. Rationale: swapping carts is the slow part, so do all your SNES carts, then all your Genesis carts, rather than hunting for adapters between each. On Windows, always eject the drive before pulling a cart; hot-swapping a mounted volume invites filesystem confusion.
12. Eject safely and store dumps with their checksums. Rationale: a backup you cannot verify is a rumour, not a backup. Keep the .sfc/.md, the .srm, and a checksums.sha1 file together. When you migrate that folder to a NAS in 2029, the hashes are how you prove nothing rotted in transit.

Configuring RETRODE.CFG

The RETRODE.CFG file you saw in the listing is how you change the device's behaviour, and it is refreshingly primitive: a plain-text file living on the RETRODE volume itself. You edit it in place with any text editor.

How the file works

Open RETRODE.CFG from the mounted drive, change a value, and save it back to the drive. The new setting takes effect the next time the device re-enumerates — unplug and replug. There is one elegant rule that saves you from yourself: deleting a line restores that parameter to its firmware default. Broke something? Delete the line, replug, and that setting reverts. There is one trap: line numbers shift between firmware versions, so documentation that says "line 15 does X" is only true for one firmware. Trust the parameter names and their described function, not their position. The authoritative reference is the project's own RETRODE.CFG documentation.

The two settings that actually matter

Most of the file is fine at defaults. Two parameters are worth knowing. The first controls filename numbering — whether dumped files get a running numeric prefix; set it off and your files are named purely from the cart header, which is usually what you want for scripted renaming. The second is the important one: the SRAM read-only flag. By default the Retrode treats cartridge saves as read-only (safe). Turn that flag off and the device will write changes to the .srm on the drive back onto the cartridge's physical SRAM. That is a genuine feature — it lets you restore a save to a real cart — and a genuine footgun, because a careless edit now overwrites a real save on real hardware. Leave it read-only unless you specifically intend to write.

An illustrative config

Below is the format, not gospel — the exact tokens are defined by your firmware and the official reference above. Treat the labels as descriptions of each line's job:

# RETRODE.CFG — illustrative of format; parameter NAMES/behaviour matter, order shifts by firmware.
# Delete any line to restore that parameter's factory default.
# Reference: https://retrode.org/documentation/the-retrode-cfg-file/

numberedFilenames   0    # 1 = prefix dumps with a running number; 0 = header name only
sramReadonly        1    # 1 = SAFE (read-only saves); 0 = write .srm changes BACK to the cart

If you want the full, exhaustively-commented working file, it is reproduced at the end of this guide.

Updating the Firmware

Skip this section if your Retrode2 is new and dumps verify cleanly. Read it if your unit is old, mis-detects carts, or mangles filenames — those are firmware-era bugs.

Why and when

The Retrode2's brain is a Microchip AT90USB646 microcontroller, and its firmware is flashable. The current public build is 0.17f; the canonical list lives on the official firmware page. Newer firmware improves cartridge detection and filename handling — the two things most likely to make an old unit look broken. There is one inviolable rule: never flash Retrode2 firmware onto a Retrode1, or vice versa. They are different hardware; cross-flashing bricks the device. Verify which you have before you download a single hex file.

Entering DFU mode

Flashing happens in the microcontroller's Device Firmware Upgrade (DFU) bootloader. To enter it, hold the RESET button (on the front) and the HWB button (on the back) together, then release RESET first and HWB second. The order is the part people get wrong; release them in the wrong sequence and you drop back into normal mode. In DFU mode the device stops presenting the RETRODE drive and instead waits for a flasher.

Flashing on Linux/macOS vs Windows

On Linux or macOS, dfu-programmer does the whole job from a terminal. Confirm the chip, erase it, write the new image, and reset:

# Linux / macOS with dfu-programmer
$ dfu-programmer at90usb646 get product-revision   # confirm the chip is talking
$ dfu-programmer at90usb646 erase
$ dfu-programmer at90usb646 flash retrode2_v0.17f.hex
# then press RESET on the device to run the new firmware

On Windows, use Atmel FLIP: select device AT90USB646, open the USB connection (Settings > Communication > USB), load the hex file, hit Run, then press RESET on the Retrode. Either way, when the device re-enumerates you will see the RETRODE drive again. On the forthcoming Retrode3 this entire ritual disappears: because the OS boots from an SD card, a bad update is fixed by reflashing the card image, which is what "practically unbrickable" means in the marketing.

Dumps into RetroArch

You now own verified .sfc, .smc, .md, and .bin files. Playing them is a RetroArch job, and RetroArch has opinions about cores.

Pick the right core

For SNES, the practical default is Snes9x — fast, accurate enough for almost everything, and it runs on a potato. If you want cycle-accurate emulation and have the CPU headroom, bsnes is the accuracy benchmark. For Genesis, Genesis Plus GX is the all-rounder; BlastEm is the accuracy pick. Loading is Load Core > pick core > Load Content > your dumped file. If you want the full, twelve-step treatment of installing and updating cores — including the trap where the wrong info files break scanning — we wrote it up separately in our RetroArch cores setup guide.

Import content and scan

Do not add ROMs one at a time. Use Import Content > Scan Directory, point it at ~/dumps, and RetroArch matches each file's checksum against its bundled database, builds a per-system playlist, and pulls box art. This is the payoff for verifying and renaming your dumps earlier: files that match No-Intro get recognised instantly; a garbled dump silently fails to match, which is a free second opinion on your dumping. The mechanics of scanning and playlists are documented at the official libretro documentation.

SRAM, saves, and not overwriting them

Your Retrode-dumped .srm is raw SRAM, and for the overwhelming majority of games that is exactly the format RetroArch expects, so dropping the .srm next to the ROM (or in RetroArch's saves directory) resurrects your original cartridge save inside the emulator. One caution: let RetroArch load the save before you play, and keep a copy of the Retrode dump elsewhere, because the moment you save in-emulator, RetroArch writes its own .srm over that path. Back up first, then play. Want those dumps on something pocket-sized instead of a desktop? They will run identically on the handhelds in our Retroid Pocket 6 comparison — same files, smaller screen.

Five Pitfalls

These are the failures that produce a file which looks fine and is not. Each has a specific fix.

Enhancement-chip games that refuse to dump

Some SNES cartridges contain a coprocessor, and the Retrode's relationship with them is uneven. Games using Super FX (Star Fox, Yoshi's Island, Stunt Race FX) and DSP-1 (Super Mario Kart, Pilotwings) dump fine. But games using SA-1 (Super Mario RPG, Kirby Super Star, Kirby's Dream Land 3), S-DD1 (Star Ocean, Street Fighter Alpha 2), or Sega's Virtua Processor (Virtua Racing) will not dump on a stock Retrode, because the FAQ tells us those chips sit between the console and the ROM as copy protection. Fix: there is no fix on the Retrode itself — these need a dumper that talks to the coprocessor, such as Sanni's Cart Reader. Do not mistake a truncated SA-1 dump for a bad clean; the chip is the wall.

Dirty contacts masquerading as everything else

Oxidised contacts cause the widest range of confusing symptoms: no file at all, a zero-byte file, a half-length ROM, or a dump whose hash changes every read. Fix: 99% isopropyl, dump twice, compare hashes. If two consecutive dumps disagree, it is always contacts, never the database.

Trusting a single read

A dump that hashes to something is not a dump that hashes to the right thing, and a lone read gives you no way to tell a clean cart from a flaky one. Fix: dump every cart at least twice; identical checksums are your confidence, a No-Intro match is your proof.

Leaving SRAM write mode enabled

If you ever flipped the sramReadonly flag off to restore a save and forgot to flip it back, you are one careless file operation away from overwriting a real cartridge save with garbage. Fix: return the flag to its read-only default (or delete the line entirely to restore the default) the instant you finish a deliberate write.

Expecting pass-through adapters to work

Plugging a Super Game Boy, a RetroPort, or a similar adapter into the Retrode and waiting for a Game Boy ROM to appear is a guaranteed disappointment — those units contain a whole console and never expose the cartridge data. Fix: use the correct official plug-in (the Game Boy / GBA adapter for Game Boy carts), and remember the odd exception that the Sega 32X adapter works only when you leave its power supply disconnected.

Troubleshooting Table

Symptoms on the left, the usual cause in the middle, the fix on the right. Most Retrode problems are mechanical or firmware, almost never software.

Symptom	Likely cause	Fix
No drive appears at all	Cable, port, or underpowered hub	Use a rear/motherboard USB port and a known-good cable; avoid unpowered hubs
Drive mounts, but no ROM file	Cart not seated or dirty contacts	Re-seat firmly, clean with 99% IPA, replug the USB cable
ROM file is 0 bytes or too small	Bad detection or an SA-1/S-DD1 game	Clean and re-seat; if it is a known enhancement-chip title, it will not dump here
Checksum does not match No-Intro	Dirty contacts or a region variant	Dump twice; if the two agree, check the DAT for your region before assuming failure
Garbled or half-length ROM	Intermittent contact mid-read	Clean, re-seat, dump again; two matching reads = trust
Controller not detected	Wrong port, or HID not enumerated	Try both ports and replug; the SNES mouse only works on the LEFT port
.srm is all 0xFF or empty	Dead cartridge save battery	The save is gone, but the ROM still dumps fine; consider a CR2032 replacement
Retrode disconnects mid-copy	Marginal USB power draw	Powered port, shorter cable; copy the file rather than streaming from it
Windows says "you need to format this disk"	OS confused by the read-only virtual FS	Do NOT format — cancel, then open the drive normally; formatting does nothing useful
Firmware flash fails / no DFU	Wrong RESET+HWB sequence	Hold both, release RESET first then HWB; reinstall dfu-programmer or FLIP
32X or Master System cart won't read	Missing or misused adapter	Use the official plug-in; the 32X adapter works only WITHOUT its own PSU attached
Game Boy cart in a Super Game Boy adapter does nothing	Adapter contains a full console	Use the official Game Boy / GBA plug-in instead; pass-throughs never expose cart data

Advanced Tips

Once the basics are muscle memory, these push the workflow from "works" to "archival-grade."

Batch verification with a DAT

Hashing files one at a time does not scale past a shoebox. Point clrmamepro or RomVault at your dumps folder plus a current No-Intro DAT, and it will auto-rename matching files to their canonical names, flag mismatches as bad dumps, and tell you what is missing from a set. This turns "did that dump work?" from a manual chore into a batch report, and it is the same database RetroArch scans against, so a file that passes here scans cleanly there.

Multi-dump consensus for flaky carts

For a cartridge that simply will not verify, escalate from two dumps to three, then compare all three with cmp or by hash. For a genuinely marginal connector, the two matching reads out of three are almost always the correct data and the odd one out is the dropout. It is crude error-correction, and it works.

The 2026 landscape your dumps live in

Your verified files do not live in a vacuum, and 2026 gave them a lot of new homes. The retro-hardware site Retrolize argued that by May 2026 the sector had become "infrastructure" rather than nostalgia — hardware, software, legal access, and archival workflows all maturing together, which is exactly the world a checksummed cartridge dump belongs in. If a handheld is where your dumps are headed, note the naming minefield first: Retrode (this cartridge reader) is not Retroid (the handheld company) and neither is RetroDECK (the software frontend, still shipping its 0.10.0b line into January 2026). Retroid's own hardware had a bumpy 2026 — Notebookcheck reported the first batch of Retroid Pocket 6 pre-orders shipping in early January with a new batch in March, after the company bought a parallel demura calibration rig that programs up to twelve OLED panels at once, roughly ten times its prior capacity, with mass shipments starting January 21. Time Extension later reported Retroid teasing at least one more handheld for the second half of 2026, possibly dual-screen. Meanwhile the Evercade Nexus was slated for October 2026 with a 5.89-inch screen, dual analogue sticks, wireless headphone support, and EverSync multiplayer, alongside portable versions of The C64 and The Spectrum from Blaze Entertainment and Retro Games Ltd. The point for a dumper: the files you make this weekend will outlive every one of those devices, which is the entire argument for making them. If you would rather play on cycle-accurate silicon than emulate, the FPGA route is a different discipline — see our MiSTer Multisystem 2 breakdown.

Waiting for the 3, sensibly

The Retrode3's Wi-Fi and browser UI will make network dumping and online database updates genuinely nicer, and merging Sanni's OSCR should widen system support over time. But it is targeted for end of 2026 with unfinished software, so do not hold your library hostage to a device you cannot order. Dump now on a 2; the files transfer to a 3 with zero changes.

The Complete Configuration

Everything above, distilled into a working reference you can copy. Treat the config file as illustrative of the format — parameter behaviour is authoritative, exact token spelling is per your firmware and the official docs.

A full RETRODE.CFG

# ============================================================
# RETRODE.CFG — working reference (illustrative of format)
# Lives on the RETRODE volume. Edit in place, save, then replug.
# DELETE any line to restore that parameter's factory default.
# Line ORDER shifts between firmware versions — trust NAMES, not positions.
# Full reference: https://retrode.org/documentation/the-retrode-cfg-file/
# ============================================================

# --- Filenames ---
# Prefix each dump with a running number? 1 = on, 0 = header name only.
numberedFilenames   0

# --- SRAM safety (the important one) ---
# 1 = read-only saves (SAFE default).
# 0 = the Retrode WRITES .srm edits back onto the physical cart SRAM (DANGEROUS).
sramReadonly        1

# --- Everything else ---
# Additional documented parameters exist (extensions, split handling, etc.).
# Leave them at default unless the official reference tells you otherwise;
# deleting a line always reverts it. When in doubt, delete and replug.

A dump-and-verify shell snippet

#!/bin/sh
# Linux: copy every ROM and save off the mounted Retrode, then checksum them.
# Adjust the mount path to wherever your desktop auto-mounts RETRODE.
SRC="/media/$USER/RETRODE"
DST="$HOME/dumps"
mkdir -p "$DST"

# Copy ROMs and saves (do NOT edit them in place on the device).
cp -v "$SRC"/*.SFC "$SRC"/*.SMC "$SRC"/*.BIN "$SRC"/*.MD "$SRC"/*.SRM "$DST"/ 2>/dev/null

# Hash everything and write a manifest to compare against No-Intro.
cd "$DST" && sha1sum ./* 2>/dev/null | tee checksums.sha1
echo "Done. Compare checksums.sha1 against https://datomatic.no-intro.org/"

The one-paragraph summary

Clean the cart, confirm the RETRODE drive and an HID gamepad enumerate, copy the ROM and the .srm to local disk, hash the ROM and match it to No-Intro, dump twice for anything that does not match, rename to canonical, and scan the folder in RetroArch. Leave sramReadonly at 1. Accept that SA-1, S-DD1, and Virtua-Processor games will not dump here. And when the Retrode3's open-source repositories finally ship a finished build at the end of 2026, your verified library will already be waiting for it — which was always the point of owning the plastic.