You're switching consoles. You copy your games to the new microSD card, launch the game you're in the middle of, and the screen offers you “New Game”. Forty hours gone, even though the file is still there, somewhere on the old card. Nine times out of ten, nothing is lost: the save exists, it just isn't in the right place, under the right name, or in the format the new machine expects. The transfer is nothing complicated, as long as you know which of the three types of save you're dealing with, because they don't travel the same way at all.
Three saves, three different fates
On a retro handheld console, a single game can produce three files of very different kinds. People often mix them up, and that's where progress gets lost.
The game's native save
This is the one the game writes itself when you reach a save point or choose “Save” in its menu. The emulator reproduces the cartridge's save memory, or the original console's memory card, and stores it in a separate file.
In the RetroArch ecosystem, this file most often has the .srm extension. The mGBA core documentation describes it like this: *.srm, “cartridge battery save”, placed in the save folder set by the frontend. It contains only data produced by the game and depends neither on the console's processor nor on the emulator version. This is the one that travels.
The save state
A save state, or simply a state, is a snapshot of the emulator's working memory at a given moment: processor registers, RAM contents, sound and video state. RetroArch stores it in a separate folder, as *.state followed by a slot number.
That snapshot only makes sense to the program that took it. Another emulator doesn't organise its memory the same way, and a different version of the same core is sometimes enough to make it unreadable. Handy for pausing a game for thirty seconds, useless as an archive format.
The firmware's resume state
Many firmwares automatically pick up where you left off. The KNULLI documentation describes the feature plainly: on shutdown, the system can save your progress “if the running emulator supports auto save”, then relaunch the last game at startup. It also points out that not all emulators support this auto save, and that ports save nothing on their own.
This resume feature usually relies on a save state and inherits the same limits: local, tied to the emulator, wiped without warning by an update. Comfortable day to day, useless for a transfer.
| Type | What it looks like | Transferable? | What breaks it |
|---|---|---|---|
| Game's native save | One file per game, often .srm or .sav
|
Yes, from one machine to another | A file name that no longer matches the ROM |
| Save state |
.state, .state1, .state2… |
Almost never | A different core, a different core version |
| Firmware auto-resume | Invisible, handled by the system | No | An update, a firmware change |
Where these files actually live
There isn't one single location, but three approaches.
The central save folder. Most custom firmwares group saves in a dedicated folder tree, split by system. It's the most convenient case: a single folder to copy.
Next to the games. This is RetroArch's default behaviour, which its documentation sums up like this: without any specific setting, it puts saves in the same folder as your ROMs. You then find Super Metroid (Europe).sfc and Super Metroid (Europe).srm side by side.
In each app's own space. On Android, every standalone emulator handles its own storage. PPSSPP, for example, recreates a Memory Stick folder tree and puts saves in PSP/SAVEDATA, one folder per game.
We won't redo the firmware-by-firmware path map here: it's covered in detail in our article on the file structure for each firmware. When in doubt, one method works everywhere: launch the game, save in it, quit, then sort the microSD card by modification date on your computer. The file that was just written is at the top of the list.
From one Linux console to another
This is the simplest case, because both machines usually share the same emulation engine.
- On the old console, save in the game, not just with a save state.
- Exit the game through the menu, then shut down properly. A sudden power cut can happen before the file has been written to the card.
- Take out the card, put it in a computer and copy the entire save folder.
- On the new card, place the files in the equivalent folder.
- Check that each save has exactly the same name as the matching game file, apart from the extension.
- Launch a single game and load the save before deciding it's all good.
If the two consoles don't run the same firmware, the location changes but the file stays identical: you adapt the path, not the content.
From Linux to Android, and back
It all depends on what you use to play. With RetroArch, the conventions are the same as on Linux consoles: a .srm from an RG35XX Pro can be read as is on a Retroid Pocket, as long as you use the same core and the same file name. Our essential RetroArch settings show where these folders are set.
With a standalone emulator, you need a go-between. These programs store their data their own way and often offer an import tool: DuckStation, for instance, advertises a memory card editor and a save importer. That's the route to take, rather than dropping a file into a folder you've guessed.
Two things slow the transfer down on Android: the emulator must be granted storage access, and some app folders stay invisible from a computer over USB. You then have to use a file manager installed on the console.
From an emulator on PC
The principle doesn't change. A PC emulator also produces a native save, and that's what you take with you. With RetroArch on a computer, the file goes to the handheld console without any changes. With a standalone emulator, first identify the format it writes, then the one the console expects. It works both ways, and the computer remains the best place to archive your saves anyway.
When renaming is enough, when you need to convert
Many native saves are raw memory dumps: the content is identical, only the label changes, and renaming is enough. The Beetle PSX core documentation is explicit: its libretro (.srm) and Mednafen (.mcr) memory card formats are identical internally and can be converted by simply renaming them.
Elsewhere, two emulators for the same system write files that look nothing alike. On Nintendo DS, the DeSmuME core stores the cartridge save as *.dsv, while melonDS writes a *.sav. Changing the extension by hand becomes a gamble: try it on a copy, never on your only one.
| Source | What it writes | To move it |
|---|---|---|
| mGBA core (Game Boy, GBA) |
*.srm in the save folder |
Copy as is to another RetroArch device |
| Beetle PSX core (PS1) |
*.srm or *.mcr depending on the setting |
Documented renaming between the two formats |
| DeSmuME core (DS) | *.dsv |
Conversion needed for a core that expects a .sav
|
| melonDS core (DS) | *.sav |
Direct copy between machines running melonDS |
| PPSSPP (PSP) | One folder per game in PSP/SAVEDATA
|
Copy the whole folder, not a single file |
| Save states, all systems |
*.state and numbered variants |
Don't transfer them; turn them back into an in-game save |
The traps that make a transfer fail
The file name. The number one cause, by far: the save is found by matching its name to the game file. If your ROM is called Chrono Trigger (USA).sfc on one side and chrono_trigger.sfc on the other, the save will never load, even in the right place. Renaming a ROM afterwards has the same effect.
The core. A save state created with one core will refuse to load with another, sometimes even with a different version of the same core. With native saves, the problem is rarer but real: two cores for the same system don't always write the same thing.
The file size. A correct save has a fixed size, dictated by the original game's memory type. An unexpected size almost always means it will be rejected. One last detail: some Game Boy Color and Game Boy Advance games include a real-time clock mixed in with the save data, and day-night cycles can behave strangely after a move.
If the game starts but ignores the imported save, our guide to the fourteen reasons a game won't launch covers related cases, from the wrong folder to a badly built archive.
The routine to adopt, and how often
A game save takes up a few kilobytes: copy the entire folder, not files picked one by one.
- After every long session on a long game, the one you'd really hate to lose.
- Before any firmware update, before any firmware change, and before formatting any card.
- Once a month if you play regularly, even when nothing special has happened.
Store each copy in a dated folder, on a device other than the console. Two copies on two different devices cover most accidents. Some firmwares help: the muOS backup module says it saves all RetroArch saves and save states, as well as those of the other supported emulators.
The microSD card remains the weak link in the chain, and it's the first thing to fail. That's also why every card we ship goes through a full write-and-read-back check before it leaves. Our article on managing saves day to day explains how to set things up.
Saves from a real cartridge
It comes up often: a Game Boy Advance cartridge in a drawer, a hundred and forty hours on it, and a battery from 1999 as its only protection. A cartridge reader extracts that save data as a file, separately from the game itself. Our complete guide to copying cartridges describes the process and the order to follow before replacing a battery.
Once you have the file, it joins the process described above: right folder, right name, trial on a copy. It also works the other way round: a save progressed on a handheld console can go back into the cartridge.
Frequently asked questions
Can you convert a save state into a normal save?
Not with a tool, but through the game itself. On the original machine, load the save state, reach a save point and save normally. You get a native save file, the one that travels. It's the habit to get into before any console or firmware change.
My save disappeared after I renamed my ROM. Is it lost?
No, it's been orphaned. The file is still there, under the old name. Rename it to match the game's new name, apart from the extension, and the save will reappear. If you renamed a lot of files, go game by game rather than in bulk.
Can I transfer my saves between two firmwares on the same console?
Yes for native saves: the file doesn't change, only its location differs. Copy the save folder to a computer before installing, then put the files back into the new folder structure. Save states generally don't survive the process.
Can PlayStation 1 memory cards be transferred too?
Yes, with the same logic. The Beetle PSX core writes a virtual memory card as a file, in libretro or Mednafen format depending on its setting, and its documentation states that the two can be converted by renaming. For a standalone emulator, use its save importer instead.
Should you transfer saves before or after the games?
Games first, saves second. That way you know the exact names the files have on the destination machine and you can match the saves to them. The reverse order often means renaming everything a second time.
My game starts but doesn't see the imported save. What should I check?
In this order: the file name, which must exactly match the game's; the folder the emulator actually uses; the core, which must be the original one; and finally the file size. Always try it while keeping the original safe somewhere else.
One last habit, whatever your hardware: before wiping a microSD card, copy its entire save folder to a computer, even if you're sure there's nothing important on it. That ten-second copy is the difference between a console upgrade and a lost save. If you're getting a new machine ready, our handheld consoles section brings together Linux, Android and Windows models.