Rational/R1000s400/Emulator
Software Emulation of the Rational R1000
Why Create a software emulation of the R1000 ?
We are quite confident that we can keep our R1000 computer running for at least another 20 years. But what about 100 years ? or 200 years ?
Museums already hate "The Plastic Age", because it transpires plastic is not forever after all: It cracks, it breaks and sometimes it turns into a substance somewhere between tar and Marmite™.
Superficially, the R1000 does not look like a computer with a lot of plastic in it, but all the 3-4 thousand chips are encapsulated in plastic, the connectors are made from plastic and so on.
At some point in the hopefully distant future, our R1000 will join the remaining handful of R1000's in the world, and also become life-less and cold artifact.
But until then, we have the chance, and we fell, the obligation, to create a software emulation of the R1000, to preserve it for the future, and to enable more people to experience the Rational Environment.
How to create a software emulation of the R1000 ? =
Normal software emulations of computers will emulate the instruction set and the peripherals in software.
This runs into a tiny little problem with the R1000, because for all practical purposes it does not have an instruction set.
The 16 bit words which come out of the Ada compiler's code-generator and which is interpreted by the microcode, may in strict technical sense be an instruction set, but it is neither documented nor even stable over time.
We have managed to reverse engineer quite a bit of this "instructions set", but given instructions such as "Action Discrete,Diana_Map_Kind_To_Vci" that does not help at all.
Therefore we will have to emulate the R1000 at the microcode level, which is not unprecedented, for instance our own GIER/Simulator is written that way.
And in difference from the instruction set, we have a bit of microcode documentation and we have almost all the schematics, so no worries?
OK, maybe a little worried, because when the R1000 boots, it spends up to an hour silently "starting virtual memory system" and that is not a very productive debugging environment.
The final option is to simply emulate all the chips, as they are drawn on the schematics.
The tremendous advantage of this approach, is that all the built in diagnostic facilities can be used for debugging.
Another advantage is that we do not really need to understand what happens on all the schematics, as long as we can emulate each of the chips and we connect them as the schematics say, it should work.
But the big disadvantage is that it will probably be about a factor thousand slower than the real machine, meaning it will spend a month "starting virtual memory system".
So the plan, as of middle 2021, is to do the start out emulating the hardware, and then once that works, migrate it to a much higher level of microcode emulation, probably on a board by board basis.