Analyse interne des cartouches Super Nintendo
(fabiensanglard.net)- Les cartouches Super Nintendo n’étaient pas de simples supports de stockage, mais du matériel qui étendait les capacités de la console en embarquant la protection anticopie CIC, de la SRAM et des coprocesseurs
- La capacité des ROM était alors promue en bits, et parmi les 3 378 titres étudiés, Star Ocean et Tales of Phantasia faisaient 48Mb, tandis que Super Mario World faisait 4Mb
- La sauvegarde reposait sur de la SRAM maintenue par batterie, et certains cas, comme le PCB de Zelda III, incluaient aussi un décodeur d’adresses MAD-1 pour gérer l’accès à la ROM/RAM
- Au total, 13 types de puces d’extension ont été utilisés dans 72 jeux, prenant en charge côté cartouche l’accélération CPU, le traitement des sprites, la décompression, les calculs mathématiques et la rastérisation de polygones
- Ces puces ont considérablement élargi les possibilités visuelles des jeux de l’époque, mais ont aussi laissé aux émulateurs une lourde charge de rétro-ingénierie sur le long terme, comme dans le cas du S-DD1 dont la structure interne inconnue imposait des graphic packs
Configuration de base d’une cartouche : CIC, ROM, SRAM
- Les cartouches Super Nintendo pouvaient contenir non seulement les instructions et assets de la puce ROM, mais aussi une puce de protection anticopie CIC, de la SRAM et même des coprocesseurs
- Le CIC fonctionne par communication en lockstep entre la puce côté console et la puce côté cartouche
- Si le CIC de la console détecte un état anormal, il réinitialise tous les processeurs
- Toutes les cartouches SNES ne possèdent pas de CIC, et le jeu non officiel Super 3D Noah's Ark n’en a pas
- Super 3D Noah's Ark doit d’abord être branché sur la console, puis une cartouche officielle doit être insérée au-dessus ; la cartouche de Noah relaie alors les lignes du bus via le CIC du jeu officiel
- La capacité des ROM était indiquée à l’époque en bits et non en octets
- Zelda III était promu comme une ROM de 8Mb, et non comme 1 048 576 octets
- La liste étudiée comprend 3 378 titres pour les marchés USA/Japon/Europe
- Star Ocean et Tales of Phantasia, avec 48Mb soit 6 291 456 octets, font partie des plus gros titres
- Super Mario World utilise une ROM de 4Mb, soit 524 288 octets
- Certains titres avec sauvegarde utilisaient de la SRAM alimentée par batterie
- Quand la console est éteinte, la SRAM passe en mode basse consommation pour réduire l’usage d’énergie
- Le PCB de Zelda III contient le CIC D413A en U4, une ROM 0x80000 (524 288 octets) en U1, une SRAM LH5268AF-10TLL 64Kbit (8KiB) en U2 et le décodeur d’adresses mémoire MAD-1 en U3
Étendue des puces d’extension et SA-1
- Le coprocesseur le plus connu est le Super FX, utilisé dans Star Fox en 1993, mais des puces EC existaient déjà auparavant
- Globalement, 13 types d’EC ont été utilisés dans 72 jeux
- La liste complète est compilée sur wikipedia et snescentral.com
- Le SA-1, ou Super Accelerator 1, est une puce d’extension majeure présente dans 34 cartouches
- Il s’agit du même CPU 65C816 que celui de la SNES, mais cadencé quatre fois plus vite à 10,74MHz
- Il inclut 2KiB de SRAM et un CIC intégré
- Le PCB de Super Mario RPG n’a pas de CIC séparé ; le SA-1 se trouve en U3, la ROM en U1, et la SRAM avec décodeur intégré en U2
- Le SA-1 fonctionne sans oscillateur dédié : il reçoit le System Master clock via le port cartouche et le divise en interne par deux pour obtenir 21.4772700MHz / 2 = 10.74MHz
- Au démarrage, le SA-1 est en état stop ; le CPU de la SNES crée ensuite le Reset Vector puis relance le SA-1
- L’Instruction Pointer initial du SA-1 est récupéré depuis son Reset Vector dédié
- Il propose trois modes de fonctionnement : Accelerator, Parallel Processing et Mixed Processing
- Dans la configuration la plus puissante, le CPU SA-1 et le CPU de la Super NES fonctionnent simultanément, portant les performances du Super Accelerator System à cinq fois celles de la Super NES d’origine
- Cette puissance de traitement accrue servait à animer et détecter les collisions sur l’ensemble des 128 sprites fournis par le PPU, ainsi qu’à faire tourner et redimensionner les sprites en temps réel avant écriture dans la VRAM du PPU
- La cartouche de démonstration Nintendo SA-1 montre ces améliorations
- La communauté du jeu rétro a réduit le slowdown de jeux existants via des projets comme Eliminating slowdown in Super Mario World, Gradius III slowdown removal et Contra III slowdown removal
- Convertir un titre vers le SA-1 semble assez complexe, en particulier à cause du remappage des accès RAM/ROM, ce qui soulève des questions alors même que la documentation SA-1 indique que « SNES et SA-1 utilisent le même mapping mémoire »
- En 2019, le SA-1 Collection Project travaillait encore à remapper automatiquement davantage de jeux SNES pour les adapter au SA-1
Puces graphiques, de compression et de calcul
- Le CX4 est une puce Capcom utilisée dans Mega Man X2 et Mega Man X3
- Elle peut gérer le rendu 3D filaire, diverses opérations mathématiques, ainsi que le redimensionnement et la rotation des sprites avant écriture en VRAM
- On peut en voir des exemples dans l’intro et les combats de boss de MMX2
- Le CX4 ne fournit pas seulement du wireframe, mais aussi des sprite functions, propulsion, vector, triangle, trigonometric functions, result tables et coordinate transform functions ; dans MMX2 et MMX3, il traite tous les sprites
- Le PCB de Mega Man X2 contient le CIC en U4, une ROM 8M en U1, une ROM supplémentaire en U2, le CX4 en U3 et un oscillateur 20MHz en X1
- Le S-DD1 est une puce de décompression de sprites capable d’alimenter directement la VRAM du PPU
- Elle est utilisée dans deux jeux : Star Ocean et Street Fighter Alpha 2
- Une rumeur voulait que l’écran vide avant le début d’un round dans Street Fighter Alpha 2 soit dû au S-DD1, mais selon l’explication de Modern Vintage Gamer, le vrai problème venait du transfert des échantillons sonores vers la DSP RAM
- Le PCB de Street Fighter Alpha 2 contient en U1 une ROM de 4MiB et le S-DD1, qui décompresse les assets à la volée ; le CIC est intégré au S-DD1, sans puce séparée
- Le DSP-1 représente 16 des 19 titres compatibles de la famille DSP, et a été utilisé dans Super Mario Kart et Pilotwings
- Le sigle DSP signifie Digital Signal Processor, mais cette appellation est jugée impropre car la puce ne traite pas de signaux continus comme un DSP classique
- D’après le manuel développeur, le DSP-1 fonctionne en blocking mode : le CPU de la Super NES attend pendant que le DSP traite les données
- Il fournit des commandes de multiplication 16 bits rapide, réciproque, projection sin/cos, taille de vecteur et rotation, essentielles à la programmation HDMA et aux mises à jour de la vue 3D du Mode 7
- Le PCB de Super Mario Kart comprend un CIC externe, une ROM, une SRAM de sauvegarde, un décodeur d’adresses MAD-1, une batterie et un oscillateur pour un fonctionnement à 8MHz
- Les trois versions DSP-1, DSP-1a et DSP-1b ont introduit des corrections de bugs et des améliorations de fabrication, mais leur comportement diffère légèrement, au point de faire s’écraser l’avion sur le sol dans la démo de Pilotwings
- D’autres puces plus modestes n’ont été utilisées que dans des jeux très spécifiques
- Le DSP-2 n’a servi que dans Dungeon Master, apparemment pour convertir des routines Atari ST, principalement afin d’aider au redimensionnement des sprites
- Le DSP-3 n’est utilisé que dans SD Gundam GX
- Le DSP-4 n’est présent que dans Top Gear 3000 et The Planet's Champ TG 3000
- L’OBC-1 n’a été utilisé que dans Metal Combat: Falcon's Revenge ; on a parlé d’une puce de manipulation des sprites, mais le sujet reste débattu sur nesdev.org
- Le S-RTC est une puce de suivi d’horloge temps réel présente dans le seul titre Daikaijuu Monogatari II, sans qu’on sache clairement pourquoi les développeurs de Hudson Soft en avaient besoin
- Le SPC7110 d’Epson est une puce de décompression de données utilisée dans Tengai Makyou Zero, Momotaro Dentetsu Happy et Super Power League 4 ; dans Super Power League 4, elle ajoute aussi une fonction d’horloge temps réel
- La famille ST de SETA Corporation aurait visé à améliorer l’IA des jeux ; le ST-010 n’a été utilisé que dans Exhaust Heat 2, le ST-011 dans Hayazashi Nidan: Morita Shougi, et le ST-018 dans Hayazashi Nidan Morita Shougi 2
- Le ST-018 semble être un CPU ARM avec des instructions stockées en ROM interne
Famille Super FX et modifications communautaires
- Le GSU-1 a été utilisé dans cinq jeux : Star Fox, Stunt Race FX, Vortex, Dirt Racer et Dirt Trax FX
- C’est l’une des puces d’extension les mieux documentées, avec des ressources sur les wikis, des tutoriels et le Super Nintendo Developer Manual Book II
- Il fonctionne à 10,74MHz en divisant par deux en interne le master clock de 21,47MHz
- Son cache d’instructions interne de 512 octets lui permet de fonctionner sans affamer le CPU de la SNES
- Une fois son travail terminé, il peut déclencher une interruption sur le C-CPU de la console
- Alors que les PPU1/PPU2 de la SNES sont orientés tilemaps et sprites, le Super FX excelle dans le rendu pixel par pixel et la rastérisation de polygones
- Il effectue généralement le rendu dans un framebuffer présent sur la cartouche
- Le contenu du framebuffer est transféré en VRAM pendant le VSYNC
- Le PCB de Star Fox contient le GSU-1 en U3, le CIC en U5, le 74LS139 en U4 et la ROM en U1 ; en U2 se trouve une SRAM 32KiB sans batterie
- Cette SRAM ne sert pas à la sauvegarde, mais en partie au stockage du framebuffer du Super FX
- La communauté SNES investit aussi du temps dans le GSU-1, comme pour le SA-1, avec des projets tels que Project Super FX pour améliorer autant que possible les anciens titres
- Le GSU-2 est un GSU-1 fonctionnant à la pleine fréquence de 21,47MHz, utilisé dans trois jeux : Super Mario World 2: Yoshi's Island, DOOM et Winter Gold
- Des expérimentations communautaires ont montré des gains de performance en remplaçant le GSU-1 d’une cartouche Star Fox par un GSU-2
- Randy Linden, auteur du portage SNES de DOOM, a tout rétro-ingéniéré sans documentation sur la puce GSU ni sur le code source de DOOM
- La version SNES de DOOM était le seul port console capable d’utiliser les niveaux PC, alors que les autres consoles devaient simplifier la géométrie
- Yoshi's Island utilise surtout le GSU-2 pour redimensionner et étirer les sprites, puis réécrit les sprites modifiés dans la VRAM du PPU
- Le PCB de Yoshi's Island intègre une batterie, ce qui permet à la SRAM de servir à la fois de framebuffer et de stockage de sauvegarde
- DOOM a été overclocké à 32MHz, ce qui a fait passer le framerate d’environ 10–11fps à 14–15fps
- Le MSU-1 n’est pas une puce présente dans des cartouches commercialisées
- Near l’a conçue pour permettre sur SNES le streaming audio qualité CD, la lecture de FMV et l’accès à jusqu’à 4GB de RAM
- Elle vise la communauté du modding, et l’on peut voir les résultats dans Enhanced Zelda III: A link to the past et Enhanced Another World
Le fardeau laissé à l’implémentation des émulateurs
- Les puces d’extension ont grandement amélioré l’expérience de jeu tout en réduisant les coûts côté éditeurs, mais elles sont ensuite devenues un défi ardu pour les développeurs d’émulateurs
- Certains jeux reposant sur des EC atypiques n’ont été correctement émulés qu’en 2012
- Au début, la structure interne du S-DD1 étant inconnue, des jeux comme Street Fighter Alpha 2 étaient « émulés » en exigeant des graphic packs de sprites préalablement décompressés
- L’implémentation de ces puces a nécessité une importante rétro-ingénierie
- Certaines puces intégraient des fonctions câblées en dur, nécessitant du de-capping
- Les puces stockant leurs instructions en ROM interne, comme certaines puces à base d’ARM, obligent l’émulateur à disposer d’un fichier BIOS
- En 2020 encore, l’émulation de certaines des puces les plus rares n’était toujours pas achevée
1 commentaires
Avis sur Hacker News
J’aime beaucoup le fait que les cartouches des anciennes consoles étaient presque l’équivalent des cartes d’extension PCI d’un PC.
Elles étaient directement connectées au bus et pouvaient donc pratiquement tout faire ; malheureusement, cette pratique a pris fin après la GameBoy Advance, et à partir de la Nintendo DS elles sont devenues plus proches de simples supports de stockage de données.
C’est ce qui permet aujourd’hui des extensions modernes bizarres comme une puce de ray tracinghttps://www.youtube.com/watch?v=2jee4tlakqo, ou encore la puce d’extension MSU1, qui semble n’exister que dans des émulateurs logiciels et pas sous forme de vraie puce physique.
En théorie, elle pourrait être fabriquée, donc on pourrait aussi créer une vraie cartouche SNES de Road Blasterhttps://www.youtube.com/watch?v=BvIXUOr4yxU.
Dans l’article lui-même, la liste indique « Street Fighter Zero 2 » comme une ROM USA, mais Street Fighter Zero était le nom japonais de Street Fighter Alpha ; Zero 2 devrait donc être la version japonaise d’Alpha 2.
Ici, une fois la cartouche remplacée par un ordinateur moderne, des choses étranges se produisent. Par exemple, faire sur NES une présentation qui est, dans les faits, un PowerPoint sur l’humour.
https://www.youtube.com/watch?v=ar9WRwCiSr0
Il y avait donc une capacité limitée à ajouter des fonctionnalités, et même si ce n’était pas aussi intéressant qu’un CPU supplémentaire, il n’y a pas non plus eu énormément de cas aussi spectaculaires sur GBA.
J’aimerais savoir si cela avait été prévu pour un cas d’usage précis, ou s’il existait un canal séparé pour des composants d’extension de cartouche limités.
Un autre détail omis ici est que même les cartouches sans puce d’extension avaient des niveaux de performance différents.
Le CPU de la SNES fonctionnait nominalement à 3,58 MHz, mais pour tourner réellement à cette vitesse il fallait qu’une cartouche « FastROM » soit insérée. Nintendo proposait aussi aux éditeurs un format « SlowROM » moins cher, auquel cas le CPU descendait jusqu’à 2,68 MHz.
Il existe aussi une communauté de moddeurs qui développe des patches pour convertir des jeux SlowROM en jeux FastROM afin de réduire les latences. J’ai lu quelque part que certains jeux SlowROM semblaient avoir été développés à l’origine pour FastROM, puis changés au dernier moment en SlowROM à la demande de l’éditeur pour réduire les coûts.
Si ma mémoire est bonne, il affirmait que dans ce cas l’utilisation de SlowROM permettait d’économiser pas moins de 50 cents par cartouche.
Sa concurrente, la TurboGrafx-16, tournait généralement à 7 MHz et utilisait un CPU de la famille 6502 qui nécessitait des timings mémoire similaires ; je me suis toujours demandé pourquoi la SNES était aussi avare en vitesse.
Cela dit, la TurboGrafx a échoué en Occident et la SNES a connu un succès mondial, donc Nintendo a bien dû faire quelque chose correctement.
Après tout, toutes les cartouches SNES embarquaient de la mask ROM.
J’aimerais que les développeurs continuent à écrire ce genre de détails sous forme d’articles sur leurs blogs plutôt que d’en faire des vlogs YouTube.
On peut faire tenir beaucoup de détails dans quelques Ko.
« Super Mario World » reste un chef-d’œuvre absolu. Il a réussi à faire tenir des personnages, des sprites et des niveaux incroyables dans seulement 360 Ko.
Ce n’est qu’une fois compressé au format ZIP qu’il descend à environ 360 Ko.
Musique superbe, contrôles précis, graphismes séduisants : il réussit tout ce qu’un jeu de plateformes doit faire.
Terranigma est presque au même niveau, et selon mes critères Super Mario World serait probablement troisième.
Le texte peut être aspiré, modifié en changeant seulement quelques mots, puis réutilisé sur des sites publicitaires SEO.
Je me demande ce qu’on pourrait faire aujourd’hui avec la possibilité d’exploiter, grâce aux technologies modernes, des « puces d’extension » dans les cartouches.
Il est indiqué que le SuperFX possède son propre framebuffer et le copie intégralement dans la VRAM.
Techniquement, serait-il donc possible de mettre dans la cartouche un SoC absurdement puissant, de l’utiliser pour rendre des graphismes modernes à la résolution de la SNES, puis de copier les frames résultantes dans la VRAM de la SNES ?
Je me demande où se situent les limites.
Le passage selon lequel « Randy Linden, l’auteur de DOOM pour SNES, n’avait accès ni à la documentation de la puce GSU ni au code source de DOOM. Il a tout fait par rétro-ingénierie » est techniquement impressionnant, mais je me demande pourquoi il a dû en arriver là
Randy Linden, l’unique programmeur du portage, était fasciné par le jeu et a d’abord commencé de lui-même à porter Doom sur Super NES
À l’époque, le code source de Doom n’était pas encore public ; Linden s’est donc appuyé sur les Unofficial Doom Specs pour comprendre en détail la structure des lumps du jeu. Les ressources ont été extraites de l’IWAD, mais certaines n’ont pas été utilisées en raison des limitations techniques
D’après des interviews, comme les systèmes de développement pour Super FX manquaient, Linden a créé lui-même, sur son Amiga, un ensemble d’outils assembleur, éditeur de liens et débogueur appelé ACCESS avant d’attaquer réellement le portage
Comme kit matériel, il a utilisé une cartouche Star Fox hackée et deux manettes Super NES modifiées, branchées sur la console et reliées au port parallèle de l’Amiga ; il a aussi utilisé un protocole série pour connecter deux appareils supplémentaires
Après avoir réalisé un prototype complet, il l’a montré à son employeur, Sculptured Software, qui l’a aidé à finaliser le développement. Linden a dit qu’il aurait aimé pouvoir intégrer les niveaux manquants, mais que le jeu avait déjà atteint la taille maximale d’un jeu Super FX 2, soit 16 mégabits, environ 2 Mo, et qu’il ne restait qu’environ 16 octets d’espace libre
Il a également ajouté la prise en charge du pistolet optique Super Scope, de la souris Super NES et du modem XBAND pour le multijoueur. Son collègue programmeur John Coffey, fan de la série Doom, a modifié des niveaux, mais certains ont été rejetés par id Software
Il y a toujours une histoire fascinante autour de ce genre de choses, et j’en ai aussi écrit un peu plus ici : https://eludevisibility.org/super-noahs-ark-3d-source-code
Si ma mémoire est bonne, l’équipe de Crash Bandicoot n’avait pas non plus de SDK, elle faisait tourner son propre code, et a fini par découvrir un bug matériel lié à la sauvegarde sur carte mémoire
Je me demande d’où viennent les nombres d’octets indiqués pour les différents jeux
Les jeux étaient sur des puces ROM, et comme il s’agit de ROM, leur taille était une puissance de deux. Par exemple, Super Mario World est sorti sur une ROM de 512 ko ; d’où vient alors le chiffre de 346 330 octets ? Est-ce une taille compressée ?
Il faudrait écrire un programme qui décompresse chaque ZIP et compte le bourrage de zéros en fin de fichier
Il est trop tard aujourd’hui ; je l’écrirai demain et mettrai l’article à jour
Il y a aussi d’autres problèmes. L’article donne l’impression que MVG a découvert que les freezes de SFA2 étaient dus au chargement des données audio, alors que c’était connu bien avant cette vidéo : https://forums.nesdev.org/viewtopic.php?p=70474#p70474
Il semble aussi y avoir pas mal de confusion au sujet du RTC. Il est évident, comme dans les jeux Pokémon GBC/GBA, qu’il sert à faire continuer l’horloge quand la console est éteinte et que la cartouche est retirée, mais l’article suggère que cela pourrait être dû à une dérive de l’horloge NTSC. Je ne comprends vraiment pas ce que ça veut dire
À propos du passage « Super Mario World aussi a eu droit à ce traitement. Je ne me souviens pas de ralentissements, mais je n’avais que douze ans à l’époque », Yoshi’s Island 4 connaît des ralentissements dans certaines conditions
C’est le cas si l’on obtient une étoile d’invincibilité en chevauchant Yoshi puis qu’on appuie sur un P-Switch, et il y a aussi un autre niveau dont je ne me souviens pas exactement. C’est un endroit où beaucoup de Monty Mole surgissent en même temps, je crois que c’était sur Chocolate Island
Il me semble qu’il y avait aussi un troisième cas où deux Sumo Bros. et un Amazing Flying Hammer Bro. apparaissent ensemble à l’écran
Je n’ai jamais vraiment compris comment on dumpe une ROM depuis une cartouche pour un émulateur
Je comprends qu’on dumpe les instructions et les assets, puis qu’on les regroupe dans un fichier de données que l’émulateur peut interpréter. Mais comment l’émulateur modélise-t-il tout le matériel des puces d’extension présent dans la cartouche ? Comment est-ce dumpé depuis la cartouche d’origine ?
Personnellement, je pense que la situation était un peu pire du côté de la NES, qui a précédé la SNES
La NES comptait beaucoup de puces d’extension appelées mappers. Leur fonction habituelle était d’étendre l’espace mémoire de la NES, plutôt que d’ajouter un processeur ou des capacités supplémentaires ; sans elles, la NES était limitée à 32 Ko de ROM PRG et 4 ou 8 Ko de ROM graphique CHR, si bien qu’on les trouvait dans la plupart des jeux
La plupart des jeux sortis après le lancement de la NES utilisaient ce type de puce
Elles aussi ont dû être entièrement rétro-ingéniérées, tout comme la console elle-même. Heureusement, c’était beaucoup plus simple que de faire la rétro-ingénierie d’un CPU ou d’un accélérateur supplémentaire
Certaines puces, comme les MMC1 et MMC3, ont été utilisées dans de nombreux jeux, tandis que d’autres, comme la MMC2, sont quasiment propres à Punch-Out
Il n’existe pas tant de types de puces d’extension que ça, donc ce n’est pas ingérable
Le système de protection contre la copie de la SNES était facile à contourner du point de vue des consommateurs. En revanche, ce n’était peut-être pas le cas pour les studios de développement ou les éditeurs de jeux.
À l’époque, tout le monde avait un « appareil de sauvegarde » pour SNES. C’était un dispositif qu’on branchait sur la SNES, avec un lecteur de disquettes, et qui permettait de « sauvegarder » les jeux sur de très bon marché disquettes 3,5 pouces.
Il ne fallait qu’une seule cartouche originale pour que le système fonctionne : on l’insérait dans le copieur, et l’appareil réutilisait la puce CIC de cette cartouche.
https://en.wikipedia.org/wiki/Game_backup_device
En lisant le passage selon lequel « le DSP-1 a existé en trois versions : DSP-1, DSP-1a et DSP-1b. Avec les corrections de bugs et les améliorations du procédé de fabrication, le comportement de la puce a légèrement changé, ce qui a eu pour résultat que l’avion de la démo Pilot Wings s’écrasait au sol », je me dis que je devrais utiliser cette excuse si quelqu’un me demande pourquoi je suis aussi mauvais.