Welcome back! Let’s continue our exploration into getting the J-90 simulator off the ground.

From the previous episode, we know we need four things:

1. a kernel
2. a root FS
3. a parameter file
4. an actual simulator

The latter two is missing. Let’s tackle the first one first: how to get a parameter file? There’s none on the CD, in fact I’ve found clues that the install process generates said parameter file using an application, called autogen, which seems to be a binary file executed on the IOSV. Catch-22.

What we’re talking about now is UNICOS installation and administration though, something that must have been documented. So let’s try to find it!

My usual go-to place for documentation is the fabulous bitsavers archive. It let me down though this time: nothing. But, Google came to the rescue:

https://users.757.org/~ethan/comp_cray/

Ethan put the entire documentation set for UNICOS online! It’s a bit unclear whether it’s for version 9 or 10, but things couldn’t possibly have changed that much between these releases.

And there, buried under an unscrupulous name, is the documentation of the parameter file:

https://users.757.org/~ethan/comp_cray/UNICOS_Config_Admin_Guide/08chap5.pdf

The documentation was written as if it was translated from Klingon – or it could just as well be; it uses so many terms I’m unfamiliar with, but it contains nice examples to start off of.

From this manuals it’s clear the parameter file tells UNICOS what to find where. Things, like hard drive geometries, partitions, logical disks, striping, that sort of stuff as well as which partition to boot off of. So I went on and coded up a parameter file (yes it says ios_e in there but the documentation insists on that even for IOSV-based systems):

So that takes care of one of the unknowns, at least for now.

The other problem to solve is the actual simulator. And not just any simulator, a simulator that executes Cray J90 instructions in the mainframe, but then intercepts, interprets and properly responds to all communication towards the IO subsystem. As an aside: the fact that the parameter file describes an IOS-E style IO subsystem strongly suggests that the communication protocol between that and the mainframe is going to follow the IOS-E standard as well.

And getting the J90 instructions implemented I need – you’ve guessed – documentation. Well, that’s not really available, at least not where I’ve looked. What I did find though is the SV1 instruction set description here:

https://www.seas.gwu.edu/~shmuel/CRAY/sv1%20sys%20prog%20ref%20man.pdf

Better than nothing, hopefully the SV1 is compatible with the J90. Fingers crossed…

Looking through the manual, the differences between the SV1 and the X-MP are rather minor. They mostly revolve around the changes needed for the expansion of the address space to 32 bits. The exchange packet layout changed somewhat – which is good news because the kernel image on the CD had an exchange packet that looked odd. Some of the instruction formats changed as well to make room for the extra bits. There’s also a new execution unit, called BMM, or bit-matrix multiplier. This looks very specialized and not terribly useful for the OS, so I don’t believe the system software would use it.

I quickly patched up the simulator (and the disassembler) to handle the new instructions, stubb-ing out the BMM instructions with ASSERT-s in case they are actually used. I’ve also stubbed out any communication with the IOS.

To summarize: I have a kernel, I have a – hacked up – parameter file and I have a RAM FS. I also have an instruction-set simulator of highly suspect quality.

Lift-off!

Oh, wait! There’s one more thing: how to put the pieces (kernel, parameter file, RAM FS) into memory and start up the simulator. The X-MP way the system booted was this:

1. The kernel header was stripped off of the kernel image.
2. The rest of the kernel image was put at address 0
3. The parameter file (COS used one as well albeit of a completely different format) was put right after the kernel
4. The initial exchange packet was patched up so that the S4 register pointed to the beginning of the parameter file and S7 pointed to the end of it.

With the real IOS missing, I’ll have to code up all this flow manually in the simulator. No biggie of course and If I’m lucky, the OS will start churning and pretty soon it will attempt to communicate with the IOS. The simulator will trap that communication and I’ll have at least something to ponder about.

If I’m not lucky, well, then I have a looong instruction trace to weed through…

I’ve fired up the simulator and – after fixing some rather trivial problems – bingo! I had an IO packet coming.

Another aside: This is actually a surprise. The way COS worked was that the first packet was sent by the IOS, not by the mainframe. Why did they used to do it that way is a bit of a mystery, it makes much more sense for the just-started portion of the system to say hello first as opposed to the one already running…

I guess it’s best to stop on a high note: I’m booting fr**kin UNICOS :)!!!