Vous changez de console. Vous copiez vos jeux sur la nouvelle carte microSD, vous lancez le titre en cours, et l'écran vous propose « Nouvelle partie ». Quarante heures ont disparu, alors que le fichier est toujours là, quelque part sur l'ancienne carte. Neuf fois sur dix, rien n'est perdu : la sauvegarde existe, elle n'est simplement pas au bon endroit, pas au bon nom, ou pas dans le format qu'attend la nouvelle machine. Le transfert n'a rien de compliqué, à condition de savoir lequel des trois types de sauvegarde on manipule, parce qu'ils ne voyagent pas du tout de la même façon.
Trois sauvegardes, trois destins différents
Sur une console rétro portable, un même jeu peut produire trois fichiers de nature très différente. On les confond souvent, et c'est là que les parties se perdent.
La sauvegarde native du jeu
C'est celle que le jeu écrit lui-même quand vous passez devant un point de sauvegarde ou que vous choisissez « Save » dans son menu. L'émulateur reproduit la mémoire sauvegardée de la cartouche, ou la carte mémoire de la console d'origine, et la range dans un fichier à part.
Dans l'écosystème RetroArch, ce fichier porte le plus souvent l'extension .srm. La documentation du core mGBA le décrit ainsi : *.srm, « cartridge battery save », déposé dans le dossier de sauvegarde défini par l'interface. Il ne contient que des données produites par le jeu et ne dépend ni du processeur de la console, ni de la version de l'émulateur. C'est celui qui voyage.
La sauvegarde d'état
La sauvegarde d'état, ou save state, est une photographie de la mémoire vive de l'émulateur à un instant donné : registres du processeur, contenu de la RAM, état du son et de l'image. RetroArch la range dans un dossier séparé, sous la forme *.state suivi d'un numéro d'emplacement.
Cette photo n'a de sens que pour le programme qui l'a prise. Un autre émulateur n'organise pas sa mémoire de la même façon, et une version différente du même core suffit parfois à la rendre illisible. Pratique pour interrompre une partie trente secondes, inutilisable comme format d'archivage.
L'état de reprise du firmware
Beaucoup de firmwares reprennent automatiquement là où vous vous étiez arrêté. La documentation de KNULLI décrit la fonction sans détour : à l'extinction, le système peut enregistrer votre progression « si l'émulateur en cours gère la sauvegarde automatique », puis relancer le dernier jeu au démarrage. Elle précise aussi que tous les émulateurs ne gèrent pas cette sauvegarde automatique, et que les portages ne sauvegardent rien tout seuls.
Cette reprise s'appuie le plus souvent sur une sauvegarde d'état et hérite des mêmes limites : locale, liée à l'émulateur, effacée sans prévenir par une mise à jour. Confortable au quotidien, inutile pour un transfert.
| Type | À quoi ça ressemble | Se transfère ? | Ce qui la casse |
|---|---|---|---|
| Sauvegarde native du jeu | Un fichier par jeu, souvent .srm ou .sav
|
Oui, d'une machine à l'autre | Un nom de fichier qui ne correspond plus à la ROM |
| Sauvegarde d'état |
.state, .state1, .state2… |
Presque jamais | Un autre core, une autre version du core |
| Reprise automatique du firmware | Invisible, gérée par le système | Non | Une mise à jour, un changement de firmware |
Où ces fichiers se trouvent réellement
Il n'existe pas un emplacement unique, mais trois logiques.
Le dossier de sauvegarde centralisé. La plupart des firmwares alternatifs regroupent les sauvegardes dans une arborescence dédiée, découpée par système. C'est le cas le plus confortable : un seul dossier à copier.
À côté des jeux. C'est le comportement par défaut de RetroArch, que sa documentation résume ainsi : sans réglage particulier, il place les sauvegardes dans le même dossier que vos ROM. Vous retrouvez alors Super Metroid (Europe).sfc et Super Metroid (Europe).srm côte à côte.
Dans l'espace propre à chaque application. Sur Android, chaque émulateur autonome gère son propre rangement. PPSSPP, par exemple, recrée l'arborescence d'un Memory Stick et place les parties dans PSP/SAVEDATA, un dossier par jeu.
Nous ne refaisons pas ici la carte des chemins firmware par firmware : elle est détaillée dans notre article sur l'arborescence des fichiers selon le firmware. En cas de doute, une méthode marche partout : lancez le jeu, sauvegardez dedans, quittez, puis triez la carte microSD par date de modification sur l'ordinateur. Le fichier écrit à l'instant est en haut de la liste.
D'une console Linux à une autre
C'est le cas le plus simple, parce que les deux machines partagent en général le même moteur d'émulation.
- Sur l'ancienne console, sauvegardez dans le jeu, pas seulement en sauvegarde d'état.
- Quittez le jeu par le menu, puis éteignez proprement. Une coupure brutale d'alimentation peut intervenir avant que le fichier ait été écrit sur la carte.
- Sortez la carte, mettez-la sur un ordinateur et copiez le dossier de sauvegarde entier.
- Sur la nouvelle carte, déposez les fichiers dans le dossier équivalent.
- Vérifiez que chaque sauvegarde porte exactement le nom du fichier de jeu correspondant, extension mise à part.
- Lancez un seul jeu et chargez la partie avant de conclure que c'est bon.
Si les deux consoles n'ont pas le même firmware, l'emplacement change mais le fichier reste identique : c'est le chemin qu'on adapte, pas le contenu.
De Linux vers Android, et l'inverse
Tout dépend de ce que vous utilisez pour jouer. Avec RetroArch, les conventions sont celles des consoles Linux : un .srm venu d'une RG35XX Pro est lisible tel quel sur une Retroid Pocket, à condition d'employer le même core et le même nom de fichier. Nos réglages RetroArch essentiels indiquent où se définissent ces dossiers.
Avec un émulateur autonome, il faut un intermédiaire. Ces programmes rangent leurs données à leur façon et proposent souvent un outil d'import : DuckStation annonce ainsi un éditeur de carte mémoire et un importateur de sauvegardes. C'est par là qu'il faut passer, plutôt que de déposer un fichier dans un dossier deviné.
Deux points ralentissent le transfert côté Android : l'autorisation d'accès au stockage doit être accordée à l'émulateur, et certains dossiers d'application restent invisibles depuis un ordinateur en USB. Il faut alors passer par un gestionnaire de fichiers installé sur la console.
Depuis un émulateur sur PC
Le principe ne change pas. Un émulateur PC produit lui aussi une sauvegarde native, et c'est elle qu'on emporte. Avec RetroArch sur ordinateur, le fichier part vers la console portable sans rien modifier. Avec un émulateur autonome, repérez d'abord le format qu'il écrit, puis celui qu'attend la console. L'aller-retour fonctionne dans les deux sens, et l'ordinateur reste de toute façon le meilleur endroit pour archiver vos parties.
Quand un renommage suffit, quand il faut convertir
Beaucoup de sauvegardes natives sont des vidages bruts de mémoire : le contenu est identique, seule l'étiquette change, et renommer suffit. La documentation du core Beetle PSX est explicite : ses formats de carte mémoire libretro (.srm) et Mednafen (.mcr) sont identiques en interne et se convertissent par un simple renommage.
Ailleurs, deux émulateurs du même système écrivent des fichiers qui ne se ressemblent pas. Sur Nintendo DS, le core DeSmuME enregistre la sauvegarde de cartouche en *.dsv quand melonDS écrit un *.sav. Changer l'extension à la main devient un pari : testez sur une copie, jamais sur votre seul exemplaire.
| Source | Ce qu'elle écrit | Pour la déplacer |
|---|---|---|
| Core mGBA (Game Boy, GBA) |
*.srm dans le dossier de sauvegarde |
Copier tel quel vers un autre appareil RetroArch |
| Core Beetle PSX (PS1) |
*.srm ou *.mcr selon le réglage |
Renommage documenté entre les deux formats |
| Core DeSmuME (DS) | *.dsv |
Conversion nécessaire vers un core qui attend un .sav
|
| Core melonDS (DS) | *.sav |
Copie directe entre machines utilisant melonDS |
| PPSSPP (PSP) | Un dossier par jeu dans PSP/SAVEDATA
|
Copier le dossier entier, pas un fichier isolé |
| Sauvegardes d'état, tous systèmes |
*.state et variantes numérotées |
À ne pas transférer, à reconvertir en sauvegarde de jeu |
Les pièges qui font échouer un transfert
Le nom du fichier. Première cause, et de loin : la sauvegarde est retrouvée par correspondance de nom avec le fichier de jeu. Si votre ROM s'appelle Chrono Trigger (USA).sfc d'un côté et chrono_trigger.sfc de l'autre, la partie ne sera jamais chargée, même au bon endroit. Renommer une ROM après coup produit le même effet.
Le core. Une sauvegarde d'état créée avec un core refusera de se charger avec un autre, parfois même avec une autre version du même core. Côté sauvegardes natives, l'ennui est plus rare mais réel : deux cores d'un même système n'écrivent pas toujours la même chose.
La taille du fichier. Une sauvegarde correcte a une taille fixe, imposée par le type de mémoire du jeu d'origine. Une taille inattendue annonce presque toujours un refus. Dernier détail : certains jeux Game Boy Color et Game Boy Advance embarquent une horloge temps réel mêlée aux données de partie, et les cycles jour-nuit peuvent se comporter bizarrement après un déménagement.
Si le jeu démarre mais ignore la partie importée, notre guide des quatorze causes d'un jeu qui ne se lance pas couvre les cas voisins, du dossier mal choisi à l'archive mal formée.
La routine à adopter, et à quelle fréquence
Une sauvegarde de partie tient dans quelques kilo-octets : copiez le dossier entier, pas un fichier choisi au cas par cas.
- Après chaque grosse session sur un jeu long, celui dont la perte vous ennuierait vraiment.
- Avant toute mise à jour de firmware, avant tout changement de firmware, et avant tout formatage de carte.
- Une fois par mois si vous jouez régulièrement, même sans événement particulier.
Rangez chaque copie dans un dossier daté, sur un support qui n'est pas la console. Deux copies sur deux supports différents couvrent l'essentiel des accidents. Certains firmwares aident : le module de sauvegarde de muOS annonce enregistrer l'ensemble des sauvegardes et des sauvegardes d'état de RetroArch et des autres émulateurs pris en charge.
La carte microSD reste le maillon fragile de la chaîne, et c'est elle qui lâche en premier. C'est aussi pour cette raison que toutes les cartes que nous expédions passent une vérification par écriture-relecture complète avant de partir. Notre article sur la gestion des sauvegardes au quotidien détaille l'organisation à mettre en place.
Les parties venues d'une vraie cartouche
Le cas revient souvent : une cartouche Game Boy Advance dans un tiroir, cent quarante heures dessus, et une pile de 1999 pour seule protection. Un lecteur de cartouches extrait ces données de partie sous forme de fichier, indépendamment du jeu lui-même. Notre guide complet de la copie de cartouches décrit l'opération et l'ordre à respecter avant un changement de pile.
Une fois le fichier obtenu, il rejoint le circuit décrit plus haut : bon dossier, bon nom, test sur une copie. Le sens inverse fonctionne aussi, une partie avancée sur console portable pouvant repartir dans la cartouche.
Questions fréquentes
Peut-on convertir une sauvegarde d'état en sauvegarde normale ?
Pas par un outil, mais par le jeu lui-même. Sur la machine d'origine, chargez la sauvegarde d'état, rejoignez un point de sauvegarde et sauvegardez normalement. Vous obtenez un fichier de sauvegarde native, celui qui se transporte. C'est le réflexe à prendre avant tout changement de console ou de firmware.
Ma sauvegarde a disparu après avoir renommé ma ROM. Est-elle perdue ?
Non, elle est devenue orpheline. Le fichier est toujours là, sous l'ancien nom. Renommez-le pour qu'il corresponde au nouveau nom du jeu, extension mise à part, et la partie réapparaîtra. Si vous avez renommé beaucoup de fichiers, procédez jeu par jeu plutôt qu'en lot.
Puis-je transférer mes sauvegardes entre deux firmwares sur la même console ?
Oui pour les sauvegardes natives : le fichier ne change pas, seul son emplacement diffère. Copiez le dossier de sauvegarde sur un ordinateur avant l'installation, puis replacez les fichiers dans la nouvelle arborescence. Les sauvegardes d'état ne survivent en général pas à l'opération.
Les cartes mémoire PlayStation 1 se transfèrent-elles aussi ?
Oui, avec la même logique. Le core Beetle PSX écrit une carte mémoire virtuelle sous forme de fichier, au format libretro ou Mednafen selon son réglage, et sa documentation indique que les deux se convertissent par renommage. Vers un émulateur autonome, préférez son importateur de sauvegardes.
Faut-il transférer les sauvegardes avant ou après les jeux ?
Les jeux d'abord, les sauvegardes ensuite. Vous connaissez ainsi le nom exact que portent les fichiers sur la machine d'arrivée et vous pouvez y aligner les sauvegardes. L'ordre inverse oblige souvent à tout renommer une deuxième fois.
Mon jeu démarre mais ne voit pas la partie importée. Que vérifier ?
Dans l'ordre : le nom du fichier, qui doit correspondre exactement à celui du jeu ; le dossier réellement utilisé par l'émulateur ; le core employé, qui doit être celui d'origine ; enfin la taille du fichier. Testez toujours en gardant l'original intact ailleurs.
Un dernier réflexe, quel que soit le matériel : avant de vider une carte microSD, copiez son dossier de sauvegarde en entier sur un ordinateur, même si vous êtes certain de n'avoir rien d'important dessus. Cette copie de dix secondes sépare un changement de console d'une partie perdue. Si vous préparez justement une nouvelle machine, notre rayon consoles portables regroupe les modèles Linux, Android et Windows.