Durant l'été 1997, alors que je devais m'ennuyer ferme, je me suis dit qu'il serait sympa d'écrire mon propre système d'exploitation. Après tout, pourquoi pas ? J'avais déjà développé un micro-OS sur une carte à base de Motorola 68010 pour mon projet de BTS Électronique.
Grand fan d'Atari et n'ayant absolument aucune idée du boulot titanesque que cela représentait, mon objectif était fou : porter le TOS d'Atari sur la plateforme CHRP (Common Hardware Reference Platform) d'IBM et Apple. Si Apple sortait déjà des machines PowerPC, leur architecture restait propriétaire. Le CHRP, lui, se voulait une version ouverte — un peu comme le PC — et c'était le candidat idéal pour mon projet.
Pour ceux qui ne l'ont pas connu, l'Atari ST est une machine mythique sortie en 1985. Elle embarquait un processeur Motorola 68000, un OS appelé TOS et une interface graphique nommée GEM, avec des fenêtres, des icônes et des menus déroulants — bien avant que cela ne devienne la norme. C'était la machine de toute une génération de musiciens, d'auteurs et de demomakers.
Me voilà donc parti dans ce projet complètement inutile, donc rigoureusement indispensable. Évidemment, je n'avais pas les sources du TOS. Mes seules armes ? Un livre, l'Atari Compendium (la bible des développeurs), et une dizaine d'années d'expérience sur la plateforme, principalement à coder des jeux et des démos en assembleur.
La théorie : trois étapes vers le Saint Graal
En théorie, il suffisait de réimplémenter toutes les API de la machine, divisées en deux grands blocs :
- Le BIOS/XBIOS : qui s'occupe du hardware (vidéo, son, accès disques, ports externes).
- GEM/VDI : pour l'affichage, la gestion des menus et des fenêtres.
La tâche étant colossale, j'avais planifié le projet en trois étapes intermédiaires :
- Étape 1 : Écrire un émulateur Atari partiel sur Mac (qui tournait sous MacOS 8 à l'époque). Partiel, car le but n'était pas d'émuler les coprocesseurs au cycle près, mais de faire tourner le Desktop (le "Finder" d'Atari) et les applications. L'idée était de prendre une ROM d'Atari ST et de lui faire croire qu'elle tournait sur son matériel d'origine, alors qu'elle s'exécutait au sein d'une application Mac.
- Étape 2 : Isoler une application Atari pour la faire tourner comme une application MacOS indépendante.
- Étape 3 : Écrire un noyau multitâche et tous les drivers natifs (vidéo, son, système de fichiers) pour booter directement sur le hardware CHRP. (Coucou Linux).
La dure réalité de la pratique
Je commence donc par développer l'émulateur du processeur Motorola 68000, le cœur de l'Atari. Avec dix ans d'assembleur 68k derrière moi, l'exercice est plutôt plaisant. Le CPU est relativement simple : une vingtaine de registres, 56 opcodes et une exécution séquentielle. Rien à voir avec les processeurs modernes.
D'ailleurs, Apple en avait aussi écrit un excellent pour ses PowerPC afin de faire tourner les anciennes applications Mac 68k. C'est à cette époque qu'ils ont acquis leur immense expérience des migrations d'architectures, qui s'est poursuivie plus tard avec Rosetta (PowerPC vers Intel) puis Rosetta 2 (Intel vers ARM).
Une fois mon émulateur 68k fonctionnel, je charge une ROM d'Atari ST et je commence à exécuter les instructions de boot du TOS, une par une. C’est là que la théorie s'effondre pour laisser place au monde fantastique et magique de la pratique.
Le problème des machines du début des années 90, c'est que les ROM sont viscéralement liées au hardware. Un Atari ST tourne sur le TOS 1.0, un STE sur le 1.6, un Falcon sur le 4.0... Impossible de faire tourner la ROM de l'un sur l'autre. Bien qu'il existe des API documentées, beaucoup ne sont pas publiques et le code fait constamment des accès directs aux composants physiques. Par exemple, le Desktop utilise directement des interruptions matérielles pour synchroniser l'affichage de ses menus !
Sans les sources, on passe son temps à désassembler la ROM pour comprendre ce qu'elle essaie de faire. La majorité du boulot consiste à lancer l'exécution, attendre que ça crash ou que ça boucle à l'infini, comprendre pourquoi, corriger, et recommencer. Un travail de moine bénédictin, long et fastidieux.
Le verdict de 1997 : un goût d'inachevé
Après quelques semaines de sessions intensives, le travail commence à porter ses fruits. J'arrive à charger et exécuter des applications en mode texte depuis une disquette virtuelle. Il faut dire qu'en 1990, la plupart des applications ne pesaient que quelques centaines de kilo-octets pour tenir sur des disquettes de 720 Ko (les machines n'avaient souvent que 512 Ko ou 1 Mo de RAM).
Mais le Desktop ? Malheureusement, je n'arriverai jamais à l'exécuter complètement, et encore moins à lancer des applications graphiques. En janvier 1998, je reprend mes études d'ingénieur à l'Epita et je pars sur d'autres projets; le noyau multitâche ainsi que le boot natif sur PowerPC sont rapidement oubliés. Adieu, mon rêve d'écrire un OS.
2026 : Claude entre dans la danse
Récemment, en faisant du rangement sur mes disques, je suis retombé sur les sources de ce projet, que j'avais baptisé Menhir. Problème : c'est du code écrit avec Metrowerks CodeWarrior pour MacOS 8. Impossible de le compiler sur un système moderne sans une quantité de travail décourageante.
Mais nous sommes en 2026, et nous disposons désormais d'un allié de poids : Claude. Même s'il est surtout entraîné pour le web et les langages modernes, je me suis dit qu'il devrait s'en sortir avec du C et de l'assembleur m68k. Je lui donne accès au dossier de mes sources de l'époque et lui lance un prompt plein d'espoir : « Voilà le code d'un émulateur Atari pour MacOS 8, porte-le sur macOS 26. »
Au bout de plusieurs heures (et pas mal de tâtonnements), je me retrouve avec un projet tout neuf pour Xcode qui compile et se lance... mais qui n'affiche qu'un écran noir. Il aura fallu plusieurs jours de sessions intensives, à me replonger dans mes vieilles documentations Atari pour rafraîchir mes connaissances et guider l'IA pas à pas, pour obtenir un premier résultat fonctionnel.
J'avais enfin ressuscité mon code de 1997 sur un Mac Apple Silicon moderne. Mais rappelez-vous : à l'époque, la ROM ne bootait pas jusqu'au bout. Le Desktop restait invisible. Je n'avais pas dit mon dernier mot, et Claude allait devoir reprendre du service.
Le moment où l'écran s'allume enfin
Faire compiler ce vieux code a été un marathon, mais le vrai frisson est arrivé au moment où le système d'exploitation Atari a démarré pour de bon.
Le fond gris caractéristique du bureau GEM est apparu. La barre de menus s'est affichée — « Bureau / Fichier / Visualisation / Options » —, les icônes des lecteurs de disquettes se sont posées dans le coin, et le curseur de la souris s’est mis à suivre mes mouvements.
À cet instant précis, ce n'était plus seulement du code. C'était une machine de 1985 qui reprenait vie dans une fenêtre, sur un ordinateur qu'aucun de ses concepteurs originaux n'aurait pu imaginer.
Puis sont venues les étapes qui donnent du sens au projet : cliquer sur une icône et la voir se sélectionner. Double-cliquer pour ouvrir une fenêtre et y découvrir la liste des fichiers. Dérouler un menu. Fermer une fenêtre. Chacune de ces petites victoires, qui m'avaient bloqué en 1997, a demandé des jours de travail, car derrière chaque clic se cache un enchevêtrement de mécanismes matériels que le système d'origine orchestre de façon millimétrée. Je ne vais pas détailler ici tout ce que j'ai du faire car je le réserve pour un futur article.
De vrais logiciels, trente-cinq ans plus tard
Le bug ultime n'était pas seulement d'admirer le bureau, mais de lancer les vrais programmes de l'époque. Et contre toute attente, ça a fonctionné, à peu près. Menhir fait aujourd'hui tourner 1st Word Plus, le traitement de texte mythique livré d'origine avec l'Atari ST, celui sur lequel toute une génération a tapé ses premiers textes.
Voir ces 150 kilo-octets de code de 1987 se charger, afficher leur interface entière (menus, barre de fonctions, palette de caractères) et répondre instantanément au clavier de mon Mac moderne, c'est un véritable voyage dans le temps.
Ce qu'il reste de cette aventure
Tout n'est pas parfait. Certains très vieux logiciels gèrent la souris à un niveau si bas qu'ils contournent les mécanismes standards du TOS : pour ceux-là, on peut taper au clavier, mais pas encore cliquer dans les menus. De même, les démos qui exploitaient le matériel à la microseconde près restent hors de portée, car mon émulateur n'a pas été conçu pour une telle fidélité matérielle. Ces limites sont comprises, documentées et assumées.
Mais l'essentiel est ailleurs. Il y a quelque chose de profondément satisfaisant à refermer une boucle ouverte il y a près de trente ans. Le code n'avait pas disparu ; il attendait simplement la bonne machine, la bonne technologie, et un peu de patience pour reconstruire le pont entre deux époques.
Cependant, soyons honnêtes : même si voir cet émulateur tourner aujourd'hui est une magnifique victoire personnelle, ce n'était pas du tout l'objectif initial de l'été 1997. Mon but ultime était de développer un tout nouvel OS moderne, capable de faire tourner nativement les anciennes applications Atari. Aujourd'hui, un tel projet n'aurait plus aucun sens technologique. Et de toute façon, ce rêve existe déjà dans le monde réel : d'autres développeurs passionnés s'en sont chargés bien avant moi, à travers l'excellent projet open-source FreeMiNT.
Menhir n'aura donc été qu'un détour nostalgique, mais quel voyage !
Menhir est un projet personnel. L'émulateur, les images système et les logiciels d'époque restent la propriété de leurs auteurs respectifs.