CHRONIQUE : Les Polygones d’Another World sur Atari Jaguar

Des cartouches d'Another World sur Jaguar en pagaille

Préface du rédacteur en chef (Guillaume Verdin) : Après un article sur le marché européen du jeu vidéo dans les années 1980, sseb22 nous propose un sujet très différent et même inhabituel. Il s’agit à la fois d’un making of du portage homebrew d’Another World (1991) sur Jaguar, mais doublé d’une étude du fonctionnement de la console d’Atari et de la conception du classique de notre membre d’honneur Éric Chahi. Comme on l’expliquait encore récemment en évoquant le développement d’une version PC Engine, le jeu a la particularité d’avoir été programmé sous la forme d’une machine virtuelle potentiellement plus simple à adapter à diverses plateformes. Mais d’un autre côté, la console de conception britannique est tristement célèbre pour présenter l’une des architectures les plus complexes et difficiles à dompter pour les créateurs de jeux… Et si vous vous demandez pourquoi il a fallu traduire un article abordant une initiative française, c’est qu’il a été écrit par Fabien Sanglard, lui-même un Français mais expatrié au Canada, et cette sommité dans le développement écrit uniquement en anglais ! Merci à lui de nous avoir autorisé à le traduire.


Les polygones d’Another World : Atari Jaguar

Par Fabien Sanglard, publié sur son blog le 13 mars 2020
Traduit de l’anglais par sseb22

Cet article fait partie d’une étude de cas des portages d’Another World. Il est recommandé de lire « Another World 101 » (NdT : en anglais) auparavant.

Le logo de l'Atari Jaguar

L’Atari Jaguar

Le développement de la Jaguar a débuté en 1990 lorsqu’Atari engage la société Flare Technology, basée à Cambridge, pour concevoir non pas seulement une mais deux nouvelles machines de jeu en même temps. Le projet inclut un système 32 bits de quatrième génération appelé Panther et la Jaguar, un audacieux projet 64 bits.

Trois ans plus tard, comme le projet Jaguar est en avance de phase, Atari décide d’abandonner la Panther et sort sa machine 64 bits en novembre 1993.

Martin Brennan, Ben Cheese et John Mathieson de Flare Technology avaient des idées très arrêtées sur le sujet et ont opéré des choix de design en ce sens. En plus d’une manette à dix-huit boutons, la machine n’avait pas moins de cinq processeurs avec lesquels il fallait jongler.

La publicité audacieuse clamant « Do the Math! » (« Faîtes le calcul ! ») pour leur 64 bits attira surtout des suspicions de la part des potentiels acheteurs. Quelle que soit la façon par laquelle John Mathieson essayait de l’expliquer dans les interviews, la console donnait l’impression que le département marketing tentait d’induire les clients en erreur. La façon dont Atari avait pu réussir à fabriquer quelque chose qui avait quatre fois la puissance des 16 bits de Nintendo et SEGA n’était en effet pas claire.

Des acheteurs prudents d’un côté rejoignaient des développeurs de jeux incrédules de l’autre. L’architecture autour de cinq processeurs était puissante mais très inhabituelle pour des gens habitués à coder pour une seule puce. Développer sur Jaguar était tout un art et peu de programmeurs prirent le temps de la maîtriser.

La ludothèque limitée au lancement empêcha la formation d’une masse critique de clients. Les faibles ventes refroidirent les développeurs et les éditeurs d’investir du temps et de l’argent dans la Jaguar ce qui, à son tour, eut un impact sur les ventes. Durant sa durée de vie de trois ans, Atari vendit environ 120 000 Jaguar.

Photo : Wikipédia

L’architecture

Les concepteurs de la Jaguar sont partis de l’architecture traditionnelle dans laquelle un CPU est le chef d’orchestre des puces audio et graphique qui ont un pipeline d’instructions fixe tout comme c’était déjà le cas avec la Super Nintendo et la Mega Drive.

Si dans ses entrailles, on trouve un Motorola 68000 comme dans l’Atari ST, l’Amiga et la Mega Drive (encore qu’ici, il est cadencé à 13,295 MHz) et un moteur de sprites (appelé OBJECT), il y a aussi deux processeurs RISC 32 bits à 26,59 MHz qui ont été nommés TOM et JERRY.

Selon la documentation (excellente), TOM tient lieu de processeur graphique tandis que JERRY, grâce à une quantité plus généreuse de SRAM, est taillé pour s’occuper de l’audio.

Ces deux processeurs peuvent exécuter des instructions provenant de la DRAM générale mais cela aurait monopolisé le bus de données. Pour atteindre un flux maximal, les données et les instructions alimentaient chaque processeur via sa SRAM propre (appelée scratch-pad).

Mais cette séparation des tâches n’était qu’une possibilité. Les deux processeurs pouvaient être utilisés pour les graphismes comme c’est le cas dans la version Jaguar de DOOM. La seule spécificité est alors que seul JERRY est connecté à l’adaptateur réseau.

John Mathieson donna de nombreuses interviews dans lesquelles il décrit les contraintes qu’ils avaient pour le choix des composants de la Jaguar et sa vision de la machine :

Atari voulait vraiment utiliser une puce de la famille des 68K et nous avons examiné plusieurs de ses membres. Nous avons d’ailleurs construit quelques prototypes avec un 68030 lors des premières phases bêta et, pour un temps, nous pensions utiliser un 68020. Cependant, cela s’est révélé trop cher. Nous avons également considéré de n’utiliser aucune puce du tout [de la famille des Motorola 680×0]. J’ai toujours pensé qu’il était important d’avoir un processeur standard pour donner aux développeurs un sentiment d’accueil chaleureux lorsqu’ils débutent. Le 68000 est peu onéreux et fait bien le job.

John Mathieson

Le 68000 est peut-être le CPU dans le sens où il est au centre des opérations [NDT : Le « C » de « CPU » veut dire « central »], il amorce la machine et permet de démarrer tout ce qui se passe ensuite ; cependant, il n’est pas au centre de la puissance de la Jaguar… Le 68000 est comme un manager qui n’exécute pas de travail opérationnel mais dit à tout le monde quoi faire. Je persiste à dire qu’il n’est là que pour lire les inputs des joysticks.

John Mathieson

Pour un programmeur prêt à retrousser ses manches, la machine était un rêve. Ceci étant dit, elle possédait quelques problèmes.

Le Blitter pouvait faire du texture mapping basique de lignes horizontales et verticales mais, comme il n’y a pas de mémoire cache, chaque pixel engendrait deux ratés dans la pagination de la RAM et n’utilisait qu’un quart du bus 64 bits. En ajoutant deux tampons 64 bits, cela aurait facilement tripler les performances en texture mapping. C’est dommage.

Le 68000 était lent. Là se trouvait le principal problème de la machine. Vous aviez deux options : soit vous y alliez à la cool en faisant faire tous les calculs par le 68000 et c’était lent, soit vous vous preniez la tête avec plein de bouts de code ASM parallélisés [NDT : Assembleur, langage de bas niveau, compliqué mais avec les meilleures performances] pour faire en sorte que ça aille vite avec les processeurs RISC.

C’est pour ça que la PlayStation était si cool pour le développement : elle était programmée comme un processeur unique en série avec un seul accélérateur rapide.

Si la Jaguar avait laissé tomber le 68000, avait pu offrir un cache dynamique sur les processeurs RISC et avait eu un peu de mémoire cache pour le Blitter, elle aurait pu raisonnablement concurrencer la machine de Sony.

John Carmack (slashdot.org)

Sébastien Briais qui a codé la version Jaguar d’Another World a aussi mentionné les difficultés pour apprivoiser le félin.

Programmer le Blitter sur Jaguar, c’est tout un art car il faut naviguer à travers des comportements subtils non documentés et des bugs.

Sébastien Briais

Une machine 64 bits, 32 bits ou 16 bits ?

Quant à l’affirmation qui a repoussé tant de clients (dont l’auteur de ces lignes) que la Jaguar est une console 64 bits, est-ce vrai ?

La machine est un méli-mélo de « bititude ». En interne, le 68000 travaille en 32 bits avec un bus en 16 bits alors que les processeurs RISC sont des puces 100% 32 bits, avec un bus 64 bits. Le processeur OBJECT travaille en interne en 64 bits avec un bus de données 64 bits. Il n’était donc pas techniquement incorrect de la qualifier de 64 bits.

La Jaguar a une interface mémoire en 64 bits afin d’avoir une grosse bande passante vers de la DRAM pas chère. Là où l’architecture nécessite d’être en 64 bits, elle est en 64 bits. Ainsi, le processeur OBJECT, qui récupère des données de la DRAM et s’occupe de l’affichage est en 64 bits ; et le Blitter, qui génère tout le rendu 3D, l’effacement de l’écran et le « pixel shuffling » [NDT : technique efficace permettant d’afficher le bon sous-pixel au bon endroit] est en 64 bits.

Là où l’architecture n’a pas besoin d’être en 64 bits, elle ne l’est pas.

Une console de jeux n’a aucun besoin d’un adressage en 64 bits ! En général, les calculs 3D et le processeur audio n’utilisent pas de nombres en 64 bits, c’est pourquoi il n’y aurait aucun avantage d’utiliser des processeurs 64 bits pour ça.

John Mathieson

C’était toutefois un choix risqué qui a fini par renforcer la suspicion vis-à-vis d’une machine au prix élevé, à la manette étrange, et avec peu de jeux au lancement.

L’architecture vidéo

JERRY est un composant assez facile à appréhender. Il s’agit d’une puce RISC 32 bits connectée à 8 Kio [NdT : alors que « K » est le symbole pour « kilo » soit « 1000 fois », « Ki » est celui de « kibi » soit « 1024 fois ». Ainsi, les outils pour éviter la confusion existent] de RAM et à un DSP.

Par contre, TOM est un véritable monstre. Son espace colorimétrique, c’était du jamais vu. Pour comprendre comment il fonctionne, il faut s’imaginer un cube, donc en 3D, avec les couleurs RVB dont on aurait aplati les trois faces lumineuses pour en faire un carré, donc en 2D. Un point dans ce carré est repéré par des coordonnées X et Y encodées sur un octet, résultant en 256 couleurs.

Ensuite, on ajoute un octet pour contrôler l’intensité de la luminosité [NdT : « darkness » dans le schéma ci-dessous]. Cela donne donc 256 teintes de 256 couleurs = 65 536 couleurs. C’est un espace colorimétrique si étrange qu’il ne peut pas être représenté précisément avec les moniteurs sRGB d’aujourd’hui.

Au cœur du système vidéo se trouve le processeur OBJECT, le composant qui génère le signal vidéo pour l’envoyer vers la TV. C’est un moteur de sprites qui récupère en entrée ce dont il va faire le rendu via des valeurs 64 bits appelées « phrases ». Cinq types de commandes sont disponibles. Il a la capacité assez cool de réduire ou agrandir (scaling) les sprites sans impact sur les performances. C’est une puce polyvalente qui accepte comme source des sprites 16 bits « CRY », 24 bits « true color » mais aussi à partir de palettes (appelées « CLUT ») avec des index sur 1, 2, 4 ou 8 bits.

Enfin, on trouve aussi le GPU 32 bits et sa RAM dédiée de 2 kio connecté à un Blitter. Le GPU possède des instructions spéciales manipulation de matrices simili 3D. Son but est principalement de piloter le Blitter afin qu’il fasse les rendus de lignes de pixels. Il a également la capacité de demander au Blitter d’effectuer du Gouraud shading sur une ligne ou d’effectuer des tests de position en profondeur (mais cela affaiblit sans aucun doute les performances de lire la DRAM). Le GPU est entièrement programmable et n’a pas pipeline fixe.

Bonne en 2D et bonne en 3D

Avec TOM, Atari a pris de nombreuses bonnes décisions. La machine est, en théorie, capable d’exceller à la fois en 2D et en 3D car le moteur de sprites n’as pas de limite en termes de dimensions de sprites.

Un jeu en 2D pouvait avoir autant de sprites que nécessaires tout en étant d’une taille arbitraire. Ses capacités en scaling étaient puissantes et amplement utilisées dans NBA Jam: Tournament Edition et des FPS comme DOOM.

Un jeu nécessitant un accès direct à la mémoire tampon, comme un jeu en 3D, pouvait le faire. Il réserve une zone de la DRAM, écrit directement dedans et le processeur OBJECT le traite comme un seul sprite gigantesque.

Another World sur Jaguar : le commencement

La jaquette d'Another World sur Jaguar

Depuis la sortie de sa 2600, les machines d’Atari ont toujours été appréciées en France. Avec la sortie de l’Atari ST, l’appréciation s’est transformée en amour.

Étant donné les défauts techniques de l’Atari ST, il est difficile de comprendre comment cette machine a pu recevoir un tel soutien. C’est d’autant plus surprenant quand on le compare à son principal concurrent qu’est l’Amiga [NdT : en plus des raisons citées plus bas, le prix a dû jouer un rôle non négligeable]. Nous avons déjà discuté de cela dans cette série. Ce qu’il faut en retenir est que, au mitan des années 1990, Atari avait réussi à rallier des légions de jeunes adultes européens derrière ses produits.

Il y avait des magazines dédiés à 100% à Atari comme ST Magazine, publié de 1985 à 2010. Les demomakers étudiaient avec acharnement la machine. Ils ont fini par atteindre une connaissance si approfondie de GLUE, le générateur de signal vidéo, qu’ils ont réussi à enlever les bandes noires autour de l’écran. Ces techniques, connues sous les noms de « overscan » ou « plein écran » furent perfectionnées jusqu’en 2005, date à laquelle l’intégralité des bordures a pu être retirée.

Quand la passion est si intense, il n’est pas surprenant qu’elle résiste au passage du temps. Encore moins quand la machine est un monstre de puissance comme la Jaguar, un produit sorti au moment du pic de popularité de l’Atari-mania.

Le groupe français Jagware avait l’habitude de rassembler les aficionados de la console. Et alors que le mouvement des Ataristes prenait de l’ampleur, tout ce qui concernait Atari a été fusionné pour donner naissance à l’Atari Association (AC). La première convention a été tenue en 2005 et a continué jusqu’en 2016 [NdR : l’AC, organisée chaque année par l’association RGC, existe toujours].

L’histoire d’Another World sur la Jaguar d’Atari commença à l’AC 2007, une manifestation qui eut lieu à Congis-sur-Thérouanne. Il se trouve qu’Éric Chahi y assistait ainsi que Sébastien Briais, membre du groupe The Removers. Tous les deux fans d’Atari, il commencèrent à discuter des circonstances empêchant Another World d’être porté sur Jaguar. Et comment remédier à la situation.

Les organisateurs de l’événement me présentèrent à The Removers [le groupe de codeurs de Briais]. Ils m’ont demandé s’il était possible de porter Another World sur Jaguar. J’ai été impressionné par leur talent de codeurs sur cette machine. Ces mecs avaient l’air fous donc j’ai tout de suite dit oui.

Éric Chahi, interview pour venturebeat.com

Ensuite, Éric envoya le code source pour Atari et Amiga à Sébastien et les autorisa à travailler sur le portage.

Recréer la chaîne de compilation de la Jaguar

Pour travailler sur ce projet, Sébastien dut construire une suite d’outils. Le prototypage fut fait en C sur ArchLinux sans audio puis des routines furent converties pour le 68000 ou RISC en fonction des besoins de puissance CPU. Pour l’implémentation sur du vrai matériel, Sébastien utilisa une Skunkboard qui est une cartouche avec du stockage en flash, inscriptible via un connecteur USB.

Ci-dessus, une PCB (ou circuit imprimé) de Skunkboard. Les connecteurs inférieurs sont destinés au port cartouche de la Jaguar. Les emplacements U1, U2 et U3 accueillent la flash et J3, le module de communication USB

L’assembleur utilisé était MadMac, écrit originellement chez Atari afin de répondre à leurs besoins de haute performance pour leur travail et qui fut l’outil distribué officiellement avec le SDK de la Jaguar. Il a l’avantage d’être compatible à la fois avec le 68000 et le RISC du couple TOM/JERRY.

Pour le linker, ALN (Atari Linker), qui fait aussi partie du SDK original, a été utilisé un temps mais a ensuite été remplacé en faveur du jilinker de Seb. MadMac et ALN sont tous les deux des outils 32 bits fermés au format « a.out ». Pour faire en sorte d’exécuter les fichiers binaires vieux de 27 ans, un module spécial de « a.out » est nécessaire.

Pour le compilateur C, Sébastien s’appuya sur le travail de Vincent Rivière permettant de gérer la maintenance de deux packages d’utilitaires binaires et de gcc [NdT : un compilateur C] sortant des instructions pour le processeur 68000.

Enfin, pour générer des images CLUT, un outil appelé jconverter fut codé.

Another World sur Atari Jaguar

En possession du code source, Sébastien aurait pu faire un travail rapide en utilisant la version Atari ST qui est entièrement en assembleur 68000. Mais il avait un plan bien plus peaufiné en tête.

Je me suis dit que j’allais exécuter une grande partie de la VM [NdT : la machine virtuelle] sur le 68000. La puce est suffisamment puissante pour la faire tourner sans problème mais, pour m’amuser un peu, j’ai écrit un compilateur JIT qui convertit des fonctions bytecode en fonctions 68000 à la volée.

J’ai optimisé les routines traçant les polygones pour qu’elles fonctionnent sur le GPU. La VM lit le bytecode et, quand c’est un code opération de dessin, il extrait les paramètres du bytecode (baseSprite, index, x, y et échelle) et les écrit dans la SRAM de TOM où une routine spéciale s’occupe du rendu.

En gros, le GPU pilote le Blitter pour qu’il rende les polygones en lignes de pixels. L’appel à la routine GPU n’est pas totalement bloquante, il retourne juste après le dernier appel au Blitter pour dessiner une ligne. Ainsi, une partie du dessin peut avoir lieu alors que l’interprétation du bytecode reprend sur le 68000.

Le processeur OBJECT (le moteur de sprites) n’a presque rien à faire à part dessiner un énorme sprite brut fait à partir de tout le framebuffer [NdT : la mémoire tampon qui stocke l’image qui doit être affichée à l’écran en attendant qu’elle soit entièrement rendue].

Quant au format de pixel, même si le jeu original utilise seulement 16 couleurs, une palette de couleurs CLUT avec 4 bits par pixel [NdT : soit 16 couleurs par pixel] n’a jamais été envisagé car je voulais utiliser les décors de fond remasterisés en 256 couleurs. J’ai donc utilisé un codage de couleurs en 8 bits par pixel et je l’aurais fait même s’il n’y avait pas eu ces décors de fond car utiliser un codage en 4 bits par pixel complique les choses pour peu de gain. Mais surtout, j’ai été traumatisé par l’Atari ST qui utilise un codage en 4 bits et c’était la galère à gérer.

Pour la musique et les effets sonores, j’ai décidé de reprendre les routines de haut niveau faites pour le 68000 de l’Amiga et j’ai écrit un émulateur de Paula [NdT : chipset sonore de l’Amiga] qui tourne sur JERRY et discute avec le DSP.

Sébastien Briais

La refonte des décors

Avoir obtenu la collaboration d’Éric Chahi a permis à Sébastien d’utiliser les nouveaux décors de fond d’une définition de 1152×720 en 256 couleurs réalisés pour Another World 20th Anniversary Edition (2013).

La version originelle d’Another World faisait un rendu des décors de fond via une série de polygones encodés dans le bytecode. Vers la fin du développement, la fatigue aidant, le code opération #25 (0x19 LOADRES) fut introduit pour charger un bitmap directement depuis les ressources dans le framebuffer 0.

L’Anniversary Edition fait toujours un rendu des décors de fond avec des polygones mais ajoute ce bout de code 0x19 de l’angoisse à la fin pour écrire par-dessus tous les décors de fond. Cette astuce permet aux joueurs d’alterner entre les rendus « classique » et « remasterisé » de façon fluide.

L’édition anniversaire n’était cependant pas la première à avoir des décors remasterisés. La version 3DO a été le premier portage à le faire mais les artistes avaient fait des choix beaucoup plus radicaux en termes de température de couleurs et de formes alors que l’édition anniversaire tente de se rapprocher de l’original en matière de tons.

Malheureusement, la capacité de 4 Mio (*) de la cartouche était trop petite pour stocker 94 décors de fond en 1152×720.

Même après avoir baissé la définition des décors de fond à 320×200, le jeu ne tenait toujours pas dans 4 Mio. Pour résoudre ce problème, je les ai compressés. Le SDK de la Jaguar bénéficiait de la gestion en interne de compression sans perte appelée BPEG mais l’outil fourni par Atari (tga2jagpeg) avait le même problème que l’assembleur et le loader (code source propriétaire et un format « a.out ») et je n’ai pas voulu m’embêter à chercher plus loin.

J’ai utilisé à la place l’algorithme LZ77 et implémenté ma propre routine dans le GPU pour décompresser les décors à la volée. Cela a permis de ramener la taille des décors de 6 Mio à 4 Mio (code inclus). Les performances étaient bonnes sauf pour la scène de l’ascenseur dans la prison dans laquelle il y a du scrolling. J’ai donc dû garder celui-ci non compressé.

Sébastien Briais

Performances

L’implémentation de la VM avec TOM et JERRY permettait sans aucun souci d’atteindre la vitesse maximale de 25 Hz du jeu.

Le jeu tourne bien sur Jaguar. Après le lancement du jeu, j’ai réalisé que j’avais encore assez de vitesse pour implémenter une version en 640×480. Je voulais me lancer un défi en apprenant le fonctionnement d’entrelacement des images. Ça a été plus facile que prévu, si on ne prend pas en compte le sur-échantillonnage des décors de fond. Peut-être qu’un jour je sortirai cette version.

Sébastien Briais

En fait, le jeu tourne si vite que c’en est devenu un problème.

La VM a un registre mémoire spécial pour indiquer combien de temps l’image doit être affichée mais il n’a pas été prévu pour des scènes graphiquement lourdes comme quand le tank entre dans l’arène. J’imagine que l’Amiga et l’Atari ST avaient tant de mal avec ce genre de scènes que ce registre n’était pas nécessaire.

J’ai dû ajouter manuellement des délais çà et là pour ralentir le jeu dans ces moments.

Sébastien Briais

Le Tour de France

Les Removers (*) ne se sont pas arrêtés à faire une version ROM du jeu. Ils voulaient produire un jeu comme à l’époque, avec une cartouche, un manuel et une boîte. Une tâche loin d’être aisée.

Pour fabriquer la cartouche, j’ai eu de l’aide de deux amis férus d’électronique (SCPCD et Zerosquare). Ils ont fabriqué une PCB qui utilise des composants modernes (de la Flash au lieu d’une EEPROM). Ils l’ont appelée Jagtopus (*). Nous avons fait faire un premier lot test de PCB en Allemagne mais nous n’étions pas satisfaits de la qualité. Nous avons fini par trouver ce dont on avait besoin avec Tom-IC en Suisse.

Pour la coque plastique de la cartouche, nous avons acheté des surplus de stock à Best Electronics puis à B&C.

Pour le boîtier, j’ai lancé Inkscape [NdT : un éditeur de dessin vectoriel libre et gratuit] et j’ai imité l’aspect des jeux Jaguar de cette époque (avec les captures d’écran à coins arrondis). Je suis allé à Paris faire le tour des imprimeurs. La plupart d’entre eux m’a regardé avec un air bizarre lorsque j’ai parlé du projet. J’ai fini par en trouver un qui voulait bien essayer mais il ne travaillait pas à la demande. Nous devions commander des lors d’au moins mille boîtiers. Après plus amples recherches, nous avons trouvé une société à Toulouse qui non seulement voulait bien imprimer mais aussi effectuer la découpe.


(*) Le nom « Jagtopus » est un mot-valise entre « Jagware » et « Octopussy » (une private joke des forums Jagware).

Sébastien Briais
La jaquette dépliée d'Another World sur Jaguar
Sébastien Briais a conçu le boîtier avec Inkscape. Inkscape déchire.

Chaque boîtier est fabriqué à la main. Un patron 2D à plat est plié avant d’être assemblé pour former le boîtier 3D.

Enfin, j’ai utilisé LaTeX pour le manuel puisque c’est le logiciel que je connais le mieux. Les manuels ont été imprimés à Orléans.

La partie la plus difficile est l’écriture de la ROM dans la cartouche ! C’est un procédé fastidieux qu’il faut faire cartouche par cartouche. Il faut une Jaguar spéciale avec un BIOS pour développeurs appelé BJL. On connecte la Jaguar via son port manette à un port parallèle d’un PC. On insère une cartouche vierge et on commence à uploader la ROM depuis le PC.

Sébastien Briais

La protection anti-copie qui veut la mort des consoles 3DO

Les cartouches de l’Atari 2600 n’avaient pas de protection anti-copie. Cette opportunité fut largement exploitée par les pirates durant les années 1980. Atari résolut ce problème en utilisant un mécanisme d’authentification asymétrique RSA sur la 7800, la Lynx et la Jaguar, comme l’a expliqué en détail TursiLion.

Les cartouches de la Jaguar d’Atari démarrent avec un header de boot crypté décomposé en blocs de 65 octets. Chaque bloc est crypté avec une clé de 520 bits (je me demande si cela ne viole d’ailleurs pas certaines restrictions d’export des années 1990…) […].

Le code est décrypté dans le GPU où il est alors exécuté. Le code fait un hachage MD5 sur la cartouche, le compare à celui qui est implémenté dans la console et, si tout va bien, il écrit la valeur magique 0x03DODEAD dans la première adresse de la RAM du GPU et s’arrête.

En d’autres termes, lorsqu’un studio s’apprêtait à lancer son jeu, il devait envoyer leur master à Atari. En utilisant leur clé privée bien gardée, Atari générait un code signé (le programme RISC et la valeur MD5) et renvoyait le tout au studio. Ce programme signé devait alors être inscrit dans la cartouche. Les consoles possédaient la clé publique et pouvaient lancer le code et comparer le MD5 généré avec le MD5 signé pour valider le jeu.

Quand Atari coula, la précieuse clé privée fut supposément perdue. Ce fut un coup pour la communauté homebrew. Pour la sortie de Battlesphere en 2000, les développeurs ont pris un boot RISC signé déjà existant et ont modifié les données du jeu jusqu’à obtenir une collision MD5 (une collision ici est une situation dans laquelle deux jeux de données différentes génèrent le même résultat après hachage. C’est une situation à éviter pour un hachage cryptographique comme MD5. Mais ici, elle permet de retrouver la clé).

Et même si Hasbro a renoncé à ses droits sur la Jaguar en 1999, ils ne savaient absolument pas où était la clé privée et n’ont pas cherché à la retrouver. Heureusement pour Another World, elle fut « retrouvée » et publiée par atarimuseum.com le 12 novembre 2003. La communauté homebrew se chargea de mettre rapidement au point un programme signé capable d’inscrire « 3DODEAD » quel que soit le programme, ouvrant ainsi la voie à une potentielle infinité de jeux et à la Skunkboard mentionnée plus haut.

Souvenirs

L’une des questions que je préfère poser dans les interviews concerne les bugs intéressants rencontrés lors du développement. Sébastien en a eu un très bon.

Il y a un bug qui m’a pris du temps à comprendre.

Alors que je testais le jeu, Lester se retrouvait coincé devant une de ces portes automatiques dans la base. La porte ne voulait tout simplement pas s’ouvrir.

Après de nombreuses recherches dans le code de la VM, j’ai découvert que j’avais implémenté un décalage binaire vers la droite en utilisant une variable signée, ce qui chamboulait la séquence de bits sur la gauche en insérant des « 1 » non désirés. La solution fut d’utiliser un entier non signé.

Les bugs sont assez difficiles à trouver sur Jaguar car il n’y a pas de debugger (d’où la valeur du prototype Linux).

Sébastien Briais

Quant à la plus difficile partie de l’aventure, voici sa réponse :

Le plus difficile, c’est le manque de documentation. Le manuel d’Atari peut être parfois énigmatique et certains tutoriels en ligne ne sont pas fiables.

Comprendre comment faire une rotation avec le Blitter n’a pas été facile. Il semblerait qu’il y ait aussi un moyen de l’utiliser pour faire de la détection de collisions, mais je n’ai jamais trouvé comment faire.

Il y a des subtilités à connaître comme, par exemple, le fait que le processeur OBJECT peut modifier la liste des objets lors de sa lecture. Ou que le scoreboarding a des bugs comme celui qui empêche la lecture d’un registre juste après son écriture (il faut alors insérer quelques instructions NOOP [NdT : « No-Op » ou « No Operation » est une instruction en assembleur demandant à l’ordinateur… de ne rien faire. Ici, donc, pour une question de timing]).

C’est pourquoi j’ai publié les sources du code de ma librairie rmvlib, pour aider d’autres programmeurs à mieux comprendre la machine. L’émulateur Paula en RISC, le moteur de rendu de polygones et le gestionnaire de sprites sont tous inclus dedans et concentre beaucoup de ce que j’ai appris sur la Jaguar.

Sébastien Briais

L’envoi du jeu

Débuté en 2006, ce projet de cœur des Removers aura pris sept ans à voir le jour, en 2013. Le résultat est un titre à la qualité professionnelle, sans aucun doute l’un des meilleurs disponibles sur la machine.

Le contenu de la boîte d'Another World sur Jaguar

Nous avons produit un peu plus de deux cents exemplaires en 2013. Puis, étant donné le succès et la demande, nous en avons fait faire autant pour la deuxième fournée.

En ce moment, nous sommes en rupture de stock mais vous pouvez manifester votre intérêt sur la liste d’attente des Removers et nous pourrions peut-être produire un nouveau lot [NdR : il y a finalement eu une une troisième série en 2022].

Sébastien Briais

Si vous ne possédez pas de Jaguar ou d’émulateur pour y jouer, Jatty Virdee a enregistré une superbe session de jeu sur un aussi superbe moniteur Sony PVM Trinitron (hébergée ici avec son autorisation) :

Épilogue

Ayant étudié la plateforme en profondeur et ayant été témoin de la qualité de ce portage, j’ai vraiment commencé à apprécier la Jaguar. J’en suis venu à me demander à quel point Atari était proche d’un succès.

Si la console avait pu bénéficier de plus de jeux de qualité comme Another World ou DOOM, je suis convaincu que les joueurs auraient pu passer outre le prix, la manette et peut-être même la tristement célèbre affirmation des 64 bits.

J’en suis arrivé à la conclusion que le problème de la Jaguar fut la difficulté plus grande que la moyenne de développer de bons jeux. Les studios n’avaient pas le temps de confectionner des instructions RISC et de naviguer à travers les bugs. Quel dommage.

Remerciements
Merci à Sébastien Briais et Grégory Montoir qui ont mis à profit leur savoir pour cet article.

Un grand merci à tous ceux qui nous soutiennent sur Tipeee

Lien Permanent pour cet article : https://mag.mo5.com/236972/chronique-les-polygones-danother-world-sur-atari-jaguar/