Retrode 2026: Dump a Cartridge in 14 Steps, 25 Min

Somewhere on retrode.com there is a product page for a device you cannot buy. The Retrode 3 is, in the manufacturer's own words, a machine whose hardware is finished while the software is still being written. It has a target price — under €100 — and a target availability of the end of the year, with the exact date and the final price both filed under “to be confirmed.” You cannot order it. You can sign up to be told when you can. That is the entire transaction currently on offer.

This is not a complaint so much as a weather report. Announced-but-not-shipping is the natural habitat of preservation hardware: principled, open-source, and perpetually eight months out. The good news is that the tool the Retrode 3 replaces still ships, still works, and still performs the exact job you came here for — turning a physical cartridge you own into a file a computer can read. So this is a tutorial about the Retrode 2, written in the long shadow of the Retrode 3, because the workflow you learn on the old box is the workflow you will use on the new one the moment it finally arrives. Fourteen steps, one cartridge, one verified ROM. Roughly twenty-five minutes, assuming your contacts are clean and your USB cable is a data cable rather than a charging cable wearing a data cable's coat.

If you want the sibling piece that drills only into the shipping hardware, we keep a dedicated Retrode 2 dumping walkthrough on file. This one takes the wider view: from the AVR microcontroller under the old box to the MIPS Linux board under the new one, and the reason the second exists at all.

Retrode 3: Announced, Finished, Unbuyable

Before you spend twenty-five minutes learning the old device, it is worth understanding precisely what the new one is, because the shape of the Retrode 3 explains why the Retrode 2's quirks are worth tolerating in 2026 rather than replacing outright.

What the Retrode 3 actually is

The Retrode 3 is built around a MIPS processor running Debian Linux, with the operating system booting from an SD card so that — in the company's phrasing — updates are simple. It has built-in Wi-Fi, which the manufacturer frames as a workflow change rather than a spec-sheet trophy: you can dump over the network, park your ROMs on a server, and update the game databases without shuffling files by hand. It is fully open source, both the software and the hardware design. Most consequentially for anyone who has fought driver installers on a Tuesday night, it abandons the Retrode 2's USB mass-storage trick and instead registers as a USB-Ethernet device, which means you drive the whole thing from a web browser with no drivers on Windows, macOS, or Linux. New to the family is an NES slot alongside the returning SNES/SFC and Mega Drive/Genesis slots. The stated design goal is the Retrode 2's plug-and-play simplicity crossed with the flexibility of Sanni's open Cart Reader project.

Why you cannot buy one yet

Because it is not for sale. The official product page states plainly that the hardware is finished and the software is in progress, that availability is being aimed at the end of the year, and that both the exact date and the final price remain unconfirmed. The target is under €100. There is no basket, no pre-order, no invoice — only a notification list hosted by the reseller DragonBox. For a 2026 retro-hardware story that is the whole plot: a device that is genuinely done in silicon and genuinely absent from your desk.

Why this tutorial uses the Retrode 2 anyway

Because the Retrode 2 is the one you can actually put in a basket today, and because the two devices are the same idea wearing different decades. The muscle memory transfers. The file formats are identical — a Super Nintendo ROM dumped in 2013 is byte-for-byte the same as one dumped in 2027. The legal posture is unchanged. Learn the read-verify-checksum loop on the AVR-powered Retrode 2 now, and the MIPS Linux box changes nothing except that the transport moves from a mounted FAT volume to a browser tab. Everything below is written to survive that transition.

What a Retrode Actually Is (and Is Not)

The single most common misconception about this device is that it plays games. It does not. Understanding what it refuses to do is the difference between a clean workflow and an afternoon of confusion.

A USB bridge, not an emulator

The official FAQ defines the Retrode as a USB interface for vintage video game cartridges and controllers — and states, in as many words, that it is not an emulator. It does not run the game. It reads the cartridge and hands the contents to a computer, so that an emulator running on that computer can load the ROM from your original media instead of from a file of dubious origin. The Retrode is the bridge; the emulator is the destination. If you were hoping to plug a cartridge into a box and see Mario on a television, this is the wrong box, and honestly the wrong hobby for that particular expectation — you want an FPGA console or a flash cart, not a dumper.

Cartridges as files, controllers as HID

Two things happen when you connect a Retrode. First, the cartridge is exposed as a set of virtual files on USB storage: the ROM and, where the cartridge has battery-backed save RAM, the save data appear as ordinary files you can copy. Second, any controllers you plug into the Retrode's ports appear to the operating system as USB HID-class controllers — the same device class as a modern gamepad — so your original pad becomes a standard input device that emulators can map. The FAQ is explicit that you can use original cartridges and original controllers on a modern computer, which is exactly why the thing has stayed relevant across four console generations of PC hardware.

The ROM-dumper question, and a word on the law

Wikipedia's Retrode entry describes the device as a USB adapter for legacy games and notes, correctly, that it can be considered a ROM dumper because it creates a copy of the cartridge's contents. That word tends to make people nervous, so here is the sober version. A raw cartridge read circumvents no technological protection measure — there is nothing to decrypt, no signature check to defeat — so the DMCA anti-circumvention argument that haunts optical-disc ripping largely does not apply here. What remains is the plain copyright question, and it is jurisdiction-dependent: making a personal backup of a cartridge you physically own sits in a widely tolerated grey zone in much of the world, while distributing that dump to other people is unambiguous infringement everywhere. The Machine's guidance is boring and correct: dump the carts you own, keep the files to yourself, and treat the checksum log as your receipt.

Prerequisites: Hardware, Software, Versions

You need less than the internet will try to sell you. Here is the actual list, with versions, so nothing surprises you halfway through.

The hardware you need

A Retrode 2, which sells for roughly $99.99 at resellers such as DragonBox; genre adapters (N64, Game Boy/GBA, Master System) run about $39.99 each and are optional unless you are dumping those systems. A data-grade USB-A cable — this is the single most common point of failure, so verify it carries data, not just power. The cartridges you own, ideally cleaned. A bottle of 99% isopropyl alcohol and lint-free swabs for the contacts. Optionally a powered USB hub if your machine's ports are flaky under load. That is the entire bill of materials.

The software stack and its versions

The Retrode 2 is a class-compliant USB mass-storage device, so on any modern Windows, macOS, or Linux install it mounts with no drivers. Beyond a file manager you want: a checksum utility (sha1sum/md5sum on Unix, 7-Zip's CRC/SHA on Windows); a set of No-Intro and Redump DAT files to verify dumps against known-good hashes; and an emulator or front-end — RetroArch 1.22.2 is the reasonable 2026 default — to prove the dump boots. Only if you intend to reflash firmware do you also need dfu-programmer 0.7.2 or newer (Linux/macOS) or Atmel/Microchip FLIP 3.4.7 (Windows), plus the firmware image itself, Retrode2-v0.18c.hex. Note the versions: firmware development on the Retrode 2 effectively stopped around 2016, which is the whole reason the Retrode 3 is being built from scratch.

The legal and practical prerequisites

Own the cartridge. Have somewhere to put the files — a folder tree like ~/roms/snes and ~/saves/snes keeps ROMs and saves from colliding. And decide up front that you will checksum every dump, because a Retrode read that looks fine and a Retrode read that is fine differ only by a hash you did not bother to compute.

How the Retrode 2 Works Under the Hood

You do not need to know the silicon to dump a cart, but knowing it turns every troubleshooting step from guesswork into deduction.

The AT90USB646 and mass-storage enumeration

At the center of the Retrode 2 is an Atmel AT90USB646, an 8-bit AVR microcontroller with native USB. When you connect the device, that chip enumerates as a USB mass-storage device and presents a small FAT volume labeled RETRODE. The firmware walks the cartridge's address and data lines, reads the ROM, and exposes it as a file on that volume. Crucially, the ROM file is presented read-only — you cannot write to a mask ROM, and the firmware does not pretend otherwise — while the cartridge's battery-backed SRAM is writable, which is what lets you not only back up your saves but, if you are careful, restore them. The whole device is bus-powered; there is a power LED, and if it is dark, nothing downstream matters.

Slots, edge connectors, and adapters

The Retrode 2 has two native cartridge slots. The upper, wider slot accepts SNES and Super Famicom carts; the lower, shorter slot accepts Sega Genesis and Mega Drive carts. On the front are two DB9 controller ports for Sega pads, and the SNES controller and mouse attach through the device's plug headers. Everything else — N64, Game Boy, Game Boy Advance, Master System — arrives through genre adapters that seat into those slots and headers. The edge connectors are the mechanical heart of the machine and the thing most sensitive to dirt, oxidation, and the tug of a stiff cable, which is why contact hygiene is step two of the dump and not an afterthought.

Firmware, effectively frozen

The Retrode 2's firmware is a .hex image flashed to the AT90USB646 through its DFU bootloader. The documented, widely referenced build is v0.18c (Retrode2-v0.18c.hex); official development stalled around 2016, and while some resellers have shipped later community builds such as v0.25a that broaden compatibility, there has been no sustained first-party firmware line for years. That stagnation is not a scandal — the device does what it does — but it is precisely the gap the open-source, Linux-based Retrode 3 is meant to close, by making the firmware a living thing you update over Wi-Fi instead of a museum piece you flash over a bootloader button combo.

The Dump: 14 Steps From Cart to ROM

Here is the whole procedure, start to finish. It reads long because every step carries its reasoning; in practice, once you have done it twice, it collapses into about twenty-five minutes of mostly waiting.

The pre-flight checklist

Before the numbered list, confirm three things, because each one prevents a specific and common failure:

• The cable carries data. A charging cable will power the LED and enumerate nothing. When in doubt, use the cable the device shipped with or one you have tested.
• The contacts are clean. A cartridge that has been in a drawer since the Clinton administration has oxidized edge fingers. Clean them before, not after, a bad dump.
• You own the cartridge. Stated once, meant permanently.

The fourteen steps

1. Verify the cartridge and its enhancement chip. Confirm the region and, for SNES carts, whether it uses a special chip. Rationale: the Retrode 2 cannot dump SA-1 or S-DD1 titles, and knowing that now saves you from blaming the cable later.
2. Clean the edge connector. Wipe the cartridge's contacts with 99% isopropyl on a lint-free swab; never use a pencil eraser, which abrades the plating. Rationale: the overwhelming majority of corrupt dumps are dirty-contact dumps.
3. Ready your tools. Open your file manager and a terminal; confirm your checksum utility and DAT files are on hand. Rationale: you want to verify the instant the dump lands, while the cartridge is still seated.
4. Seat the cartridge in the correct slot. SNES/SFC in the upper, wider slot; Genesis/Mega Drive in the lower, shorter slot; label facing you, seated firmly but without force. Rationale: the wrong slot reads nothing, and a half-seated cart reads garbage.
5. Connect the Retrode with a known-good data cable. Plug directly into a rear USB port or a powered hub, not a front-panel or keyboard passthrough port. Rationale: undervolted or noisy ports produce intermittent reads that corrupt silently.
6. Confirm enumeration. The device should appear as a removable volume named RETRODE — check lsblk on Linux, Finder on macOS, Explorer on Windows. Rationale: if the volume never appears, no amount of copying will help; fix enumeration first.
7. Open the RETRODE volume and identify the files. You are looking for a ROM file (.SFC, .SMC, .BIN, or .GEN) and, if present, a save file (.SRM). Rationale: knowing which file is which prevents copying the config file and calling it a ROM.
8. Copy — do not move — the ROM to local storage. Drag or cp the ROM off the device into your ROM folder. Rationale: the volume is the cartridge; you never write to it, and copying leaves the original untouched.
9. Copy the save file too. If a .SRM exists and you care about your saves, copy it to your saves folder. Rationale: that save lives in a battery-backed chip that will eventually die; this is your only backup.
10. Dump a second time and compare. Reconnect or re-copy and diff the two ROMs, or simply dump twice. Rationale: intermittent contacts produce reads that are corrupt in different places each time; two identical dumps is strong evidence of a clean read.
11. Checksum against a DAT. Run sha1sum (or md5) on the ROM and compare it to the No-Intro or Redump entry. Rationale: this is the only authoritative confirmation that your dump matches a known-good copy byte for byte.
12. Fix the format if a tool demands it. Deinterleave Genesis dumps if a core rejects them; strip a copier header from an SNES .SMC if the checksum is off by 512 bytes. Rationale: some cores and hash databases expect headerless, deinterleaved data.
13. Boot it in the correct emulator or core. Load the ROM in RetroArch and, if you are using the Retrode's controller passthrough, test the pad too. Rationale: a matching checksum plus a clean boot is proof, not hope. This is also the moment to pick the right RetroArch core for the system.
14. Eject cleanly, store the cart, log the hash. Unmount the RETRODE volume before unplugging, return the cartridge to its case, and record the checksum. Rationale: a clean unmount avoids FAT corruption on the device volume, and a hash log is the backbone of any real preservation habit.

The copy itself, on Linux, is as unremarkable as this — the device usually auto-mounts under /run/media:

# The RETRODE volume typically auto-mounts; confirm where:
lsblk -o NAME,LABEL,MOUNTPOINT | grep -i retrode

# Copy the ROM and save off the device (never onto it):
cp -v "/run/media/$USER/RETRODE/SUPER MARIOWORLD.SFC" ~/roms/snes/
cp -v "/run/media/$USER/RETRODE/SUPER MARIOWORLD.SRM" ~/saves/snes/

Why you dump twice

The one habit that separates a preservationist from a person with a folder of maybe-fine files is the double read. Cartridge edge connectors are analog contacts under mechanical tension; a single read that lands on a momentary bad connection can drop or flip bytes in a way that produces a file of exactly the right size that nonetheless fails a checksum — or worse, passes casual inspection and crashes forty hours into an RPG. Dumping twice and confirming the two reads are identical costs ninety seconds and removes that entire category of heartbreak.

Expected Output: What Success Looks Like

You should not have to guess whether it worked. Here is what a healthy dump looks like at each stage on a Linux box; the macOS and Windows equivalents differ only in cosmetics.

The mounted volume and file listing

On connection, the kernel logs a mass-storage device and mounts a small FAT volume. The listing shows the ROM as read-only and the save as writable — exactly the split described earlier:

$ dmesg | tail -n 4
usb 1-2: new full-speed USB device number 7 using xhci_hcd
usb-storage 1-2:1.0: USB Mass Storage device detected
scsi 6:0:0:0: Direct-Access     Retrode2                  PQ: 0 ANSI: 2
sd 6:0:0:0: [sdb] Attached SCSI removable disk

$ lsblk -o NAME,LABEL,FSTYPE,SIZE,MOUNTPOINT
sdb
└─sdb1  RETRODE  vfat   4M  /run/media/you/RETRODE

$ ls -la /run/media/you/RETRODE
-r--r--r-- 1 you you 524288 Jul 29 11:02 'SUPER MARIOWORLD.SFC'
-rw-r--r-- 1 you you   2048 Jul 29 11:02 'SUPER MARIOWORLD.SRM'
-r--r--r-- 1 you you    512 Jul 29 11:02  RETRODE.CFG

Checksums that match

Compute the SHA-1 and compare it to the DAT. The hash below is illustrative — the point is that your hash must equal the database entry character for character:

$ sha1sum "SUPER MARIOWORLD.SFC"
b9b7d4c... (40 hex chars)  SUPER MARIOWORLD.SFC

# Look up the No-Intro entry for "Super Mario World (USA)".
# A byte-for-byte match means a verified dump. Anything else
# means redump, deinterleave, or strip a header — see step 12.

Controllers that enumerate

If you are using the Retrode as a controller bridge, the original pad appears as a joystick device. A quick sanity check with jstest should show axes and buttons responding as you press them:

$ ls /dev/input/js*
/dev/input/js0

$ jstest --normal /dev/input/js0
Driver version is 2.1.0.
Joystick (Retrode) has 4 axes and 12 buttons.
Axes:  0:     0  1:     0 ...   Buttons:  0:off  1:off  2:on ...

Firmware: Flashing 0.18c With FLIP or dfu-programmer

Most people never need to touch the firmware. But the maintenance path is part of understanding the device, and it is the clearest illustration of why the Retrode 3's over-the-network updates are a genuine improvement rather than marketing.

Whether to update at all

Reflash only if you have a concrete reason — a compatibility fix for a specific cartridge, or a device that shipped with a build older than the one your cart needs. There is no upside to flashing for its own sake, and a bootloader-level operation always carries a small risk. It is worth contrasting this with how firmware works on newer preservation hardware, where updates are frequent, reversible, and low-drama; our log of eleven Analogue 3D firmware builds is a fair picture of the modern cadence the Retrode 2 predates.

The Linux and macOS path: dfu-programmer

Put the device into DFU mode with the hardware buttons, confirm the Atmel bootloader enumerated, then erase, flash, and reset. The AVR target name is at90usb646:

# 1. Enter DFU mode: hold HWB, tap RESET, then release HWB.
# 2. Confirm the Atmel bootloader appears (VID 03eb is Atmel;
#    the product ID depends on your bootloader build):
$ lsusb | grep -i 03eb
Bus 001 Device 010: ID 03eb:2ff9 Atmel Corp.

# 3. Erase, flash the .hex, and reset back to normal mode:
$ dfu-programmer at90usb646 erase --force
$ dfu-programmer at90usb646 flash Retrode2-v0.18c.hex
Checking memory from 0x0 to 0x...  Empty.
Programming 0x.... bytes...  Success
Validating...  Success
$ dfu-programmer at90usb646 reset

The Windows path: Atmel FLIP and the .hex

On Windows the equivalent is Atmel's (now Microchip's) FLIP 3.4.7. The documented procedure — captured in more than one community and Japanese-language guide — is to enter update mode with the same hardware-button dance, launch FLIP, select the AT90USB646 device, open the USB communication channel, load Retrode2-v0.18c.hex, and run the erase/program/verify cycle. It is the same three operations as the command line, wrapped in a dialog box. If FLIP cannot see the device, you are almost always not actually in DFU mode, or the Atmel USB driver did not bind — both covered in the troubleshooting table below.

Common Pitfalls and Their Fixes

Every one of these has cost someone an evening. Reading them now is cheaper than rediscovering them at midnight.

Power and contacts

• The charge-only cable. The LED lights, nothing mounts, and you begin to suspect the device is dead. Fix: swap to a known data cable and plug into a rear or powered port. This is the number-one cause of “my Retrode broke.”
• Oxidized or dirty edge fingers. Dumps that are the right size but fail checksums, or that differ between two reads. Fix: 99% isopropyl on a lint-free swab, reseat, dump twice, and confirm the two match.

Writing, saves, and formats

• Writing to the RETRODE volume. Treating the mounted volume as scratch space, or letting a “safely remove” nag talk you into formatting it. Fix: the volume is the cartridge; only ever copy files off it.
• Interleave and header mismatches. A Genesis dump a core refuses, or an SNES checksum off by exactly 512 bytes. Fix: deinterleave the Genesis image, or strip the 512-byte copier header from the .SMC, then re-checksum.

Chips and shells

• Enhancement-chip cartridges. SA-1 titles (Super Mario RPG, Kirby Super Star) and S-DD1 titles (Star Ocean, Street Fighter Alpha 2) dump as garbage or the wrong size. Fix: there is none on the Retrode 2; these need a reader that supports the chip, which is where Sanni's Cart Reader — and, in time, the Retrode 3 — come in.
• Third-party shells and region tabs. A reproduction or reshelled cart that will not seat, or a region whose tabs foul the slot. Fix: the Retrode 2 slot is tolerant of both NTSC and PAL SNES pinouts, but aftermarket shells vary; check for plastic tabs before forcing anything.

Troubleshooting Table

When a dump goes wrong, resist the urge to reflash firmware as a first move — it is almost never the firmware. Work the table top to bottom.

How to read the table

The left column is the symptom you actually observe; the middle is the most likely cause, ordered by probability; the right is the fix to try first. If a row does not resolve it, the next-most-likely cause is usually the row directly below.

The table

When to suspect the cart, not the Retrode

If a single cartridge fails every test while a dozen others dump cleanly on the same device and cable, the device is not the problem — the cartridge is. Corroded traces, a cracked PCB, or a genuinely dead ROM all present as Retrode failures and are none of them. The double-dump discipline plus a second, known-good cartridge as a control will isolate this in under two minutes.

Advanced Tips: Chips, Saves, Scripting

Once the basic loop is second nature, these are the refinements that turn a one-off dump into a repeatable, auditable process.

Batch dumping and checksum manifests

If you are working through a shelf, do not verify by eyeball. Generate a SHA-1 manifest for a whole folder and diff it against your DATs in one pass:

# Build a hash manifest for every SNES ROM you have pulled:
for f in ~/roms/snes/*.sfc; do
  sha1sum "$f"
done | tee ~/roms/snes/manifest.sha1

# Later, re-verify nothing has rotted on disk:
sha1sum -c ~/roms/snes/manifest.sha1

Controllers into RetroArch

The Retrode's HID passthrough means your original pad can drive an emulator with authentic input latency characteristics. One non-obvious detail: a SNES mouse must go in the LEFT controller port to be recognized, a quirk inherited from the original hardware. Map the pad through RetroArch's autoconfig system and it becomes a first-class input device; the same dumped ROMs and mapped pads drop straight onto a distro build if you would rather run a dedicated Batocera image than a desktop RetroArch install.

Special chips and where the Retrode 2 stops

The Retrode 2's limits are a map of its age. It handles the vast common library and a surprising amount of the odd stuff — the Sega 32X adapter works even without its power supply — but it stops hard at certain enhancement chips (SA-1, S-DD1) and certain passthrough cartridges (the Super Game Boy adapter does not dump). The modern answer to those gaps is Sanni's open-source Cart Reader, whose flexibility the Retrode 3 is explicitly designed to fold into the Retrode line. If your shelf is mostly common carts, the Retrode 2 is more than enough; if it is full of enhancement-chip oddities, that is the strongest argument for joining the Retrode 3 notification list.

The Retrode 3 Bet: MIPS, Linux, Open Everything

Circle back, now that you understand the old device, to the new one — because the case for waiting, or not, is now legible.

Why Wi-Fi and a browser change the workflow

The Retrode 2 workflow is “mount a volume, copy files, unmount.” The Retrode 3 workflow is “open a browser tab.” Because the device registers as a USB-Ethernet interface and runs a local web UI, there are no drivers and no drive letters; and because it has built-in Wi-Fi, the dump does not even have to touch the machine in front of you — it can land on a server, and the game databases can update themselves. For anyone dumping in volume, that is not a gimmick; it is the difference between a chore and a pipeline.

Open hardware and the Sanni lineage

The Retrode 3 is fully open source in both software and hardware, with the design published in public repositories — the Debian-based operating system lives at github.com/DragonBox-Shop/retrode3 and the hardware design files at the companion hardware repo. That openness is philosophically continuous with Sanni's Cart Reader and with the broader open-hardware preservation movement; if you find that ethos compelling, it is the same one that produces community FPGA gear like the MiSTer Multisystem. Open hardware ages differently from closed hardware: when the vendor moves on, the community can keep the firmware alive, which is exactly the failure mode the frozen Retrode 2 firmware demonstrates.

Should you wait?

The Machine's verdict is unsentimental. If you have carts to dump now — and especially if they are the common SNES and Genesis libraries the Retrode 2 handles flawlessly — buy the shipping device and start, because a dumped, checksummed, backed-up cartridge in 2026 beats a €100 promissory note for late 2026. If your library is dominated by enhancement-chip carts the Retrode 2 cannot touch, or you want the Wi-Fi pipeline, join the DragonBox notification list and wait for a device that is, by the maker's own account, finished in hardware and merely unfinished in software. Either way, the twenty-five-minute loop above is the loop you will run on both.

The Complete Working Configuration

Everything above, distilled into three files you can keep. Treat the first as illustrative and the other two as ready to use.

The RETRODE.CFG (illustrative)

The Retrode exposes a config file on its volume that tweaks naming and dump behavior. The exact keys differ between firmware builds, so the following is a representative shape rather than gospel — always read the README on your own RETRODE volume for the keys your firmware honors:

# RETRODE.CFG — ILLUSTRATIVE. Key names vary by firmware build;
# consult the README on the RETRODE volume for your version.
FILENAME=header      ; header | fixed | auto
SNES_EXT=.sfc        ; extension for SNES/SFC dumps
GENESIS_EXT=.bin     ; extension for Genesis/Mega Drive dumps
DUMP_SRAM=on         ; also expose battery-backed saves as .SRM
READ_RETRIES=1       ; increase only if a cart reads intermittently

The dump-and-verify script

A small, defensive Bash script that copies ROMs and saves off the mounted volume, sorts them, and writes a checksum manifest — the whole loop, minus the human judgment:

#!/usr/bin/env bash
# retrode-dump.sh — copy a cart off the RETRODE volume and verify it.
# Usage: ./retrode-dump.sh /run/media/you/RETRODE ~/roms
set -euo pipefail

SRC="${1:?path to the mounted RETRODE volume}"
DEST="${2:?destination root, e.g. ~/roms}"
mkdir -p "$DEST/rom" "$DEST/save"

# Copy ROMs and saves; the config file stays on the device.
find "$SRC" -maxdepth 1 -type f ! -name 'RETRODE.CFG' -print0 \
  | while IFS= read -r -d '' f; do
      base="$(basename "$f")"
      case "$base" in
        *.SFC|*.sfc|*.SMC|*.smc|*.BIN|*.bin|*.GEN|*.gen|*.N64|*.z64)
          cp -v "$f" "$DEST/rom/" ;;
        *.SRM|*.srm)
          cp -v "$f" "$DEST/save/" ;;
      esac
    done

# Write a SHA-1 manifest next to the ROMs for DAT comparison.
( cd "$DEST/rom" && sha1sum ./* | tee manifest.sha1 )

echo "Done. Compare manifest.sha1 against your No-Intro/Redump DAT."

The RetroArch controller autoconfig

Finally, a template autoconfig so your original pad, passed through the Retrode, maps cleanly in RetroArch. Button indices are hardware-specific — use the in-app binder to fill in yours — and the format is documented in the libretro documentation:

# ~/.config/retroarch/autoconfig/udev/Retrode.cfg  (TEMPLATE)
input_driver = "udev"
input_device = "Retrode"
input_vendor_id = "1003"     # illustrative — read yours from the log
input_product_id = "0000"    # illustrative
input_b_btn = "0"
input_a_btn = "1"
input_y_btn = "3"
input_x_btn = "4"
input_select_btn = "8"
input_start_btn = "9"
input_up_btn = "h0up"
input_down_btn = "h0down"
input_left_btn = "h0left"
input_right_btn = "h0right"

That is the entire discipline: a device that reads, a loop that verifies, and three files that make it repeatable. The Retrode 3 will change the transport and keep the discipline. The cartridges, meanwhile, are not getting any younger — which is the only deadline in this hobby that actually matters.