Retrode 2 in 2026: Dump Carts to ROMs in 14 Steps

The device is called the Retrode. Say it out loud in a room with anyone who reads horoscopes and watch their eyes light up, because for one syllable it sounds like the thing astrologers blame for every missed text and bricked router between February and November. We are going to use that confusion shamelessly, because a 2026 readership cannot scroll past the word retrograde without an opinion, and because the joke happens to be load-bearing: the Retrode is a USB cartridge reader, and the single most common reason a cartridge dump fails is the same reason your phone call dropped — bad contacts and worse planning, neither of which a planet caused.

Here is the actual subject. The Retrode 2 is a small plastic box with two cartridge slots that turns physical Super Nintendo and Sega Genesis cartridges into ROM files by reading the silicon directly and presenting it to your computer as if it were a USB thumb drive. No capture card, no soldering, no questionable download. You own the cart, you read the cart, you keep the file. This tutorial walks the entire procedure in fourteen numbered steps, covers Genesis as well as SNES, extracts your decades-old save games, verifies the dumps against the canonical preservation databases, and ends with a complete working configuration you can copy. Along the way the Machine will note exactly when Mercury, Jupiter, Saturn, and the rest are doing their backwards-looking pantomime in 2026, strictly so you have something to blame that is not your own dirty edge connector.

What the Retrode 2 Actually Is

Before you buy anything, understand what class of device this is, because the marketing around cartridge readers in 2026 is a swamp and half the products with similar names work nothing like this one.

A mass-storage device, not a flasher

The Retrode 2 enumerates over USB as a standard Mass Storage Class device. That is the entire trick and the entire genius. When you plug it in with a cartridge seated, your operating system sees a removable volume — typically labeled RETRODE — and inside that volume sits a file: Game Title.SFC for a SNES cart, Game Title.BIN or .GEN for a Genesis cart. You drag that file to your hard drive and you have a ROM. There is no proprietary client, no account, no firmware required on the host side. This is why it works identically on Windows 11, macOS, and Linux: every one of them has spoken USB Mass Storage fluently for twenty years. If you have ever copied a photo off a camera, you already know the workflow.

What it reads natively versus by adapter

The base unit reads two families directly through its two slots: Super Nintendo / Super Famicom on one side and Sega Genesis / Mega Drive on the other. Everything else — Nintendo 64, Game Boy, Game Boy Advance, Virtual Boy, Sega Master System with the appropriate converter — requires a plugin adapter that seats into the cartridge connector and re-pins it for the target system. The adapters are not emulated cleverness; they are physical wiring that lets the same microcontroller talk to a different cartridge bus. If a guide tells you a stock Retrode 2 dumps N64 carts without an adapter, that guide is wrong, and you should close it.

The controller ports nobody mentions

The Retrode 2 also exposes the original controller ports from both systems as USB HID gamepads. Plug a real SNES pad into the unit and your computer sees a generic USB controller, no extra driver. This matters more than it sounds: it means the same box that backs up your library also lets you play those backups with the genuine hardware input, which is the one thing software emulation of a controller can never quite replicate. We will configure this in the saves-and-controllers section. For now, file it under "reasons this device has survived since the early 2010s when fancier dumpers have come and gone."

Prerequisites: Hardware and Software Versions

Gather everything in this section before you start. Half of all failed dumps trace back to a missing cable or an out-of-date firmware, and the other half trace back to contacts you did not clean. None of them trace back to the cosmos, regardless of what the calendar says.

Hardware you must have

• A Retrode 2 unit with the latest firmware it shipped with, or flashable to current. Earlier hardware revisions exist; the procedure is identical, only the firmware file differs.
• A USB-A to mini-USB cable rated for data, not charge-only. This is the single most common silent failure: a charge-only cable powers the unit's LED but never enumerates the storage volume. If the light comes on but no drive appears, suspect the cable first.
• The cartridges themselves, ideally cleaned. A cotton swab, 90%+ isopropyl alcohol, and patience. Do not use a pencil eraser on the contacts despite what the internet told you in 2009 — it abrades the gold plating.
• Plugin adapters only if you are dumping N64, Game Boy, GBA, or Virtual Boy. Skip if you are only doing SNES and Genesis.
• A host computer with a USB 2.0 or 3.x port. The Retrode is a USB 2.0 device; plugging it into a 3.x port is fine and changes nothing about throughput, which is bounded by the cartridge bus, not the host.

Software versions for 2026

You need almost nothing, which is the point, but pin these versions:

• Operating system: Windows 10 21H2 or later, Windows 11, macOS 12 Monterey or later, or any current Linux distribution with a 5.x+ kernel. All mount Mass Storage out of the box.
• RetroArch 1.19 or newer for playing and verifying dumps. Pair it with current SNES and Genesis cores — bsnes-mercury, snes9x, or mesen-s for SNES; genesis_plus_gx or blastem for Sega. Our RetroArch cores setup walkthrough covers installing these cleanly in twelve steps if you are starting from zero.
• A checksum tool: md5sum and sha1sum on Linux/macOS, or CertUtil on Windows. Built in. No download.
• A DAT comparison tool (optional but recommended): No-Intro's DAT-o-MATIC for SNES headerless verification and Redump for disc systems, plus a ROM manager like ClrMamePro to read them.
• A serial terminal only if you intend to flash firmware — covered in the advanced section, skippable otherwise.

The 2026 retrograde calendar, for excuse-making purposes

Astrology calendars insist that Mercury retrograde scrambles communication, travel, and technology — which maps suspiciously well onto USB enumeration, file transfers, and firmware flashing if you are inclined to believe it. You are not. But for completeness, and because a 2026 reader expects it, here are the windows multiple sources cite, presented as a config block you should treat as commentary and not gospel:

# 2026-retrograde.conf -- DO NOT TREAT AS A DIAGNOSTIC TOOL
# Sources: Cafe Astrology, The AstroTwins, AstroSage, AstroChart.ai

mercury_retrograde_1 = "2026-02-26 .. 2026-03-20"   # ~24 days; some sources say 03-22
mercury_retrograde_2 = "2026-06-29 .. 2026-07-23"   # ~24 days; some sources say 07-24
mercury_retrograde_3 = "2026-10-24 .. 2026-11-13"   # ~22 days; some sources say 11-15

jupiter_retrograde   = "2025-11-11 .. 2026-03-10"   # in Cancer (Cafe Astrology / AstroTwins)
uranus_retrograde    = "... turns direct 2026-02-03; shadow ends 2026-05-21"
pluto_retrograde     = "2026-05-06 .. 2026-10-15"   # Aquarius; shadow 2026-01-12 .. 2027-02-06
saturn_retrograde    = "2026-07-26 .. 2026-12-10"   # Aries (AstroTwins); AstroSage says 07-27 in Pisces
neptune_retrograde   = "2026-07-07 .. 2026-12-12"   # Aries
venus_retrograde     = "2026-10-03 .. 2026-11-13"   # Scorpio into Libra
mars_retrograde      = none                          # "No Mars retrograde in 2026" (AstroChart.ai)

Note that the sources disagree by a day or two on nearly every boundary, which is the single most honest thing about astrology calendars: they are approximate. The Old Farmer's Almanac explains the underlying phenomenon correctly — retrograde is an optical illusion produced by Earth and an outer planet passing each other in their orbits, not actual reverse motion — and that is the only fact in this block worth keeping. If your dump fails during one of these windows, the cause is your edge connector. We will keep saying that.

Assembling the Unit and Cartridge Adapters

Out of the box the Retrode 2 needs almost no assembly, but the small things you do here determine whether the next hour is smooth or maddening.

Orientation and slot identification

The unit has two cartridge slots on its top face. One is shaped for SNES/Super Famicom cartridges, the other for Genesis/Mega Drive. They are physically keyed differently, so you cannot easily force a cart into the wrong slot, but you can seat one at an angle if you are impatient. Cartridges insert label-forward in the conventional orientation. Seat firmly until the cart sits flush and stops — not a slam, a deliberate press. A cart that rocks or sits proud will read intermittently, and intermittent reads are the worst kind because they produce a file that looks complete and is not.

Installing a plugin adapter

If you are dumping N64, Game Boy, GBA, or Virtual Boy, the plugin adapter seats into the cartridge connector before you insert the game. Power down — unplug the USB cable — install the adapter into the appropriate slot, then power back up. The unit reads the adapter on enumeration; hot-swapping an adapter while mounted is how you confuse the firmware and end up with a phantom volume. Treat adapter changes like changing a hard drive: power off first. This is the closest thing to a hardware rule in this entire guide.

The cleaning ritual

Before any cartridge goes into any slot, clean its contacts. Dampen a swab with high-concentration isopropyl alcohol, run it along the edge connector until the swab comes away without brown residue, and let it flash off — fifteen seconds, alcohol evaporates fast. A thirty-year-old cart that has been in an attic will hide oxidation that reads as a truncated dump or a checksum mismatch. Ninety percent of "my dump is corrupt" reports are oxidation. This is not glamorous and it is not optional, and it will save you more time than anything else in this article.

Drivers, Permissions, and First Mount

This is where the device proves it deserves its longevity: there is almost nothing to install. There is, however, one Linux wrinkle worth handling up front.

Windows and macOS: plug and wait

On Windows 10/11 and macOS 12+, plug the cable in with a cleaned cartridge seated and wait five to ten seconds. A removable volume named RETRODE appears in Explorer or Finder. Open it and you will see the cartridge's ROM as a file, plus a RETRODE.CFG configuration file. That is the entire driver experience. If nothing appears, it is the cable (charge-only) or the contacts (dirty), in that order of likelihood. Do not install third-party "Retrode drivers" you find on a forum; the device needs none, and those packages are how people end up with malware in 2026.

Linux: udev rules for non-root access

Linux mounts the storage volume automatically under most desktop environments, but firmware flashing and the serial console require permission to touch the raw USB device, which by default means root. Rather than running everything with sudo, drop a udev rule so your user owns the device. Create the file as root:

# /etc/udev/rules.d/60-retrode.rules
# Grant the local user access to the Retrode's serial + storage interfaces.
# Replace the idVendor/idProduct with the values from `lsusb` if they differ.

SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{product}=="Retrode", MODE="0660", GROUP="plugdev", TAG+="uaccess"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", SYMLINK+="retrode", MODE="0660", GROUP="plugdev"

Then reload and replug:

$ sudo udevadm control --reload-rules
$ sudo udevadm trigger
# unplug and replug the Retrode, then confirm:
$ ls -l /dev/retrode
lrwxrwxrwx 1 root root 7 Jun 20 11:42 /dev/retrode -> ttyUSB0

The vendor ID may read as an FTDI-class identifier depending on your unit's USB bridge; run lsusb and substitute the real values. The uaccess tag lets your logged-in seat own the device without group fiddling on systemd distros.

Confirming enumeration before you trust anything

Whatever your OS, confirm the device enumerated correctly before you spend an hour dumping a shelf of carts. On Linux, dmesg tells the truth:

$ dmesg | tail -n 8
[ 1182.004] usb 1-3: new full-speed USB device number 9 using xhci_hcd
[ 1182.151] usb 1-3: New USB device found, idVendor=0403, idProduct=97c1
[ 1182.151] usb 1-3: Product: Retrode
[ 1182.151] usb 1-3: Manufacturer: Retrode.org
[ 1182.302] usb-storage 1-3:1.0: USB Mass Storage device detected
[ 1182.305] scsi host6: usb-storage 1-3:1.0
[ 1183.318] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[ 1183.401] sd 6:0:0:0: [sdb] 4096-byte logical blocks

If you see Retrode as the product and a removable disk attached, you are good. If you see a device but no storage, the firmware is in a bad state or the cartridge is not seated — re-seat and replug before doing anything else.

The 14-Step Dump Procedure

This is the core of the article: the full SNES dump, start to finish, with a stated reason for every step. Do them in order. The reasons matter because they tell you which step to suspect when a dump goes sideways. If you only read one section, read this one — and if you came here from our Retroid Pocket 6 verdict looking for legit ROMs to load on a handheld, these are the files you want.

1. Power down the unit and clean the cartridge. Rationale: oxidation is the number-one cause of bad dumps; cleaning now prevents a re-dump later. Unplugging first prevents hot-seat confusion in the firmware.
2. Seat the cartridge firmly in the SNES slot, label forward. Rationale: a flush, stable seat is the difference between a complete read and a silently truncated file. Rock the cart gently after seating; if it moves, re-seat.
3. Connect the data-rated mini-USB cable to the host. Rationale: a charge-only cable powers the LED but never enumerates storage. Using a known-data cable here eliminates the most common phantom failure before it happens.
4. Wait for the RETRODE volume to mount. Rationale: the firmware reads the cartridge header and builds the virtual file at mount time; opening the volume before it finishes can show a zero-byte file. Give it ten seconds.
5. Open the volume and read the ROM filename. Rationale: the filename is derived from the internal cartridge header. A garbled or generic name (e.g., all caps gibberish) signals a header read problem, usually contacts — re-clean before copying.
6. Check the reported file size against expectation. Rationale: SNES ROMs are powers of two (256KB, 512KB, 1MB, 2MB, 3MB, 4MB, 6MB). A size that is not a clean multiple, or is suspiciously small, means a partial read. Catching it here saves verification time later.
7. Copy the ROM file to your host drive — do not move it. Rationale: copying leaves the original on the device so you can re-copy without re-seating if the transfer is interrupted. The Retrode's virtual file is regenerated each mount; there is nothing to "delete" from the cart.
8. Copy the accompanying .SRM save file if present. Rationale: battery-backed saves live in cartridge SRAM and appear as a separate file. If you skip this, your thirty-year-old save dies with the next battery. Grab it now.
9. Eject the volume cleanly before unplugging. Rationale: the firmware can be mid-write to its config; yanking the cable risks corrupting RETRODE.CFG, which then misbehaves on the next mount. Eject like any USB drive.
10. Generate checksums of the copied ROM. Rationale: MD5 and SHA-1 are how you prove the dump matches a known-good reference. Without a checksum you are guessing. Run sha1sum immediately while the file is fresh in your mind.
11. Strip or account for the copier header if present. Rationale: some dumps carry a 512-byte SMC header that No-Intro's reference set does not. A mismatched checksum that is otherwise plausible usually means a header — handle it before declaring the dump bad.
12. Compare the checksum against No-Intro's DAT. Rationale: this is the verification that turns "a file" into "a known-good preservation-grade dump." A match means you are done; a mismatch means re-seat and re-dump, not panic.
13. Rename the verified ROM to the No-Intro canonical name. Rationale: canonical naming makes RetroArch's scanner recognize the game and pull box art and metadata. It also makes your library self-documenting five years from now when you have forgotten what "GAME01.SFC" was.
14. Load the ROM in RetroArch to confirm it boots and saves. Rationale: a checksum-perfect file that crashes on a special chip means a core problem, not a dump problem — and you want to know which before you shelve the cart. Boot it, reach the title screen, save state, reload. Done.

Expected output from the verification steps looks like this:

$ ls -lh "Super Metroid (USA).sfc"
-rw-r--r-- 1 denis denis 3.0M Jun 20 12:03 Super Metroid (USA).sfc

$ sha1sum "Super Metroid (USA).sfc"
da957f0d63d14cb441d215462904d29bcdb9af56  Super Metroid (USA).sfc

$ md5sum "Super Metroid (USA).sfc"
21f3e98df808eb44a76b8c0d2b53e4ec  Super Metroid (USA).sfc
# Compare these against the No-Intro DAT entry. A match = preservation-grade dump.

Dumping Genesis and Mega Drive Carts

The Genesis side works the same way with a few format quirks worth knowing so you do not mistake normal behavior for a fault.

File formats: BIN versus GEN versus MD

The Retrode presents Genesis cartridges as a .BIN (or sometimes .GEN) file. These are raw, byte-for-byte dumps in the order the cartridge stores them. Most modern cores — genesis_plus_gx and blastem in particular — accept .bin directly. The older .smd interleaved format is a relic of 1990s copiers; you will not produce it with a Retrode and you do not want it. If a tool insists on .smd, it is older than the hardware you are using and you should ignore it.

Region and the lockout question

Genesis cartridges carry region information, and some games refused to boot on the wrong region of original hardware. The Retrode does not care — it reads the silicon regardless of region, so a Japanese Mega Drive cart dumps perfectly on a US setup. Region handling happens in the emulator core at play time, not at dump time. This means you can back up an import collection with the same unit and let RetroArch sort out region behavior per the core's settings. The lockout was a hardware handshake; you are bypassing the hardware entirely by reading the ROM directly.

Sega CD, 32X, and what the base unit cannot do

The Retrode 2 dumps Genesis cartridges. It does not dump Sega CD discs — those are optical media, and you verify those against Redump, not No-Intro. The 32X is a cartridge and dumps fine through the standard slot. Know the boundary: anything on a disc is out of scope for this device, and anything on a cartridge is in scope. If you are building a complete Sega library, the cartridge side comes off the Retrode and the disc side comes off an optical drive with a different toolchain entirely.

$ ls -lh "Sonic the Hedgehog 2 (World).md"
-rw-r--r-- 1 denis denis 1.0M Jun 20 12:18 Sonic the Hedgehog 2 (World).md

$ sha1sum "Sonic the Hedgehog 2 (World).md"
7e1f2d6e... (compare against No-Intro Genesis DAT)

# Genesis ROMs are also clean powers of two: 512K, 1M, 2M, 4M.
# A 1.3MB file means a partial read. Re-seat and re-dump.

Pulling SRAM Saves and Using Cart Controllers

Two features that separate the Retrode from a generic ROM site: it recovers your actual decades-old saves, and it turns your real controllers into USB devices. Both are easy and both are routinely missed.

Recovering battery-backed SRAM

Games that saved progress did so to SRAM kept alive by a coin-cell battery on the cartridge board. Those batteries are now thirty years old and dying. When you mount a save-capable cart, the Retrode exposes the SRAM as a .SRM file alongside the ROM. Copy it. That file is your save — the literal bytes of your childhood file three on Final Fantasy VI — and once the battery dies it is gone forever. RetroArch reads .srm files directly when placed in the saves directory with a matching filename, so a recovered save drops straight into the emulated game. This is genuinely the most time-sensitive thing the device does; do it before the batteries decide otherwise.

Writing saves back to a cartridge

The Retrode can also write SRAM back to a cartridge — copy a modified .srm onto the volume and the firmware writes it to the cart's silicon. This is how you restore a save to original hardware after editing it, or recover a save to a cart whose battery you just replaced. Be deliberate: this writes to physical memory, so confirm the filename matches and the cart is the right one. There is no undo on a write to a thirty-year-old chip.

Controllers as USB HID

Plug a genuine SNES or Genesis controller into the unit's controller port and your OS sees a generic USB gamepad — no driver. In RetroArch, go to Settings, Input, Port 1 Controls, and bind the buttons; the real D-pad and face buttons map exactly as you would expect. The appeal is concrete: you back up the cart and play the backup with the original input device on the same box. If you are deciding where those backups ultimately live, a handheld with proper controls matters — our breakdown of the Miyoo Mini Plus library is a reasonable destination for a verified SNES and Genesis collection, and the controls there are competent enough that you may not miss the original pad.

Verifying Dumps Against No-Intro and Redump

A dump you have not verified is a rumor. Verification is the step that converts "a file that probably works" into "a preservation-grade copy that provably matches the reference set," and it is fast once you have the workflow.

Why headers ruin checksums

The single most confusing verification failure is the copier header. Some SNES dumps carry an extra 512 bytes at the front — a leftover from 1990s copier hardware. No-Intro's reference set is headerless, so a dump with a header produces a checksum that matches nothing, even though the actual ROM data is perfect. The fix is to detect the header (the file size will be a clean power of two plus 512 bytes) and strip it. Most ROM managers do this automatically; if you are doing it by hand, drop the first 512 bytes and re-checksum:

# Detect a 512-byte SMC header (size = power-of-two + 512)
$ stat -c%s "game.sfc"
3146240            # 3,145,728 (3MB) + 512 = headered

# Strip the header into a clean file, then re-verify
$ dd if="game.sfc" of="game-clean.sfc" bs=512 skip=1
$ sha1sum "game-clean.sfc"
# now compare against the No-Intro DAT

Reading the DATs with a ROM manager

Download the current SNES DAT from DAT-o-MATIC and the disc DATs from Redump for any Sega CD work. Load them into a ROM manager like ClrMamePro, point it at your dump folder, and it tells you in one pass which files match, which are headered, and which are unknown. A "have" status means your dump's checksum exactly matches the database's known-good reference — that is the gold standard. An "unknown" status during a Mercury retrograde window still means re-seat the cart, not consult the stars.

What a mismatch actually means

A checksum mismatch is almost never a sign that the cartridge is unusual or that your dump is uniquely cursed. In descending order of likelihood it means: a copier header (strip it), dirty contacts producing a bad byte (clean and re-dump), a special-chip cart needing current firmware (flash and re-dump), or — rarely — a genuinely different revision than the one in the database, which is itself worth documenting. Work down that list before concluding anything. The reference databases are very large and very thorough; the odds that you hold an undumped variant are low, and the odds that your edge connector is dirty are high.

Five Pitfalls That Will Cost You an Evening

Every one of these has eaten someone's Saturday. Read them now so they do not eat yours.

Charge-only cables and dirty contacts

The first pitfall is the cable. A charge-only mini-USB cable powers the LED and enumerates nothing, producing the maddening "the light is on but no drive appears" symptom. Keep one cable you have proven carries data and use only that one. The second pitfall, inseparable from the first in frequency, is contacts: a dump that is the right size but fails its checksum is oxidation until proven otherwise. Clean, re-seat, re-dump. These two account for the clear majority of all failures and neither is exotic.

Special chips and stale firmware

The third pitfall is special-chip carts. Games using DSP, SA-1, SuperFX (Star Fox, Yoshi's Island), or S-DD1 (Star Ocean) have extra silicon the firmware must know how to address. An out-of-date firmware reads these wrong or not at all, producing a truncated or garbage dump from a perfectly clean cart. If a specific game fails while everything else dumps fine, suspect the chip and flash the latest firmware before suspecting the cart.

Headers, moves, and yanked cables

The fourth pitfall is treating the header as a fault — it is not, it is 512 stripped bytes, covered above. The fifth is workflow: moving instead of copying the file (there is nothing to move; the file is regenerated each mount, and a "move" that interrupts leaves you re-seating for no reason), and yanking the cable without ejecting, which can corrupt RETRODE.CFG and make the next mount misbehave. Copy, never move. Eject, never yank. These are unglamorous habits that prevent the most frustrating class of failure: the kind where the hardware is fine and you broke it with impatience.

Troubleshooting Table

Symptom on the left, the actual cause and fix on the right. Note that "Mercury retrograde" appears in zero rows, because it causes zero of these.

Advanced Tips and Firmware Tricks

Once the basics are routine, these earn their keep on a large collection or an awkward cart.

Flashing firmware safely

Firmware adds support for special chips and fixes edge cases. Flashing is done over the serial interface or by entering the unit's update mode and copying the firmware file, depending on hardware revision — follow the instructions that match your unit precisely, because a botched flash is the one thing in this guide that can actually brick the device. Do it on a stable power source, do not unplug mid-flash, and verify the reported firmware version after. This is the one operation where the deadpan advice is sincere: do not start a firmware flash and then walk away. If you must blame a planet for picking a bad moment, fine, but the real rule is uninterrupted power and full attention.

Batch dumping a shelf efficiently

For a large library, build a rhythm: clean the next cart while the current one mounts, copy with a consistent destination folder, and run checksums in a batch at the end rather than one at a time. A simple loop over your dump folder verifies an evening's work in seconds:

#!/usr/bin/env bash
# verify-dumps.sh -- checksum every ROM in a folder for DAT comparison
set -euo pipefail
DUMPDIR="${1:-./dumps}"

for rom in "$DUMPDIR"/*.{sfc,smc,bin,gen,md}; do
  [ -e "$rom" ] || continue
  size=$(stat -c%s "$rom")
  sha=$(sha1sum "$rom" | cut -d' ' -f1)
  printf '%-48s %10d bytes  %s\n' "$(basename "$rom")" "$size" "$sha"
done
# Pipe the output into ClrMamePro or diff against a No-Intro DAT export.

Editing RETRODE.CFG

The on-device RETRODE.CFG controls file extensions, the controller mode, and a handful of read behaviors. You can change the SNES output extension, toggle whether saves are exposed, and adjust controller emulation by editing this plain-text file directly on the volume and ejecting cleanly. Keep a backup of a known-good config; if a yanked cable ever corrupts it, you restore in seconds rather than guessing at the syntax. The RetroArch side of the equation — cores, scanning, playlists — is documented thoroughly in the official libretro documentation, and the import-content guide is the canonical reference for getting verified dumps to show up with box art. For deeper core internals and source, the RetroArch GitHub repository is the authority. If your endgame is an FPGA-accurate setup rather than software emulation, our look at the Analogue 3D firmware and save states covers where these verified ROMs land on hardware that runs them cycle-accurately.

The Complete Working Configuration

Everything assembled into one place. Copy the RETRODE.CFG to your device, the udev rule to Linux if you flash firmware, and the verification script to your dump folder. This is the configuration the Machine actually runs.

RETRODE.CFG (on-device)

# RETRODE.CFG -- on-device configuration
# Place at the root of the RETRODE volume. Eject cleanly after editing.

# --- File output ---
SNES_EXT      = SFC      # SNES/SFC ROM extension (.sfc is No-Intro friendly)
GENESIS_EXT   = BIN      # Genesis/Mega Drive raw dump extension
EXPOSE_SAVES  = 1        # 1 = show .SRM SRAM saves, 0 = hide
ALLOW_WRITE   = 1        # 1 = permit writing .SRM back to cartridge SRAM

# --- Controllers ---
CTRL_MODE     = HID      # expose controller ports as USB HID gamepads
CTRL_PORT1    = SNES
CTRL_PORT2    = GENESIS

# --- Read behavior ---
VERIFY_HEADER = 1        # validate internal cart header before naming file
STRIP_SMC     = 0        # 0 = keep raw output; strip 512B header in toolchain
# End of file

Host-side verification toolchain

# 1. Linux device permissions (only needed for firmware flashing)
#    -> /etc/udev/rules.d/60-retrode.rules (see Drivers section)

# 2. Per-dump verification (run after each copy)
sha1sum "Game (Region).sfc"
md5sum  "Game (Region).sfc"

# 3. Header detection / strip (only if size = power-of-two + 512)
stat -c%s "Game (Region).sfc"
dd if="Game (Region).sfc" of="Game (Region)-clean.sfc" bs=512 skip=1

# 4. Batch verify a whole folder against a No-Intro DAT
./verify-dumps.sh ./dumps   # see Advanced section for the script

# 5. DAT sources for comparison:
#    SNES/Genesis cartridges -> https://datomatic.no-intro.org/
#    Sega CD / disc systems   -> http://redump.org/

RetroArch playback profile

# RetroArch core selection for verified Retrode dumps (1.19+)

# SNES / Super Famicom
core_snes_accurate   = bsnes-mercury-accurate   # accuracy, special chips
core_snes_fast       = snes9x                    # lower-power handhelds
core_snes_modern     = mesen-s                    # modern accuracy core

# Genesis / Mega Drive / 32X
core_genesis_default = genesis_plus_gx           # broad compatibility
core_genesis_accurate= blastem                    # cycle-accurate timing

# Save handling
savefile_directory   = "~/retroarch/saves"        # drop recovered .srm here
savestate_directory  = "~/retroarch/states"
# Match the .srm filename to the ROM filename for auto-load.

That is the whole machine: a device that reads what you already own, a workflow that proves the read is perfect, and a configuration that turns a shelf of plastic into a verified, playable, preservation-grade library. The cartridges do not care what Mercury is doing — they never did. The only retrograde that matters here is the one in the device's name, and it just means "the box that reads backward, off the silicon, into a file you keep." Clean your contacts, copy don't move, eject don't yank, and the planets can do whatever they like.