Retrode 2026: Dump a Cart in 11 Steps, ~30 Min

The Retrode is one of those objects that shouldn't need to exist and does anyway. It is a plastic slab with a Super Nintendo slot on one edge and a Sega Genesis slot on the other, and when you plug a cartridge into it and connect it to a computer over USB, the cartridge shows up as a flash drive with a ROM file sitting on it. No drivers. No capture card. No emulator. You copy the file off like it is a holiday photo. That is the whole trick, and it has been the whole trick since 2009.

In 2026 the device is having a strange second act. The original Retrode2 hardware is out of production and increasingly a used-market item, its firmware frozen somewhere around a community build labelled 0.25a and its companion utility throwing errors on old macOS releases. Meanwhile the successor, the Retrode3, has finished hardware, no orders, and a promise to ship by the end of the year. This is a tutorial for the machine you can actually buy today and use tonight, with an honest accounting of the one you cannot buy yet. We will dump a cartridge end to end, verify the result against a No-Intro reference so you know it is bit-perfect, back up your save, wire the controllers up as USB gamepads, and, for the brave, reflash the firmware over DFU.

What the Retrode Actually Is

Before you dump anything, understand what is in your hand, because half of the bad advice about this device comes from people who think it is something it is not.

A USB interface, not an emulator

The Retrode's own FAQ is unusually blunt, so let us use its words: it is a USB interface for vintage video game cartridges and controllers that wraps whatever memory chips there are on the cartridge into virtual files on a USB drive, and makes the gamepads appear as USB HID-class controllers. And then, in case you were about to misfile the product category: The Retrode is not an emulator. That distinction matters more than it sounds. An emulator pretends to be a Super Nintendo. The Retrode does the opposite: it reads the actual silicon in your actual cartridge and hands the bytes to your computer as a file. What you do with that file, usually run it in an emulator, is a separate step involving separate software. The Retrode never executes a single instruction of game code. It is a bridge, not a console. If you would rather play the cart on original-accuracy silicon than turn it into a file at all, that is an FPGA job, and the MiSTer Multisystem 2 is the device for it — a completely different philosophy from dumping.

What is inside

The Wikipedia entry is correct on the internals and worth stating precisely: the Retrode2 is built around an Atmel AVR microcontroller, the AT90USB646, with an integrated USB interface, wired through GPIO pins to the cartridge slots and controller ports, running firmware based on the LUFA library. To your computer it enumerates as a composite USB device: a mass-storage endpoint (the drive with your ROM on it) plus one or more USB game controllers. That is why it works with no drivers on any modern operating system. Mass storage and HID gamepads are device classes every OS already speaks fluently. The device was created by Matthias Hullin and produced by the German outfit Retrode UG. Manufacturing stopped in summer 2013, then resumed under OpenPandora GmbH licensing in March 2015, which is why, a decade later, it is DragonBox (the OpenPandora shop) that will eventually sell you a Retrode3.

What it dumps, natively and otherwise

Out of the box the Retrode2 reads two families: Super Nintendo / Super Famicom and Sega Genesis / Mega Drive. Everything else — Nintendo 64, Game Boy / Color / Advance, Master System, Game Gear, Atari 2600, TurboGrafx-16, Virtual Boy, Neo Geo Pocket, Sega Pico, V.Smile — needs a plug-in adapter that sits in one of the native slots and re-routes the pins. Some adapters are official products, some are do-it-yourself community designs. The controller side is symmetric: four ports, two per system, exposed as standard SNES and Sega (3- and 6-button) gamepads. The SNES mouse works, but only in the left port, a quirk we will come back to and that will otherwise cost you an evening.

The Retrode3 Question

You clicked expecting a 2026 device, and the honest answer is that the 2026 device is not for sale. Here is exactly where it stands, because the marketing does not lead with the caveat.

Finished hardware, unfinished software

Per the current Retrode3 product page, the hardware is done. The software is not. Orders are not open. You cannot pre-order — you can only sign up for notifications through DragonBox, the named distribution partner. The stated target is availability by the end of the year, at a price the company will only commit to as under EUR 100, final figure unconfirmed. If that reads like a project that is ninety percent finished and ten percent from shipping, that is because it is, and the last ten percent of an embedded-Linux product is where release dates go to die.

A different machine entirely

Retrode3 is not a spec bump. Where the Retrode2 is a bare-metal AVR pretending to be a flash drive, the Retrode3 is a small computer: a MIPS processor running Debian Linux, booting off an SD card so a failed update cannot brick it. It has built-in Wi-Fi, which unlocks network dumping, remote ROM storage, an online game database for naming files, and over-the-air OS updates. Plugged into USB it appears as an Ethernet device, no drivers, or it runs standalone over Wi-Fi with no host computer at all. The framing on the product page is explicit and, for once, honest about the trade it is making: combine the plug-and-play simplicity of the Retrode2 with the flexibility of Sanni's Cart Reader, the open-source Arduino-based dumper that reads almost anything if you are willing to fiddle. Retrode2 has always been the easy one and Sanni's has always been the flexible one; Retrode3 wants to be both. Whether it manages that is a 2027 question.

Open all the way down

The one claim that is not hedged: the complete source code and hardware design are freely available, split across four GitHub repositories — the Cart Reader adaptation, the kernel, the user space, and the hardware design. That is a genuine open-hardware posture, not a marketing garnish, and it is the reason a Debian-on-MIPS cartridge reader is even plausible for a sub-100-euro hobby product: almost none of it is written from scratch. One caveat worth flagging: Retrode2 plugin support on the 3 is, per the page, planned but not yet confirmed. If your workflow depends on a specific Retrode2 adapter, do not assume it carries forward. Because you can use the Retrode2 tonight and the 3 not at all, the rest of this guide is about the 2. We walked the basic path in a companion twelve-step dump; what follows is the deeper cut — verification, saves, firmware, and the failure modes nobody warns you about.

Prerequisites

The dump itself is just file copying, so the requirements are light. The verification and firmware work is where you need real tools. Gather these before you start rather than mid-dump with a cartridge already seated.

Hardware you need

A Retrode2, which in 2026 means the used market, since the 3 is not shipping. A USB cable, mini-USB on the older units, and a data cable rather than a charge-only one. The cartridges you actually own — we will get to the legal footnote in the FAQ. Ninety-nine percent isopropyl alcohol and lint-free swabs, non-negotiable, because dirty contacts are the single largest cause of bad dumps. And a computer with a real USB host port. The FAQ's requirement is refreshingly low: anything with a USB host port that runs a modern operating system (Linux, Mac OS X, Windows) that recognizes USB mass storage and controllers.

Software and versions

You need less than you would think. For the dump: a file manager or a shell. That is the entire dumping toolchain, genuinely. For verification: a checksum tool (md5sum / sha1sum / crc32 on Linux and macOS, CertUtil or 7-Zip on Windows) and a ROM manager such as ClrMamePro or RomVault, plus the current No-Intro DAT files for SNES and Genesis. For firmware: dfu-programmer on Linux or macOS, or Atmel FLIP on Windows. And an emulator to play the result: RetroArch with the appropriate cores (bsnes or Snes9x for SNES, Genesis Plus GX for Genesis) is the sane default.

What you do not need, and the one version that bites

You do not need a capture card, an emulator to dump (only to play), or any vendor driver. Because the Retrode presents standard USB classes, a 2011 build of your OS and a 2026 build mount it identically; do not go hunting for a signed driver package, there is not one. The only place versions bite is firmware flashing. Per a documented Retrode Utility GitHub issue, the Retrode 2 does not accept Firmware Flash from 10.11.5 — that specific macOS build cannot push firmware. Keep a Linux box or a Windows machine around for flashing and you sidestep the entire class of problem. Confirm the device enumerates before you go further:

# Linux — the Retrode shows up as a small removable volume named RETRODE
lsblk -o NAME,LABEL,SIZE,MOUNTPOINT | grep -i retrode

# macOS — it mounts under /Volumes
ls /Volumes/RETRODE

# Windows (PowerShell) — find it by its FAT label
Get-Volume | Where-Object FileSystemLabel -eq 'RETRODE'

How Dumping Works Over USB

Understanding the mechanism turns most troubleshooting from guesswork into deduction, so spend two minutes here before you touch a cartridge.

The cartridge as a filesystem

When you seat a cartridge and connect USB, the Retrode's firmware reads the cart's memory map and synthesizes a tiny FAT filesystem in RAM. On that filesystem it places a file named after the game — pulled from the cart's internal header where one exists — with the appropriate extension: .SFC for SNES, .BIN or .GEN for Genesis, whose contents are the raw ROM. Alongside it, if the cart has battery-backed save RAM, appears a .SRM file containing your save, plus a plain-text RETRODE.CFG. The drive is a fiction the firmware maintains; there is no flash storage inside the Retrode holding your ROM. Unplug the cart and the file is gone, because the file was never anywhere but the cartridge.

Headerless dumps and why you care

The Retrode dumps SNES ROMs headerless — raw, with no 512-byte copier header of the kind old SMC copiers prepended. That is why the extension is .SFC (headerless) and not .SMC (traditionally headered). This is the correct, modern behavior and it is exactly what No-Intro expects, but it trips people who compare against ancient headered dumps, see a 512-byte size difference and a totally different checksum, and conclude their hardware is broken. If a ROM is exactly 512 bytes larger than a known-good entry, you are looking at a header, not a bad dump. Remember that number: 512.

What it can and cannot read

The Retrode reads the ROM and mask-ROM chips directly, which means its coverage is defined by which on-cart coprocessors it understands. Per the Retrode FAQ, Super FX and DSP-1 carts dump fine. But SA-1, S-DD1, and Sega's Virtua Processor (SVP) are currently not supported — so Super Mario RPG and Kirby Super Star (SA-1), Star Ocean and Street Fighter Alpha 2 (S-DD1), and Virtua Racing (SVP) will either fail or produce garbage. That is not a defect you can clean away; it is a limit of the firmware's mapper support. Know your cart's chip before you blame your contacts, because no amount of isopropyl fixes an unsupported mapper.

The Dump: 11 Steps

This is the core procedure, from a dusty cartridge to a verified file. Do all eleven the first few times; once the muscle memory sets in you will compress the middle. Each step has a reason, and the reasons are why the dump comes out right instead of merely plausible.

The eleven steps

1. Clean the cartridge contacts. Ninety-nine percent isopropyl on a lint-free swab, wipe the gold fingers until the swab comes away clean, let it flash off. Do not use a pencil eraser; it abrades the plating and sheds grit. Rationale: every bit error in your final dump traces back to a contact that did not fully connect.
2. Seat the cartridge fully, powered off. SNES on the SNES edge, Genesis on the Genesis edge, firm and completely home, no wobble. Rationale: partial seating reads partial address lines and yields a truncated or mirrored dump that can still look superficially valid.
3. Connect to a real USB host port. A rear-panel port on a desktop, or straight into a laptop — not a bus-powered hub. Rationale: the Retrode draws cart power over USB, and an underpowered hub browns out mid-read and corrupts the dump silently.
4. Wait for the RETRODE volume to mount. Linux auto-mounts under /media or /run/media, macOS puts it in /Volumes/RETRODE, Windows assigns a drive letter. Rationale: a no-mount is a hardware or seating problem; you do not fix it by copying faster, so stop and reseat.
5. Open the volume and confirm the ROM file. You should see one file per populated slot, named from the header, plus a .SRM if the cart saves and the RETRODE.CFG. Rationale: the filename is your first integrity check — a header the firmware could not parse shows up as a generic or garbled name.
6. Check the file size before you copy. A SNES ROM is a clean sum of banks (512 KB, 1, 1.5, 2, 3, 4 MB); a Genesis ROM likewise. Rationale: a size that is not a sane ROM size is a dead giveaway of a bad read, and catching it here saves a full verification round-trip.
7. Copy the ROM off to local storage. Drag it, or cp / copy it. Do not run it in place from the volume. Rationale: the volume is a live view of the cartridge over USB; an emulator hammering it directly can hitch, and you want a stable local artifact regardless.
8. Copy the .SRM save too, and keep it separate. Rationale: that save is a battery-backed original that has survived on a coin cell for twenty-plus years. It is more irreplaceable than the ROM, which exists in a thousand identical copies online.
9. Fingerprint your local copy. Run sha1sum on it (or CertUtil on Windows). Rationale: you cannot verify what you have not fingerprinted, and this number is what you match against No-Intro in the next section.
10. Re-seat, re-dump once, and compare. Pull the cart, reseat, dump again to a second file, and diff the two. Rationale: two independent dumps that hash identically are almost certainly correct; a mismatch localizes the fault to the read, not your storage.
11. Eject cleanly, then unplug. Unmount the volume before pulling the cable. Rationale: the .SRM is the one thing the Retrode can write, and yanking a mounted FAT volume mid-write can corrupt the very save you just backed up.

Reading the expected output

A healthy Super Metroid dump — 24 Mbit, so 3,145,728 bytes, with an 8 KB battery save — looks like this on the mounted volume. Note the three files: the ROM, the save, and the tiny config. The sizes are the tell; 3,145,728 is a textbook SNES size, and 8,192 is a standard SRAM size.

$ ls -la /Volumes/RETRODE
-rwxr-xr-x  1 you  staff  3145728  SUPER METROID.SFC
-rwxr-xr-x  1 you  staff     8192  SUPER METROID.SRM
-rwxr-xr-x  1 you  staff      148  RETRODE.CFG

The two-dump rule

Step 10 is the one people skip and the one that saves archives. Dump the same cart twice and byte-compare. If the two files are identical, your read is stable; if they diverge, a contact is marginal and you clean and repeat. This is the cheapest insurance in the entire hobby.

$ cmp -s dump1.sfc dump2.sfc && echo 'STABLE: two dumps identical' || echo 'MISMATCH: clean contacts and redump'
STABLE: two dumps identical

Verifying Against No-Intro

A dump that runs is not a dump that is correct. This section is the difference between an archive and a pile of maybe-files.

Why a file that runs can still be wrong

A ROM with a handful of flipped bits will usually boot, often play for hours, and then hard-lock in the one room whose graphics data sat under a dirty contact. It ran is not verification. The only verification that means anything is a byte-exact match against a reference database, and for cartridge dumps that database is No-Intro: a community-maintained set of DAT files listing the CRC32, MD5, and SHA-1 of every known-good, headerless cartridge dump. If your file matches a No-Intro entry, it is provably identical to what other people's good hardware produced from the same cart. If it does not, you have a bad read, a header, or an unlisted revision, and you find out which before you file it away.

The command-line way

For a handful of files, fingerprint each dump and eyeball the hash against the DAT. A No-Intro DAT is XML; open it in any editor and search for your game, or grep it. The workflow:

$ sha1sum 'SUPER METROID.SFC'
7c... (full 40-hex SHA-1)   SUPER METROID.SFC

# Match that SHA-1 against the No-Intro SNES DAT.
# Byte-exact match = verified dump. No match = bad read, or a 512-byte header.

The ROM-manager way

Beyond a few carts, drive it with a ROM manager. ClrMamePro (Windows, the old standard) or RomVault (cross-platform, friendlier) load the No-Intro DAT, scan your folder, and bucket every file as correct, bad, or needs-rename. A correct dump gets the canonical No-Intro name; a bad one is flagged and you go clean contacts and re-dump. This is the same tooling preservation groups use, and it scales from three carts to three hundred without changing shape. Once a file is verified, it is portable: drop it into a RetroPie build or sideload it onto a handheld like the Miyoo Mini Plus and it plays anywhere, because the byte-exactness you just proved is the whole point.

Saves and Controllers

The Retrode does two things beyond dumping ROMs, and both are underused. One of them can destroy data if you are careless, so read this before you move .SRM files around.

Reading, and writing, SRAM

The Retrode's most underrated trick is bidirectional save access. ROM chips are read-only and the Retrode treats them that way, but battery-backed SRAM is fair game in both directions. The .SRM on the volume is your live save, and per the FAQ, users can modify SRAM (savegame data) on many cartridges. Copy the .SRM off to archive a save that has been decaying on a CR2032 since the Clinton administration. Copy a .SRM on to restore a save, move a playthrough between two copies of a cart, or resurrect a game whose battery finally died. This is the one write path in the whole device, which is exactly why step 11 told you to eject cleanly. Back the save up twice before you ever write one back.

Controllers as USB gamepads

The four controller ports show up as standard SNES and Sega (3- and 6-button) gamepads over USB HID. Plug a real SNES pad into the Retrode and it is a generic USB controller your OS and RetroArch will happily bind. It is a legitimately nice way to use original pads without a separate adapter — you are already plugging the Retrode in to dump, so the controller ports come free. Sega pads report as 3- or 6-button depending on the pad; if your six-button layout only maps three, you have a three-button pad or a mapping that assumed six.

The mouse footnote

One quirk from the FAQ worth memorizing before you waste an evening on it: the SNES mouse is supported, but only in the left port. If your Mario Paint pointer or your Mario's Picross cursor is dead, you have almost certainly seated the mouse in the right-hand port. Move it left. That is the entire fix, and it is documented, and people still burn hours on it.

Firmware and DFU

Most people never need this section. Read it anyway so you know when you do, and — more importantly — when you do not.

When you actually need to reflash

If your Retrode dumps and mounts, leave the firmware alone. There is no glory in flashing for its own sake, and every flash is a small chance to brick a device you cannot easily replace in 2026. You reflash for exactly two reasons: a specific bug fix or mapper-support improvement in a newer build, or a botched prior flash you must redo. Community discussion in 2026 still circles two reference points — a build labelled 0.25a cited for both Retrode 1 and Retrode 2, and a separate thread of users hunting a version around 26a — which tells you the firmware world here is community-tracked folklore, not a tidy vendor changelog. Write down the version you have before you touch anything.

The DFU workflow

The AT90USB646 has an on-chip DFU bootloader, and on Linux or macOS the tool is dfu-programmer. A 2026 Linux update script published as a gist does exactly this: drives dfu-programmer against the at90usb646 target to erase and flash. The shape of it, which is the same erase-flash-reset dance every AVR DFU device uses:

# 1) Enter the AT90USB646 DFU bootloader (hold the firmware/boot button
#    while connecting USB; the exact procedure varies by board revision).
# 2) Then, on Linux or macOS:

dfu-programmer at90usb646 erase
dfu-programmer at90usb646 flash retrode.hex
dfu-programmer at90usb646 reset

# Expected, roughly:
#   Checking memory ... Empty.
#   Validating ... Success.

The macOS trap

Before you flash from a Mac, know that a documented Retrode Utility GitHub issue records the Retrode 2 refusing a firmware flash from macOS 10.11.5 specifically. If you are on that build, do not fight it — flash from Linux with dfu-programmer or from Windows with Atmel FLIP. Flashing is the one operation where the any-modern-OS rule has an asterisk, and this is the asterisk. Everything else the Retrode does is OS-agnostic; firmware writing is not.

Five Ways It Goes Wrong

Six, actually. These are the failure modes that produce the most confusion, sorted by what kind of mistake they are, because the fix follows from the category.

Physical pitfalls: contacts and power

• Dirty contacts, trusted once. A single dump is a hypothesis, not a fact. Fix: clean with isopropyl, then always re-dump and compare (step 10). Two identical hashes is the proof; one dump is a guess.
• Bus-powered hub brownout. The Retrode powers the cart from USB, and a shared hub cannot always deliver. Fix: a rear motherboard port, a powered hub, or straight into the machine. Intermittent, unrepeatable read errors almost always mean power.

Logical pitfalls: headers and mappers

• Header confusion. A .SFC is headerless and correct; a checksum that is wildly off with a 512-byte size delta is a header, not corruption. Fix: compare against No-Intro (which is headerless) and stop panicking about the 512 bytes.
• The unsupported-mapper mirage. SA-1, S-DD1, and SVP carts will not dump correctly no matter how clean the contacts. Fix: check the cart's chip first; if it is Super Mario RPG or Star Ocean or Virtua Racing, the Retrode2 simply cannot, and that is the answer.

Destructive pitfalls: saves and firmware

• Overwriting a save you meant to keep. The SRAM path is writable, and a careless copy-on destroys a two-decade-old original. Fix: archive the .SRM off, twice, before you ever write one back, and eject cleanly every time.
• Flashing firmware you did not need to. Every flash risks a brick for usually no benefit. Fix: if it dumps, do not flash; and never flash from macOS 10.11.5.

Troubleshooting

When a dump misbehaves, work top to bottom: mount, then read, then verify, then peripherals, then firmware. The table maps symptoms to the most likely cause and the fix that actually addresses it, rather than the folk remedy that does not.

Symptom-to-fix table

When the table does not help

If a specific cart fails every angle, escalate by elimination: try a different cartridge in the same slot (isolates cart vs. Retrode), a different cable and port (isolates power), and a different computer (isolates the host). If a known-good cart also fails, the Retrode or its cable is the suspect; if only one cart fails, it is that cart, its contacts, or an unsupported mapper. Do not change three variables at once — you will fix it and never know how.

Reporting a Retrode bug

The firmware and the Retrode Utility live on GitHub, and the macOS 10.11.5 flashing issue is exactly the kind of thing that gets logged there. Before you conclude your unit is defective, search the existing issues; the odds are high that whatever you are seeing has a thread, a workaround, or a known mapper limitation attached to it. Preservation tooling is only as good as the bug reports feeding it.

Advanced: Adapters and N64

Once you have dumped a shelf of SNES and Genesis carts, the questions become: what about everything else, and how do I stop doing this one file at a time.

The adapter ecosystem

The native slots read SNES and Genesis; everything else rides a plug-in adapter that re-routes the pins. Official and community adapters exist for N64, Game Boy / Color / Advance, Master System and Game Gear, and more exotic targets. Two hard rules from the FAQ: adapters that contain a whole console — the Super Game Boy, the RetroPort — do not work, because you would be asking the Retrode to read a console rather than a cartridge; and the Sega 32X reads fine as long as you leave its power supply off. Match the adapter to the slot it is designed for, seat it as firmly as you would a cartridge, and treat the adapter's own edge contacts as another thing to keep clean.

N64 byte order, the eternal headache

N64 dumps via adapter arrive in one of three byte orders — big-endian .z64, byte-swapped .v64, little-endian .n64 — and half the my-N64-dump-is-broken reports are just the wrong order for the target. Standardize on .z64, which is big-endian and No-Intro's format, and byte-swap once with a converter rather than collecting three copies of every game in three endiannesses. If N64 preservation is really your goal and you would rather play the cart at native accuracy than wrestle byte order, the Analogue 3D is the FPGA answer — again, a different tool for a different job than dumping.

Batch dumping without losing your mind

If you are working through a collection, script the boring parts: copy off, hash, log the size and name, and you have a manifest you can later diff against No-Intro in one pass. A minimal loop, per cart, keeps a running record so a duplicate or an insane file size announces itself instead of hiding in a folder of two hundred:

#!/usr/bin/env bash
# Dump-and-log a shelf: copy each ROM, hash it, record size + name.
SRC=/media/$USER/RETRODE
OUT=$HOME/roms/incoming
mkdir -p "$OUT"

for f in "$SRC"/*.SFC "$SRC"/*.BIN; do
  [ -e "$f" ] || continue
  name=$(basename "$f")
  cp "$f" "$OUT/$name"
  sz=$(stat -c%s "$OUT/$name")
  sha=$(sha1sum "$OUT/$name" | cut -d' ' -f1)
  echo "$sha  $sz  $name" | tee -a "$OUT/manifest.txt"
done

The Complete Working Setup

Everything above, distilled into the three artifacts you keep: a Linux access rule, the on-device config, and a single script that copies, fingerprints, and stages a dump for verification.

Linux udev rule for painless access

On Linux a udev rule saves you from sudo and gives the device a stable symlink. The Retrode's USB vendor and product IDs vary by unit and firmware, so read yours off lsusb and substitute them rather than trusting a number copied from a forum:

# /etc/udev/rules.d/60-retrode.rules
# Find YOUR ids first:  lsusb   (locate the Retrode / mass-storage line),
# then fill in idVendor / idProduct below and reload.
SUBSYSTEM=="usb", ATTR{idVendor}=="xxxx", ATTR{idProduct}=="xxxx", MODE="0660", GROUP="plugdev", SYMLINK+="retrode"

# sudo udevadm control --reload-rules && sudo udevadm trigger

RETRODE.CFG on the device

The virtual volume carries a plain-text RETRODE.CFG you can edit to change behavior — naming, verbosity, forcing sizes on a stubborn cart. The exact keys are firmware-specific, so treat this as a template and check your build's manual for the authoritative option list before you edit. The honest default advice is to leave it alone unless a specific cart misbehaves:

; RETRODE.CFG — lives on the device's virtual volume, plain text.
; Keys are firmware-specific; treat this as a template and check your
; build's manual for the authoritative option list before editing.
;
; Toggles people commonly reach for:
;   forceSize  - override a mis-detected ROM size on a stubborn cart
;   verbose    - write extra diagnostics to the volume
;   sramWrite  - allow or deny writing the .SRM back to the cartridge
;
; Leave it alone unless a specific cart misbehaves; the defaults are sane.

The full pipeline, start to finish

This is the capstone: mount check, pull ROM and save, fingerprint, and hand you a hash list to match against No-Intro. It fails loudly if the volume is not mounted and ignores cartridge types that are not present, so it is safe to run against any single seated cart. Run it, then verify the hashes — the dump is not done until it matches.

#!/usr/bin/env bash
# retrode-dump.sh — copy, fingerprint, and archive one cartridge.
set -euo pipefail

SRC="/media/$USER/RETRODE"     # macOS: SRC="/Volumes/RETRODE"
DEST="$HOME/roms/incoming"
mkdir -p "$DEST"

# 1. Is the volume mounted?
[ -d "$SRC" ] || { echo 'RETRODE not mounted - check seating and cable'; exit 1; }

# 2. Pull every ROM and save off the device (ignore missing types)
cp -v "$SRC"/*.SFC "$SRC"/*.BIN "$SRC"/*.SRM "$DEST"/ 2>/dev/null || true

# 3. Fingerprint what you pulled
cd "$DEST"
sha1sum *.SFC *.BIN 2>/dev/null | tee dumps.sha1

echo 'Match dumps.sha1 against the No-Intro DAT before you trust anything.'

That is the entire discipline: read the actual silicon, prove the bytes against a reference, protect the save that cannot be re-downloaded, and leave the firmware alone unless you have a reason. Do that and your dumps outlive the cartridges — which, given what coin cells and edge connectors do over forty years, is the entire point of owning a Retrode in the first place. The Retrode3 may make all of this wireless and one-click by 2027. Until DragonBox actually opens orders, the 2 on your desk is the one that works.