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:

$ ls -la
total 34
drwxr-xr-x+ 1 tantos None    0 Oct 15 21:01 .
drwxr-xr-x+ 1 tantos None    0 Oct 15 21:00 ..
-rwxr-xr-x  1 tantos None    4 Jun 23  1998 .volume
drwxr-xr-x+ 1 tantos None    0 Oct 15 21:00 CYRIinstall
drwxr-xr-x+ 1 tantos None    0 Oct 15 21:00 CYRIpkgs
drwxr-xr-x+ 1 tantos None    0 Oct 15 21:00 IOSV
-rwxr-xr-x  1 tantos None   44 Jun 23  1998 Product.list
-rwxr-xr-x  1 tantos None 2700 Jun 23  1998 setup
drwxr-xr-x+ 1 tantos None    0 Oct 15 21:02 UNICOS_exe```

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

#!/bin/sh
# USMID @(#)cit/setup	20.2	07/29/97 17:24:59
#
#	(C) COPYRIGHT CRAY RESEARCH, INC.
#	UNPUBLISHED PROPRIETARY INFORMATION.
#	ALL RIGHTS RESERVED.
#
# This script is intended to be on the CD-ROM which contains the
# CYRIinstall and CYRIpkg packages.
# It will:
#	1) check to see if the CYRIPKGDIR environment variable is set
#	   to a directory, if so then use it.
#	2) determine which platform this script is running on and
#	   invoke the appropriate version of CIT.
#	3) if not on a supported platform, assume that tk/tcl binaries are
#	   in the user's path.

BASEDIR=`dirname $0`;			export BASEDIR
MY_CYRIDIR=` cd $BASEDIR ; pwd `;	export MY_CYRIDIR
MACHINE=UNKNOWN
PREDEFINED=FALSE

# Check to see if the CYRIPKGDIR directory is pre-defined.
if [ -n "$CYRIPKGDIR" ] ; then
    echo "CYRIPKGDIR = $CYRIPKGDIR"
    if [ -d $CYRIPKGDIR ] ; then
	PREDEFINED=TRUE
	echo "Using pre-defined Tcl/Tk binary path."
    else
	echo "Ignoring pre-defined Tcl/Tk binary path (invalid)."
	CYRIPKGDIR=""
    fi
fi

# Determine which platform we are running on to define which CYRIpkg
# to use.
if [ -z "$CYRIPKGDIR" ] ; then
    OS_REL=`uname -r`
    if [ -f "/bin/sun" -a /bin/sun ] ; then
	case $OS_REL in
	    4*)
		MACHINE=SunOS4
		;;
	    5*)
		MACHINE=SunOS5
		;;
        esac
    elif [ -f "/bin/mips" -a /bin/mips ] ; then
	case $OS_REL in
	    5.3*)
		MACHINE=IRIX53
		;;
	    6.*)
		MACHINE=IRIX62
		;;
	esac
    else
	PLATFORM=`uname -s`
	case $PLATFORM in
	    AIX*)
		MACHINE=AIX
		;;
	    HP-UX*)
		MACHINE=HPUX
		;;
	    OSF1*)
		MACHINE=OSF1
		;;
	esac
    fi
fi

# If the above succeeded, export the CYRIPKGDIR and CIT_PLATFORM for
# use in CIT.  Otherwise, display a warning message and continue.
if [ "$MACHINE" != "UNKNOWN" ]; then
    CIT_PLATFORM=$MACHINE
    export CIT_PLATFORM
    CYRIPKGDIR=$MY_CYRIDIR/CYRIpkgs/CYRIpkg-${MACHINE}
else
    if [ "$PREDEFINED" != "TRUE" ]; then
	echo "Cannot determine machine type for Tcl/Tk binaries."
	echo "Assuming Tcl/Tk binaries are defined in your path."
	echo
	echo "If this fails, set the CYRIPKGDIR variable to the"
	echo "correct CYRIpkg directory and invoke setup again."
    fi
fi

export CYRIPKGDIR
cd $BASEDIR

#  Path has to include location of xterm, xhost and xauth.
PATH=$MY_CYRIDIR:$CYRIPKGDIR/bin:$PATH:`pwd`:/usr/openwin/bin
export PATH

#  The MY_CYRIDIR before the argument list of $* ensures that there is
#  always a default directory of wherever setup is located.  If the user
#  specifies a different directory, then the last directory has precedence.
#  Since MY_CYRIDIR comes before all user arguments, it will always be
#  overwritten if another directory is specified.
./CYRIinstall/bin/cit $MY_CYRIDIR $*

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:

$ ls -la
total 350115
drwxr-xr-x+ 1 tantos None         0 Oct 15 21:02 .
drwxr-xr-x+ 1 tantos None         0 Oct 15 21:01 ..
-rwxr-xr-x  1 tantos None      2338 Jun 23  1998 boot_ram
-rwxr-xr-x  1 tantos None      4340 Jun 23  1998 CIT.mkfs.preload
-rwxr-xr-x  1 tantos None      3386 Jun 23  1998 CIT.mntfs.preload
-rwxr-xr-x  1 tantos None     11985 Jun 23  1998 CIT.network.preload
-rwxr-xr-x  1 tantos None      1373 Jun 23  1998 CIT.pstload
-rwxr-xr-x  1 tantos None     37660 Jun 23  1998 CIT.tk
-rwxr-xr-x  1 tantos None   1179648 Jun 23  1998 gzip_11.cpio
-rwxr-xr-x  1 tantos None       185 Jun 23  1998 gzip_11.vif
-rwxr-xr-x  1 tantos None      9858 Jun 23  1998 initial.install
-rwxr-xr-x  1 tantos None     13232 Jun 23  1998 initial.setup
-rwxr-xr-x  1 tantos None      1288 Jun 23  1998 Installrules
-rwxr-xr-x  1 tantos None     10948 Jun 23  1998 j90initial.install
-rwxr-xr-x  1 tantos None     10234 Jun 23  1998 j90initial.setup
-rwxr-xr-x  1 tantos None   2874137 Jun 23  1998 krn_11.bgz
-rwxr-xr-x  1 tantos None       371 Jun 23  1998 krn_11.vif
-rwxr-xr-x  1 tantos None  50331648 Jun 23  1998 ram_fs
-rwxr-xr-x  1 tantos None  23730143 Jun 23  1998 rbf_11.gzc <<<<<
-rwxr-xr-x  1 tantos None    344790 Jun 23  1998 rbf_11.vif
-rwxr-xr-x  1 tantos None      4175 Jun 23  1998 sysinfo.default
-rwxr-xr-x  1 tantos None  24224181 Jun 23  1998 uex_11.gzc <<<<<
-rwxr-xr-x  1 tantos None    163415 Jun 23  1998 uex_11.vif
-rwxr-xr-x  1 tantos None 147614750 Jun 23  1998 uni_12.gzc <<<<<
-rwxr-xr-x  1 tantos None     53626 Jun 23  1998 uni_12.vif
-rwxr-xr-x  1 tantos None 107209624 Jun 23  1998 uni_22.gzc <<<<<
-rwxr-xr-x  1 tantos None    534196 Jun 23  1998 uni_22.vif
-rwxr-xr-x  1 tantos None      3602 Jun 23  1998 UNICOS.mingle
-rwxr-xr-x  1 tantos None     38951 Jun 23  1998 UNICOS.pstload
-rwxr-xr-x  1 tantos None      3193 Jun 23  1998 UNICOS_exe.PIF
-rwxr-xr-x  1 tantos None     12280 Jun 23  1998 upgrade.install
-rwxr-xr-x  1 tantos None     17046 Jun 23  1998 upgrade.setup
-rwxr-xr-x  1 tantos None        99 Jun 23  1998 version

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!

$ gunzip -c uni_12.gzc > uni_12.c

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

$ hexdump -n 512 uni_12.c -C -v
00000000  00 00 00 00 00 00 71 c7  00 00 00 00 00 00 22 79  |......q......."y|
00000010  00 00 00 00 00 00 24 46  00 00 00 00 00 00 81 ed  |......$F........|
00000020  00 00 00 00 00 00 00 02  00 00 00 00 00 00 00 02  |................|
00000030  00 00 00 00 00 00 00 01  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 35 5c b3 09  00 00 00 00 00 00 00 09  |....5\..........|
00000090  00 00 00 00 00 07 18 28  65 74 63 2f 67 7a 69 70  |.......(etc/gzip|
000000a0  00 00 00 00 00 18 07 01  07 00 00 00 00 00 00 88  |................|
000000b0  d2 00 00 00 00 00 00 44  22 00 00 00 00 00 01 e3  |.......D".......|
000000c0  51 00 00 00 00 00 00 16  09 00 00 00 00 00 00 00  |Q...............|
000000d0  20 00 00 00 00 00 00 00  00 00 06 66 48 00 00 00  | ..........fH...|
000000e0  01 02 00 02 00 02 00 02  00 0c 00 03 dd 00 00 00  |................|
000000f0  00 57 6f 72 64 32 3d 4f  4b 57 6f 72 64 33 3d 4f  |.Word2=OKWord3=O|
00000100  4b 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |K...............|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 74 40 7a 78 7b f9 2a  79 46 80 76 82 20 80 00  |.t@zx{.*yF.v. ..|
00000130  00 00 00 30 02 10 00 00  2e 0e 01 62 88 20 40 cc  |...0.......b. @.|
00000140  c1 00 00 a3 80 00 00 00  00 47 c7 48 b7 5a 87 7a  |.........G.H.Z.z|
00000150  ba 40 c0 00 02 00 00 4c  13 1a 00 00 46 a2 80 00  |.@.....L....F...|
00000160  26 00 00 a3 80 00 26 00  00 0c 00 00 4b a3 80 00  |&.....&.....K...|
00000170  12 00 00 47 e0 4a b7 a0  00 88 d7 00 00 a2 c0 00  |...G.J..........|
00000180  09 00 00 26 90 1a 00 00  64 30 02 10 00 00 5f 0c  |...&....d0...._.|
00000190  00 02 2c 20 40 cc c1 00  00 a2 c0 00 09 00 00 52  |.., @..........R|
000001a0  03 18 00 00 64 0c 00 03  66 29 b9 ad 00 00 00 00  |....d...f)......|
000001b0  00 ad 40 00 01 00 00 ad  80 00 02 00 00 79 f9 20  |..@..........y. |
000001c0  40 bd 58 00 00 b3 c0 00  00 00 00 20 40 bd 59 00  |@.X........ @.Y.|
000001d0  00 b3 c0 00 00 00 00 20  40 bd 5a 00 00 b3 c0 00  |....... @.Z.....|
000001e0  00 00 00 78 78 b0 40 88  db 00 00 b1 00 88 d7 00  |...xx.@.........|
000001f0  00 b1 40 88 d8 00 00 b1  80 88 d9 00 00 20 80 88  |..@.......... ..|

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:

$ tree -d
.
├── bin
├── ce
│   ├── bin
│   ├── oldmon
│   ├── scripts
│   └── smarte
├── etc
│   ├── config
│   │   └── urm
│   ├── conv
│   ├── craylm
│   ├── diag
│   │   ├── oldmon
│   │   └── scripts
│   ├── install
│   ├── nulib
│   ├── privdb
│   ├── uidmaps
│   └── yp
├── lib
│   └── nls
│       └── En
├── skl
│   ├── etc
│   │   ├── config
│   │   │   └── urm
│   │   ├── nulib
│   │   ├── privdb
│   │   ├── udb_2
│   │   ├── uidmaps
│   │   └── yp
│   ├── lib
│   │   └── segdirs
│   └── usr
│       ├── adm
│       │   └── acct
│       │       └── nite
│       ├── air
│       └── lib
│           ├── acct
│           ├── array
│           ├── cron
│           └── mailx
└── usr
    ├── air
    │   ├── bin
    │   └── test
    │       ├── kern
    │       ├── msgd
    │       ├── nqs
    │       ├── tapes
    │       ├── tcp
    │       └── urm
    └── bin
        └── X11

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?

00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000050  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000060  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000070  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000080  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000090  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000000b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000000c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000000d0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000000e0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000000f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000100  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000110  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000120  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000130  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000140  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000150  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000160  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000170  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000180  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000190  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000001a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000001b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000001c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000001d0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000001e0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000001f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

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

00001000  6e 63 31 66 73 31 63 6e  52 41 4d 46 53 00 00 00  |nc1fs1cnRAMFS...|
00001010  52 41 4d 46 53 00 00 00  00 00 00 00 00 00 22 57  |RAMFS........."W|
00001020  00 00 00 00 00 00 30 00  00 00 00 00 00 00 0c 00  |......0.........|
00001030  00 00 00 00 00 00 80 00  00 00 00 00 00 00 00 00  |................|
00001040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001060  00 00 00 00 35 5d cd 66  00 00 00 00 00 00 00 0c  |....5].f........|
00001070  00 00 00 00 00 00 00 02  00 00 00 00 00 00 00 00  |................|
00001080  00 00 00 00 00 00 00 0b  00 00 00 00 00 00 00 01  |................|
00001090  00 00 00 00 00 00 00 0a  00 00 00 00 00 00 00 01  |................|
000010a0  00 00 00 00 00 00 00 04  00 00 00 01 00 00 00 ce  |................|
000010b0  00 00 00 00 00 00 20 02  72 61 6d 5f 66 73 00 00  |...... .ram_fs..|
000010c0  00 00 00 00 00 00 30 00  00 00 00 c1 00 00 00 0d  |......0.........|
000010d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000010e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000010f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000011a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000011b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000011c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000011d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000011e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000011f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

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:

00000000  30 37 30 37 30 37 30 32  31 31 37 31 30 30 30 30  |0707070211710000|
00000010  30 31 31 30 30 37 35 35  30 33 30 37 37 33 30 33  |0110075503077303|
00000020  35 30 36 37 30 30 30 30  30 31 30 30 30 30 30 30  |5067000001000000|
00000030  30 36 35 32 37 33 32 33  37 36 37 30 30 30 30 30  |0652732376700000|
00000040  37 30 30 30 30 30 30 31  30 32 36 30 63 6c 72 79  |700000010260clry|
00000050  6d 70 00 00 00 00 00 18  07 01 07 00 00 00 00 00  |mp..............|
00000060  00 02 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 0e 00 00 00 00 00  |................|
00000080  00 00 84 00 00 00 00 00  00 00 00 00 00 00 40 00  |..............@.|
00000090  00 00 01 00 00 00 84 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 ff ff ff 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 ff ff ff 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 09 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 01 1f 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 ff ff ff 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 ff ff ff 00  00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 09 00  00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000190  00 00 00 00 00 00 00 00  00 00 00 a0 40 00 20 00  |............@. .|
000001a0  00 46 90 48 ca b0 c0 00  e5 00 00 5a b0 48 ca 58  |.F.H.......Z.H.X|
000001b0  cf b0 c0 00 e6 00 00 5a  b0 48 ca 5a f0 52 03 1a  |.......Z.H.Z.R..|
000001c0  00 00 9b 40 c0 00 10 00  00 b0 c0 00 e7 00 00 5a  |...@...........Z|
000001d0  b0 48 ca b0 c0 00 e8 00  00 25 50 25 82 33 c0 a0  |.H.......%P%.3..|
000001e0  40 00 e6 00 00 58 41 31  f8 52 01 18 00 00 b7 1c  |@....XA1.R......|
000001f0  00 00 a9 35 3e 31 25 02  a1 31 20 02 a0 0c 00 00  |...5>1%..1 .....|

I recognize this! This is a CPIO archive.

$ mv krn_11.b krn_11.cpio
$ cpio -t < krn_11.cpio
clrymp
grsysdmp
mfboot
mfchkye
mfsysdmp
unicos.generic
18381 blocks

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

00000000  00 00 00 00 00 07 01 07  00 00 00 00 00 0f ab eb  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 10 74 f6  |..............t.|
00000020  00 00 00 00 00 01 37 7c  00 00 00 00 00 00 00 a8  |......7|........|
00000030  00 00 00 00 00 00 00 00  00 00 00 40 00 00 00 01  |...........@....|
00000040  00 00 00 a8 00 00 00 88  00 00 00 00 00 00 01 00  |................|
00000050  00 ff ff fc 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 ff ff fc 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 09 eb 00 00 00 00  00 00 00 04 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  4a 42 6b 63 6f 6d 70 72  |........JBkcompr|
00000170  00 00 00 00 00 40 bd 12  00 00 00 00 00 10 74 f6  |.....@........t.|
00000180  00 00 00 00 00 0f ab eb  00 00 00 00 00 00 02 00  |................|
00000190  90 00 00 4a 00 00 90 40  00 4b 00 00 90 80 00 4c  |...J...@.K.....L|
000001a0  00 00 90 c0 00 4d 00 00  b0 00 00 4e 00 00 b0 40  |.....M.....N...@|
000001b0  00 4f 00 00 b0 80 00 50  00 00 30 02 10 00 00 c9  |.O.....P..0.....|
000001c0  80 40 00 28 00 00 80 80  00 27 00 00 30 8a 0c 00  |.@.(.....'..0...|
000001d0  00 e6 60 b9 26 50 20 c0  02 00 00 00 30 4b 80 80  |..`.&P .....0K..|
000001e0  00 27 00 00 72 42 30 8a  61 21 61 f9 80 c0 00 28  |.'..rB0.a!a....(|
000001f0  00 00 32 0b 16 00 00 e6  a2 40 00 00 00 00 b4 40  |..2......@.....@|

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!

Leave a comment

Comments are reviewed before they are published, so yours will not show up right away.

You can use **strong** and *italic* text, `code`, and lists (lines starting with - or 1.). Everything else, HTML included, is shown as it was typed.