Retrode3 ROM Dumping: 14 Steps in 45 Minutes (2026)

Let us start with the thing the marketing pages will not tell you in the first sentence: as of this writing, you cannot buy a Retrode3. The hardware is finished, the maker says, but the software is still in development, the price is still a moving target somewhere south of EUR 100, and the only thing you can actually do on the official site is sign up to be notified. So this is a tutorial about a device that is half real and half promissory note. That is fine. The Retrode concept has been real and shipping since 2012, and the Retrode2 has been quietly dumping cartridges on people's desks for over a decade. Most of what you will do with a Retrode3 is conceptually identical to what you already do with a Retrode2 — you put a cartridge in a slot, the device reads the silicon, and a file comes out the other end. What changes is the plumbing, and the plumbing is the interesting part.

This guide walks the full workflow: prerequisites, the physical setup, the network handshake, fourteen numbered steps to get a clean ROM off a cart, save-file extraction, checksum verification against the No-Intro database, and the handoff into RetroArch so the thing is actually playable. It also tells you where the floor is loose. If you have never dumped a cartridge before, read the whole thing once before you touch hardware. If you are a veteran with a Retrode2 and you are here for the Retrode3 delta, skip to How the Retrode3 Works Under the Hood and Network and Browser Connection, because those are the two sections where the new device stops behaving like the old one.

What a Retrode Actually Is

A Retrode is a cartridge reader. That is the entire pitch, and the discipline of the original design was in refusing to be anything more. When Matthias Hullin described the concept in his 2012 interview with Sega-16, he was deliberate about one point that people still get wrong: the Retrode does not replace emulation. It does not contain a CPU that runs Mega Drive code. It is not a clone console. It is a bridge that reads the program data and the save RAM directly off an original cartridge and hands the bytes to a PC, where an emulator — your emulator, of your choosing — does the actual running. You can read his framing in the original Sega-16 interview with Matthias Hullin, and it is worth reading because the design philosophy explains the device's limits as much as its features.

The practical consequence of that philosophy is that a Retrode produces a file that is, byte for byte, the ROM image on the cartridge you own. Not a download. Not a scene release of dubious provenance. The exact contents of the mask ROM that Nintendo or Sega had fabricated decades ago, pulled by your hardware from the cartridge in your hand. For preservation work this is the entire ballgame, because provenance is everything and "I dumped it myself from a verified cart" is a sentence that survives scrutiny in a way that "I found it on a forum" does not.

The Retrode2 reads Super Nintendo / Super Famicom and Sega Mega Drive / Genesis cartridges natively, with adapters available for Game Boy, Game Boy Advance, Nintendo 64 and a handful of others. The Retrode3, per the official product page, supports Mega Drive / Genesis, SNES / SFC and NES, reads both ROM and SRAM, and — a detail the old hands will appreciate — still works with original controllers plugged into the cartridge reader's gamepad ports, so you can use a real Genesis pad on a modern machine. The canonical reference for all of this is the official Retrode site, which in 2026 functions as the only authoritative source for Retrode3 specifications and availability.

Prerequisites: Hardware and Software Versions

You cannot wing this with a USB cable you found in a drawer and good intentions. Here is what you actually need, with versions, because version drift is where half of all dumping sessions die.

Hardware:

• A Retrode device. Either a Retrode2 (shipping, available now through DragonBox) or a Retrode3 (announced, not orderable as of mid-2026 — you can only register for notification). This tutorial covers both; where they diverge, the section says so.
• The cartridge you intend to dump, physically clean. A bottle of 99% isopropyl alcohol and lint-free swabs. Dirty contacts are the single most common cause of a bad dump, and no software fixes a dirty cart.
• For the Retrode2: a USB 2.0 cable (Mini-B on the device end) and a host port that supplies a stable 500 mA. Powered USB hubs are fine; flaky front-panel ports on a fifteen-year-old case are not.
• For the Retrode3: a USB cable and, separately, a microSD card of at least 8 GB, Class 10 or better. The Retrode3 boots its OS from the SD card, which is the mechanism the maker points to when they call the device "practically unbrickable."
• Optional but recommended: a USB current meter. Knowing whether your cart is pulling 60 mA or 300 mA tells you instantly whether a read is healthy or whether something is shorting.

Software (host PC):

• An operating system that can talk to the device. For the Retrode2 that means any OS with USB mass-storage support — Windows 10/11, macOS 12 or newer, or a modern Linux kernel (5.x or 6.x). For the Retrode3, the design registers as a USB-Ethernet device and is operated through a web browser, with stated driverless compatibility for Windows, macOS and Linux.
• A current browser if you are on a Retrode3. Anything on a 2025-or-later release of Chromium, Firefox or Safari is fine; the device serves a local web UI, it does not depend on any cloud service.
• RetroArch 1.19 or newer for the playback half of the workflow, with the appropriate cores: Snes9x or bsnes for SNES, Genesis Plus GX for Mega Drive / Genesis, Mesen or FCEUmm for NES.
• A checksum tool. On Linux/macOS, sha1sum/shasum ships with the system. On Windows, use CertUtil or install a port of the coreutils.
• A recent No-Intro DAT set for the systems you are dumping, for verification. More on that in Verifying Dumps Against No-Intro.

One prerequisite that is not on any spec sheet: patience for the firmware situation. The Retrode2's classic firmware is a known, stable quantity. The Retrode3's software is, by the maker's own admission, still in development. If you are reading this with a Retrode3 in hand because you got an early unit, assume the web UI and the on-device tooling will change under you, and pin a known-good SD image before you do anything irreversible.

How the Retrode3 Works Under the Hood

This is the section that justifies the entire "successor to the Retrode2" claim, so pay attention even if you skim the rest. The Retrode2 was, architecturally, a microcontroller that presented the cartridge as a USB mass-storage device. You plugged it in, your operating system saw a removable drive, and on that drive sat a file — GENESIS.BIN, SNES.SFC, whatever the cartridge was — that you copied off like any other file. Beautifully dumb, in the engineering sense. Nothing to configure, nothing to install, no drivers on any modern OS. The dumb-appliance design is the reason it lasted.

The Retrode3 keeps the appliance spirit but moves the brain up several weight classes. Per the official site, it is built around a MIPS processor running Linux — specifically a Debian-based OS — with built-in Wi-Fi, booting from that SD card mentioned above. Instead of presenting as a mass-storage drive, it registers as a USB-Ethernet device and exposes a web interface. You operate it through a browser. That sounds like overkill for "read a cartridge," and for the simple case it is, but the new capabilities are what the extra silicon buys: the device can dump games over the network, push ROMs to a server rather than only to the machine it is plugged into, and update game-identification databases like No-Intro online. The whole stack — hardware design and source code — is stated to be fully open source under the DragonBox-Shop organization on GitHub. It is made in Germany. These are not idle details; they are the difference between a peripheral and a small networked appliance you happen to feed cartridges.

The reframing matters because it changes your mental model of the workflow. With a Retrode2 you think in terms of files on a drive. With a Retrode3 you think in terms of HTTP endpoints and a device on your network. The cartridge slots are the same; the everything-after-the-slots is different. If your instinct is to look for the mounted drive, you will not find it, and you will waste twenty minutes before you remember to open a browser tab. The Microsoft Developer team's GDC 2026 coverage of friction-reduction tooling is, weirdly, a useful frame here: the whole industry has been moving toward browser-like, driverless, server-mediated workflows, and the Retrode3 is that trend arriving in the cartridge-dumping corner of the world. The friction goes down; the conceptual surface area goes up.

Hardware Setup and First Boot

Physical setup is the same gesture on both devices, with one extra step for the Retrode3. Do this before you connect anything to your PC.

First, clean the cartridge. This is not optional and it is not paranoia. Decades of oxidation and household grime sit on those edge connectors, and a single high-resistance contact produces a dump that is 99.9% correct and therefore worthless, because the 0.1% is silently wrong and you will not know until a boss fight crashes. Dampen a lint-free swab with isopropyl, run it firmly along the contacts a dozen times each direction, let it dry completely, and inspect for visible grime transfer onto the swab. If the swab comes away black, clean again until it comes away clean.

Second, seat the cartridge fully in the correct slot. The Retrode reads the Genesis and SNES slots independently; inserting a cart crooked or half-seated is the second most common cause of a bad read after dirty contacts. It should sit flush and require a deliberate, even press.

For the Retrode2, that is the hardware phase complete — connect USB and move on. For the Retrode3, you have one more job: the SD card. The OS lives there, so before first boot you flash the maker's image to the card. Here is the canonical flash on Linux or macOS; substitute your card's actual device node, and triple-check it, because dd writing to the wrong device is how people erase their main drive.

# Identify the SD card device FIRST. Do not guess.
lsblk -d -o NAME,SIZE,MODEL
# Example output:
#   sda   931.5G  Samsung SSD 870
#   sdb     7.4G  Generic- SD/MMC      <-- this is the card

# Write the Retrode3 image (replace path and /dev/sdb to match yours)
sudo dd if=retrode3-debian-2026.img of=/dev/sdb bs=4M status=progress conv=fsync

# Flush and eject cleanly
sync
sudo eject /dev/sdb

Insert the flashed card, then connect the device. On first boot the Retrode3 brings up its Debian OS from the card, which is the whole point of the SD-boot design: a corrupted update never bricks the hardware, because you reflash a card instead of reflashing soldered storage. Keep a second card with a known-good image in a drawer. That is your undo button, and on a device whose software is explicitly still in development, you will want an undo button.

Network and Browser Connection

This section applies to the Retrode3. Retrode2 users can skip ahead to Dumping a Cartridge in 14 Steps, where your device simply shows up as a drive.

When you plug a Retrode3 into your PC, it registers as a USB-Ethernet adapter. Your operating system sees a new network interface — not a drive, a network interface — and the device serves its web UI over that link. On Linux you can confirm the interface came up before you ever open a browser:

# Confirm the USB-Ethernet interface enumerated
ip -br link | grep -i usb
# Expected: a new interface, e.g.
#   enxAABBCCDDEEFF   UP   aa:bb:cc:dd:ee:ff

# Confirm you pulled an address on the device's link-local subnet
ip -4 addr show enxAABBCCDDEEFF
# Expected: inet 169.254.x.x/16  or a device-assigned 10.x range

The device exposes its interface at a fixed local address or hostname. Open a browser and navigate to it. Because the Retrode3 is driverless by design on Windows, macOS and Linux, there is nothing to install — the appliance-spirit promise survives the architecture change. If the page does not load, the problem is almost always that your OS routed the interface as a regular network and is trying to send the request out your real gateway. Pin the route to the device interface explicitly:

# Force traffic for the device subnet onto the USB-Ethernet link
# (adapt the subnet and interface name to your machine)
sudo ip route add 10.55.0.0/24 dev enxAABBCCDDEEFF

# Verify the route exists and points at the right interface
ip route get 10.55.0.1
# Expected: 10.55.0.1 dev enxAABBCCDDEEFF src 10.55.0.42

The built-in Wi-Fi is a separate path. Configured through the web UI, it lets the device dump straight to a server on your LAN rather than to the attached PC — the network-dumping capability the maker advertises. For a first session, ignore Wi-Fi and use the USB link; it is one fewer variable. Once the wired path works end to end, come back and set up Wi-Fi for the hands-off archival workflow described in Advanced Tips.

A note on the web API: because the Retrode3 software is still in development, the exact endpoint paths in the examples below are illustrative. Treat the shape as correct and the literal strings as something to confirm against whatever version ships on your SD image. The official site and the DragonBox-Shop GitHub repositories are the sources of truth once the software is final; the open-source stack means you can read the actual route definitions rather than guess.

Dumping a Cartridge in 14 Steps

Here is the core procedure. Each step has a rationale, because a tutorial that says "now click dump" without telling you why is training you to fail silently. Steps that differ between Retrode2 and Retrode3 are marked.

1. Clean the cartridge contacts. Rationale: every bad dump downstream traces back to here. A clean read is impossible from a dirty connector, and the failure is silent. Do not skip this even on a cart you cleaned last week — oxidation returns.
2. Seat the cartridge fully in the correct slot. Rationale: a half-seated cart reads partial address lines and produces a file that is the right size but wrong contents. Flush and firm, every time.
3. Connect the Retrode to the host. Rationale: power before logic. The device needs stable bus power to drive the cartridge's address and data lines; an underpowered port browns out mid-read. Use a rear port or a powered hub.
4. Confirm enumeration. Rationale: prove the OS sees the device before you trust it. On a Retrode2, confirm the mass-storage drive mounted; on a Retrode3, confirm the USB-Ethernet interface came up (see Network and Browser Connection). If this step fails, nothing after it can succeed.
5. Open the interface. Retrode2: open the mounted drive in your file manager. Retrode3: open the device's web UI in a browser. Rationale: this is the moment the two devices stop being interchangeable, and confusing the two is the single biggest time-waster for people moving up from a Retrode2.
6. Identify the cartridge. Rationale: the device (or you) needs to know whether it is reading a Genesis cart, an SNES cart, or NES, so it applies the right pinout and ROM-size heuristics. On the Retrode3 the on-device No-Intro database can name the title; on the Retrode2 you confirm by the slot and the auto-detected size.
7. Check the reported ROM size. Rationale: known-good titles have known sizes. A 4 Mbit game that reports as 2 Mbit means a read fault or a bad mapper detection. If the size is wrong, stop and reseat — do not dump a file you already know is short.
8. Dump the ROM. Retrode2: copy the .bin/.sfc/.smc file off the drive to local storage. Retrode3: trigger the dump in the web UI (or via the API in the config section) and let it write to your chosen destination. Rationale: this is the actual read of the mask ROM. Everything before it was setup; everything after it is verification.
9. Copy, do not edit in place. Rationale: on a Retrode2 the file you see is a live view of the cartridge, not a stored copy. Always copy it to your disk before doing anything to it. Renaming or hashing the in-place file re-reads the cart every time, which is slow and invites a mid-operation glitch.
10. Record the read current, if you have a meter. Rationale: a healthy SNES read sits in a predictable current band; a cart pulling far more is shorting, far less is not fully seated. This is your cheapest early-warning signal and most people never use it.
11. Dump the SRAM, if the cart has a battery save. Rationale: the save RAM is separate silicon from the program ROM and is dumped separately. If you skip it, you lose decades of someone's progress. See Pulling SRAM Saves Off the Cart.
12. Compute the checksum. Rationale: a dump you have not hashed is a dump you have not verified. Run sha1sum (or the device's built-in hash) immediately, while the cart is still seated, so a mismatch can be retried without re-handling hardware.
13. Verify against No-Intro. Rationale: the No-Intro DAT is the reference for "is this byte-for-byte the canonical good dump." A match is proof; a mismatch is a flag to investigate, not necessarily a failure (region and revision variants exist). See Verifying Dumps Against No-Intro.
14. Name and file the ROM, then eject. Rationale: a verified dump with a junk filename is a future archaeology problem. Adopt the No-Intro naming convention now, while you still know what the cart was, then eject cleanly so the next cartridge starts from a known state.

Run those fourteen steps once slowly and the second cartridge takes under three minutes. The first one takes longer because you are learning where the floor creaks.

Pulling SRAM Saves Off the Cart

The save game is not part of the ROM. On a cartridge with battery-backed memory — most RPGs, most games with a save feature predating password systems — there is a small SRAM chip kept alive by a coin cell, and its contents are someone's actual play history. The Retrode reads it as a separate operation, and the file it produces is what an emulator expects as the cartridge's save RAM.

On a Retrode2 the SRAM appears as a second, smaller file on the mounted drive alongside the ROM. Copy it the same way you copied the ROM:

# Retrode2: copy both ROM and SRAM off the mounted device
# (mount point varies; this assumes /media/retrode)
cp "/media/retrode/CHRONO.SFC"  ~/dumps/snes/
cp "/media/retrode/CHRONO.SRM"  ~/dumps/snes/saves/

# Confirm the SRAM is a sane size (2KB-32KB is typical for SNES)
ls -l ~/dumps/snes/saves/CHRONO.SRM
# Expected: -rw-r--r-- 1 you you 8192 ... CHRONO.SRM

On a Retrode3 you trigger the SRAM read through the web UI or the API, the same as the ROM dump but targeting the save region. The device knows the difference between program ROM and save RAM and reads the appropriate address space. The file extension your emulator wants varies by system — .srm for many libretro cores, .sav for others — so check your core's expectations in the RetroArch / libretro documentation before you rename anything.

One blunt warning: the battery in a thirty-year-old cartridge is the thing keeping that save alive. If the battery is dead, the SRAM is already gone and there is nothing to dump — you will read zeroes or garbage. If the battery is alive but weak, the act of handling the cart can lose the save. Dump SRAM first, before you do anything else to a cart you care about, and never dump SRAM from a cart whose battery you are mid-way through replacing. Save preservation is a race against chemistry, and chemistry is undefeated.

Verifying Dumps Against No-Intro

A dump you have not verified is a rumor. Verification is the step that converts "I think I dumped this correctly" into "this file is provably identical to the community reference," and it is the entire reason the preservation crowd takes the Retrode seriously. The reference is the No-Intro project, which maintains DAT files listing the canonical good dump of every known cartridge by checksum. The Retrode3 advertises the ability to update these databases online, which is genuinely useful — your verification reference stays current without manual DAT wrangling.

The manual verification, which works for both devices, is a three-line affair:

# Compute the SHA-1 of your fresh dump
sha1sum ~/dumps/snes/CHRONO.SFC
# Example output:
#   a3f5c1...e09b  /home/you/dumps/snes/CHRONO.SFC

# Look that hash up in the No-Intro SNES DAT.
# A match means: byte-for-byte identical to the verified good dump.
# A mismatch means: investigate — wrong region, bad read, or a variant.
grep -i "a3f5c1...e09b" "Nintendo - SNES (No-Intro).dat"
# Expected on success: a <rom name="..." sha1="A3F5C1...E09B"/> line

If the hash matches, you are done — file it under the name from the DAT and move on. If it does not match, do not panic and do not immediately re-dump. Mismatches have mundane causes: you dumped a Japanese SFC cart and compared against the US DAT, you have a revision the DAT lists separately, or the header bytes differ. Read the DAT entry for your title, confirm the size matches a known variant, and only suspect a bad read if size and region are right but the hash is still wrong. The No-Intro project's own site documents its conventions and DAT format; grab the current sets from no-intro.org and keep them updated, because a stale DAT throws false mismatches on titles added after your last download.

Handing ROMs to RetroArch

The Retrode produces a file. RetroArch runs it. The handoff is where the two halves of the "original cart, your emulator" promise meet, and it is mostly a matter of putting files where the cores expect them. Install the cores for your systems, drop the verified ROMs into a folder RetroArch scans, and place the SRAM files where the core looks for saves.

The save-file placement is the part people get wrong. RetroArch, by default, stores saves next to content or in a dedicated saves directory depending on your config. If you want the SRAM you pulled off the real cartridge to load — your actual save, decades of it — the file has to land where the core reads it and carry the basename the core expects. Here is the relevant slice of a working retroarch.cfg:

# retroarch.cfg — relevant save/system paths
savefile_directory = "~/dumps/snes/saves"
savestate_directory = "~/states"
system_directory = "~/.config/retroarch/system"

# Keep cartridge SRAM and emulator save states clearly separate
sort_savefiles_enable = "true"
sort_savestates_enable = "true"

# Don't let RetroArch silently overwrite a hand-dumped .srm
# until you've confirmed it loaded correctly
savefiles_in_content_dir = "false"

Match the SRAM filename to the ROM filename — CHRONO.SFC pairs with CHRONO.srm — so the core associates them. Load the ROM, and if everything lined up, your real-cartridge save is right there in the load menu. The core-specific details (which save extension, which system files a core needs, BIOS requirements for some systems) live in the libretro documentation, and you should read your specific core's page once rather than assuming the defaults match. Genesis Plus GX, Snes9x and Mesen each have their own quirks, and the docs are good.

Five Pitfalls and Their Fixes

These are the failures that eat the most time, ranked by how often they happen and how badly they are diagnosed.

1. Dirty contacts producing a near-correct dump. This is number one for a reason. The file is the right size, it even boots in an emulator, and then it corrupts at a specific point because a few bytes read wrong. Fix: clean the cart properly with isopropyl, reseat, re-dump, and verify the hash against No-Intro. If the hash is right, the dump is right; if it keeps mismatching at the same size, the contacts are still dirty or a data line is intermittent.
2. Looking for a mounted drive on a Retrode3. Lifelong Retrode2 users plug in a Retrode3 and stare at a file manager that never shows a drive, because the Retrode3 is a network device, not a mass-storage device. Fix: stop looking for a drive. Confirm the USB-Ethernet interface enumerated and open the web UI in a browser. This is documented in Network and Browser Connection.
3. Underpowered USB port browning out a read. Front-panel ports on old cases, unpowered hubs, and long flaky cables all sag under the current a cartridge read draws, especially on larger SNES carts with extra chips. The read fails partway or produces garbage. Fix: use a rear motherboard port or a powered hub, and a known-good short cable. A USB current meter turns this from a guessing game into a measurement.
4. Treating the in-place Retrode2 file as a stored copy. On a Retrode2 the file on the mounted drive is a live read of the cartridge, not a saved file. People hash it, rename it, or open it repeatedly, each operation silently re-reading the cart, which is slow and exposes you to a mid-operation glitch. Fix: copy the file to local disk first, then do all hashing, renaming and verification on the local copy.
5. Losing an SRAM save to a dying battery. The save lives on battery-backed RAM, and a weak coin cell can drop the save during handling — or it is already gone before you start. Fix: dump SRAM first, before any other handling, on any cart you care about. Never dump a save mid-battery-replacement. If the battery is already dead, accept that the save is gone; the ROM is still perfectly dumpable.

Troubleshooting Table

Symptom-to-cause-to-fix, for the things that go wrong often enough to tabulate.

Advanced Tips

Once the basic loop is muscle memory, the Retrode3's networked design opens workflows the Retrode2 never could.

Batch dumping over the network. The Retrode3 can dump to a server rather than the attached PC. If you are working through a crate of cartridges, point the device at a NAS share or a small HTTP endpoint and let each dump land directly in your archive, named and hashed, without the attached-machine round trip. This is the difference between dumping a collection over a weekend and dumping it over a month. The illustrative API call below shows the shape; confirm the real endpoints against your shipped software and the DragonBox-Shop repositories.

# Illustrative: trigger a dump on a Retrode3 and stream it to a file.
# Endpoint paths are not final — confirm against your installed version.
DEVICE="http://10.55.0.1"

# Ask the device what cartridge is present
curl -s "$DEVICE/api/cart/identify" | python3 -m json.tool
# Expected: {"system":"SNES","title":"Chrono Trigger (USA)","rom_kb":4096}

# Dump ROM to a local archive path, then hash it on arrival
curl -s "$DEVICE/api/cart/dump?region=rom" -o ~/archive/chrono.sfc
sha1sum ~/archive/chrono.sfc

Keep the No-Intro reference current on-device. Because the Retrode3 can update its game databases online, schedule that refresh so your on-device identification and verification never drift from the community reference. A stale DAT is the quiet cause of false mismatches.

Read the source. The entire stack is open source under DragonBox-Shop on GitHub. When the web API documentation is incomplete — and on in-development software it will be — the route definitions in the source are the real documentation. This is the practical payoff of open hardware: you are never blocked waiting for a manual, because the manual is the code. It is also your insurance policy. An open-source, SD-bootable, Debian-based device is one you can keep alive long after any company stops caring, which is exactly the property a preservation tool should have.

Use a current meter as a diagnostic, not a gadget. Logging the read current per cartridge gives you a baseline. When a known-good title suddenly reads at double its usual current, you have a hardware problem to chase before it produces a silently bad dump, rather than after.

Pin your firmware. On a Retrode3, keep a known-good SD image and update on a copy, not the original. The maker's "practically unbrickable" claim rests entirely on this design; honor it by actually keeping the spare image. The friction-reduction trend the wider industry is riding — see the Microsoft Developer GDC 2026 writeup — makes updates frictionless, which is wonderful right up until a frictionless update ships a regression. Cheap rollback is the counterweight.

A Complete Working Configuration

Here is an end-to-end configuration that ties the whole workflow together: a directory layout, the network route for a Retrode3, a small dump-and-verify script, and the RetroArch config that makes the dumped saves load. Adapt the device address, interface name and paths to your machine.

# ── Directory layout ───────────────────────────────────────────
# ~/archive/
#   roms/snes/      verified .sfc/.smc files (No-Intro names)
#   roms/genesis/   verified .bin/.md files
#   roms/nes/       verified .nes files
#   saves/          .srm files pulled from cartridge SRAM
#   dats/           current No-Intro DAT files

# ── Retrode3 network route (run once per session) ──────────────
IFACE="enxAABBCCDDEEFF"          # your USB-Ethernet interface
DEVICE_SUBNET="10.55.0.0/24"
sudo ip route add "$DEVICE_SUBNET" dev "$IFACE" 2>/dev/null || true

# ── dump-and-verify.sh ─────────────────────────────────────────
#!/usr/bin/env bash
set -euo pipefail
DEVICE="http://10.55.0.1"
OUT="$HOME/archive/roms"
SAVES="$HOME/archive/saves"
DAT="$HOME/archive/dats/Nintendo - SNES (No-Intro).dat"

# 1. Identify the cart
meta=$(curl -s "$DEVICE/api/cart/identify")
system=$(echo "$meta" | python3 -c 'import sys,json;print(json.load(sys.stdin)["system"])')
title=$(echo  "$meta" | python3 -c 'import sys,json;print(json.load(sys.stdin)["title"])')
echo "Detected: $title ($system)"

# 2. Dump ROM and SRAM
rom="$OUT/${system,,}/${title}.sfc"
srm="$SAVES/${title}.srm"
curl -s "$DEVICE/api/cart/dump?region=rom"  -o "$rom"
curl -s "$DEVICE/api/cart/dump?region=sram" -o "$srm" || echo "no SRAM / dead battery"

# 3. Verify against No-Intro
hash=$(sha1sum "$rom" | cut -d' ' -f1)
if grep -iq "$hash" "$DAT"; then
  echo "VERIFIED: $title  ($hash)"
else
  echo "MISMATCH: investigate region/revision before trusting $rom"
fi

# ── retroarch.cfg (save-relevant excerpt) ──────────────────────
rh_savefile_directory   = "~/archive/saves"
savefile_directory      = "~/archive/saves"
savestate_directory     = "~/states"
system_directory        = "~/.config/retroarch/system"
sort_savefiles_enable   = "true"
sort_savestates_enable  = "true"
savefiles_in_content_dir = "false"
# Cores: Snes9x / bsnes (SNES), Genesis Plus GX (MD/Genesis),
#        Mesen / FCEUmm (NES). Match each .srm basename to its ROM.

That is the whole loop: clean, seat, dump, save, verify, file, play. The script is illustrative on the exact Retrode3 endpoints — they are not final as of mid-2026 — but the structure is correct and maps cleanly onto whatever the shipped software calls its routes. For a Retrode2 the same workflow drops the network route and the curl calls, replacing them with cp from the mounted drive, and everything downstream is identical.

Where the Retrode Sits in 2026

Strip away the architecture talk and the Retrode is the same honest tool it was when Hullin described it fourteen years ago: a bridge that gives you the ROM directly from the cart, without pretending to replace the emulator that runs it. That restraint is why it earned the trust of the preservation community when flashier clone-console hardware came and went. The Retrode3 does not betray that idea; it scales it. A MIPS-class Linux device with built-in Wi-Fi, SD-boot, online database updates and network dumping is the same bridge wearing a much larger backpack, and the backpack is full of preservation features — provenance, verification, archival-grade workflows — rather than gimmicks.

The honest caveat, and The Machine does not do dishonest caveats: as of the 2026 product page you cannot buy one. The hardware is done, the software is not, the team was aiming for availability by year-end, the final price is unconfirmed with a target under EUR 100, and the official site routes you to a notification signup through DragonBox rather than a buy button. Made in Germany, fully open source, practically unbrickable — all promising, all unproven at retail scale until units are actually in hands. If you need to dump cartridges today, the Retrode2 does it now and this entire tutorial applies to it minus the network layer. If you want the networked, open, preservation-first successor, the correct action in 2026 is to keep dumping with what you have and watch the official Retrode site for the day the notify button becomes an order button. Preservation is patient work. So is waiting for good hardware to ship.