Rational/R1000s400/2022 Project Status

Fra DDHFwiki
Spring til navigation Spring til søgning

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.

Hardware

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.

Spare parts

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

Software

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.

Reverse engineering

Our reverse engineering efforts are exposed via the "AutoArchaeologist" software:

68K code

This is reverse engineered using the PyReveng3 tool. It would be nice to be able to "uncompile" to PASCAL source code.

8051 code

This is also reverse engineered using PyReveng3, essentially completed.

DIPROC Experiments

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.

Compiled programs

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).

Microcode

We have started to make sense of the binary microcode, but this is on pause, awaiting avilability of the emulator as a tool.

Tape formats

These have been figured out, as far as we know.

DFS filesystem

We have a good idea, and can probably implement it in FUSEFS, if we need to.

R1000 On-disk object store

No clue.

Archive files

We can take them apart at proper byte boundaries, but we do not fully understand the metadata.

Documentation

The majority of our documentation came with the Terma machine, but PAM contributed a few artifacts too, including his "Field Engineer Handbook".

Preservation

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.

Software Emulation

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 [1]

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


Current functionality

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.

Missing Functionality

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.

FPTEST

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.)

Snapshot/Resume facility

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.

Terminal Emulation

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.