Retrode2 2026: Dump a SNES Cart in 12 Steps, 20 Min

There are two honest ways to get a Super Nintendo cartridge into your emulator. You can download a ROM someone else dumped and pretend you occupy the moral high ground, or you can read the chips off the plastic brick sitting on your shelf. The Retrode2 exists for the second kind of person. It is a small USB adapter with a SNES slot on top and a Genesis slot on the bottom, and when you plug it in it does something quietly subversive: it lies to your computer, telling it that a 1994 mask-ROM is an ordinary USB thumb drive. Copy the file off, and you have dumped the cart. No soldering iron, no driver disc, no chip clip, no ceremony.

This is a tutorial for actually using one in 2026, a year in which the device is old enough to drink and its successor has been coming by the end of the year for longer than some of its buyers have owned a PS5. We will cover the full twelve-step dump, save extraction, the RETRODE.CFG file nobody reads until a dump comes out wrong, firmware flashing over DFU, and the exact cartridge that will defeat you no matter how clean your contacts are. The Machine has opinions about all of it. Budget about twenty minutes for your first cart and five for every one after.

What the Retrode2 Actually Is

Before you plug anything in, understand what you bought, because the marketing and the reality have drifted apart in an amusing way.

A cartridge that pretends to be a thumb drive

The Retrode2 is a class-compliant USB device with two cartridge slots and four controller ports. It contains an Atmel AT90USB1287 microcontroller, an 8-bit AVR with native USB, and its entire trick is impersonation. It enumerates as a USB mass-storage volume and, simultaneously, as a set of USB HID controllers. Wikipedia's entry, last touched on 8 February 2026, defines it plainly as a USB adapter that lets legacy game cartridges and controllers be used with emulators. That is the whole product in one sentence. There is no ripping software, no capture step, no proprietary app that phones home. The ROM appears as a file. You copy the file. That is the dump.

Retrode2 versus Retrode3: what ships and what is promised

Here is where you must not be misled. The official site in 2026 no longer leads with the Retrode2. Its homepage headlines the Retrode3 under the tagline "The Open-Source Retro Cartridge Reader, Reinvented," a genuinely different machine with a MIPS processor running Linux, built-in Wi-Fi, a browser-based interface, and fully open hardware and software. The site's own words: "We are aiming for availability by the end of the year; an exact date and the final price (target: under EUR 100) are still to be confirmed." Note the currency. The pricing guidance is in euros, not dollars, which matters if you are a US reader trying to model import cost. Note also the verbs: aiming, still to be confirmed. As of August 2026 you cannot order a Retrode3; you can register interest at DragonBox and wait.

The device this tutorial is about, the one you can actually buy and use today, is the Retrode2. Its own "About" page, updated 16 August 2026, still calls it "the world's most versatile (and fun!) USB adapter for vintage video games." So the correct 2026 mental model is a shipping product (Retrode2) and a perpetually pre-launch successor (Retrode3). Do not buy the tense wrong.

Who should own one, and who should not

Own a Retrode2 if you have a physical SNES or Genesis library and you want your own dumps of your own carts, save files included, without opening the shells. Do not buy one if your goal is a complete verified ROM set; someone has already dumped every cartridge ever pressed, and a torrent will not misdetect a mapper. And absolutely do not buy one expecting it to defeat copy protection. It cannot, by design, and that limitation is the punchline of an entire section below.

Prerequisites: Hardware and Software

The Retrode2's headline feature is that it needs almost nothing. Almost. The gap between almost-nothing and nothing is where first-time dumps go to die.

Hardware you need

You need the Retrode2 itself, currently sold through DragonBox, which still lists it as a cartridge dumper and USB adapter, confirming the thing is not vaporware even as its sequel hovers. You need a USB mini-B cable, and this is the single most common point of failure: it must be a genuine data cable, not a charge-only cable salvaged from a bargain bin. The Retrode is bus-powered, so a marginal cable or an underpowered port will let it half-enumerate and then read garbage. You need a host with a real USB host port. You need the cartridges you intend to dump, which you should own. And you want 99% isopropyl alcohol and a lint-free swab for the contacts, because a 30-year-old edge connector is filthy whether it looks it or not.

Software and versions

The beautiful part: on the base workflow you need no software at all, because the FAQ's compatibility line is "Anything with a USB host port that runs a modern operating system (Linux, Mac OS X, Windows, you name it)" as long as it "recognizes standard USB mass storage drives and game controllers." That is every desktop OS made this century. You will, however, want a few tools for verification and playback:

• A hashing utility. shasum or md5sum on macOS and Linux; CertUtil -hashfile on Windows. Non-negotiable if you care whether your dump is correct.
• An emulator. RetroArch with the snes9x and Genesis Plus GX cores is the pragmatic default. Any standalone emulator works; the ROM is a standard file.
• dfu-programmer (cross-platform) or Atmel FLIP (Windows) if you ever flash firmware. Both are covered later. Neither is needed for a stock dump.

That is it. There is no Retrode desktop application to install, and if a webpage tells you to download one, you are on the wrong webpage.

The cartridges themselves

Condition is a prerequisite, not a footnote. A cartridge with corroded or dust-caked contacts will produce a dump that hashes differently on every read, which is the single clearest symptom of a bad connection. Clean the edge connector with isopropyl alcohol and let it dry fully before insertion. Do not blow into the cartridge; the folklore is wrong and the moisture is real. Battery-backed carts (anything with a save) should be dumped sooner rather than later, because a dead CR2032 takes your saves with it, and the Retrode is the cheapest save-archival insurance you will ever buy.

How the Dump Works

Understanding the mechanism turns troubleshooting from guesswork into deduction. It is worth two minutes.

The mass-storage trick

The Retrode FAQ, updated in August 2026, states the mechanism directly: the device "wraps whatever memory chips there are on the cartridge into virtual files on a USB drive." The word virtual is doing heavy lifting. There is no flash storage inside the Retrode holding your ROM. When your OS reads the file, the microcontroller reads the cartridge's ROM in real time and streams it back as if it were sectors on a disk. This is why copying a large cart is not instant, and why a flaky contact corrupts the middle of a file rather than failing outright: you are reading silicon over an edge connector, live, one address at a time.

When it mounts, you see a volume named RETRODE. On macOS it lands at /Volumes/RETRODE; on Linux at /media/<user>/RETRODE or similar; on Windows it takes the next free drive letter. Insert a cart and the listing looks like this:

$ ls -la /Volumes/RETRODE
total 6208
-rwxrwxrwx  1 user  staff  3145728 Aug 20 2026  Super Metroid.sfc
-rwxrwxrwx  1 user  staff     8192 Aug 20 2026  Super Metroid.srm
-rwxrwxrwx  1 user  staff      512 Aug 20 2026  RETRODE.CFG

Three files. The .sfc is the SNES ROM as a virtual file (Sega carts appear as .bin). The .srm is the cartridge's battery-backed save RAM. RETRODE.CFG is the plain-text config that controls the device's behavior. Copy the .sfc to your disk and you have dumped Super Metroid, all 3,145,728 bytes of it.

Controllers as USB HID

The same FAQ line finishes: it "makes the gamepads appear as USB HID-class controllers." The four ports on the front (two SNES, two Genesis) are wired straight to the AVR's USB stack, so a real SNES pad plugged into the Retrode shows up to your OS as a standard game controller. No mapping software, no calibration blob. This is the feature people forget they paid for and then rediscover with delight the first time they play a dump with the original pad.

Why there are no drivers

Both faces of the device, mass storage and HID, use USB device classes every operating system has supported natively for two decades. That is the entire reason the Retrode is driverless and cross-platform: it never asks the OS to trust custom code, only to recognize a disk and a joystick. It is, in the most literal sense, boring standards-compliant hardware pretending to be two boring standards-compliant peripherals. Boring is why it still works in 2026.

The 12-Step Dump Workflow

Twelve steps, each with a reason. Skip a reason and you will meet it again in the troubleshooting table. This is the SNES path; the Genesis path is identical except the file lands as .bin and you use the bottom slot.

Steps 1 to 4: physical setup

1. Inspect and clean the cartridge. Wipe the edge connector with 99% isopropyl alcohol on a lint-free swab and let it dry. Rationale: the number-one cause of a dump that hashes differently every time is a dirty contact, and no software setting fixes a physics problem.
2. Connect the Retrode2 to your host with a data-capable USB mini-B cable. Rationale: the device is bus-powered. A charge-only cable or a weak port will let it appear and then fail mid-read, which looks like a firmware bug and is not.
3. Confirm enumeration before inserting any cart. The RETRODE volume should mount and the HID controllers should register. Rationale: if the empty device does not enumerate cleanly, nothing downstream will work, and you want to isolate cable and port problems from cartridge problems.
4. Insert the cartridge fully and squarely into the correct slot. SNES on top, Genesis on the bottom, seated firmly. Rationale: the Retrode reads on detection; a half-seated cart reads half a ROM. Seat it like you mean it.

Steps 5 to 8: reading and verifying the ROM

5. Open the RETRODE volume and read the file listing. You should see a .sfc (or .bin), possibly a .srm, and RETRODE.CFG. Rationale: the virtual filename is derived from the cartridge header, so a sane name is your first sign the header read correctly.
6. Copy the ROM file off the drive. Drag it, or use cp. Rationale: because the file is streamed live from the cart, copying is dumping; there is no separate export.
7. Verify the dump by hashing it, then dump again and compare. Rationale: a correct read is deterministic. Two identical hashes across two independent reads is your proof the contact was stable. This is the step everyone skips and then regrets.
8. If the size or content is wrong, apply a RETRODE.CFG override and re-read. Rationale: some carts misdetect mapper or size; forceSize and forceMapper exist precisely for the truncated or garbage dump. Covered in full below.

Here is what steps 6 and 7 look like in a shell, with the verification that separates a real dump from a hopeful one:

$ cp "/Volumes/RETRODE/Super Metroid.sfc" ~/roms/
$ shasum -a 1 ~/roms/"Super Metroid.sfc"
a1b2c3d4e5f6...  Super Metroid.sfc    # first read

# Re-insert, re-copy, hash again:
$ shasum -a 1 ~/roms/"Super Metroid (2).sfc"
a1b2c3d4e5f6...  Super Metroid (2).sfc # identical == clean read

The two hashes above are illustrative; the point is that they must match each other. If they diverge, you have a contact problem, not a dump. If they match a No-Intro DAT as well, you have a verified dump. That is the gold standard.

Steps 9 to 12: saves, ejecting, and booting

9. Copy the save file off the drive. Grab the .srm alongside the ROM. Rationale: that is your battery-backed progress, and the battery is older than the person reading this. Archive it now.
10. (Optional) Write a save back only after setting sramReadonly to 0. Rationale: the Retrode ships with SRAM write-protected so you cannot accidentally clobber a save; you must deliberately disable protection to restore one. Details in the saves section.
11. Safely eject the RETRODE volume before pulling the cartridge. Rationale: ejecting flushes any pending writes (critical when restoring saves) and forces a clean re-detect for the next cart. Yanking a cart mid-write is how you corrupt an .srm.
12. Load the dump into an emulator and boot it. Rationale: the only real test of a dump is a clean boot and a working in-game save. A file that hashes fine but hangs on the title screen tells you the read was incomplete in a way size alone did not reveal.

Follow those twelve and your first cart is archived, verified, and playable in roughly the time it takes to make coffee. Every subsequent cart is steps 4 through 12, and you will stop thinking about it.

Backing Up and Restoring Saves

The Retrode is a save-management tool as much as a ROM dumper, and this is the use case that actually justifies owning one when the ROMs are a search away.

Reading SRAM off the cart

Any cartridge with a battery presents its save RAM as a .srm file on the RETRODE volume. Copying it off is identical to copying the ROM: drag or cp. Do this the day you buy the Retrode, for every save you care about, because you are racing a coin-cell installed during the Clinton administration. The .srm format the Retrode produces is the same raw SRAM image most emulators expect, which is why a save pulled from a real cart usually drops straight into RetroArch's saves folder and just works.

Writing a save back

Restoring a save (from an emulator back to the physical cart, or from your archive after a battery swap) requires flipping one setting. By default sramReadonly is 1, meaning the on-cart SRAM is protected and the virtual .srm is effectively read-only. Set it to 0 in RETRODE.CFG, re-mount, then copy your .srm onto the drive:

# In RETRODE.CFG, change:
sramReadonly 0

# Then, with the cart inserted and protection off:
$ cp ~/saves/"Super Metroid.srm" /Volumes/RETRODE/
$ diskutil eject /Volumes/RETRODE     # macOS; flushes the write

The eject is not optional here. The write is streamed to the cartridge's SRAM chip, and pulling the cart before the flush completes is the fastest way to write half a save and brick your file. When you are done restoring, set sramReadonly back to 1 so you cannot fat-finger a working save later. The Machine restores with protection off and lives with it on.

The Sega 16-bit SRAM quirk

Genesis save hardware is not uniform, and some carts store SRAM in a 16-bit arrangement that the Retrode reads incorrectly unless told otherwise. The segaSram16bit key exists for exactly this. If a Genesis save comes out the wrong size, byte-swapped, or refuses to load in an emulator, toggle segaSram16bit and re-read. It is a one-line fix for a problem that otherwise looks like data corruption. Phantasy Star IV and other RPGs with real save systems are the usual place you meet it.

Cartridge-Port Controllers as USB HID

The controller ports are the Retrode's underrated half. You paid for them; use them.

Mapping the pads in RetroArch

Plug a genuine SNES or Genesis pad into the Retrode and the OS sees a standard USB game controller. In RetroArch, go to Settings, Input, Port 1 Controls and bind the buttons once; the mapping persists like any other pad. Because it is plain HID, the pad also works in browsers, standalone emulators, and anything else that reads a joystick, which makes the Retrode a surprisingly good way to use original controllers on a modern PC without a dedicated adapter. The libretro documentation covers per-core input remaps if you want a SNES pad's layout to differ between, say, snes9x and a Genesis core.

Port quirks and the SNES mouse

Not every port is equal. The SNES Mouse, of all the oddball peripherals, is supported, but it works on the left SNES port specifically. This is the kind of undocumented-until-you-need-it detail that turns a ten-minute problem into a ten-second one: if your mouse is dead, it is probably in the wrong hole. Standard directional pads work in either port of their respective system.

What the Retrode will not do

Set expectations. The controller ports handle ordinary digital pads and the SNES Mouse. They do not handle light guns (the Super Scope, the Menacer) or multitaps, both of which rely on timing and signaling the Retrode does not reproduce. If your plan hinged on dumping your Super Scope high scores, revise the plan. For six-button Genesis pads and standard three-button pads, you are fine.

RETRODE.CFG and Firmware Updates

Two maintenance topics live here: the config file that fixes misbehaving dumps, and the firmware flash you will do roughly once.

RETRODE.CFG: location and syntax

RETRODE.CFG sits in the root of the RETRODE volume and is plain text: one key value per line. Edit it in place with any text editor, save, and eject; the device reads it on next detection. The single most useful behavior to memorize: deleting a line restores that parameter to its factory default. So when you have made a mess of overrides and a cart that used to work now will not, do not try to remember the defaults. Delete the offending lines. A representative file looks like this:

# RETRODE.CFG (excerpt)
detectionDelay 3        # raise if reads begin before the cart settles
filenameChksum 0        # 1 appends a checksum to the virtual filename
sramReadonly 1          # 1 protects on-cart SRAM; 0 allows writes
segaSram16bit 0         # toggle if Genesis saves read wrong
snesRomExt SFC          # extension for the SNES virtual ROM file
segaRomExt BIN          # extension for the Sega virtual ROM file

Detection overrides: forceSystem, forceSize, forceMapper

Autodetection is right the vast majority of the time and wrong in exactly the cases that matter: unusual mappers, odd ROM sizes, region-quirky boards. Three override keys handle it. forceSystem pins the console when the slot autodetect is ambiguous. forceSize pins the ROM size when a cart reads truncated or padded. forceMapper pins the memory map when a LoROM/HiROM guess goes wrong and the dump boots to garbage. The precise accepted values for these are firmware-defined, so consult the current documentation rather than trusting a value you saw in a forum post from 2013; the safe move is to leave all three commented out and add exactly one at a time when a specific cart misbehaves, re-reading and re-hashing after each change. Change one variable, observe one result. That is debugging, not flailing.

Firmware updates over DFU

You will rarely need to flash, but when a new cart family or a bug fix lands, the AT90USB1287's Atmel DFU bootloader makes it painless. Enter DFU mode with the button dance: hold HWB, tap RESET, then release HWB. The device now presents as a DFU target instead of a mass-storage drive. Flash with the cross-platform dfu-programmer (Windows users can use Atmel FLIP instead):

dfu-programmer at90usb1287 erase
dfu-programmer at90usb1287 flash retrode-0.18d.hex
dfu-programmer at90usb1287 reset

The erase first is not decoration; flashing over a non-erased chip is how you produce a device that enumerates as neither a drive nor a DFU target and sends you to a forum at midnight. Use the current firmware .hex for your board (the 0.18 line has been the long-lived one), verify the file before you flash, and do not interrupt the write. After reset, the Retrode re-enumerates as a normal mass-storage device and your carts read again.

Loading Dumps into RetroArch

A verified dump is a file. Playing it is the easy part, but the details separate a tidy library from a folder called roms_final_FINAL.

The right cores

In RetroArch, load a SNES .sfc with snes9x (accurate and light) or bsnes if you want cycle-accuracy and have the CPU for it; load a Genesis .bin with Genesis Plus GX. From the command line it is a one-liner:

retroarch -L cores/snes9x_libretro.so ~/roms/"Super Metroid.sfc"
retroarch -L cores/genesis_plus_gx_libretro.so ~/roms/"Sonic The Hedgehog 2.bin"

Your Retrode-pulled .srm drops into RetroArch's saves directory under the matching ROM name, and your real-cartridge progress continues on the emulator. That round trip, cart to emulator to cart, is the entire point of owning the thing.

Organizing and naming your dumps

The virtual filenames the Retrode generates are derived from cartridge headers and are frequently ugly or truncated. Rename after copying, not before, and adopt a scheme (No-Intro naming is the sane default) so your dumps deduplicate cleanly against a DAT later. Keep the .sfc/.bin and its .srm together. Future-you, building a library on new hardware, will thank present-you for the discipline.

Where to actually play them

The dumps are portable, so the more interesting question is what plays them. On a desktop, a RetroPie build on an old PC turns a spare tower into a couch console. For handhelds, a Miyoo Mini Plus eats SNES and Genesis without breaking a sweat, and a Retroid Pocket gives you the same libraries with headroom to spare. If you want your dumps played on hardware that behaves like the original silicon rather than software approximating it, a MiSTer FPGA with a SNAC adapter is the accuracy end of the spectrum, and it pairs naturally with a Retrode workflow because both camps care about the same thing: the actual bytes on the actual cart.

Five Pitfalls That Ruin a Dump

Every one of these has cost someone an evening. Read them before you meet them.

Cables and contacts

Pitfall 1: the charge-only cable. The Retrode is bus-powered and the failure mode is insidious: it enumerates, mounts, and then reads corrupt data because the port cannot sustain it. Fix: use a known-good data cable and a rear motherboard USB port, not a front-panel header or an unpowered hub. Pitfall 2: dirty contacts. Symptom is a file that hashes differently on every read. Fix: 99% isopropyl alcohol, lint-free swab, full dry time, reseat firmly. No config value substitutes for a clean connection.

Misdetection and the SA-1 wall

Pitfall 3: mapper or size misdetection. The dump is the wrong length or boots to a garbled screen. Fix: add exactly one of forceSize or forceMapper to RETRODE.CFG, re-read, re-hash; delete the line if it does not help. Pitfall 4: the SA-1 cartridge. This is the big one. Carts built around the SA-1 coprocessor, Super Mario RPG, Kirby Super Star, and friends, include an anti-piracy behavior a stock Retrode2 cannot satisfy, so they read as garbage or refuse outright. Fix: there is no config fix; you need a dedicated SA-1-aware dumper. The irony is exact: the Retrode is thwarted by copy protection precisely because it makes no attempt to circumvent it. SuperFX carts like Star Fox usually read fine, so do not overgeneralize the failure.

Saves and ejecting

Pitfall 5: writing a save and yanking the cart. Because SRAM writes are streamed live, removing the cartridge or the cable before the eject completes writes a partial save and corrupts the file you were trying to restore. Fix: always eject the RETRODE volume and wait for the OS to confirm before pulling anything, and set sramReadonly back to 1 when you finish restoring so a stray drag cannot overwrite a good save.

Troubleshooting Table

Symptom on the left, cause and fix on the right. This table is the section people actually bookmark.

The table

Reading a bad dump

The diagnostic hierarchy is: does the empty device enumerate, does the cart read at all, and does it read the same twice. If the empty Retrode will not mount, it is cable or port, full stop. If it mounts but the cart reads garbage, it is contacts, then detection overrides, in that order. If it reads but two hashes diverge, it is contacts again, always. Only after clean contacts and stable hashes should you suspect the cartridge itself, and even then the answer is usually SA-1, not a mystery.

When to stop fighting a cartridge

There is a point of diminishing returns. If a cart is SA-1, stop; the Retrode2 will never read it and no amount of RETRODE.CFG tuning changes that. If a cart's contacts are physically corroded past cleaning, a dedicated dumper with a firmer connector may succeed where the Retrode's slot cannot. Knowing the two lost causes, SA-1 and dead contacts, saves you the hour you would otherwise spend re-seating a cartridge that was never going to cooperate.

Advanced Tips and the Retrode3

Once the basics are muscle memory, these are the moves that separate an archive from a pile of files.

Batch verification against No-Intro DATs

The single highest-value habit is verifying dumps against a No-Intro DAT with a tool like clrmamepro or an equivalent. Two matching self-reads prove your read was stable; a DAT match proves your dump equals the canonical known-good dump of that exact cartridge revision. That is the difference between "probably fine" and "provably correct," and it costs you one batch job. Keep your naming No-Intro-compatible so the matcher does the work for you.

Adapters beyond SNES and Genesis

The two built-in slots cover SNES/Super Famicom and Genesis/Mega Drive, but the cartridge slot has hosted adapters over the years for Nintendo 64, Game Boy and Game Boy Advance, and Master System and Game Gear, and the FAQ still references a Sega 32X adapter working. Availability of any given plug-in varies and has always been the Retrode ecosystem's soft spot, so check DragonBox for what is actually in stock rather than assuming a decade-old adapter is a click away. The corresponding n64RomExt, gbRomExt, gbaRomExt, smsRomExt, and ggRomExt keys in RETRODE.CFG exist to name those virtual files when the adapters are present.

The Retrode3, and the FPGA alternative

Two futures are worth watching. The first is the Retrode3, the open-hardware, Linux-running, Wi-Fi-equipped successor the official site is teasing at "under EUR 100" and "availability by the end of the year," both still unconfirmed as of August 2026. If it ships as described, it stops being a mass-storage impersonation and becomes an actual networked computer with a cartridge slot, which changes the workflow entirely; until it ships, it changes nothing. The second is the accuracy camp: for playback that behaves like the original console rather than software approximating it, FPGA platforms and boutique consoles occupy the other end of the spectrum from the Retrode's pragmatic "just give me the bytes" philosophy. If you have gone deep enough to be reading DAT files, you will eventually want both a dumper and something like an FPGA console living off firmware updates on the shelf next to it. The Retrode gets your carts into files; where those files go is a rabbit hole with no bottom.

The Complete Working Configuration

Here is a full RETRODE.CFG you can paste over the one on your drive as a sane, well-commented baseline. Every line is set to a safe default; the override lines are commented so autodetection stays in charge until a specific cart forces your hand.

The file

# RETRODE.CFG  --  Retrode2 baseline configuration
# Rule: delete any line to restore that parameter's factory default.

# --- Behavior ---
detectionDelay 3          # raise if reads start before the cart settles
filenameChksum 0          # 1 = append a checksum to the virtual filename

# --- Saves (SRAM) ---
sramReadonly 1            # 1 = protect on-cart SRAM; set 0 only to restore a save
segaSram16bit 0           # toggle if Genesis saves read wrong size/byte order
sramExt SRM               # extension for the virtual save file

# --- Virtual ROM file extensions ---
snesRomExt SFC
segaRomExt BIN
n64RomExt N64
gbRomExt GB
gbaRomExt GBA
smsRomExt SMS
ggRomExt GG

# --- Autodetect overrides (leave commented unless a cart misdetects) ---
# Accepted values are firmware-defined; consult current docs before use.
# forceSystem SNES
# forceSize 24
# forceMapper LoROM

Deploying it

Copy this over RETRODE.CFG in the root of the RETRODE volume, save, and eject so the device re-reads it on next detection. Start with every override line commented; add exactly one, re-read, re-hash, and either keep it or delete it, one cart and one variable at a time. That single discipline, change one thing and verify, is the whole craft. The Retrode2 is not a clever device, and that is its virtue: it does one honest job, it does it over standards every OS already speaks, and when it fails it fails for reasons you can name. Dump your carts, hash them twice, keep your saves, and let the Retrode3 arrive whenever it arrives.