LA REVOLUTION OXO

31/01/2022 13:44

Si la préhistoire du jeu vidéo vous intéresse alors vous avez probablement déjà entendu parler de OXO, ce jeu de morpion de 1952 qui tournait sur l’un des tout premier supercomputer électronique, l'EDSAC de l’université de Cambridge en Angleterre.

Répertorier tous ces cas hors norme pour reconstruire l’histoire du jeu vidéo est évidemment très pertinent et indispensable mais OXO faisait partie de ces cas qui personnellement m'intéressaient peu. Probablement parce que j’avais déjà du mal à considérer le morpion comme un jeu tout court donc savoir quelle était la place de OXO dans l'histoire du jeu vidéo ne me passionnait pas énormément.

Puis j'ai entendu l'éminent Douglas Alves en parler et ce fut le déclic quand il évoqua brièvement l'élément qui maintenant me semble être le plus intéressant de OXO: Sa méthode de visualisation. Une solution bien plus intéressante que ce que j’imaginais jusque-là et qui cette fois connecte directement OXO à nos jeux vidéo modernes.

En effet j’avais trop rapidement rangé OXO dans la même catégorie que Nimrod qui simulait un jeu de Nim quelques mois auparavant. Je l'avais probablement confondu avec "Bertie the Brain" un autre jeu de morpion électronique de 1950. Mais sur ce point de la représentation visuelle d'un jeu, OXO va bien plus loin que Nimrod ou Bertie ce qui change fortement ma perception de OXO qui finalement me semble etre un cas assez incroyable, une pierre angulaire. Car cette question de la représentation visuelle, même sans être trop rigide, est tout de même relativement centrale dans ce qui définit le jeu vidéo.

Je vais donc spoiler directement ma conclusion: OXO me semble être le premier exemple connu de construction en temps réel d'une image numérique dans un framebuffer bitmap tel que finalement on le fait encore aujourd'hui dans un jeu PS5. Et cela, il y a 70 ans!
Et pour ne rien gâcher, ce framebuffer prend physiquement une forme incroyable, croyez moi vous allez être surpris…

Les bienfaits insoupçonnés du monitoring

L'EDSAC (Electronic delay storage automatic calculator) opérationnel dès 1949, est donc un énorme supercomputer qui consomme 11 000 watts et occupe un bâtiment entier. Sa logique est constituée de 3500 tubes à vide et permet d'exécuter “seulement” quelques centaines d'instructions par seconde. Les programmes sont stockés sur des rubans de papier perforé et écrits dans un langage qui ressemblent aux prémices de l’assembleur avec des mnémoniques. L’output est une imprimante qui imprime donc les résultats.

Mais pour pouvoir surveiller le fonctionnement d’une machine aussi complexe et aider au debugging, l’ESDAC se voit accompagné d’un système de monitoring assez avancé qui permet de visualiser en temps réel l’état de la machine sur des petits écrans CRT au format oscilloscope (d'où le terme usuel “moniteur” pour nos écrans d’ordinateur qui au départ avaient donc une fonction secondaire de monitoring). Vous pouvez les voir dans le fond à droite sur la photo ci-dessus.

Ces écrans servent donc à “surveiller” (monitoring) l’état de la machine, pas à afficher les résultats produits par le programme en cours (l’imprimante est là pour ça).
Sur cette photo l'écran de gauche et de droite affichent l’état de certains registres internes de l’EDSAC (dont l’adresse de l’instruction en cours d'exécution à droite) sous la forme de pics verticaux qui représentent chaque bit du registre. Il existe un second bloc de 3 écrans qui affichent l’état d’autres registres dont l’accumulateur et l’instruction en cours (l’ESDAC utilise des instructions de 17 bit). Ce sont littéralement des outils de debugging.

Mais l’écran qui nous intéresse est celui du milieu. Sa fonction n’est guère plus complexe à comprendre que les autres. Il affiche simplement l'état de la “RAM” ou tout du moins de l’une des 16 banks mémoire sélectionné (appelé ici “Tank”) qui contient 16 mots de 35 bit. Chaque bit est représenté sur l’écran par un petit point qui est plus lumineux si le bit est à 1 ce qui permet de contrôler visuellement les data que contient cette bank de “RAM”.

L’affichage de cette bank mémoire de 16 mots de 35 bit prend donc la forme de 16 lignes de 35 points… ce qui revient exactement à afficher le contenu d’un framebuffer de résolution 35x16 pixels avec une profondeur de 1 bit par pixel (monochrome). Vous commencez à comprendre la révolution?
Un framebuffer bitmap consiste précisément à stocker les uns à côté des autres la valeur binaire d’intensité de chaque pixel d’une image (de gauche à droite et de haut en bas) dans chaque “case” mémoire successive d’un buffer en RAM pour ensuite visualiser celui ci sur un écran et c’est exactement ce que fait finalement OXO en dérivant l’usage des outils de debugging de l’ESDAC.
C’est littéralement génial et c’est ce qu’on continu de faire aujourd’hui sur un jeu PS5 avec juste plus de pixels (3840x2160 au lieu de 35x16 pour avoir une finesse d’image bien plus élevé) et une plus grande profondeur de pixel (32 bit par pixel ou plus au lieu de 1 bit pour avoir beaucoup plus de couleur et de range HDR).

Pour résumer, le programme OXO (programmé par Alexander Shafto "Sandy" Douglas) va donc attribuer la fonction de framebuffer à l'une des 16 bank de RAM (celle connecté au monitoring) et construire l’image du jeu en temps réel dans ce framebuffer monochrome (1 bit = 1 pixel) pour le visualiser ensuite par l'intermédiaire du monitoring de l’EDSAC tel un jeu moderne (plutôt qu’en passant par l’imprimante) tout en gérant aussi l’IA.
A savoir aussi que le "contrôleur" du joueur prend la forme d’un cadran rotatif de téléphone pour sélectionner le numéro de la case où sera placée la prochaine croix.

Une résolution 35x16 monochrome peut sembler ridiculement faible mais c’est pas si mal. C’est mieux par exemple que la console portable Microvision (1979) avec ses 16x16 monochrome et pas si loin du VMU Dreamcast (1998) et ses 48x32 monochrome ou de la console de salon Studio II de RCA (1977) et ses 64x32 monochrome. On est sur des framebuffers assez comparable mais en 1952.

Évidemment, même si le refresh du monitoring se fait probablement à haute fréquence (je ne sais pas combien), l’EDSAC n’est pas capable de refresh le framebuffer à 60 fps même partiellement. On est sans doute très loin de ça (j'ai testé le programme "Space Invaders" sur un émulateur ESDAC en mode real time. Ca tourne à 5 fps et c'est juste une animation sans gameplay) mais on est déjà sur quelque chose d’étrangement moderne pour du jeu vidéo de 1952.

J'ai éludé la question mais le simple fait que le jeu OXO soit un programme chargé dans une mémoire et exécuté par un ordinateur est déjà très moderne comme incarnation d'un jeu vidéo (ce ne sera pas le cas par exemple des premiers jeux d'arcade qui ne sont pas des "programmes"). Il faut quand même le préciser car même si ce n'est pas le sujet de ce billet, ce n'est pas un détail. Ca participe un peu plus à donner à OXO le statut de jeu vidéo au sens le plus strict du terme et donc en faire une étape importante.

J’ajouterais aussi qu'il me semble que le monitoring de la RAM balaye cette matrice de “points” de gauche à droite et de haut en bas contrairement aux autres écrans de monitoring qui fonctionne plutôt comme un oscilloscope. Et ce type de rastérisation de l’écran dans laquelle ont injecte à la volée l'information des “pixels” serait alors assez proche finalement du principe d’affichage vidéo de nos TV tel qu’on le pratique encore aujourd’hui pour nos jeux vidéo modernes. On n'est pas vraiment sur un affichage vectoriel tel que pourra l'expérimenter à la marge le jeu vidéo de la fin des années 70, début 80 (ou le Spacewar de 1962 sur PDP-1) mais sur quelque chose de plus “moderne” d'une certaine façon.

Le plus badass des framebuffers!

Cette révolution du framebuffer apporté par OXO est incroyable mais ce qui l’est peut être encore plus c’est la forme physique sous laquelle celui-ci va se matérialiser.

En effet la “RAM” de l’EDSAC prend la forme d’une “batterie” (l'équivalent de nos barrettes de RAM), qui doit peser entre 200 et 300 kg, composée d’un coffrage en acier et de 16 tubes (les 16 bank nommés ici “Tank”). Tout cela offre à l'EDSAC une capacité de RAM d’environ 1 Ko. Quelques années après OXO une seconde “barrette” de RAM sera ajoutée pour atteindre les 2 Ko. C’est même pas l'équivalent d’une NES qui était pourtant très chiche en RAM ^^.

Mais ce n’est même pas ça le plus dingue. Chacun de ces tubes d’acier qui représente une bank de RAM stock donc 16 mots long de 35 bit (qui peuvent aussi être divisé en 32 mots court de 17 bit) soit 560 bits (70 octets). Le framebuffer du jeu OXO va donc remplir l'intégralité de l’un de ces tubes qui sera dédié à cette fonction.

Mais comment sont stockés ces 560 bit le long de ce tube? Et bien sous la forme d’ondes acoustiques qui circulent dans un bain de mercure car ces tubes d’acier sont ni plus ni moins que des réservoirs de mercure liquide.

C’est ce qu’on appelle des lignes à retard (et qui explique en partie le nom de l'ESDAC) avec ici une certaine originalité dans l'exécution. Chaque bit sous forme électrique est transformé à l'extrémité du tube en onde acoustique par un cristal piézoélectrique, puis le bit circule alors “lentement” dans le mercure pour atteindre le second cristal à l’autre extrémité du tube qui va retransformer le bit en signal électrique pour être à nouveau réinjecter à l’autre extrémité et tourner ainsi en boucle.

C’est cette capacité à ralentir fortement la circulation de ces bits (par cette transformation provisoire en onde acoustique) qui permet de former cette boucle perpétuelle et ainsi stocker 560 bits à la queuleuleu dans cette barre de 1m55 tout en pouvant quand même les discriminer temporellement et ainsi les lire ou les modifier lors de leur phase électrique.

Mais une onde acoustique c'est vraiment extrêmement lent comparé à un signal électrique. Peut-être même trop... Heureusement le son se déplace à plus de 5000 km/h dans le mercure ce qui permet quand même un bon débit.
Si mes calculs sont bons chaque bit doit faire une boucle complète en repassant par les I/O en exactement 1 milliseconde donc on peut dire que le temps d'accès à cette RAM est de l’ordre du milliseconde ce qui me semble raccord avec la fréquence d'exécution des instructions de l’ESDAC qui est inférieur au kilohertz.

Même les registres internes de l’EDSAC utilisent la même technologie mémoire mais sur des tanks bien plus courts car ils n’ont besoin de contenir que quelques dizaines de bits. Voici en photo à quoi ressemble un registre de l’EDSAC.

Ainsi le tout premier framebuffer de jeu vidéo prenait donc la forme de 560 ondes acoustiques circulant en boucle dans du mercure liquide contenu dans un long tube d'acier de 10 ou 15kg. Je trouve ça juste incroyable.
Si le framebuffer d’un jeu PS5 utilisait la même technologie alors son poids serait du même ordre de grandeur que celui de la tour Eiffel ^^.

Conclusion

Dans cette grande histoire du jeu vidéo encore en construction, OXO n’avait pas su accrocher mon attention jusque là, c’est maintenant chose faite et d’une belle manière car je le considère dorénavant comme une pierre angulaire au même titre qu’un Spacewar ou qu’un Pong (1952 OXO, 1962 Spacewar, 1972 Pong… au moins les dates sont faciles à retenir ^^).

OXO nous raconte (entre autres) l’histoire des premières images numériques, du premier framebuffer, ce qui le connecte directement aux jeux vidéo d’aujourd’hui, 70 ans après. Mais en plus il raconte cette histoire d’une manière on ne peut plus spectaculaire. Tous les ingrédients d’une bonne histoire à partager. Je ne me fais donc aucun souci pour la postérité de OXO.

Il existe un simulateur/émulateur de l’EDSAC et donc de OXO:
https://www.dcs.warwick.ac.uk/~edsac/

Et même une version FPGA:
https://hackaday.com/2020/05/15/edsac-lives-in-mister/

Ainsi qu’un projet de réplication:
https://www.tnmoc.org/edsac

EDIT Août 2023:

J'ai pris quelques semaines de mon temps pour apprendre à programmer sur l'EDSAC afin de savoir enfin ce qu'il était concrètement possible de faire en temps réel sur une machine aussi vieille.
Ça donne cette démo de casse-brique qui tourne à environ 12 fps. Je suis très content du résultat étant donné les performances très limitées. Tous les détails dans le descriptif de la vidéo youtube.