Préface du rédac’ chef (G. Verdin) : Après une petite chronique maison un peu particulière, retour à SSeb22 avec l’une de trois traductions réalisées en avril 2019 – on avait déjà publié celle sur la genèse d’Alpha Waves l’été dernier. Mais celle-ci, comme la troisième d’ailleurs, appartient à un registre un peu différent, et c’est pourquoi je l’ai également classée dans la rubrique « technologie » du site, car il ne s’agit pas tout à fait d’Histoire du jeu vidéo… Néanmoins, à l’heure où il devient malheureusement de plus en plus évident que la préservation de ce patrimoine passera aussi par l’émulation à terme, il me semblait urgent de tordre le cou à certaines idées reçues, et notamment rappeler pourquoi retranscrire le fonctionnement de consoles pourtant trentenaires nécessite des machines beaucoup plus puissantes qu’on ne pourrait le croire… En revanche, comme à mon habitude, j’ai souhaité préserver au maximum la nature et la position des illustrations de l’article d’origine, mais je dois vous prévenir qu’elles sont bien peu nombreuses !
L’exactitude requiert de la puissance : la quête des 3 GHz pour bâtir un émulateur SNES parfait
Comment l’émulation de la Super Nintendo peut nécessiter 3 GHz ? L’homme derrière l’un des grands émulateurs l’explique.
Par Byuu, publié sur Ars Technica en août 2011
Traduit de l’anglais par SSeb22
Les émulateurs pour faire tourner de vieux jeux sont extrêmement populaires sur internet et les débats pour déterminer le meilleur émulateur pour tel jeu éclatent régulièrement. Aujourd’hui nous vous présentons un point de vue différent, celui du gentleman qui a créé l’émulateur Super Nintendo bsnes. Il souhaite partager ses réflexions concernant la partie la plus importante dans l’émulation : l’exactitude.
Il ne faut pas beaucoup de puissance brute pour jouer à des jeux NES ou Super Nintendo sur un PC moderne ; les émulateurs pouvaient le faire dans les années 1990 avec des processeurs cadencés à 25 MHz (NdT : à titre indicatif, et même si ce n’est pas directement comparable, le CPU de la SNES tourne à 3,58 MHz). Mais émuler ces vieilles consoles avec exactitude est une autre paire de manches ; les émulateurs précis peuvent nécessiter jusqu’à des fréquences de 3 GHz pour recréer fidèlement ces technologies qui datent. Dans cet article, nous allons voir pourquoi l’exactitude est si importante pour les émulateurs et pourquoi elle est si difficile à atteindre.
Pour faire simple, l’exactitude rend compte de la fidélité avec laquelle le logiciel d’émulation imite le matériel d’origine. La compatibilité apparente est le critère le plus évident pour mesure cette précision ; est-ce qu’un vieux jeu va fonctionner avec mon nouvel émulateur ? Mais une telle vision naïve peut masquer de nombreux petits problèmes. En vérité, la plupart des logiciels tournent avec une grande tolérance par rapport aux problèmes de timing et semblent fonctionner normalement même si ce timing peut avoir un décalage qui monte à 20%.
Donc la question devient : si on peut avoir une compatibilité de base, pourquoi s’embêter à améliorer l’exactitude au prix de tels besoins en vitesse CPU ? Deux raisons : la performance et la préservation.
Tout d’abord, la performance. Prenons le cas de Speedy Gonzales: Los Gatos Bandidos (1995). C’est un jeu de plateformes sur Super Nintendo sans fonction de sauvegarde et qui dure environ deux à trois heures. À première vue, il semble tourner sans souci sur tous les émulateurs. Cependant, quand vous atteignez le niveau 6-1, vous pouvez rapidement remarquer la différence entre un émulateur précis et un émulateur rapide ; il y a un interrupteur dont l’activation est nécessaire pour terminer le niveau. Le jeu se bloque si un cas limite au niveau du matériel n’est pas émulé. On peut donc s’imaginer la frustration de perdre instantanément trois heures de progression à cause d’un jeu infinissable. À moins que le logiciel ne se comporte exactement comme le matériel le faisait, le jeu restera irrémédiablement cassé.
Prenez aussi Air Strike Patrol (1994, Desert Fighter en Europe, NdT), où une ombre est dessinée sous votre avion. Cet effet est réalisé en utilisant des effets de trame avec scanline (NdT : mid scanline raster effects), qui sont extraordinairement gourmands en ressources à émuler. Mais sans ces effets, l’ombre de votre appareil n’apparaîtra pas, comme vous pouvez le voir dans l’image ci-dessous. C’est un détail facile à négliger, surtout si vous ne savez pas que c’est censé être présent. Mais une fois que l’avez vu, vous réalisez que c’est plutôt utile. En effet, votre avion a la capacité de jeter des bombes et cette ombre agit comme une sorte de système de visée pour déterminer où elle va atterrir – et c’est un peu plus difficile sans cet effet qui semble mineur au premier abord.
Le second problème est la préservation. Intéressons-nous au hardware des Game & Watch de Nintendo. Ces appareils furent lancés en 1980 et, maintenant, la plupart des 43 millions d’exemplaires qui ont été produits ne fonctionnent plus à cause de leur âge ou ont été détruits. Et même si on peut encore en trouver de façon relativement aisée, leur rareté ne peut qu’augmenter car aucun nouvel exemplaire ne sera fabriqué. Et c’est valable pour toutes les machines ; une fois perdue, c’est pour de bon. À ce moment-là, les émulateurs sont la seule manière de jouer à nouveau à ces jeux, ils devraient donc être capables de le faire avec exactitude.
Mais cette précision a un coût. Faire un émulateur deux fois plus précis le rendra, grosso modo, deux fois plus lent ; doublez cette précision et il sera maintenant quatre fois plus lent. Et en même temps, le gain pour cette exactitude diminue rapidement car la plupart des jeux ont l’air « jouable » à un niveau modeste de précision dans l’émulation (la plupart des émulateurs ciblent une sorte de « point idéal » de 95% de compatibilité avec des performances optimales).
Il n’y a rien de mal à avoir des émulateurs moins précis mais plus rapides, et ce genre de code peut tourner sur du matériel moins puissant comme des téléphones et consoles portables. Ces émulateurs sont également mieux adaptés pour des ordinateurs portables sur lesquels l’autonomie est un point important. Mais il y a des avantages à rechercher l’exactitude et c’est ce que j’ai essayé de faire dans mon travail. Voici pourquoi ça me tient à cœur.
La méthode logicielle
À la fin des années 1990, Nesticle était, de loin, le meilleur émulateur NES et il tournait avec des CPU d’environ 25 MHz. Cette performance avait un prix non négligeable ; les images des jeux étaient bidouillées pour tourner sur cet émulateur spécifiquement. Les traductions de fans et les hacks se basaient sur des particularités de l’émulation qui rendaient les jeux injouables sur la vraie console ou sur d’autres émulateurs, créant ainsi une espèce de verrouillage qui demanda du temps à être contourné. À l’époque, l’expérience originale des jeux n’était pas très importante pour les gens, ils voulaient juste que ça tourne bien dans cet environnement artificiel et arbitraire.
De nos jours, les émulateurs NES les plus dominants sont Nestopia et Nintendulator qui demandent, respectivement, 800 MHz et 1,6 GHz pour tourner à pleine vitesse. Le besoin en vitesse ne vient pas du fait que ces émulateurs ne sont pas bien optimisés ; c’est parce qu’ils recréent de façon bien plus fidèle le hardware de la NES dans leur environnement logiciel.
Maintenant, comparons-les à un vieil émulateur Nintendo 64, UltraHLE dont les prérequis sont un système équivalent à un Pentium II à 350 MHz. Pour l’observateur occasionnel, il peut être surprenant de voir que faire tourner Mario 64 demande moins de puissance de traitement que le Super Mario Bros. initial.
Mon expérience en émulation concerne la Super Nintendo avec mon travail sur l’émulateur bsnes. J’adore l’idéal derrière Nestopia et je voulais faire de même pour la Super Nintendo. Il se trouve que, pour avoir le même degré d’exactitude, il faut, pour la SNES, un minimum de 2 à 3 GHz en fonction du titre.
Nestopia est devenu à la mode parce que ses spécifications techniques étaient déjà dérisoires à sa sortie, mais je n’ai aucun doute sur le fait que s’il était sorti en 1997, le résultat aurait été désastreux. Puisque mon émulateur nécessitait au final une puissance que plus de la moitié des ordinateurs sur le marché n’avait pas, j’ai vécu directement les effets de spécifications techniques élevées et les réactions négatives que cela entraîne. C’est plus facile d’accuser le programme que d’admettre que votre ordinateur n’est pas assez puissant, mais la réalité est que simuler une console de jeu entièrement de façon logicielle est un processus intensif.
Pourquoi la précision est importante
Donc si un émulateur semble faire tourner tous les jeux correctement, pourquoi l’améliorer ? Une réponse simple est que ça améliore des aspects que nous ne connaissons pas encore. C’est particulièrement important pour des titres moins populaires.
Comparons par exemple l’animation des triforces tournantes dans l’introduction de The Legend of Zelda sur les émulateurs ZSNES et bsnes. Sur le premier, les triforces vont effectuer leurs rotations bien trop rapidement car le CPU tourne plus de 40% plus vite que le vrai sur Super Nintendo. Ce sont des petits détails mais si l’exactitude vous importe, cela peut vous rendre fou.
J’ai rencontré des dizaines de titres avec d’obscures particularités. Parfois, l’émulateur correct et plus précis donne un « mauvais » résultat. La démo tournante dans l’introduction de Super Bonk (1994) se désynchronise et Bonk se retrouve coincé près d’un mur sur la plupart des vraies consoles. Et Star Fox souffre de ralentissements significatifs tout au long du jeu. Ce ne sont pas des choses que l’on souhaite avoir mais elles sont quand même authentiques. On n’arrondirait pas Pi à 3 juste parce que les nombres irrationnels ne sont pas pratiques, n’est-ce pas ?
Je ne nie pas les avantages de vouloir améliorer les jeux classiques ; les émulateurs Nintendo 64 utilisent de magnifiques packs de textures et de l’upscaling en 1080p et les émulateurs Super Nintendo fournissent souvent de l’antialiasing 2× pour les graphismes en mode 7 et de l’interpolation par des splines cubiques pour les échantillons audio. Des jeux émulés ainsi sont meilleurs visuellement comme au niveau sonore. Bien qu’il n’y ait rien de mal à cela, c’est contraire au but d’un émulateur voulant singer précisément le matériel qu’il émule. Ces techniques d’amélioration compliquent même encore plus les choses pour privilégier l’exactitude, en fait.
Un autre domaine dans lequel la précision est un avantage est le travail réalisé par les fans pour les traductions, le hack de ROM et le développement de homebrew. Les gens qui font ça n’ont pas souvent la possibilité de faire tourner du code directement sur du vrai matériel, et développent donc leurs outils en utilisant des émulateurs. Malheureusement, les émulateurs privilégiant la vitesse d’exécution vont souvent ignorer certaines limitations techniques. Ce n’est pas un souci pour des jeux commerciaux ; lors des tests sur les vraies machines, le bug serait alors vite découvert et réparé. Mais si vous ne pouvez tester que sur un émulateur spécifique, de tels bugs tendent à rester.
Je peux vous donner quelques exemples. Les fantrads de Dragon Quest 1&2, Dual Orb 2, Sailor Moon: Another Story et Ys 4 souffrent toutes de problèmes de textes invisibles résultant d’une écriture dans la RAM vidéo alors que le processeur vidéo en avait interdit l’accès parce qu’il était en train de s’occuper de l’affichage à l’écran. Seulement la moitié d’entre elles ont depuis été corrigées.
On est au courant de cette limitation matérielle depuis 1997 et sa correction ne demande qu’une ligne de code mais les émulateurs les plus populaires ne sont toujours pas compatibles. Le résultat est que les traductions faites pour cet émulateur continuent à poser des problèmes et des verrouillages. Qui voudrait d’un émulateur plus précis s’il ne peut pas faire tourner un grand nombre de vos fantrads préférées ?
Et ça ne s’arrête pas là. Le hardware original de la Super Nintendo a un retard lors de la demande de résultat d’une multiplication ou d’une division à l’unité de calcul. À nouveau, n’importe quel jeu commercialisé respectait ses délais mais dans les hacks de fans, on s’est retrouvé avec des musiques coupées dans les traductions de Zelda et un Super Mario World qui part en vrille à cause du patch des Chain Chomps.
De même, un émulateur peut ignorer le fait que le processeur sonore écrit des échantillons d’écho dans de la RAM partagée. Ce n’est pas un problème jusqu’à ce que vous tombiez sur des hacks utilisant un espace vraiment déraisonnable pour les tampons d’écho, qui finissent du coup par écraser tout le programme audio en mémoire, résultant en crash spectaculaire. Ce problème est responsable à lui tout seul de rendre injouables des dizaines de niveaux de Super Mario World créés par des fans.
Un émulateur pour tous les jeux
Il n’est pas impossible d’entrevoir un futur sombre dans lequel un utilisateur aura besoin de ZSNES v1.42 pour quatre traductions, Snes9x v1.51 pour six autres hacks de ROM et bsnes v080 pour quelques obscurs jeux japonais. Quelle lourdeur !
Il vous faut réaliser que même les émulateurs ont une certaine durée de vie. C’est particulièrement vrai pour ceux comme ZSNES qui sont écrits en pur assembleur pour x86. Vous ne pouvez tout simplement pas le faire tourner sur un téléphone portable. En faisant un hack de ROM juste pour ZSNES, vous le condamnez à l’obsolescence. Dès que Windows abandonnera la rétrocompatibilité avec les codes 32 bits comme il l’a fait avec les codes 16 bits, ces fantrads et ces hacks seront perdus à jamais. À ce moment-là, l’émulateur en lui-même devient presque une console morte au lieu d’être un moyen de préserver les vieux jeux.
Et puis il y a cet épineux problème que les jeux Super Nintendo devraient pouvoir fonctionner sur, je ne sais pas, une vraie console Super Nintendo. En créant des émulateurs qui imitent le comportement du matériel d’origine parfaitement, ou autant que faire se peut, nous créons une plateforme qui peut fonctionner sur différents systèmes et permettre aux traductions et aux hacks de marcher sur les futures versions. Le but est de conserver les détails du hardware de la SNES et pas juste l’idée qu’on se fait de ses jeux.
Mais vraiment, 3 GHz ? Vous vous moquez de moi ?
Il est tout à fait possible qu’un émulateur Super Nintendo conçu pour la vitesse d’exécution et bien optimisé tourne à pleine vitesse sur un CPU à seulement 300 MHz. Et il est aussi tout à fait possible que vous vous retrouviez avec des centaines de bugs obscurs.
Ce qui se passe en général, c’est que ces problèmes sont résolus en bidouillant. ZSNES et Snes9x contiennent tous les deux des listes internes de la cinquantaine de jeux les plus populaires. Quand vous chargez ces jeux, les émulateurs modifient leurs timings et patchent certaines parties de leurs codes pour faire tourner ce jeu en particulier. C’est une amélioration par rapport à l’époque de Nesticle où les jeux eux-mêmes devaient être patchés, mais c’est quand même de la triche, quel que soit le résultat visuel final.
Le joueur casual qui ne joue qu’à la vingtaine de jeux les plus connus ne verra pas de différences notables entre un émulateur nécessitant 300 MHz et un autre demandant 3 GHz et il choisira bien sûr le premier. Bien que je respecte et apprécie ces émulateurs conçus pour la vitesse, ceux qui s’intéressent à l’exactitude ne peuvent s’empêcher de regretter la façon qu’a cette approche de retarder les progrès. Sans plus de joueurs utilisant des émulateurs orientés vers l’exactitude, nous ne trouverons pas les bugs dans tous les jeux supportés par l’émulateur. Plus on a de gens qui jouent aux jeux tels qu’ils ont été prévus, et meilleur sera l’émulateur car les bugs seront détectés et éradiqués, pas en modifiant du code pour chaque jeu mais en améliorant l’exactitude de l’émulateur.
La capture d’écran ci-dessous est un excellent exemple d’un jeu de niche (NdT : Speedy Gonzales sur Super Nintendo). C’est en fait un très bon jeu de plateformes mais peu de gens en ont entendu parler. C’est un bon exemple montrant pourquoi, simplement parce que la plupart des jeux populaires tournent de façon décente sur des émulateurs imprécis, l’exactitude est quand même importante. Vous ne saurez jamais quand votre jeu favori, celui qui est légèrement atypique, pourrait rencontrer un bug comme celui-ci. Dans les screenshots ci-dessous, vous voyez un interrupteur. Quand on l’actionne dans les autres émulateurs, le jeu se bloque instantanément. Ce qui est censé arriver est illustré dans les autres screenshots ; l’interrupteur fait se déplacer un bloc jusqu’au milieu d’un champ électrique. Il est nécessaire que cette action soit réalisée pour finir le niveau, et donc le jeu. Au moment de la rédaction de cet article (NdT : août 2011), bsnes est le seul émulateur Super Nintendo capable de faire tourner ce jeu normalement.
La Super Nintendo possède non seulement un mode d’affichage à haute résolution mais aussi une variante appelée mode pseudo hi-res. Ce mode est utile pour créer un vrai alpha blending entre les couches d’affichage (NdT : un peu comme les calques dans Photoshop) du hardware de la SNES. Ignorer ce mode résulte en des couches qui en obstruent complètement d’autres comme on peut le voir sur les images ci-dessous (NdT : du jeu Jurassic Park).
Les jeux vidéo font partie de notre histoire et nous devons respecter le fait qu’il y a une « bonne » apparence, celle qu’ils présentaient à leur sortie. Imaginez qu’on n’ait qu’une image JPEG de Mona Lisa, qu’un stream RealVideo (NdT : un vieux format de compression vidéo datant des débuts d’Internet et réduisant drastiquement la taille et donc la qualité des vidéos) de l’atterrissage sur la Lune ou qu’une interprétation MIDI de Walking in the Air. Nous avons la possibilité de garder notre passé en vie et j’ai le sentiment que c’est presque un devoir de le faire.
Mais alors, à quoi servent ces 2,7 Ghz supplémentaires ? La synchronisation.
L’idée reçue la plus répandue dans l’évaluation de la performance d’un émulateur est de croire qu’il suffit de regarder la fréquence du processeur de la machine émulée. Malheureusement, cela ne vous apportera pas beaucoup d’information. Le CPU de la Nintendo 64 a beau avoir une fréquence d’horloge trente-cinq fois plus rapide que celle du CPU de la Super Nintendo, UltraHLE nécessite la même puissance de traitement que ZSNES.
Un émulateur a avant tout besoin du nombre de fois par seconde qu’un processeur doit se synchroniser avec un autre. Un émulateur est intrinsèquement un processus séquentiel. Tenter de se reposer sur les processeurs multi-cœurs actuels mène à plein de problèmes de timing. Prenez l’exemple d’une ligne d’assemblage ; une personne décharge les boîtes, une autre les scanne, une troisième les ouvre, une autre commence à assembler les pièces… La synchronisation est l’équivalent de bloquer et de vider complètement la ligne pour tout recommencer avec un autre type de produit. C’est un coup dur pour la cadence de production. Cela annule complètement les bénéfices des pipelines et de l’exécution dans le désordre (out-of-order execution, NdT). Plus vous avez de choses à synchroniser et plus vite votre ligne d’assemblage doit aller pour suivre.
Comparons les ratios de synchronisation entre ZSNES (à gauche, NdT) et bsnes (à droite, NdT) :
S-CPU : 600 000 contre 21 477 272
S-SMP : 256 000 contre 24 576 000
S-DSP : 32 000 contre 24 576 000
S-PPU : 15 720 contre 21 477 272
Total : 903 720 contre 92 106 544
Commençons par le CPU qui est typiquement cadencé à 3,58 MHz. Cette fréquence s’applique au nombre de cycles exécutés par seconde. Une instruction classique peut consommer jusqu’à huit cycles et ZSNES se synchronise une fois par instruction. Mais pour entrer plus dans les détails techniques, les cycles sont décomposés en délais d’attente de bus qui nécessitent un timing au niveau de l’oscillateur brut. L’oscillateur du CPU de la Super Nintendo est cadencé à 21,47 MHz. Cela s’applique aussi au SMP dont l’oscillateur va à 24,58 MHz.
En ce qui concerne la vidéo, 99% des jeux n’essaient pas de modifier les registres d’affichage au moment de l’affichage sur l’écran. Ceci permet à des scanlines entières d’être dessinées d’un coup, nécessitant 262 scanlines × 60 images par seconde soit 15720 synchronisations. Mais faîtes tourner un jeu comme Air Strike Patrol qui écrit dans le registre de la luminosité d’affichage plusieurs fois par scanline et vous devez maintenant vous synchroniser après chaque cycle d’horloge si vous voulez une exactitude complète.
En ce qui concerne l’audio, quasiment tous les titres fonctionneront bien avec une synchronisation au taux d’échantillonnage maximal du DSP de la Super Nintendo (32 kHz). Et pourtant, lancez un jeu comme Earthworm Jim 2 et vous vous apercevrez que les effets sonores seront coupés si vous ne vous synchronisez pas au même rythme que le cycle de l’oscillateur. Kōshien 2 (1992), lui, pourrait même freezer périodiquement.
Donc même si bsnes tourne dix fois moins vite que ZSNES, il est littéralement cent fois plus précis. En vérité, c’est très impressionnant de pouvoir faire ça à seulement 3 GHz. C’est seulement parce que j’ai utilisé du multithreading coopératif et de la synchronisation « juste à temps » – des techniques que je n’ai jamais vues implémentées dans des émulateurs avant – que j’ai pu tirer de bsnes la performance qu’il a actuellement. Les automates finis, sans compter l’ordonnancement du noyau, ne sont tout simplement pas à la hauteur.
L’observation première est que, même à un rythme de synchronisation cent fois plus lent, ZSNES se débrouille quand même bien avec la plupart des jeux. On ne peut le nier, la synchronisation absolument parfaite est très rarement nécessaire. Mais le fait est qu’il y a des cas où ça l’est. Avec le CPU de la Super Nintendo si lent, plein de jeux ont poussé la machine dans ses derniers retranchements.
Si vous n’atteignez pas le timing parfait, vous finirez (NdT : en tant que développeur d’un émulateur) par jouer à un perpétuel jeu de tape-taupes. Corriger un jeu pourrait en casser deux autres et en les réparant, vous en cassez encore deux autres. Et les réparer pourrait casser le premier. Il vous suffit de jeter un œil aux changelogs de ces quinze dernières années pour le vérifier.
Émuler les processeurs supplémentaires
L’un des aspects sympas des machines utilisant des cartouches, c’est que vous insérez littéralement une PCB dedans. Ainsi, vous pouvez ajouter des coprocesseurs supplémentaires, souvent des DSP (NdT : Digital Signal Processors ou Processeurs de Traitement Numérique du Signal), à l’intérieur de la cartouche. Cela vous donne un avantage compétitif par rapport aux titres de vos concurrents. Les coprocesseurs les plus connus sur Super Nintendo étaient le Super FX pour le rendu de polygones et la rotation de sprites (utilisé dans Star Fox et Super Mario World 2) et le DSP-1 pour le calcul 3D (utilisé dans Super Mario Kart et Pilotwings).
Souvent, ces processeurs sont tellement séparés du processeur hôte qu’il est possible de les implémenter en utilisant de l’émulation de haut niveau (NdT : HLE pour High Level Emulation). Ce n’est pas unique aux coprocesseurs de la Super Nintendo ; on peut aussi le voir dans l’émulation du microcode vidéo de la Nintendo 64, entre autres.
L’idée ici est de ne pas penser en termes d’instructions individuelles mais en groupe d’instructions et de ce qu’elles peuvent faire ensemble. En d’autres termes, il faut penser à un programme avec des fonctions comme « fais le rendu d’un triangle à ces points » ou « effectue une rotation de ce sprite de N degrés ». Il est alors possible de simuler ces opérations avec quasiment aucun coût machine supplémentaire. Malheureusement, cette approche ne prend en compte aucune information de timing, pourtant nécessaire pour l’exécution de chaque instruction. Et, pire que tout, c’est généralement tout sauf parfait ; des cas limite mineurs, des particularités et des défauts dans l’implémentation initiale sont perdus, résultant en un fonctionnement légèrement différent.
L’approche par l’émulation de bas niveau (NdT : Low-level emulation ou LLE) consiste à traiter le DSP comme un processeur normal : exécuter toutes ses instructions, une par une. Les jeux ne sont plus accélérés comme ils le devraient mais tous les cas limite fonctionnent correctement. Mais c’est immensément plus exigeant. Alors que Super Mario Kart tourne tout aussi rapidement en HLE que Super Mario World, un jeu sans coprocesseur, il tourne 25 à 30% plus lentement en LLE. La puce Cx4 utilisée dans les derniers jeux Mega Man X est si puissante qu’elle peut carrément diviser par deux la performance en LLE. Les DSP sont en fait vraiment puissants, tournant généralement à 21 MIPS ou plus, même à l’époque de la Super Nintendo (NdT : le Cx4 est cadencé à 20 MHz).
La LLE est aussi très chère, financièrement parlant ; pour obtenir le code d’un DSP, il faut faire fondre le circuit intégré avec de l’acide nitrique, scanner la surface de la puce avec un microscope électronique et ensuite soit teinter et lire manuellement, ou altérer physiquement et surveiller les traces pour extraire le programme et les ROM de données. Ce genre de travail peut coûter jusqu’à plusieurs millions de dollars si on veut que ce soit fait professionnellement, en fonction de la complexité de la puce, à cause du savoir extrêmement spécialisé et du matériel mis en jeu. Grâce aux efforts d’un individu du nom de « Dr. Decapitator », nous avons pu extraire ces données de presque une douzaine de puces pour seulement le coût du matériel.
Une fois ceci fait, vous devez vous rendre compte que les DSP sont généralement des composants spécialisés uniques. On doit alors faire de la rétro-ingénierie sur leurs jeux d’instructions à partir de pâtés en binaire et les émuler pratiquement sans documentation. C’est un processus lourd et cela montre le niveau d’implication nécessaire pour émuler précisément ces jeux.
Assez précis ?
Honnêtement, même avec tous les problèmes listés ci-dessus, nous n’avons fait qu’effleurer la surface de l’émulation précise. Prenez le cas de DICE, l’émulateur numérique de circuits intégrés (NdT : Digital Integrated Circuit Emulator). C’est un émulateur qui travaille au niveau du transistor pour une reconstitution absolument parfaite des tout premiers jeux vidéo. Pour faire tourner Pong à environ 5 à 10 images par seconde, DICE a besoin d’un processeur à 3 GHZ ! Oui, vous avez bien lu ; aucun processeur ne peut actuellement faire tourner Pong au niveau des transistors à pleine vitesse. Ce n’est pas que DICE soit lent ; c’est un programme très bien optimisé. C’est que le coût pour simuler les délais de propagation de chaque transistor est élevé.
Mais un jour, ce sera possible. Et, en ce qui me concerne, je suis ravi que ce classique ait pu être complètement répliqué pour les générations futures.
Mais appliquer l’approche du DICE à des systèmes plus modernes devient problématique. Prenez le cas de Visual6502. Des gens très intelligents ont utilisé une technique similaire à notre méthode d’extraction des DSP pour scanner la surface du CPU 6502 utilisé par la NES et le Commodore 64, entre autres. Ils ont vectorisé les transistors et ont fourni une émulation haut niveau de la puce, ce qui ne tient donc pas compte des délais de propagation. Le fonctionnement de ce code a été démontré de façon brillante en Javascript mais a aussi été porté en C et optimisé. Mais même avec les raccourcis qu’il utilise, les ordinateurs ne sont pas encore assez puissants pour utiliser cette implémentation dans l’émulation.
Même si j’aimerais que chaque émulateur penne en compte tous les délais de propagation de chaque transistor, en vérité, ce n’est tout simplement pas possible. Il est probable que, de notre vivant, nous ne verrons jamais du matériel capable d’émuler une Nintendo 64 à ce niveau et à une vitesse jouable.
En fait, je doute que ce soit même possible pour la Super Nintendo. Et je reconnais que, dans une certaine mesure, la puissance des ordinateurs modernes détermine à quel point les émulateurs peuvent être précis.
Le compromis que j’ai fait a été de fabriquer un design grossier similaire au vrai hardware et d’isoler proprement chaque processeur, ne partageant que les états que les vrais processeurs partageraient. Le but étant toujours de faire parfaitement correspondre les résultats de toutes les opérations avec le vrai hardware, mon approche crée au moins un système émulé qui est quasiment indiscernable du vrai matériel. Mais contrairement au DICE, ce n’est pas la retranscription numérique parfaite du design d’origine.
Mais pour la Nintendo 64 et les systèmes plus puissants, je conçois que même cette approche n’est plus de mise. Je n’ai aucune réponse aisée mais je sais que personne ne pourra, de façon réaliste, développer un émulateur qui ne peut même pas tourner à une image par seconde sur l’ordinateur le plus puissant du monde.
Conclusion
Ce qui m’inquiète est que, dans leur grande majorité, les développeurs ont peur d’utiliser ne serait-ce que la moitié de la puissance disponible dans les machines d’aujourd’hui. Les configurations minimales des plus anciens et moins précis des émulateurs deviennent le mètre-étalon pour toutes les initiatives futures.
Je ne vois pas pourquoi on devrait se priver de toute la puissance disponible aujourd’hui – et même un peu plus en prévision des machines plus puissantes qui ne manqueront pas d’arriver. Les émulateurs les plus anciens ne disparaîtront pas ; ils seront toujours là pour les personnes avec des machines plus vieilles, moins puissantes.
Pour celles et ceux qui disposent de systèmes plus puissants, donnez une chance aux émulateurs les plus précis, s’il vous plaît ! Les développeurs ont désespérément besoin d’améliorer la fidélité de leurs émulateurs et ils ont besoin d’une base d’utilisateurs qui peut les encourager à continuer.
Un grand merci à tous ceux qui nous soutiennent sur Tipeee
