Souvenirs de l'un des développeurs du ST - Page 2

Mes souvenirs du projet ST sont diffus et biaisés mais voici ce dont je me souviens, au commencement en juillet 1984. Il y a de nombreux détails qui manquent; je me souviens principalement des morceaux sur lesquels j'ai trvaillé, mais les autres drilles du projet se souviendront probablement d'autres choses ou de choses contradictoires. Excusez par avance mes oublis; ça ne date pas d'hier.

[ul]
[li]Juillet : Les Tramiels achètent Atari et regroupent les gens qu'ils ne virent pas dans un unique bâtiment. Le plan "ST" est annoncé mais personne ne sait grand chose.[/li]
[li]Aout : Le hardware du ST commence à se poser, on étudie les autres os, toussa[/li]
[li]Septembre : En plus de la sortie du CPC64, le travail démarrer à Montery, à proximité du campus Digital Research[/li]
[li]Octobre : Travail, on emménage dans des maisons de location à Montery[/li]
[li]Novembre : Plus de travail. On ne voit plus trop ces maisons[/li]
[li]Décembre : Encore plus de travail. On fait démarrer un ST avec un TOS pour la première fois[/li]
[li]Janvier : CES (avec des STs sur CP/M-68k). Le choix est fait de prendre un nouveau système de fichiers(GEMDOS)[/li]
[li]Février : Les ROMs de boot de 16k sont écrites (au cout d'un effort de deux semaines)[/li]
[li]Mars : Toujours plus de travail. Deux semaines pour écraser TOS et le faire tenir dans 192k[/li]
[li]Avril : les ROMs fonctionnent (vous savez combien de temps ça prend de graver une rom de 192k, sans compter l'effaçage aux UVs ?[/li]
[li]Mai : Michael Jackson enregistre We Are The World avec de nombreux autres artistes Le TOS 1.0 sur ROM est expédié, pfiou.[/li]
[/ul]

Bon, voilà d'autres détails...
[HR]
L'autre ingénieur me criait "Si tu es patient avec moi, je serai patient avec toi".

Il est sorti en piétinant de son bureau. Pas son vrai bureau, celui vers lequel il aurait aimé aller piétiner. Son vrai bureau était dans le nirvanan du Digital Reserarch, dans les bâtiments qu'il nous était interdit de visiter. A la place, il devait se contenter de trainer du pied en sortant de son bureau pourri dans le bâtiment où il avait été relogé temporairement, où il était obligé de travailer avec.... nous. Les arrivistes de chez Atari. Les bidouilleurs de la vallée de cinglés qui voulaient juste matière à travailler.

On est restés dans le bâtiment satellite au campus de la DRI pendant plusieurs mois. Le premiers prototypes allaient peut être arriver dans un mois (mais à ce moment là on ne savait pas quand). La tension pour parvenir à faire fonctionner quelque chose était intense, et la vérité sur la raison pour laquelle nous avions racheté DRI devenait claire : le logiciel n'était pas techniquement propre, et le faire fonctionner sur le matériel Atari ne se résumait pas à faire un simple protage parce qu'une bonne partie de GEM n'était simplement pas finie

En théroie, on peut écrire du code très portable en C. Tant que vous respectez certaines règles et que vous avez un degré suffisant de paranoïa dans votre travail, vous avez de bonnes chance d'obtenir du code qui puisse tourner sur différentes plateformes avec un minimum d'effort. La meilleur solution étant d'avoir du code qui tourne, dès le premier jour, sur différentes architectures utilisant des compilateurs différents. DRI n'a pas fait ça avec tout et ça résultait en des problèmes allant de la simple erreur remontée par le compilateur qu'il était rapide à corriger à des situations qui nécessitaient de ré-étudier le design si on l'exécutait sur autre chose qu'un 8086. C'était lent, frustrant et source de frictions. Et un peu de hurlements aussi.

C'est une bien piètre description des relations DRI / Atari. Souvent, les choses fonctionnaient. Certains employés de DRI étaient sympas et c'était cool de bosser avec eux. Mais nous avons tous nos défauts. Là où le plus mauvais des ingénieurs de DRI pensaient qu'ils étaient des dieux en programmation qui ne pouvaient pas pondre une ligne de code erronnée, alors le pire des ingénieur Atari était un enfoiré d'arriviste qui voulait juste de quoi bosser. Parfois les choses s'arrangeaient, parfois on était comme des scorpions dans une bouteille.(je ne vois pas trop d'expression équivalent en FR)

Je ne me souviens plus à quel occasion la dispute au sujet de la "patience" avait éclaté. L'autre ingénieur avait raison, ou j'avais raison, ou peut être avions nous tort tous les deux. Une heure plus tard, on s'excusais chacun envers l'autre et on s'asseyais pour simplement faire le taf. Mais quelques années plus tard, longtemps après que nous soyons revneus dans les bureaux d'Atari à Synnyvale, on se souvenait cette dispute pendant nos blagues du déjeuner.
[HR]
La partie ATARI de l'équipe logicielle ST se sépara en 6 petites groupes :

Graphismes. Deux ou trois mec prirent la couche graphique spécifiée par DRI et écrivirent le rendu des polices, les copies de bloc, tracé de lignes et autres primitives. De mon point de vue, c'est eux qui s'amusaient le plus, et vu qu'ils étaient des programmeurs de jeux vidéos (oui, techniquement parlant c'étaient des exprogrammeurs de jeux vidéos à ce moment là) ils avaient des débats d'architecture sur la validité des abstractions graphiques décidées par DRI. Les primitives du ST avaient des extensions très intéressants, et GEM n'utilisait qu'une petite partie de ce qui était disponible.

PortageFaire que GEM fonctionne. Deux ou trois autres de nos personnes aidaient à faire fonctionner GEM sur 68000. Ca ne se limitait pas à "compiler, débugger, nettoyer, recommencer", vu que GEM n'était pas vraiment fini. Ces gars travaillaient en relation vraiment étroite avec les ingénieurs DRI chaque jour, et c'étaient probablement les plus frustrés de nous tous.

BIOS(drivers) et OS(deux personnes, dont moi). Une mise en place simple des systèmes. Beaucoup de taf, mais rarement passionnant.

Infrastructure. Dispute sur la réalisations, la gestion des sources, le foutoir et de brèves observations au sujet de la nature de l'humanité au vu de son utilisation des ordinateurs et tout particulièrement, les mauvaises habitudes dans le code source. On n'utilisait pas de contrôle des sources. Je ne suis même pas sûr que nous faisions des diffs. Le plus souvent on avait quelques dossiers pleins de fichiers source qui seraient compilés par un gars qui saurait s'y prendre. Rustique, mais ça marchait.

Applications. Bon, applications, il y avait un gars qui bossait pour porter le Basic de DRI. C'était pour ainsi dire un désastre, même si éventuellement ça se finissait un jour. J'ai de vagues souvenirs d'un ingénieur embauché par les Tramiels qui n'avait pas fait du très bon travail - Je pense qu'il est tombé dans un tas de champs de mines de portabilité, qu'il a été décourragé et achevé par le management (à ce moment, on n'avait pas encore débroussaillé le code DR qui n'était ni portable ni lisible). Il a fini par démissionner ou se faire virer, je ne parviens plus à me souvenir.

Moral (sous la forme d'un très gentil berger allemand, capable de jouer au frisbee au delà de l'endurance humaine; utile pour déstresser).
[HR]
CP/M-68k était un "Système d'Exploitation" dont les fondements remontaient aux seventies. A peu près dix ans plus tôt, Gary Kildall avait travaillé sur les systèmes DEC PDP-11, comme eux, et avait été inspiré pour écrire un OS léger pour les tous récents ordinateurs à base de 8080. Longtemps, CP/M était le standard de facto. Gary avait lancé une boite appelée InterGalactic Digital Research pour le développer et le vendre. MSDOS n'était sorti qu'il y a quelques années et DRI (renommé - en perdant le coté intergalitic pour que des personnes en costard puissent lui faire confiance) tachait de gagner des parts de marché grâce à un portage de CP/M sur le 8086, le processeur des IBM-PC.

CO/M-68k était un portage pour 68000, et aussi l'OS pour lequel les Tramiels avaient passé un contrat.

CP/M (dans toutes ses variantes) ne faisait vraiment pas grand chose. Il y avait seulement un système de fichier plat. Il y avait quelques routines d'affichage en console (inutiles avec une interface graphique). Et CP/M pouvait charger des programmes. C'était à peu près tout. (d'un point de vue moderne, il manquait : un système de fichier hiérarchique avec des dossiers, le réseau, la gestion mémoire, la gestion des processus et leur ordonancement, la notion de temps, la synchronisation et les verrous primitifs, une architecture à base de drivers, des graphismes, des polices, des charsets... vous voyez)

GEM s'appuyait sur ces primitives. Vu que l'OS socle ne gérait pas plus d'une tâche, GEM avait une grosse part du travail à sa charge pour permettre des choses comme les "accessoires du bureau" qui pouvaient tourner en concurrence avec (par exemple) un traitement de texte. C'était assez maladroit.

Aucun d'entre nous n'aimait CP/M-68k. Donc, quand on a su que quelqu'un de DRI avait sorti quelque chose de meilleur, même si ce n'était pas fini, on s'est jetés dessus officieusement. GEMDOS a démarré par un projet relevant d'un travail de cochon d'un des ingénieurs de DRI qui avait la réputation d'être un franc tireur. GEMDOS avait un système de fichiers hiérarchique compatible avec MSDOS; il avait aussi d'autres améliorations mais c'était le tout début. Mais en décembre 1984 GEMDOS était encore en cours d'écriture.

Les STs qui furent présentés au CES tournaient sous CP/M-68k. Vers la fin du mois de janvier, après un tas de bras de fers, Leonard Tramiel choisit de donner sa chance à GEMDOS. On allait avoir à travailler dessus pendant plusieurs semaines, et il semblait que ça serait bon. En particulier, nous n'avions pas de disque dur pour le tester, donc tous nos tests étaient effectués sur des environnement à base de disquettes - et ça nous fit bien mal par la suite.
[HR]
C'était évident que le TOS sortirait en retard. Mais on avait le boot qui fonctionnait bien, donc on a passé quelques semaines pour obtenir un petit loader de ROM de 16ko. Tout ce qu'il faisait était dessiner quelques petits graphismes, charger un secteur depuis la disquette et l'exécuter. On avait envoyé les ROM de boot sans vraiment savoir si ça démarrerait un OS mais ça marchea bien finalement.

A peu près au moment où nous envoyions les ROMs, l'équipe software était la tête sous l'eau. Les choses prenaient plus de temps que prévu; il y avait beaucoup de bugs à corriger, il manquait des fonctionnalités, il y en avait d'autres qui ne seraient jamais incluses au produit, et c'était clair que le Mac nous avais surclassé. Aussi, quasiment tout le monde se sentait dépassé par les événements.

Jack Tramiel organisa une réunion. On ne l'avait pas souvent rencontré et c'était une gross négociation. Il commença par dire "j'ai entendu dire que vous n'étiez pas contents". Imaginez une fois grave, autoritaire, comme Dark Vador, et la même attitude, un peu plus même.
Désolé Jack, les choses ne vont pas comme on le voudrait. On a essayé de rester humbles mais on a terminé crevés.
Il gronda "Je ne comprends pas pourquoi vous n'êtes pas heureux". "Vous devriez être très heureux; je paye vos salaires, je suis celui qui n'est pas heureux. Le logiciel est en retard. Pourquoi est il si en retard ?"

Jeune et idéaliste, j'ai sorti: "vous savez, je ne pense pas qu'on soit ici pour l'argent. Je pense qu'on est juste ici pour fournir le meilleur ordinateur que nous puissions"

Jack me fit taire. "Donc vous vous en foutez si je divise votre salaire par deux ?"

J'ai pigé le message. Il n'a même pas eu besoin de faire appel à la Force.
[HR]
On était à nouveau occupés et on envoya les premirs systèmes à base de ROM un ou deux mois plus tard. Je ne me souviens plus exactement mais voici quelques points :

Le TOS ne rentrerait pas, même dans une rom de 192K. On était déjà au delà des 200K (210 ? 220 ?) et ça augmentait encore. Alors, pendant deux semaines, tout le monde cessa ce qu'il faisait pour nettoyer le code. C'est dingue la quantité de choses que vous pouvez dégager si vous le voulez vraiment. Notre linker ne faisait pas de décapage de code mort, mais même si ça avait été le cas, ça ne nous aurait pas montré les énormes morceux de code commun, des réimplémentations pathétiques de strlen, strcpy qu'il y avait partout, ainsi que l'inutile et affreux découpage en couches qui pouvait être remplacé par quelques lignes de code.

{J'ai alors trouvé que virer du code est une bonne méthode pour améliorer un système existant; vous ne vous libérez pas seulement d'une montagne de bugs, vous obtenez un résultat plus simple à comprendre, et qui tourne souvent plus vite. Vous avez un projet énorme, lourdissime qui dure l'éternité à compiler et c'est la galère pour y faire des modifications ? Plongez vous dedans et commencez à supprimer. Devenez un prophète de la destruction constructive; si vous atomisez quelque chose de critique, récupérez le du dépot. Le logiciel c'est génial!}

Peu de temps après que les ROMs du TOS aient été envoyées, Léonard Tramiel organisa un dîner pour les ingénieurs pour marquer le coup et parvint à faire venir Jack. A peu près la moitié du repas (qui avait lieu dans un Chinois fantastique appelé Fung Lum, à Campbell), Léonard commença à rappeler l'histoire de l'arrivé de John Feagans et lui même dans le bâtiment de la Atari Coin-op pour décider de ceux qu'ils garderaient.

"Alors, cette voix sortit de l'intercom-"

- Et merde, Une chose que vous devez savoir au sujet de Jack est qu'à l'age de 12 ans, il était en camps de concentration à Aushwitz. J'ai vu son tatouage. Ce à quoi il a survécu là bas lui donna son caractère, vu que la plupart des gens était concerné et-

"-et la voix dit, «Les troupes impériales ont pénétré la base!»".

Jack n'avait pas vu Star Wars, et il n'avait pas saisi la référence. Et pour lui, la phrase "Storm Trooper" voulait dire tout autre chose. Ca prit un bon moment pour que Léonard convainques Jack que c'était quelque chose de drôle, non, honnêtement, c'était vraiment une blague, OK ? Et je ne suis pas sûr que Jack compris. Mais à la fin on a ri; tous les autres avaient trouvé ça drôle.
Je gardai mon taf.

Je suis resté encore quelques années avant de partir pour Apple. Il y avait encore quelques méchants bugs dans GEMDOS qui ne seraient jamais réellement corrigés (vous pouvez télécharger le sources - je l'ai fait il y a quelques années, et j'ai trouvé le même lot de corrections insatisfaisantes pour y arriver, mais je ne suis pas sûr que ça ait jamais été livré). J'ai pris un ST avec moi, mais je n'en ai jamais fait grand chose. Je ne suis pas resté en contact avec les gens de l'équipe ST; un mail de loin en loin, c'est à peu près tout.

La communauté ST a fait des choses vraiment impresionnantes; une sorte de système d'exploitation moderne décent, une tonne de logiciel audio et bien plus encore. C'est gratifiant d'avoir aidé à ce que tout ceci puisse arriver. Je sais aussi ce que j'aimera être capable en seconde prise sur un projet comme le ST. J'ai cette petite liste...