Les débuts d’un émulateur

Par Sylvain Glaize.

Retournons un peu en arrière. Dès nos premières discussions sur le projet, il y avait l’idée de création d’un simulateur de Micral N. Et cela pour deux raisons principales.
La première est, à terme, d’offrir à chacun la possibilité de manipuler virtuellement cette machine rare. La seconde, de pouvoir étudier une machine que nous ne connaissions pas encore et dont nous ne savions pas si notre exemplaire était fonctionnel ni même complet.

Avoir un simulateur, ou un émulateur peu importe le nom qu’on lui donne, c’est pouvoir travailler sur un replica d’une machine précieuse, sans risque de l’endommager.
Cela permet d’avancer en parallèle entre la machine réelle et son double.

Plus tard, après avoir étudié la composition physique détaillée de ce Micral N, l’intérêt du simulateur sera validé. En effet, il nous manque les câbles de branchements entre certaines cartes, il va donc falloir les reconstruire. Et pour cela, il nous faut comprendre exactement comment les cartes communiquent entre elles.

Simuler le 8008

Simuler un processeur peut se faire à plusieurs niveaux. Tout en bas, dans le détail, on peut utiliser un FPGA pour reproduire sa structure. Beaucoup plus haut, on peut simuler les changements d’états dû à l’exécution de chaque instruction machine. C’est sur un niveau intermédiaire que je pars : une simulation des changements d’états après chaque « state » (état) du processeur.

C’est une manière de simuler les signaux du processeur assez finement et d’en comprendre le fonctionnement détaillé. La documentation officielle du 8008 aide en cela qu’elle contient un tableau de ces états et des opérations élémentaires effectuées par le processeur à chacun de ces états.

Extrait Datasheet i8008

Et cela se traduit assez naturellement sous forme de données décrivant le fonctionnement du processeur, étape par étape.

Code d'instructions Émulateur

L’exécution du simulateur est cadencée par un ordonnanceur qui indique à chaque changement d’état du système quels sont les composants simulés qui doivent en être avertis. Si ce composant provoque à son tour un changement d’état du système, il indique à l’ordonnanceur à quel moment ce changement se produira.

Ici encore, avec une bonne connaissance du système, il serait plus simple d’avoir un ordonnanceur fixe qui sait qui parle à quoi et qui réagit à quoi. Ne connaissant pas le système, une architecture où chaque composant dialogue avec l’ordonnanceur permet d’être flexible, au prix d’un certaine lenteur. Mais pour un processeur qui tourne à 500 kHz, ça passe ; même sur un Raspberry Pi 4.

L’enrobage

Pour lancer l’émulateur, deux « enrobages » sont prévus.

Le premier enrobage est un mode sans interaction direct, mais que l’on peut imaginer ouvrir un port série ou bien s’interfacer avec BlinkenBone (http://retrocmp.com/projects/blinkenbone), cette architecture qui permet une interaction avec des panneaux de contrôle lumineux, répliques ou réels.

Le second enrobage est un mode interactif avec de nombreuses fenêtres, pour visualiser l’état de la machine, le contenu de sa mémoire et reproduire le panneau de contrôle en façade. C’est principalement celui-là qui sera utilisé pendant toute la recherche. Cette version utilise l’incontournable bibliothèque Dear ImGui (https://github.com/ocornut/imgui) pour la partie graphique.

Le simulateur est architecturé de manière à pouvoir imaginer d’autres enrobages plus tard. Il est tout à fait envisageable et envisagé d’avoir une version utilisateur simplifiée afin de faire découvrir la machine. Sur le Web, par exemple, avec des scenarii et des explications de fonctionnement. Mais n’allons pas trop vite.

Voici un des premiers écrans du programme :

Capture d'écran de l'émulateur Micral N

Reproduire une carte

Reproduire une carte, c’est déjà la comprendre. Pour base, il y a la documentation. Mais la documentation que nous avons ne couvre pas l’intégralité des cartes de la configuration de ce Micral N. Et elle en couvre d’autres que nous n’avons pas. Autre vecteur de compréhension : le fonctionnement du Pluribus. Ce bus est passif, il ne fait que transmettre des informations électriques aux cartes (et leur amener l’énergie électrique nécessaire). Cependant, même en étant passif, le Pluribus décrit une interface : un ensemble de règles et contraintes sur les signaux que les cartes doivent respecter. Et c’est une information précieuse.

Ainsi, on connait les différents moment importants du système. Le moment de la demande d’une donnée de la part de la carte processeur et le moment où cette donnée arrive par exemple. On peut être certain que les cartes respectent ces contrats.

Un autre vecteur de compréhension sont les cartes physiques elles-même. C’est assez fastidieux mais grâce à des scans de cartes que nous avons faits et en suivant visuellement les pistes reliant les composants, on peut affiner l’idée que l’on se fait du fonctionnement de la carte. Fastidieux, mais pas impossible. Les cartes ne comportent que deux couches, une en surface de chaque côté de la carte.

Scan Carte Processeur Micral N

Le dernier grand vecteur de compréhension, et pas des moindres, est le contenu des deux ROMs présentes dans le système, sujet d’un article précédent. Ces deux ROMs sont aussi des éléments fonctionnels du système. Ainsi, leur exécution va permettre de valider le bon déroulement des opérations.

Quand le modèle mental de la carte atteint un certain niveau qui semble fonctionnel, il est temps d’en implémenter une première version dans le système. De cette version, on tire des enseignements qui font parfois reconsidérer les théories émises. Et petit à petit, en recoupant tous ces vecteurs, un modèle fonctionnel apparait.

Il y a encore beaucoup à faire à ce niveau-là de l’analyse, et nous reviendrons dans un futur article sur la suite de la construction du programme de simulation.

N’oubliez pas de participer à la campagne pour soutenir nos travaux ! https://micral.mo5.com