In short
With the last set of changes, I can boot the full COS operating system.
Booting the system the first time
Download the updated image (version 0.82) from the download page. Then open a command prompt, and type cray_xmp_sim xmp_sim.cfg in the ‘bin’ directory. This will start the simulator.
In order to boot the OS the first time, you have to do something called ‘install’. What this does essentially is to initialize all the hard-drives (formatting if you wish). To start the process, you’ll have to start the simulator. It will pup-up three consoles with similar content. Look for the one, that corresponds to IOP-0:
In the prompt at the bottom, type in a date between 1989 and 1999! I usually use 01/01/89. The next prompt asks you for the time. I’ve used 01:01:01 in this example, but any valid time should work. If the system accepts your input, it echoes back the date and the time like this:
Now you’re in the IOP console prompt. Here you can issue several commands (type in HELP to see a list). The one we’ll use is the ‘START’ command. This loads the specified OS image and parameter file from the IOP (expander) hard-drive into to the mainframe, and start the main CPU(s). On the disk there’s an OS image, called COS_117 and a prepared install parameter file, called INSTALL. So, the command you need to type in is: START COS_117 INSTALL. A short while later, the main CPU is released from reset, the communication path between the IOP and the main CPU is established, and the following messages appear on the console:
At this stage, we’re ready to start the Cray Station SW, which is essentially the console to the COS operating system. The command to do that is STATION. When you hit enter, the following window will appear on your screen:
This is the main screen on the Cray Station. Here you have a different set of commands to play with than in the IOP console, again HELP gives you a list. The first thing we need to do is to log on to the system. You do that with the ‘LOGON’ command:
If the logon finishes, the OS greets you with it’s version number and build date. Also notice at the top of the screen the letter ‘L’ appeared. This tells you the console is logged on. The letter ‘M’ informs you about unread messages. To see them, you need the ‘STMSG’ (station message) command:
Here you could change the supplied configuration options, but you don’t need to do that. You can let the system continue booting by typing in REPLY,0,GO. This means that you reply to message ‘0’ with ‘GO’:
In a short while another message pops up:
You reply to it the same way you did to the previous one (REPLY,1,GO):
Now, the install process really starts. And it takes a long time. On a fast machine, it takes about 10-15 mintes. So, while you’re waiting, you can check certain things out. For example, you can check the progress by looking at information messages (STMSG,INFO command):
Or, you can look at how busy the various parts of the STP (System Task Processor) process are (STP command):
Eventually the system finishes the install process and starts up. At that point you should see the following in your STMSG,INFO display:
There’s more though, so you can flip between the frames with the ‘+’ and ‘-‘ keys. The second frame shows this:
The last message is the key one. It tells you that the system is fully booted and is operational now. I’ve created a short video of the boot process as well:
Subsequent boots
Once you waited through the install process, you can get the system up and running much faster. This is called the ‘deadstart’ option, where the system is booted from a cold state, but the content of the hard drives is preserved. The initial part of the boot is the same, the first difference is the parameter file that you give to the START command: instead of ‘INSTALL’, you specify ‘DEADSTART’:
Once the system loaded the files, you can start the Cray Station and log on just as before:
The STMSG command asks you about configuration changes, just as before, simply reply with go (REPLY,0,GO).
Next, you’re asked about the missing label on the BMR-0-20 drive. This is a RAM-disk drive, which of course doesn’t preserve it’s content between boots. According to the COS Operational Procedures Reference Manual, this message is displayed unless the *RESTORE directive is present in the parameter. File. I’m not sure why the OS assumes a volatile device would preserve it’s content between boots. Maybe this is just a safety feature to prevent accidental automatic re-writes of the disk label during warm-boots. At any rate, type in REPLY,10,CONTINUE to re-write the disk label to this RAM-disk.
At this point the booting starts, and just as before, you can check the progress with the STMSG,INFO command:
After some time, some new messages appear:
And just as with install, there’s (eventually) more on the second frame:
Here, again, the last message informs you about a fully booted system. You can watch a video of this type of boot as well:
Noticed your comment regarding persistent ram disks…
Not sure about these CDC systems, but slightly earlier
ram disks used core memory, which persists across
power cycles.
-brian
Thanks for your comment!
This particular machine had a MOS memory (SRAM I would think) for RAM-disks. It also had an SSD option that I don’t know much about, that might have been persistent.
WOW! Brilliant work: from deducing the manchester encoding on the raw magnetic photographs to coding the main & I/O CPUs. In the 70’s all I could do was make my own 8080 (2K Ram) based computer. I also aquired some old ICL EDS 8 hard drives and got them to work with my little “toy”. I could only dream about the likes of Cray and the other big iron stuff. You have allowed me to experience the type of system I was dreaming about: without the large power and maintenance bills! Thank you! As a programmer, I appreciate what you’ve done and the huge amount of work it must have taken. The modern stuff takes out all the romance and “hands on” understanding you had to have to operate those beasts. I can write source that will compile on Linux, Win32/64 & Android and not have any concern about the hardware. How things have changed.
SRAM usually persists for quite some time after the power is out. In other words, chances are that an SRAM disk would retain it’s state for minutes, possibly longer.
Now it’s just waiting for someone to program Craysis….
Workbook for CRAY-1S with IOP and STATION commands and their description.
They work on your emulator too.
Detailed one is T0201D… in the same dir.
Fantastic work and lots of interesting info. Didnt all young computer nerds dream about the magical Cray and its vector driven mechanics 🙂
Ive successfully run and installed the cos under linux wine. Did notice the simulator called out for MPCAP or something similar. Are you planning on networking the simulator one day? Would love to see native simulator on linux or other unix.
Thanks!
The simulator uses TCP/IP to communicate with the consoles. That’s all the networking in there. In theory the ‘FrontEnd interface’ was what you would call these days the network, but the protocol was very complex, so writing a client would be a lot of work.
As far as Linux support goes, I’m working on it. It was always my intent that the code would work under it, but along the way something got borken. At the moment (the the release version, but what I have locally) compiles just fine, but doesn’t run properly under any GCC-based environment. I don’t know yet why, but once I’ve figured it out I’ll post a new release.
This software is not working on Windows XP (32bit) !. All exe files are producing error “is not a valid Win32 application”.
Please fix it – 40% of power users are using XP! You cant ignore that
True, I didn’t know about this issue. Thanks for bringing it to my attention. I’ll fix this in the next release. In the meantime, you can re-compile locally, just change the ‘platform toolset’ to v110_xp. See http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx for details.
I found the problem:I did not restore the system; this is the (quite obvious)
reason why it did not work! 🙁
Sorry for the inconvenience,
lg
Interesting. COS_117_1 has a newer creation date. June instead of February.
The creation dates on these files are totally arbitrary and set when you create the extender disk image using exp_disk_create. In fact it doesn’t even have to be a date, it’s just two 8-char long strings. I’m not sure why it would be different though then the rest.
Oh, I was referring to the date given after LOGON. COS_117_1 was assembled in June, apparently versus COS_117 which was assembled in February.
Hello Andras.
I’m very impressed with your work with the CRAY emulator and since I’m such a hopeless computer romantic, the CRAY – especially the CRAY 2, is one of my obsessions. When I found out about your work I just had to give it a try (naturally)… 🙂
After a few minor problems with compilation under Linux (Kali 1.0.9) I managed to get the CONSOLE software running in the emulator and the COS INSTALL running in the CON.
After a while however, the INSTALL process crasches the emulator.
After installing boost libraries before I successfully managed to compile the software.
(The GCC version used is 4.7.2 and BOOST version is 1.49) This I specified in the ‘common.mak’ -file before the emulator compiled successfully.
The Linux environment runs natively on the computer (a Panasonic CF-19 Toughbook with 4 GB of RAM). No virtual environment like WMWare.
Link below is a screenshot of the emulator console (launch terminal window) showing the burp line after the crash. Also note the directory listing from where the emulator was launced: There is no less than 9 disk image dumps which of 8 is 606,8 MB and 1 is 73,7 kB. This happens a few minutes after the INSTALL procedure is launced from COS CON. The CTRL-X was not pressed as stated…
Is it correct that there should be this many disk dumps? (I have seen these also while the emulator is still running.) I used to delete the oldest intstances to see if the emulator survives but no matter what I do so far, the COS crashes after a while.
https://www.dropbox.com/s/wu93kkux8fqb256/Screenshot%20from%202015-01-19%2006%3A49%3A02.png?dl=0
My very best regards!
// Mike
Mike!
Thanks for trying the SW out. From what I see everything seems normal with the disk files – except for the crash of course. Assuming you’re using the latest sources, the problem seems to be in the simulator trying to read over the end of exp_disk.img. The disk files are kosher. In this particular machine there were 8 ~600MB hard drives for the mainframe and an ~80MB one for the I/O console. If you deleted exp_disk.img, that could be a problem, though the file size seems to be right on the screen-shot. The simulator also creates a number of memory dumps, 5 or 6 when it terminates. One for each I/O processor, one for the main memory and one for the buffer memory. This machine had a very fragmented memory architecture with lots of different address spaces you see. One thing you can try (though I actually doubt it is the root of the problem) is to set the simulation to single-threaded. You can do that by changing this line in the xmp_sim.cfg file:
MultiThreaded yes
to
MultiThreaded no
You can also try to diagnose the problem by looking at the content of the exp_disk.img file. When you boot up the simulator, and after entering the date and time, type in FSTAT to see the file listing. You should see this:
FSTAT
FILE CREATED WORDS
IOPBOOT 01/01/89 01:01:01 5120
COS_117 01/01/89 01:01:01 279040
COS_117_1 01/01/89 01:01:01 285696
COS_117_2 01/01/89 01:01:01 279040
CSP2 01/01/89 01:01:01 47339
JDIAGGO 01/01/89 01:01:01 190
JFLUSH 01/01/89 01:01:01 37
JGENCAT 01/01/89 01:01:01 48
JINSTALL 01/01/89 01:01:01 1008
JSYSDIR 01/01/89 01:01:01 31
JTEST30 01/01/89 01:01:01 34
RECALL 01/01/89 01:01:01 44
DEADSTART 01/01/89 01:01:01 69
RESTART 01/01/89 01:01:01 80
INSTALL 01/01/89 01:01:01 79
TOTAL ————— 897855
FSTAT COMPLETE
I hope this helps, and thanks again for the feedback!
Andras