By Sylvain Glaize.
The Micral N is up and running. Once the emotions were over, a mixture of relief and joy, it was time to check whether the emulator behaved like the real machine. Particularly on unclear points in the documentation, which could lead to several interpretations.
This was the case, for example, with the use of front switches". AV "and SUB ". How exactly do they behave? By putting the machine in a known state after a sequence of manipulations prepared beforehand on the emulator, it is possible to remove any doubts.
Control buttons on the panel, with SUB and AV
After a few adjustments, it is possible to perform the same operations in parallel on the real machine and its digital replica to confirm that both behave visibly in the same way.
By following the addresses displayed on the control panel, it is possible to enter the sequence used to enter the monitor (the ROM program used to manage certain machine operations), and check that the sequence of addresses and data displayed correspond to those expected when you are in the monitor.
So it's time to move on to the next stage, and to do that, we need to make progress on the emulator. The machine launches, but we still don't have any input/output, and there's still the mystery of the boot ROM: what exactly does it do?
ROM and Mystery Card
Whether it's the real Micral N or the emulator, they have the same start-up behaviour: after a brief moment, the machine stops on a HLT.
Having already analysed the ROM, this is not very surprising: it seems to establish a dialogue with a board in the machine by sending it signals and waiting for responses. These responses are read from one of the two 'stack/channel' cards, which can act as buffers.
These "pile/channel" cards are important for the operation of the Micral N, although technically not essential. These memory cards interface on one side with the PLURIBUS, and therefore with the rest of the machine. On the other, they can be connected to another card for direct communication, independent of the processor. In "stack" mode, the card behaves like a computer stack: whatever is written last in the memory is read first (LIFO); in "channel" mode, data is read starting with the oldest data written (FIFO).
The emulator already manages the 'stack' mode of these cards, because the program in the monitor ROM uses one of them as auxiliary memory, in addition to RAM. This was one of the first parts to be emulated and made functional. But it seems that this second card is used in its 'channel' world and, above all, it seems that it must receive data from a peripheral.
Viewing the memory of a channel/stack card in the emulator (256 bytes)
As it receives nothing, the ROM quickly stops.
So we're looking for this peripheral: what is it? It's an input device, but is it a punched tape, a floppy drive, something else?
Once again, the emulator makes it possible to test things without the hardware. Since the card needs to receive data, let's send it data from nowhere. A random sequence, for example, but exactly the number expected by the ROM.
And that takes things even further. This time, the emulator no longer freezes on start-up. However, if the execution of the machine is not stopped, the ROM runs in circles and returns the same sequences.
The study showed that there was a checksum calculation. And this sum is obviously wrong, which is to be expected if you send anything.
The emulator is modified to send the expected checksum. Suddenly, the emulator starts loading data into RAM.
Emulated disc playback.
By analysing the signals sent and expected to and from the card, the hypothesis of a floppy disk drive emerges. What the ROM loads are sectors. We even have a very good candidate for the model.
But above all, it gives us the information we need to configure 'Pauline', the disk emulator designed by Jean-François. So I wrote a few programs that could be sent to the real machine for demonstration, which I could then fine-tune on the emulator.
Tracker on the control panel.
But how is it connected?
Before you can connect the disk emulator, you need to know how these cards are connected to each other. The connections to the peripherals and between the controller card and the 'channel' card are made on the opposite side of the board. PLURIBUSAnd this side is not standardised. And we don't have the documentation, nor the cables, which will have to be rebuilt.
Back to the emulator. When I say that we don't have any documentation, that's not quite true. There is information in the user manual, but it's incomplete and sometimes inconsistent between the diagrams and the text.
By making virtual connections in the emulator, studying the scans of the cards to trace the tracks, the connection diagram gradually takes shape, until we're finally sure of ourselves.
The serial card
Similar work is done for the serial I/O card, which is used through a generic I/O card in the Micral N.
Once again, a few trips back and forth between the scans of the cards, the (again imprecise) documentation and the emulator enabled us to come up with a diagram that we are certain of.
With everything you need to interact with the Micral N via the serial port and load a program into RAM, it's time to get down to business.
Release of a programme written specifically to test the Micral N.
Don't forget to take part in the campaign to support our work! https://micral.mo5.com
