So, here we go: I have an X-MP simulator and a J-90 CD. And big plans to marry the two of them and since I can’t modify the CD, I’ll have to adopt the simulator.

As we’ve seen previously the J90 is more or less a low-end Y-MP, which itself is an evolution from the X-MP. The main difference between the two machines – from an instruction-set perspective – is the change from 23- to 32-bit address-space. Doesn’t sound too scary.

On the surface. The devil is always in the details of course and if I am going to have any chance at getting a J-90 simulator going, I’ll have to understand the content of the CD I have. So what’s on it? In this episode, we’ll investigate the content of this shiny round object. (In real life, I don’t actually have the CD, only an image of it, but let’s ignore that detail, shell we!)

The top-level directory of the CD is looks like this:

Good! There’s even a file, called setup. Let’s look at it!

Well, that’s a dead-end: it’s a shell-script, which in short order executes some another shell script after determining the host machine type. From the code it’s rather obvious that it was supposed to run on the SWS and supported SunOS, Irix, AIX, HPUX and OSF1. (I wasn’t aware that the SWS could be anything other then a Sun workstation, but apparently I was wrong.)

The SWS was the support computer that was shipped with the J90 to control the machine. It communicated with the IO subsystem in the J90 through – from what I gather – thin Ethernet.

Either way, this is not terribly useful: I don’t have an SWS nor any intention making a simulator for it if I can avoid it.

Of the four directories on the CD, the IOSV one contains IOSV-related stuff (which I can’t simulate due to total lack of HW documentation, but more on that later) and the other two are the infrastructure for the setup itself it seems. So, let’s start by digging deeper into the most interesting one: UNICOS_exe:

See those large files with the gzc extension? Those contain the to-be-installed files for various parts of the system. But what the format could be? The ‘gz’ part indicates a gzip compressed file, so let’s try that!

No error, no complaints, just a new 402Mbyte file on my hard drive!

So what is that? Presumably some sort of archive format, (not TAR, that would be too easy, but something along those lines). It’s probably not compressed anymore, that would make no sense. So let’s look at it:

Well, that’s not encouraging. It’s some sort of an archive all right, but not something I readily recognize. What could this be? After some poking around, some pattern emerged:

The archive contains files, preceded by their file-name (etc/gzip in the example above) and a fixed-length header. This header contains what looks like a bunch of mambo-jumbo, but two entries are rather intriguing: the last two QWORDs contain the length of the filename and the length of the file. That’s enough to extract the content!

So I’ve made a little extraction utility that crawled through the content file and extracted it:

This looks very much like a root FS. Rinse and repeat for the other three archives, and (drumroll) I have access to the raw content of the archives in all their glorious details! Two are rather strange (uex_11.gzc and rbf_11.gzc contain some ‘stuff’ for the lack of a better word), but uni_12.gzc really looks like ‘/’ and uni_22.gzc is ‘/usr’.

At this point it’s worth taking stock of what I need if I want to boot this OS. First I need a kernel of course. Then I need a root file-system (not just the content of it, but something I can mount). All UNIX systems delegate most of the boot work to the ‘init’ process, and UNICOS does it the same way. Without a root FS and ‘init’ the whole project is still-born as we’ve seen with UNICOS 4.0 on the X-MP. Finally – again drawing from my previous experience with COS and UNICOS – I’ll need some sort of configuration file, that tells the OS about the layout of the I/O subsystem, including the location and size of hard drives and which to attempt to mount as root. I of course also need a simulator (a small matter) but for now let’s concentrate on things that the CD contains! All three of these things must exist on an install CD in some format or another, so while it’s nice and very important that I have extracted the contents of the install binaries, that didn’t get me any closer to finding these ingredients.

Looking back at the root directory, there’s another intriguing looking file: ram_fs. If all goes well – and would be rather logical – the setup used a small RAM file-system for bootstrapping the system. Could this be it?

Hmm, maybe not. But let’s look a little further before giving up…

Much better. From what I know, Cray uses 4kbyte sectors, so this is the beginning of the second sector. The first string, ‘nc1fs’ seems to identify the file-system type (old UNICOS on X-MP used c1fs and UNICOS on Cray-2 used c2fs). So chances are, this is ‘new’ c1fs or something similar. The rest I can’t immediately make sense of, but at least this looks promising: the file could actually be a minimal root FS.

What else? There’s another interesting file, called krn_11.bgz. After pushing it through gunzip, we’re greeted with the following hex-dump:

I recognize this! This is a CPIO archive.

Looking at the newly available files, the one that stands out is unicos.generic:

It is 8.5Mbytes large, and the beginning looks like a valid kernel image. How do I know? Well, initially it was just an educated guess, but kernel files in the old COS age looked like this: a small header followed by what essentially is a memory dump starting from physical address 0. The first few words in the memory dump is an ‘exchange packet’ which the mainframe CPU uses to bootstrap most of its registers from during reset. Among these registers is the all-important P or program counter, which determined the address of the first executed instruction. This file matches that description, though what should be the exchange packet looks weird. Maybe they’ve change the layout of that between the X-MP and the J-90? Something to look at…

The JBkcompr string however is bad news: it suggests a compressed kernel image. The problem with that is this: I won’t be able to easily disassemble the image and look at the boot flow off-line. Still, it’s better than nothing, much better.

In summary we have a kernel, we have the content of the root FS and even /usr. We also have what appears to be a minimal file-system, called ram_fs. Things look great! I still have to hunt down the parameter file, but I’ll save that part of the story for next time; this post is getting long already. Next I’ll look at what it would take the get the simulator off the ground. Till then, thanks very much for your patience!