Une ROM DS qui ne démarre pas sur émulateur peut renvoyer des messages d’erreur très différents selon le problème réel : fichier non reconnu, écran noir au lancement, crash immédiat, ou simple absence de réaction.
L’émulateur Nintendo DS le plus utilisé aujourd’hui est melonDS, mais DeSmuME reste très présent dans les configurations existantes. Les causes d’échec de lancement se répartissent en plusieurs catégories distinctes, et elles ne se traitent pas de la même façon.
Format de fichier ROM DS : .nds, .zip et les pièges courants
Un fichier ROM DS standard porte l’extension .nds. Certains émulateurs acceptent les archives compressées (.zip, .7z), d’autres non. melonDS, par exemple, nécessite un fichier .nds non compressé dans la plupart des configurations de base. Charger une archive sans que l’émulateur supporte ce format produit un échec silencieux ou un message générique.
Le nom du fichier ne dit rien de son intégrité réelle. Une ROM peut être mal nommée, incomplète, ou avoir été modifiée sans que l’extension .nds ne change. Les bases de préservation comme No-Intro identifient les dumps par leur empreinte (somme de contrôle), pas par leur nom – c’est la seule façon fiable de savoir si un fichier correspond à un dump de référence reconnu.
Les ROMs dites « trimées » – dont les données inutilisées ont été retirées pour réduire la taille – peuvent avoir une empreinte différente d’un dump complet. Un émulateur configuré pour vérifier l’intégrité peut alors refuser ce fichier, même s’il est fonctionnel sur d’autres logiciels.
BIOS et firmware DS : ce qui bloque réellement le lancement
C’est souvent là que le problème se situe, et c’est la cause la moins visible. melonDS propose deux modes de démarrage : le Direct Boot, qui charge le jeu sans passer par le firmware, et le démarrage par firmware, qui simule l’allumage réel de la console.
Le démarrage par firmware exige des fichiers spécifiques : le BIOS ARM7, le BIOS ARM9 et le firmware DS. Ces fichiers doivent être extraits d’une vraie console Nintendo DS – ils ne peuvent pas être générés. Certains firmwares extraits d’une DSi ou d’une 3DS ne contiennent pas le code de démarrage nécessaire pour émuler une DS standard. Un firmware DSi n’est pas interchangeable avec un firmware DS dans ce contexte, même si les fichiers semblent similaires.
Si ces fichiers sont absents ou incorrects, le lancement par firmware échoue. Le Direct Boot contourne ce problème pour la majorité des jeux DS standard, mais il ne reproduit pas le comportement exact de la console réelle et peut créer des incompatibilités sur certains titres.
Compatibilité DSi et cas particuliers d’émulation
Tous les fichiers .nds ne sont pas des jeux DS standard. Certains titres ont été conçus pour le mode DSi, qui dispose de capacités matérielles supplémentaires. L’émulation de ce mode est distincte et reste signalée comme en développement dans la documentation de melonDS.
Une ROM conçue pour le mode DSi peut échouer à se lancer dans une configuration standard, non parce que le fichier est corrompu, mais parce que l’émulateur n’est pas configuré pour émuler ce mode spécifique. Le message d’erreur affiché ne fait pas toujours cette distinction clairement.
DeSmuME, de son côté, ne supporte pas le mode DSi. Sur ce logiciel, un jeu DSi-enhanced qui requiert ces fonctionnalités ne se lancera pas correctement, indépendamment de la qualité du fichier ou de la configuration générale.
Dépannage par émulateur : melonDS et DeSmuME
Les causes et les solutions diffèrent selon l’émulateur utilisé. Voici les vérifications à effectuer dans l’ordre logique :
- melonDS : vérifier d’abord si le Direct Boot est activé dans les paramètres. S’il ne l’est pas et que les fichiers BIOS/firmware sont absents ou issus d’une DSi, le lancement échouera systématiquement. Activer le Direct Boot permet de contourner l’exigence de firmware pour tester si la ROM elle-même est valide.
- DeSmuME : les ralentissements sévères et les bugs d’affichage sont souvent liés à la configuration audio. Désactiver la synchronisation audio ou modifier la méthode (passer en mode asynchrone) réduit la charge sur les machines moins récentes. Les crashs au lancement peuvent indiquer une incompatibilité avec certains dumps modifiés (hacks, traductions non officielles).
- Vérification du fichier : si le jeu ne démarre sur aucun émulateur, comparer l’empreinte du fichier avec une base No-Intro permet de savoir si on dispose d’un dump de référence ou d’une version modifiée. Un outil de vérification de somme de contrôle suffit pour ce test.
Hacks, traductions et ROMs modifiées
Les traductions non officielles et les ROM hacks constituent un cas à part. Ces fichiers ont été modifiés par rapport au dump d’origine, ce qui leur donne une empreinte différente d’un dump de référence. Certains émulateurs ou configurations qui vérifient l’intégrité des fichiers peuvent les signaler comme non conformes.
Plus concrètement : une traduction française d’un jeu japonais peut fonctionner parfaitement sur DeSmuME et échouer sur melonDS selon les paramètres. Un fichier modifié n’est pas un fichier corrompu – les deux situations ne se traitent pas de la même façon. Un fichier corrompu ne se lance nulle part de façon cohérente ; un fichier modifié peut échouer sur un émulateur précis pour des raisons de compatibilité liées aux modifications elles-mêmes.
La documentation de melonDS signale également que certaines ROMs avec protections anti-copie peuvent se comporter différemment selon le mode de démarrage activé. Le Direct Boot désactive certaines vérifications que le firmware réel effectuerait, ce qui peut soit résoudre soit créer des problèmes selon la ROM concernée.
Problèmes de configuration sur Android et frontends multi-émulateurs
Sur Android, melonDS est disponible sous forme de port communautaire distinct. L’émulateur ne signale pas toujours clairement que le problème vient d’un accès refusé plutôt que d’un fichier invalide, ce qui rend le diagnostic plus difficile.
Dans les frontends comme RetroArch ou EmuDeck, une ROM DS peut ne pas se lancer parce que le core chargé ne correspond pas au fichier. Un frontend peut tenter de lancer un fichier .nds avec un core prévu pour une autre console si la détection automatique échoue. Vérifier quel core est effectivement assigné aux fichiers .nds dans la configuration du frontend est une étape que beaucoup ignorent.
Les limites de compatibilité entre certains firmwares et certains dumps restent documentées de façon incomplète dans les sources disponibles – notamment pour les cas où la ROM fonctionne en Direct Boot mais pas en mode firmware complet, sans message d’erreur explicite.
