Par Sylvain Glaize.
Le Micral N est en état de marche. Passées les émotions, mélange de soulagement et de joie, il est temps de vérifier si l’émulateur se comporte comme la machine réelle. Particulièrement sur des points peu clairs de la documentation, qui pouvaient amener à plusieurs interprétations.
C’était le cas par exemple de l’utilisation des interrupteurs de façade « AV » et « SUB ». Comment se comportent-ils exactement ? En mettant la machine dans un état connu après une séquence de manipulations préparées auparavant sur l’émulateur, il est possible de lever les doutes.
Les boutons de contrôle sur le panneau, avec SUB et AV
Après quelques ajustements, il est possible de faire en parallèle les mêmes opérations sur la véritable machine et son replica numérique pour confirmer que les deux se comportent visiblement de la même manière.
Uniquement en suivant les adresses affichées sur le panneau de contrôle, il est alors possible d’entrer la séquence qui permet d’enter dans le moniteur (le programme en ROM permettant de gérer certaines opérations de la machine), et constater que la séquence des adresses et données qui s’affichent correspondent bien à celles prévues lorsqu’on se trouve dans le moniteur.
Il est donc temps de passer à l’étape suivante, et pour cela, il faut avancer sur l’émulateur. En effet, la machine se lance mais nous n’avons encore pas d’entrée/sortie et il reste toujours le mystère de la ROM de boot : que fait-elle exactement ?
La ROM et la Carte Mystère
Que ce soit le véritable Micral N ou l’émulateur, ils ont le même comportement au démarrage : après un bref instant, la machine s’arrête sur une instruction HLT.
Ayant déjà analysé la ROM, ce n’est pas très étonnant : celle-ci semble établir un dialogue avec une carte de la machine en lui envoyant des signaux et en attendant des réponses. Ces réponses sont lues sur l’une des deux cartes « pile/canal », qui peuvent agir en tant que mémoires tampons.
Ces cartes « pile/canal » sont importantes pour le fonctionnement du Micral N, même si techniquement pas indispensables. Ce sont des cartes mémoire qui s’interfacent d’un côté au PLURIBUS, et donc au reste de la machine. De l’autre côté, elles peuvent être reliées à une autre carte pour une communication directe, indépendante du processeur. En mode « pile », la carte se comporte comme une pile informatique : ce qui est écrit en dernier dans la mémoire est lu en premier (LIFO) ; en mode « canal », on lit les données en commençant par les plus anciennes à y avoir été écrites (FIFO).
L’émulateur gère déjà le mode « pile » de ces cartes, car le programme présent sur la ROM du moniteur en utilise une comme mémoire auxiliaire, en plus de la RAM. Cela faisait partie des premières parties émulées et fonctionnelles. Mais il semble que cette seconde carte soit utilisée dans son monde « canal » et surtout, il semble qu’elle doive recevoir des données d’un périphérique.
Visualisation de la mémoire d’une carte canal/pile dans l’émulateur (256 octets)
Comme elle ne reçoit rien, la ROM s’arrête rapidement.
Nous sommes donc à la recherche de ce périphérique : quel est-il ? C’est un périphérique d’entrée, mais est-ce un ruban perforé, un lecteur de disquette, autre chose ?
L’émulateur permet à nouveau de pouvoir tester des choses sans le matériel. Puisque la carte doit recevoir des données, envoyons lui des données venues de nulle part. Une suite aléatoire par exemple, mais exactement le nombre attendu par la ROM.
Et cela permet d’aller plus loin. Cette fois, l’émulateur ne bloque plus au démarrage. Cependant, si l’exécution de la machine n’est plus stoppée, la ROM tourne en rond et renvoie les mêmes séquences.
L’étude de celle-ci avait montré qu’il y avait un calcul de somme de contrôle. Et cette somme est visiblement fausse, ce à quoi on pouvait s’attendre en envoyant n’importe quoi.
L’émulateur est modifié pour envoyer la somme de contrôle attendue. Et soudain, l’émulateur se met à charger les données dans la RAM.
Lecture du disque émulé.
En analysant les signaux envoyés et attendus vers et depuis la carte, l’hypothèse d’un lecteur de disquette se dessine. Ce que charge la ROM, ce sont des secteurs. On a même un très bon candidat quant au modèle.
Mais surtout, cela nous donne les informations nécessaires pour pouvoir configurer « Pauline », l’émulateur de disque conçu par Jean-François. J’écris donc quelques programmes qui pourraient être envoyés sur la machine réelle pour démonstration, que je peux mettre au point sur l’émulateur.
Chenillard sur le panneau de contrôle.
Mais comment est-ce branché ?
Avant de pouvoir brancher l’émulateur de disque, il reste à savoir comment ces cartes sont branchées entre elles. En effet, les connexions avec les périphériques, ainsi qu’entre la carte contrôleur et la carte « canal » se font du côté opposé au PLURIBUS, et ce côté là n’est pas normé. Et nous n’en avons ni la documentation, ni les câbles qu’il va falloir reconstruire.
Retour à l’émulateur. Quand je dis que nous n’avons pas de documentation, ce n’est pas tout à fait exact. Il y a des informations dans le manuel de l’utilisateur, mais celles-ci sont incomplètes et parfois incohérentes entre les schémas et le texte.
En effectuant des branchement virtuels dans l’émulateur, en étudiant les scans des cartes afin de tracer les pistes, progressivement, le schéma de connexion se dessine, jusqu’à ce que nous soyons enfin certain de nous.
La carte série
Un travail similaire est fait pour la carte d’entrée/sortie série, qui est utilisée à travers une carte générique d’entrées/sorties dans le Micral N.
À nouveau, quelques aller-retours entre les scans des cartes, la documentation (à nouveau imprécise) et l’émulateur permettent d’en sortir un schéma dont nous sommes certains.
Avec tout ce qu’il faut pour interagir avec le Micral N à travers le port série et lui charger un programme en RAM, il est temps de passer à la pratique.
Sortie d’un programme écrit spécifiquement pour tester le Micral N.
N’oubliez pas de participer à la campagne pour soutenir nos travaux ! https://micral.mo5.com
