Rational/R1000s400/2022 Project Status
Rational R1000/s4000 ten year project status
The R1000 project at Datamuseum.DK has existed for a bit over 10 years now and that is a good reason to stop for a moment and summarize where we are.
The Terma Machine & Facit Twist Terminal
More than ten years ago we received a R1000/s400 machine, a Facit Twist terminal, some blank disks, two boxes of documentation, but no software from Terma A/S. (Genstand:11000070).
After replacing some defect SRAM chips on the IOC board, this machine and the Facit Twist terminal works.
The original PSU works intermittendly, but it is worn out, so we have replaced it with two modern switch mode power supplies.
We are also using a "SCSI2SD" board instead of the two harddisks, to preserve their remaining life expectancy.
The PAM Machine
When PAM visited us, he brought another R1000/s400 machine, originally from internal Rational use via Université de Haute-Alsace.
This machine suffers from the "IOC RAM failure", and we expect it can be repaired and brought to live.
It has been suggested that we should attempt to repair it, and donate it to an appropriate qualified computer museum abroad, but for now the machine is in storage.
PAM also brought his stash of spare-parts, including:
- A set of printed circuit boards from a R1000/s200. These boards are almost identical, but not plug compatible with the R1000/s400 boards, but they can be used for reverse engineering and spare-parts.
- Spare power supplies
- An 8" SMD disk from a R1000/s200
PAM donated all the software we have in our collection, in the shape of a box of 8mm "ExaByte" tapes and the contents of two 5¼" SCSI disks.
The images from the two disks is the only currently working software image we have.
Our reverse engineering efforts are exposed via the "AutoArchaeologist" software:
This is reverse engineered using the PyReveng3 tool. It would be nice to be able to "uncompile" to PASCAL source code.
This is also reverse engineered using PyReveng3, essentially completed.
This is reverse engineered using PyReveng3, but some parts of the instruction set interacting with the DFSM awaits the emulation before we can tell what they do.
We have a "parrot" disassembler, based on PyReveng3, based primarily on hand-disassembly of a compiled module containing a disassembler. We dont understand what a lot of the instructions do, and we suspect there are more instructions too (for instance to talk to the IOC via the FIFO).
We have started to make sense of the binary microcode, but this is on pause, awaiting avilability of the emulator as a tool.
These have been figured out, as far as we know.
We have a good idea, and can probably implement it in FUSEFS, if we need to.
R1000 On-disk object store
We can take them apart at proper byte boundaries, but we do not fully understand the metadata.
The majority of our documentation came with the Terma machine, but PAM contributed a few artifacts too, including his "Field Engineer Handbook".
All documentation, all software and all firmware from programmable chips has been deposited in our Bit Archive, with the following exceptions:
- The PAL-chips on the ENP100 network processor have not yet been preserved.
The schematics have been redrawn in KiCad in order to produce net-lists of the computer.
The netlists can be converted to SystemC classes, relying on a library of SystemC-components matching the KiCad symbols.
The library of SystemC-components still contains a fair number of empty placeholders, in partiular for the PAL chips on the MEM32 (and RESHA) boards.
The IOC's 68K20 CPU is emulated with Karl Stenerud's "Musashi" FOSS package 
The diagnostic i8051 processors are emulated with our own C-code.
The CLI interpreter and such tracing and debugging infrastructure as has been needed have been implemented.
The current size of the emulator in lines of code is:
2356 DIPROC 2431 IOC (machine generated) 4980 IOC 5369 Infrastructure 9560 Components 28496 Musashi 36584 Musashi (machine generated) 41531 Schematics (machine generated, IOC and FIU only) ------ 175195 total
The emulator can run the DFS/CLI environment stand-alone without the SystemC part running.
The DFS partition can be loaded from (emulated) tape.
Emulating only the IOC hardware, the "TEST_IOC.EM" experiment passes.
Emulating only the IOC & FIU hardware, the "TEST_IOC.EM" experiment passes, and about a dozen subtests from "TEST_FIU.EM" pass, but the rest fails.
IOC tracing and debugging allows instrumentation of the running code.
SystemC tracing allows instrumentation of individual SystemC components.
FIU passing stand-alone tests
SEQ integration and passing stand-alone tests
TYP integration and passing stand-alone tests
VAL integration and passing stand-alone tests
MEM32 integration and passing stand-alone tests
This includes writing SystemC models of the PAL chips, using the preserved fuse-maps.
Passing the FPTEST
Booting the Rational Environment
This involves figuring out the R1000 <-> IOC communication and DMA access use.
The IOC CPU, main RAM and peripherals are not tied into the SystemC emulation.
This will be needed when the R1000 starts talking back to the IOC via the FIFOs and direct memory access. Since we dont know anything about the DMA, we dont know what functionality is required.
A number of the IOC self-test routines are skipped
Some to avoid wasting time (RAM test), some because we have not needed to implement those peripherals yet (Ethernet) and some because of the missing connection to SystemC (spurious interrupts etc.)
With run-times measured in weeks, we need to be able to snapshot and resume snapshots. This is not trivial, in particular with respect to SystemC, but we have what feels like a good plan, which has yet to be attempted.
ENP100 network processor emulation
In the absense of any documentation at all for this daughterboard or how the IOC & R1000 interact with it, our primary plan is to hope that the R1000 can run without a ENP1000 board plugged into the RESHA board, making the emulator effectively a single-user system.
It is likely feasible to reverse engineer and emulate the ENP100 board at the VME interface, but it will require either a very workable (ie: not month long boots) R1000 emulation, or a VME-bus analyzer with the necessary extender-cables to work on the RESHA when mounted in the R1000 chassis.
Currently we only have the single Facit Twist terminal which can work with The Rational Environment. We are ponding creating a software emulation of it, using the preserved firmware and character generator EPROMs.