By Sylvain Glaize. Translation by Sébastien Marty.

Let’s go back a bit. From the moment we first discussed the project, there was the idea of creating a Micral N simulator. And this for two main reasons. First of all to offer everyone, at the end of the day, the opportunity of virtually handling this rare machine. Second, to be able to study a machine we didn’t know yet, and didn’t know whether our unit was in working order or even complete.

Having a simulator or an emulator, whatever you call it, makes it possible to work on a replica of a precious machine without risk of damaging it. It allows you to move forward in parallel between the real machine and its virtual twin.

Later on, after studying the detailed physical arrangement of this Micral N, the interest of the simulator will be validated. Indeed, we are missing the connection cables between certain boards, so we will have to rebuild them. And to do that, we need to understand exactly how the boards communicate with each other.

Simulating the 8008

Simulating a processor can be done at several different levels. At the very lowest and most detailed level, we can use an FPGA to reproduce its structure. At a much higher level, we can simulate the state changes due to the execution of each machine instruction. I decided to work at an intermediate level: simulating the state changes after each “state” of the processor.

It is a way to simulate the processor’s signals quite finely and to understand their detailed operation. The official documentation for the 8008 helps in that it contains a table of these states and of the elementary operations performed by the processor at each of these states.

And that quite naturally translates into data describing how the processor works, step by step.

The execution of the simulator is clocked by a scheduler which indicates, at each state change of the system, the simulated components that must be notified. If this component in turn causes a change in the state of the system, it indicates to the scheduler when this change will occur.

Here again, with good knowledge of the system, it would be easier to have a fixed scheduler that knows who is talking to what and who is reacting to what. Not knowing the system, an architecture where each component talks with the scheduler provides flexibility, at the cost of a certain slowness. But for a processor that runs at 500 kHz, it’s ok – even on a Raspberry Pi 4.

The wrapping

PTo launch the emulator, two “wrappings” are provided.

The first wrapping is a mode without direct interaction, but one can imagine opening a serial port or interfacing with BlinkenBone (http://retrocmp.com/projects/blinkenbone) – an architecture which allows interaction with illuminated control panels, either real or replicas.

The second wrapping is an interactive mode with many windows to visualize the state of the machine, the contents of its memory and reproduce the control panel at the front. This is the main one that will be used throughout our research work. This version uses the essential Dear ImGui library (https://github.com/ocornut/imgui) for the graphics part.

The simulator is structured in such a way as to be able to imagine other wrappings later. It is quite possible, and actually planned, to have a simplified user version in order to let people discover the machine – on the Web, for instance, with scenarios and operating explanations. But let’s not go too fast.

Here is one of the first screens of the program:

Reproducing a board

Reproducing a board is already a good way to understand it. As a starting point, there is the documentation. But the documentation we have does not cover all the boards in this specific Micral N’s configuration. Conversely, it does cover others that we do not have. Another vector of understanding is the operation of the Pluribus. This is a passive bus, it only transmits electrical information to the boards (and brings them the necessary electrical energy). However, even though it’s passive, the Pluribus describes an interface: a set of rules and constraints on the signals that the boards must respect. And that’s valuable information.

We know thereby the different important moments of the system. The moment the processor board requests data and the moment this data arrives, for instance. You can be sure that the boards respect these contracts.

Another vector of understanding are the physical boards themselves. It’s quite tedious but thanks to the board scans we did and by visually following the tracks connecting the components, we can refine our idea of the board’s functioning. Tedious it is, but not impossible. The boards only have two surface layers, one on each side.

The last major vector of understanding, and not the least, is the contents of the two ROMs installed in the system, which were discussed in a previous article. These two ROMs are functional elements of the system too. Thus, their execution will make it possible to validate the smooth running of the operations.

When the mental model of the board reaches a certain level that seems functional, it is time to implement a first version of it in the system. From this version, lessons are drawn which sometimes lead to reconsideration of the theories put forward. And little by little, by corroborating all these vectors, a working model appears.

There is still a lot to do at this stage of the analysis, and we will come back in a future article to the next steps in the building of the simulation program.

Meanwhile, don’t forget to take part in the campaign to support our work! https://micral.mo5.com