Retrode 2 ROM Dumping: 12 Steps, 30 Min (2026 Guide)

A note before we start, because a search engine sent at least some of you here by mistake: this is not about Mercury stationing retrograde in Cancer from 29 June to 23 July 2026, nor about Pluto loitering in Aquarius until October. If you arrived expecting your horoscope, the planets will be fine without you. Retrode is a piece of hardware. It reads game cartridges. The only thing going retrograde here is your relationship with the 1990s, and that is entirely intentional.

The Retrode 2 is one of the few pieces of retro-gaming hardware that does exactly what it claims, refuses to editorialize about it, and then gets out of your way. You plug a Super Nintendo or Sega Genesis cartridge into the top, plug the unit into your computer with a cable, and a USB drive appears containing your game as a file. That is the entire pitch. No drivers. No proprietary client. No account. No telemetry. It behaves like a USB stick that happens to have a cartridge slot, and in a market saturated with devices that want to be your friend, that restraint is almost moving.

This tutorial takes you from an unopened Retrode to a verified, hash-checked, No-Intro-matched ROM library that loads cleanly in RetroArch, plus the firmware maintenance and save-transfer workflows that the original documentation buried. Budget thirty minutes for your first cartridge and about ninety seconds for every one after that.

Why Dump Your Own Cartridges

The honest answer is preservation, and the less honest answer is that downloading a ROM is faster. We are going to deal with both, because pretending the second one doesn't exist insults your intelligence.

Cartridges die. Not dramatically—they corrode. The save battery in a Super Metroid or Pokémon cart is a CR2032-class cell soldered to a board, and it has been discharging since the Clinton administration. The mask ROM itself is durable, but the edge connector oxidizes, the SRAM loses its charge, and the plastic shell warps. A cartridge is a physical object decaying on a physical timeline. The file you pull off it is not. Dumping your own cartridge is the act of moving the data from a medium that is dying to one that can be copied infinitely and checksummed forever. That is the whole of digital preservation in one sentence.

Then there is provenance. A ROM you dumped yourself, from a cartridge you can hold, with a hash that matches a No-Intro database entry, is a known quantity. A ROM you found on a forum in 2009 is not. It may be a bad dump—a byte flipped during somebody else's bad cable run twenty years ago. It may be a hacked translation labeled as a clean dump. It may carry an intro screen bolted on by a release group. When you dump your own, you become the authority. The Machine approves of being the authority.

On the law, since this site knows the law: in the United States, there is no clean statutory blessing for ripping a cartridge you own, and anyone who tells you otherwise is selling something. The closest hooks are 17 U.S.C. § 117, which contemplates copies made as an essential step in using software, and the general fair-use analysis, neither of which was written with a SNES cart in mind. The act of dumping does not require circumventing an access control under the DMCA—mask ROMs have no encryption to break—which removes one whole category of trouble that, say, optical-disc ripping invites. None of this is legal advice; I am a sardonic narrator, not your attorney. The defensible position is the simple one: dump cartridges you physically own, keep the cartridge, and do not distribute the files. Preservation is a much easier story to tell when the original is still on your shelf.

What the Retrode 2 Actually Is

The Retrode 2 is the second-generation cartridge reader designed by Matthias Lange, originally sold through retrode.com and later through various European distributors. At its heart sits an Atmel AT90USB1287—an 8-bit AVR microcontroller with native USB support. That chip choice is the entire design philosophy. The AT90USB1287 can present itself to your operating system as a standard USB Mass Storage Class device, which means every OS written in the last twenty years already has the driver. The Retrode exploits this ruthlessly.

When you insert a cartridge, the firmware reads the cartridge's internal header, works out the ROM size and mapper type, reads the entire ROM into a virtual file, reads the battery-backed SRAM into a second virtual file, and exposes both as files on a FAT-formatted volume that mounts automatically. The SNES ROM appears with a .SFC extension, the Genesis ROM with .BIN, and the save data with .SRM. The volume is conventionally labeled RETRODE. You copy the files off like any other drive.

Two slots on top handle the two console families: one for Super Nintendo / Super Famicom carts, one for Sega Genesis / Mega Drive. Two controller ports on the side expose the original SNES and Genesis pads as standard USB HID gamepads—a genuinely clever bonus that turns your authentic controllers into emulator input devices with zero adapters. Plugin connectors on the board accept official and third-party adapters for Game Boy, Game Boy Advance, Nintendo 64, Master System, and Game Gear, dramatically expanding what one unit can read.

What the Retrode is not: it is not a flash cart, it cannot write new ROMs to blank cartridges, and it is not a fast device. It is USB Full Speed, not High Speed, so a large cartridge takes the better part of a minute to read. It does not handle the exotic enhancement chips gracefully in every firmware revision—Super FX and SA-1 carts have historically needed the right firmware and sometimes manual coaxing. We will get to all of that.

Prerequisites: Hardware and Software

Gather everything before you start. Half the support threads in existence are people who began step seven before they owned the cable for step two.

Hardware you must have:

• A Retrode 2 unit. The first-generation Retrode exists but is rare; this guide assumes the Retrode 2 with the AT90USB1287.
• A Mini-USB cable—not Micro, not USB-C. The Retrode 2 predates both. Read the port before you order a cable.
• A computer running Windows 10 or 11, macOS 12 (Monterey) or later, or any Linux kernel from the 5.x or 6.x series. A native USB 2.0 port is preferable to a cheap hub; powered hubs are fine, unpowered hubs are a coin flip.
• At least one SNES or Genesis cartridge. Clean the edge connector first—more on that in pitfalls.
• Optional: plugin adapters for Game Boy/GBA, N64, or Master System/Game Gear if you intend to dump those.

Software, with versions:

• For basic dumping: nothing. Your operating system's built-in USB Mass Storage support is the only driver required. This is the point of the device.
• For firmware updates on Linux/macOS: dfu-programmer 0.7.2 or the 1.x series. On Debian/Ubuntu it is one apt away.
• For firmware updates on Windows: Microchip/Atmel FLIP 3.4.7, the canonical AVR DFU flasher.
• A hashing tool. On Linux/macOS, sha256sum or shasum -a 256 ships with the OS. On Windows, certutil is built in.
• The latest stable RetroArch and the cores Snes9x (or bsnes/Mesen) and Genesis Plus GX, installed via the RetroArch core downloader. See the libretro documentation.
• For dump verification: a current No-Intro DAT file from Datomatic, plus a ROM manager such as clrmamepro or RomVault to compare against it.

Confirm your toolchain works before touching the Retrode. On Linux, verify the hashing and USB tools are present:

$ sha256sum --version | head -n1
sha256sum (GNU coreutils) 9.4

$ lsusb --version
lsusb (usbutils) 015

$ dfu-programmer --version
dfu-programmer 0.7.2

If any of those three error out, fix that now. You do not want to discover a missing tool with a cartridge half-read.

The Dump Procedure in 12 Steps

This is the core of the tutorial. Each step has a reason attached, because a step you perform without understanding is a step you will perform wrong under stress.

1. Inspect and clean the cartridge. Tilt the cartridge to the light and look at the gold edge connector. If it is dull, hazy, or has visible grime, dampen a lint-free swab with 90%+ isopropyl alcohol and wipe the contacts in one direction. Rationale: the Retrode reads the cartridge bus directly; one oxidized pin produces a corrupt dump that still looks like a file. Cleaning first turns a future mystery into a non-event.

2. Power off and seat the cartridge with the Retrode disconnected. Insert the cart fully and squarely into the correct slot—SNES carts only fit the SNES slot, Genesis only the Genesis slot, but a partially seated cart will fit just enough to lie to you. Rationale: inserting under power can momentarily short the bus and, in the worst case, corrupt the save battery's contents. Seat cold.

3. Connect the Retrode to the computer with the Mini-USB cable. The unit has no power switch; USB provides the power. Rationale: bus power means cable quality matters. A flaky or charge-only cable will brown out the unit mid-read. Use a known-good data cable.

4. Confirm enumeration. The OS should detect a USB Mass Storage device within a couple of seconds. On Linux, watch the kernel ring buffer and the USB device list:

   $ lsusb
   Bus 001 Device 014: ID 0403:97c1 Matthias Lange Retrode
   
   $ dmesg | tail -n 6
   [ 4123.551] usb 1-2: new full-speed USB device number 14
   [ 4123.701] usb-storage 1-2:1.0: USB Mass Storage device detected
   [ 4124.713] scsi 6:0:0:0: Direct-Access     Retrode  Retrode2
   [ 4124.910] sd 6:0:0:0: [sdb] 4096-byte logical blocks
   [ 4124.913] sd 6:0:0:0: [sdb] Attached SCSI removable disk

   Rationale: the exact VID:PID printed by your unit depends on its firmware—read yours, do not copy mine—but the device must appear as removable storage. If it appears as something else, or not at all, stop and go to troubleshooting.

5. Mount the volume. Most desktop environments auto-mount the RETRODE volume. If yours does not, mount it by hand:

   $ lsblk -o NAME,LABEL,SIZE,MOUNTPOINT | grep -i retrode
   sdb1   RETRODE   3.9M
   
   $ sudo mkdir -p /mnt/retrode
   $ sudo mount /dev/sdb1 /mnt/retrode
   $ ls -la /mnt/retrode
   -r-xr-xr-x 1 root root 3145728 Jan  1  2000 SUPER METROID.SFC
   -rwxr-xr-x 1 root root   8192  Jan  1  2000 SUPER METROID.SRM
   -r-xr-xr-x 1 root root    512  Jan  1  2000 RETRODE.CFG

   Rationale: the ROM file is read-only by design—the cartridge cannot be written to in the ROM region—while the .SRM is read-write because save RAM can be written back. The filenames come from the cartridge's internal header, which is why they are sometimes truncated or oddly spelled. That is the chip telling you its true name.

6. Verify the reported size matches the cartridge. A 24 Mbit Super Metroid should read as a 3,145,728-byte (3 MB) file. A mismatch—half the expected size, or a suspiciously round small number—means a bad read or an unsupported mapper. Rationale: catching a short read here saves you from hashing garbage in step nine.

7. Copy the ROM off the device, do not work in place. Pull the file onto local storage before doing anything else:

   $ cp "/mnt/retrode/SUPER METROID.SFC" ~/roms/snes/
   $ cp "/mnt/retrode/SUPER METROID.SRM" ~/saves/snes/
   $ ls -l ~/roms/snes/
   -rw-r--r-- 1 you you 3145728 Jun 16 11:02 SUPER METROID.SFC

   Rationale: the Retrode reads the cartridge live every time a sector is requested. Hashing or loading a file directly off the mount re-reads the cartridge bus repeatedly and multiplies your exposure to a flaky contact. Copy once, then operate on the copy.

8. Read the file twice and compare. Copy a second time to a different name and diff the hashes:

   $ cp "/mnt/retrode/SUPER METROID.SFC" /tmp/pass2.sfc
   $ sha256sum ~/roms/snes/"SUPER METROID.SFC" /tmp/pass2.sfc
   9a3b...e1f0  /home/you/roms/snes/SUPER METROID.SFC
   9a3b...e1f0  /tmp/pass2.sfc

   Rationale: two reads with identical hashes is your cheapest possible confidence check. A flaky connector tends to produce different garbage on each pass; identical hashes across two independent reads make an intermittent fault very unlikely.

9. Hash the dump and record it. Compute and save the checksum alongside the ROM. Rationale: this hash is the dump's fingerprint. You will compare it to No-Intro in the next section, and you will keep it forever as proof the file has not rotted on your own disk.

10. Unmount before removing anything. Eject the volume cleanly, then disconnect the Retrode before removing the cartridge:

    $ sync
    $ sudo umount /mnt/retrode
    $ echo "safe to disconnect"
    safe to disconnect

    Rationale: if you wrote a save back (covered later), unmounting flushes it to the cartridge's SRAM. Pulling the cart under power risks the same bus short as step two, with your save battery in the firing line.

11. Rename to the No-Intro canonical name. The header-derived name is functional but not standard. Rename the verified file to its No-Intro entry, e.g. Super Metroid (USA).sfc. Rationale: RetroArch's playlist scanner matches files against its database by name and hash; canonical names produce clean playlists with correct box art instead of a list of shouty header strings.

12. Scan into RetroArch. Point the content importer at your ROM directory and let it build the playlist. Rationale: a verified dump is only preserved if you can actually play it; importing confirms the file is well-formed and that your core loads it. The full process is documented in the RetroArch import-content guide.

That is the loop. The first run is deliberate; by the third cartridge you will be doing steps three through ten on autopilot in under two minutes.

Verifying Your Dumps Against No-Intro

A dump you have not verified is a rumor. Verification against the No-Intro database is what converts your file from "probably fine" into "provably the same bytes as every other clean dump of this cartridge in the world."

No-Intro maintains DAT files: XML databases listing every known-good ROM with its CRC32, MD5, and SHA-1. You compare your dump's hash against the relevant DAT. A match means your read is bit-perfect against the community reference. A miss means either a bad dump, a regional variant, or a revision the DAT splits out separately.

The quick manual check uses the same hashing tools from the prerequisites. Generate all three hashes No-Intro tracks:

$ cd ~/roms/snes
$ FILE="Super Metroid (USA).sfc"
$ crc32 "$FILE"        # from the 'libarchive-zip-perl' package on Debian
d63ed5f8
$ md5sum "$FILE"
21f3e98df4780ee1c667b84e57d88675  Super Metroid (USA).sfc
$ sha1sum "$FILE"
da957f0d63d14cb441d215462904d29ccb5d99c4  Super Metroid (USA).sfc

Then search the SHA-1 in the No-Intro database via Datomatic. A hit on all three hashes is a verified dump. For a whole library, do not do this by hand—load your ROM folder and the matching DAT into clrmamepro or RomVault and let the manager report matches, mismatches, and unknowns in one pass.

One wrinkle specific to SNES dumps: copier headers. Some old tools prepend a 512-byte header to .smc files. The Retrode produces clean, headerless dumps, which is correct and what No-Intro expects, but if your hash is off by exactly the difference a 512-byte prefix would cause, that is your culprit. Expected output for a clean, headerless 24 Mbit ROM is a file size that is an exact power-of-two multiple of the bank size with no 512-byte remainder:

$ stat -c '%s bytes' "Super Metroid (USA).sfc"
3145728 bytes
$ python3 -c "print(3145728 % 1024)"
0

A file size of 3146240 (i.e. 3145728 + 512) would betray a stray copier header. The Retrode does not add one, but a tool in your pipeline might.

Firmware Updates Without Bricking

The Retrode's firmware is what determines which mappers and enhancement chips it understands. Older firmware chokes on Super FX (Star Fox, Yoshi's Island) and SA-1 (Super Mario RPG, Kirby Super Star) carts; newer firmware handles many of them and adds plugin support. If a cartridge dumps short or empty, a firmware update is often the fix. It is also the single most nerve-wracking thing you will do with the device, so we do it carefully.

The AT90USB1287 has a factory DFU (Device Firmware Upgrade) bootloader baked into protected flash. You cannot erase the bootloader through normal flashing, which means a botched firmware flash is recoverable—you re-enter DFU mode and try again. This is the safety net. Respect it and you cannot truly brick the unit.

To enter the bootloader, you hold the Retrode's bootloader button (or short the HWB jumper, depending on your board revision) while connecting the USB cable, then release. The device now enumerates as an Atmel DFU device rather than a mass-storage device. Confirm it:

$ lsusb | grep -i atmel
Bus 001 Device 021: ID 03eb:2ff9 Atmel Corp. atmega32u2 DFU bootloader

# Note: the AT90USB1287 bootloader reports as 03eb:2ff9

Once you see the 03eb: Atmel DFU device, flash with dfu-programmer. Erase, flash the official .hex, then reset:

$ sudo dfu-programmer at90usb1287 erase --force
Checking memory from 0x0 to 0x1FFFF...  Erased.

$ sudo dfu-programmer at90usb1287 flash retrode2-firmware.hex
Validating...
28160 bytes used (21.48%)

$ sudo dfu-programmer at90usb1287 reset

On Windows, the equivalent is Atmel FLIP 3.4.7: select the AT90USB1287 target, open the firmware HEX, tick Erase / Program / Verify, run, then start the application. After reset, unplug and replug normally; the unit should re-enumerate as mass storage with your new firmware. Expected behavior: insert a previously-failing Super FX cartridge and it should now produce a full-size ROM.

Two rules that keep this boring instead of exciting: always download firmware from the official Retrode source—archived at the project site, see the Retrode project pages—and never interrupt the flash. The erase step blanks the chip; if you pull the cable between erase and flash, the unit will boot to DFU mode and nothing else until you finish the flash. That is alarming the first time and trivially fixable: re-enter DFU and flash again.

Reading and Writing Save RAM

The Retrode does not just read ROMs—it reads and writes the battery-backed SRAM on cartridges that have it. That makes it a bridge between your physical save and an emulator, in both directions, which is genuinely useful and slightly underappreciated.

Reading is automatic: the .SRM file that appears next to the ROM is your cartridge's current save data. Copy it off, point your emulator's save path at it (RetroArch expects saves in its configured save directory, named to match the content), and your decades-old file resumes exactly where the battery left it. This is the move when a cartridge battery is failing—pull the save now, before the cell dies and the SRAM forgets everything.

Writing is the genuinely clever part. The .SRM on the Retrode volume is read-write. Copy a save file onto the cartridge's .SRM, unmount cleanly, and the data is written back to the physical SRAM. Concretely:

$ ls -l "/mnt/retrode/"*.SRM
-rwxr-xr-x 1 root root 8192 Jan 1 2000 SUPER METROID.SRM

# write an emulator save back to the cartridge
$ cp ~/saves/snes/"Super Metroid (USA).srm" "/mnt/retrode/SUPER METROID.SRM"
$ sync && sudo umount /mnt/retrode
# the save now lives on the cartridge's battery-backed RAM

Two hard constraints. First, the save file size must match what the cartridge expects—you cannot push a 32 KB save onto an 8 KB SRAM, and a size mismatch produces a corrupt or rejected write. Second, the cartridge battery must be alive; if the CR2032 is dead, the SRAM cannot hold what you write the instant the cart loses power. Writing saves is also the one time the "unmount cleanly" instruction in step ten is non-negotiable—an interrupted write to SRAM is exactly as bad as it sounds.

Using the Controller Ports

The two controller ports on the side of the Retrode are not decoration. The unit presents connected SNES and Genesis pads as standard USB HID gamepads, so your authentic 1991 controller becomes an input device for any emulator, with no adapter and no driver. The Machine finds this delightful: the same box that liberates the game also liberates the controller.

Plug a controller in, and the OS reports a new HID gamepad. On Linux you can confirm and watch its events:

$ ls /dev/input/by-id/ | grep -i retrode
usb-Retrode_Retrode2-joystick

$ jstest /dev/input/js1
Axes:  0:     0  1:     0   Buttons:  0:off  1:off  2:off  3:off

In RetroArch, the pad shows up under input settings as an ordinary joypad; bind it like any other. The latency is fine for HID over USB Full Speed—not tournament-grade, but indistinguishable from any other USB pad for single-player play. The practical upshot: one cable, original cartridge, original controller, modern accuracy core. For libretro core specifics, the Snes9x core docs cover input options in detail.

Common Pitfalls and Fixes

Five failure modes account for the overwhelming majority of grief. Read these before you need them.

1. The charge-only cable. The single most common failure is a Mini-USB cable that carries power but not data. The Retrode powers on—any LED lights—but never enumerates as storage. Fix: swap to a cable you have verified moves data on another device. If the unit powers up but no volume appears, suspect the cable before anything else.

2. Dirty or partially seated cartridge. A grimy edge connector produces a dump that completes but is silently corrupt—it hashes, it has a plausible size, and it crashes three levels in. Fix: clean the contacts with isopropyl alcohol, reseat squarely and fully, and rely on the two-read hash comparison from step eight to catch intermittent contacts.

3. Hot-swapping cartridges. Inserting or removing a cart while the Retrode is powered can short the bus and, on save-equipped carts, corrupt the SRAM. Fix: always disconnect USB before changing cartridges. Treat the unit as cold-swap only, every time, no exceptions.

4. Unsupported enhancement chips on old firmware. Super FX and SA-1 cartridges read as zero-byte or truncated files on firmware that predates their support. Fix: update to the latest official firmware (see the firmware section). If a cart still fails after updating, confirm the chip is one your firmware revision lists as supported.

5. Working off the mount instead of a copy. Hashing, loading, or scanning files directly on the RETRODE volume re-reads the cartridge bus repeatedly and turns a marginal contact into a corrupt result. Fix: copy the ROM to local disk first (step seven) and never operate in place.

6. Region and physical-fit mismatches. Super Famicom and Japanese Mega Drive carts often will not seat in the slots designed for US/PAL shells without an adapter, and forcing them damages pins. Fix: use the correct slot adapter for the cartridge shape rather than applying pressure.

Troubleshooting Table

Symptom on the left, the likely cause and fix on the right. Work top to bottom; the cheap fixes are listed first on purpose.

Advanced Tips

Once the basic loop is muscle memory, these earn their keep.

Automate the verify loop. A short shell script that copies twice, compares hashes, and refuses to keep the file unless both reads agree turns step eight from a discipline into a guarantee. Pipe the surviving hash into a log file and you have a self-documenting dump archive—every file stamped with the hash it had the day you dumped it, so future bit-rot on your own disk is detectable.

Keep firmware and DAT files versioned together. When you update Retrode firmware, note the version next to your dump log. If a future dump disagrees with No-Intro, knowing which firmware produced it narrows the investigation instantly. Pull fresh DATs from No-Intro periodically; the database grows as new variants are catalogued.

Pick your core for accuracy, not speed. For SNES, Snes9x is the fast, compatible default, but bsnes/Mesen offer cycle-accurate emulation that exposes enhancement-chip behavior more faithfully—worth it on the exact carts most likely to reveal a marginal dump. Genesis Plus GX is the reliable Genesis choice. The trade-offs are catalogued in the Genesis Plus GX core documentation.

Use the plugin adapters deliberately. The GB/GBA and N64 plugins extend the same drag-and-drop model to those cartridges, but they depend on firmware support—update first, then add the adapter. The dump-verify-rename-scan loop is identical; only the file extension and target core change.

Batch-rename with the DAT, not by hand. A ROM manager can rename your entire verified library to canonical No-Intro names in one pass, which is both faster and less error-prone than typing region tags by hand. Clean names are what make RetroArch's scanner pull correct metadata and box art.

Complete Working Configuration

Here is the full configuration that ties the workflow together: a Linux udev rule so the Retrode mounts predictably without root, and a RetroArch directory configuration so dumped ROMs and pulled saves land where the emulator expects them.

First, discover your unit's real VID:PID with lsusb (do not trust mine), then write a udev rule. Replace VVVV and PPPP with the values you read:

# /etc/udev/rules.d/70-retrode.rules
# Tag the Retrode for predictable, non-root access.
# Read your IDs from lsusb first; do not copy these blindly.
SUBSYSTEM=="usb", ATTR{idVendor}=="VVVV", ATTR{idProduct}=="PPPP", MODE="0660", GROUP="plugdev", TAG+="uaccess", SYMLINK+="retrode"

# Allow dfu-programmer to talk to the Atmel DFU bootloader without sudo
SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2ff9", MODE="0660", GROUP="plugdev"

Reload the rules and confirm your user is in plugdev:

$ sudo udevadm control --reload-rules && sudo udevadm trigger
$ groups | grep -o plugdev
plugdev

Next, the relevant RetroArch directory settings so dumped ROMs scan in and your pulled saves load. Add or confirm these in retroarch.cfg:

# ~/.config/retroarch/retroarch.cfg (relevant keys)
savefile_directory = "~/saves"
savestate_directory = "~/states"
rgui_browser_directory = "~/roms"
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/info"
# Match Retrode .srm saves to content by content name
sort_savefiles_enable = "true"
sort_savestates_enable = "true"

Finally, the end-to-end command sequence as one reproducible block—clean, copy twice, verify, log, unmount. This is the entire tutorial compressed into something you can keep:

#!/usr/bin/env bash
set -euo pipefail
MNT=/mnt/retrode
DEST=~/roms/snes
LOG=~/roms/dump-hashes.log

sudo mount /dev/disk/by-label/RETRODE "$MNT"
SRC=$(find "$MNT" -maxdepth 1 -iname '*.sfc' | head -n1)
base=$(basename "$SRC")

cp "$SRC" "$DEST/$base"
cp "$SRC" /tmp/pass2.sfc
h1=$(sha256sum "$DEST/$base" | cut -d' ' -f1)
h2=$(sha256sum /tmp/pass2.sfc | cut -d' ' -f1)

if [ "$h1" = "$h2" ]; then
  echo "OK  $h1  $base" | tee -a "$LOG"
else
  echo "FAIL two reads disagree: $base" >&2
  rm -f "$DEST/$base"
fi

rm -f /tmp/pass2.sfc
sync && sudo umount "$MNT"
echo "done"

Expected output on a healthy dump:

OK  9a3b1c...e1f0  SUPER METROID.SFC
done

That is the whole machine. A device that refuses to be clever, a workflow that refuses to trust a single read, and a configuration that puts every file where it belongs. The cartridges will keep decaying—that part is not optional, it is physics—but the data does not have to go with them. Dump what you own, verify it against the world's reference, keep the original on the shelf, and the only thing going retrograde will be the games. For deeper core and import documentation, the libretro docs remain the authoritative reference.