So over on Modular Circuits, Andras had posted a promising ‘UNICOS Update‘ which had detailed that 2 CD-ROM’s of Unicos had surfaced on archive.org cray-cd1 & cray-cd2. Along with posting the updated source to github, so I had no choice to replicate the experiment!
First the install is INSANELY slow. It requires you to setup a Linux (or unix) machine with rsh. Surprisingly there is a rsh-server package for Ubuntu 22.04. Basically it boils down to following the instructions. Although with WSLv2 I ended up making the bridge manually with:
brctl addbr craybr ip tuntap add mode tap tap1 ifconfig tap1 up brctl addif craybr tap1 ifconfig craybr 172.16.0.1 netmask 255.255.255.0
It’s coded in the example configs to use tap1, but there you go. It’s a pretty straightfoward install but the decompression on the cray side takes the installation hours. As an experiment I changed the commands from rcp to remsh to gzip -dc the files locally on my PC, which had the benefit of of being much faster, and not taking up space.
I went ahead and uploaded both of my installs for anyone wanting to play OS tourist enough to check out UNICOS but not wanting to sit through the install.
The C compiler is.. ancient. and very touchy. You’ll need to add /usr/gen/bin to the path, and explicitly add the path for the linker like this:
/usr/gen/bin/cc zap.c -L/usr/gen/lib
Although the breakage is.. pretty epic. I had pretty much no luck bringing over any of my favorites. There should be a much better / modernish C compiler and Fortran compiler, although I’m not sure if it’s on these CD-ROM’s or I’m just massively ignorant of UNICOS, because I never got a chance to be anywhere near a legit supercomputer.
(This is a guest post by Antoni Sawicki aka Tenox)
Project Monterey was an attempt to unify the fragmented Unix market of the 90s in to a single, cross vendor Unix OS that would run on the upcoming Intel Itanium (and others) CPU. The main collaborators were: IBM, who brought its AIX, SCO brought UnixWare, HP was supposed to bring parts of HP-UX and SequentDYNIX/ptx. Ironically the project shared fate of the Itanium CPU—it totally failed. In the end Linux took spot of the “single Unix OS”. IBM donated AIX pieces to Linux instead and the main legacy of Project Monterey was the famous SCO vs IBM lawsuit.
IBM did however produce AIX version for the Itanium architecture! According to Wikipedia, some 30+ licenses were sold in 2001-2002. For years a dedicated group of individuals was trying to locate a copy of the legendary OS. It seemed that the OS was lost forever…
…until some 21 years later friends of NCommander checked in with a set of AIX5L IA64 CDROMS! The CDs have now been dumped and you can download them here. Unfortunately downloading will not get you much closer to actually running this. As of today no publicly available virtualization or emulation platform can boot this. Yes we tried Simics, looked at QEMU IA64 and XEN/KVM for IA64, etc. The OS will not boot on modern Itanium 2 (McKinley) CPUs, only the early “pre-release” Itanium 1 aka Merced. The only emulator allegedly capable of doing so was the super elusive unobtanium called Intel SoftSDV.
It’s currently speculated that AIX5L IA64 will work on and only on so called “Intel Software Development Vehicle (SDV)” sometimes referred to as “Intel Engineering Sample”. It was an Intel made machine, later sold in several OEM branded version: IBM IntelliStation Z Pro 6894, HP i2000 Workstation, SGI 750, Dell Precision Workstation 730 and Fujitsu-Siemens Celsius 880.
…yes, they all look alike because all of them were in fact produced by Intel with custom case badges and paints.
Luckily I was able to score a working HP i2000. AIX booted up and installed on a first try:
Initially I was not able to get the onboard NIC working. Upon short investigation AIX5L IA64 supports only two network cards:
Luckily again I was able to find a working NIC on eBay!
The system comes with X11 and CDE but so far I was not able to get any GPU working beyond basic text mode. I tried many different video cards from that era but there simply doesn’t appear to be any driver in the OS except for basic VGA / LFT. I think the key to getting video working is the previously mentioned extended hardware drivers cd.
Finally, if you want to read more I have found some interesting pieces on ibmfiles and various mirrors here and here.
Well this is a bit ambiguous. As Im waking up to check emails I get this notice:
Congratulations! Ancient UNIX/BSD emulation on Windows has just been recognized with the following awards by SourceForge:
Community Choice SourceForge Favorite
These honors are awarded only to select projects that have reached significant milestones in terms of downloads and user engagement from the SourceForge community.
This is a big achievement, as your project has qualified for these awards out of over 500,000 open source projects on SourceForge. SourceForge sees nearly 30 million users per month looking for, and developing, open source software. These award badges will now appear on your project page, and the award assets can be found in your project admin section.
Since I’ve been dealing with XHomer a lot lately in order to get the two dumped VENIX/PRO versions to work, I noticed that the XHomer documentation mentions a thing called “maintenance mode” and the DEC Pro port of 2.9BSD, so I was interested.
After doing a bit of searching around I found some install notes on www.frijid.net from real hardware, so I decided to adapt these notes for XHomer and install it. TL;DR – I did it, here I’m explaining all this stuff.
Step 1 – Acquiring XHomer
XHomer is a DEC Pro 350 emulator that can run P/OS, Venix, 2.9BSD and possibly RT-11, but I didn’t get to installing the last one yet. There is a statically linked binary but, since I’m a Gentoo Linux person (but I didn’t use Gentoo for this particular install)and prefer compiling everything I can, I grabbed the source code (https://xhomer.isani.org/xhomer/xhomer-9-16-06.tgz) and quickly compiled it on my Linux box. It was pretty simple, just install a development toolchain (build-essential on Debian based systems), the libX11 development package (libx11-dev on Debian based systems) and the XShm extension which is included in libxext-dev on Debian based systems. During make it spit out a bunch of warnings but I got a working xhomer binary. Also it kind of messes the xterm settings a bit after being closed, so I’d recommend running it in a separate xterm window. Since there’s no install target in the Makefile I just copied the xhomer binary to /usr/bin, and that was it. From here on, I will assume that the XHomer binary is called xhomer and is somewhere in your PATH, if not just modify the way I run XHomer.
Step 2 – Acquiring the distribution
Thanks to the people at the same www.frijid.net site I mentioned earlier, I was able to easily piece together a distribution set. Since we don’t really rely on how many physical floppies we have with an emulator, I grabbed the recommended root disk set and the 15 disk usr set with the source code, although we won’t be compiling the kernel in this post. Maybe next one? We’ll see.
The site with the floppies is http://www.frijid.net/download/pro350/bsd/raw/ and here’s what I used for my install:
The 3 disk usr set in box#2/ doesn’t include the source, so I didn’t grab it. The maintenance disks are all the same, so I just grabbed the one in box#0/. The 6 disk root set in box#0/ does include some extra dev files and something that appear to be leftovers from the development DEC Pro, but it’s missing /bin/ed and /bin/passwd, so I suggest using the 5 disk set instead.
There is also box#2/procomm.img which was labeled as containing “PRO/COMM terminal emulation” but when I mounted it to install, there was only an empty lost+found directory. Perhaps the original disk had gone bad over the years or someone accidentally reformatted it? We may never know.
Step 3 – XHomer configuration & serial port preparation
Since the maintenance (install) floppy uses a serial terminal interface over the printer port and XHomer only allows us to send its output over serial, I had to do some searching again since most PCs nowadays don’t have a serial port to use. Thanks to cantoni over at StackOverflow I managed to find instructions for using socat in order to generate a pty, which actually worked for me. At first you need to install socat (bruh) and then run “socat -d -d pty,raw,echo=0 pty,raw,echo=0”. Something like this will be printed out on the terminal:
Then we do a quick test. I use putty to connect to the pty’s output, in my case it’s /dev/pts/3. Just use the default settings for serial connection with speed 9600 and the device as /dev/pts/3. If everything goes well, you will get a blank putty terminal window. Don’t panic, the fact it’s blank is normal.
Let’s test if our serial port works. Echo something in the pty’s input, in my case it’s /dev/pts/4. For example, “echo “Test” > /dev/pts/4″. If the word “Test” appears on the screen, congratulations, you have successfully set up the pty to a point where BSD will happily talk to it when we set up the connection later. !! DO NOT CLOSE THE PUTTY WINDOW AT ANY POINT DURING THE INSTALL UNTIL WE NO LONGER NEED IT (at the initial hd boot) !!
Now we configure XHomer. At first, let’s make a disk image. BSD only supports RD51 or RD50, we’ll use RD51 as it’s slightly bigger. If you get the hard disk wrong, BSD will silently hang at boot. Here’s the command to make a 10MB RD51 disk image for use with XHomer:
dd if=/dev/zero of=29bsd.rd bs=10027008 count=1
Let’s make the XHomer config file. Note that everything after the symbol | including the symbol itself does not need to be inputed, it’s just my notes.
screen = window | make the emulator window mode window_position = 0, 0 window_scale = 2 full_scale = 3 screen_gamma = 10 pcm = on framebuffers = 0 serial0 = /dev/pts/4 | change to your needs, pty input la50 = null la50_dpi = 300 kb = lk201 ptr = serial0 | DO NOT CHANGE, we'll replace it later when we no longer need serial com = null rd_dir = ./ rx_dir = ./ rd0 = 29bsd.rd, 4, 306, 16 | change if not using suggested disk force_year = 99 | fix y2k bugs by forcing year to 1999 maint_mode = on | DO NOT CHANGE, bsd install uses maintenance mode for terminal int_throttle = off | random workarounds for clocks or older linux systems, we don't need this on new stuff nine_workaround = off libc_workaround = off lp_workaround = off
Save the file as xhomer.cfg.
Now run the xhomer binary. If everything goes right, you should have something like this on your screen:
If you didn’t run the test documented above or changed the string, the “Test” string will not be in the terminal or will be some other text, this is all okay.
Step 4 – BSD install
In order to feed floppies to XHomer, you have to use the XHomer control menu. In order to get to it, press Ctrl+F1 when the emulator window has focus. The two floppy drives we need are rx0: and rx1:, these are equivalents of A: and B: in DOS. Insert the maintenance0.img disk in rx0. If all goes okay, the floppy disk picture should disappear from the display window, leaving just the DIGITAL logo. The putty window should then display something like this:
(all following input is in the terminal unless otherwise stated)
If all is okay, congratulations, you have booted from the installation diskette. Now type the following in the putty window after the : symbol:
Then, if you inserted an RD51 10MB disk in the emulator as suggested, type 0 when asked for drive type. If you inserted the 5MB RD50 instead, type 1. If you don’t know the exact disk sizes and types, refer to the XHomer documentation, specifically the Emulated Hard Disk part. The formatting shouldn’t take long, then it will dump you back in the 40Boot prompt. Now you need to boot the UNIX kernel, type this in the putty window:
If everything goes okay, you should have something like this now:
If you get a boot hang instead (like me), restart both XHomer and putty, connect putty back to the pty, then in XHome insert the maintenance0 floppy back and boot the UNIX kernel again. DO NOT FORMAT THE DRIVE AGAIN!!
At first, create the root filesystem by running:
/etc/mkfs /dev/rrd0a 2240
Then insert the root1 disk in the 2nd floppy drive (rx1) and restore the root filesystem dump from the 5 root set floppies:
restor rf /dev/rr51 /dev/rrd0a
When it says “Last chance before scribbling on /dev/rrd0a.” just press Enter. When it says “Mount volume N”, just insert the right floppy and press Enter. Volume number == floppy number in this case.
After the “end of tape” message, verify the rootfs:
If it succeeds, create the usr filesystem by running:
/etc/mkfs /dev/rrd0c 6528
Then insert the usr+k00 disk in the 2nd floppy drive (rx1) and restore the usr filesystem dump from the 16 usr set floppies:
restor rf /dev/rr51 /dev/rrd0c
When it says “Last chance before scribbling on /dev/rrd0c.” just press Enter. When it says “Mount volume N”, just insert the right floppy and press Enter. Floppy number == volume number – 1 in this case.
After the “end of tape” message, verify the usr fs:
(all following input is in on the Pro display unless otherwise stated)
If everything is okay, run sync two times and shut down the emulator. Restart it with only the maintenance floppy in rx0, then type this in the terminal (NOT the Pro display):
This should boot up Berkeley UNIX (BSD). We’re not done yet, but it’s close.
Type the following to install the hard disk bootblock:
dd if=/rdboot of=/dev/rrd0h count=17
If everything goes okay, set the root password:
Congratulations, you have successfully installed 2.9BSD. Here are the cleanup and hdboot prep stuff:
Bring the OS to single user mode:
(you can close putty now)
Then run sync two times and shut down the emulator.
Step 5 – Booting the OS
In order to boot the OS, you need to do the following:
Open the xhomer.cfg file;
Remove the serial0 = line;
Change the ptr = serial0 line to ptr = null;
Change the maint_mode = on to maint_mode = off.
Then save, after running XHomer you should be able to just log in.
Congratulations, you have successfully installed 2.9BSD for the DEC Pro 350! Sadly it’s pretty unstable, and due to emulation issues in XHomer vi completely crashes BSD, but there’s always ed 😉
Appendix A – Transferring Files
In order to transfer the files (up to 400KB per file) you will need some additional utilities. Here’s a guide on how to install them:
(the following steps are done on the Linux host side)
Run XHomer and attach the generated rx2f.c.dsk to rx0
(the following steps are done on the BSD side)
Grab the file from the floppy:
dd if=/dev/r50 of=rx2f.c skip=18 bs=1 count=891
Compile the utility:
cc -o rx2f rx2f.c
You’re now ready to transfer files.
Short file transfer handbook:
Run f2rx FILE on the host box, FILE being the file to use;
Insert FILE.dsk into rx0 on XHomer;
Run rx2f on the BSD side.
Appendix B – Init: no more children issue workaround
On some hosts, programs from the install floppy may randomly die with the “no more children” message. A workaround is to disable RTC mode and enable IOTRACE mode in the XHomer Makefile and recompile, leading to a much more slower (due to accurate timing) and working XHomer. After the installation, you can revert to normal settings and it should work, as the programs installed on the hard drive to not appear to suffer from the same issue.
Appendix C – Sequels
Possibly coming soon to VirtuallyFun:
Undocumented Madness 2 – Big hard drives on 2.9BSD XHomer Undocumented Madness 3 – Custom Kernel on 2.9BSD XHomer
Despite Gould’s location being a few minutes drive from where I first arrived in America, I never had any idea they existed, were making their own exciting machines, or were even a Unix VAR. At a time during the Unix wars one was left to choose SYSV or BSD, but Gould had gone another direction with UTX with a ‘why not both’ approach. Truly an 80’s miracle of Unix.
Even better he’s included tape images, and working INI files which I was able to make into a working system! (after some help with a tape bug)
File is COFF format
-> section (.bss) size (177960) clearing at (0xcbc18)
-> section (.text) size (724800) loading at (0x1200)
-> section (.data) size (105176) loading at (0xb2140)
UTX/32 2.1B (exp) #0: Mon Apr 10 19:46:05 GMT 1989
V6 CPUIPU(P) configuration (IPU not present)
top of system = 0x400000
real mem = 8388608
End of kernel map 0x218464
avail memory = 7356416
using 256 buffers containing 262144 bytes of memory
using 256 mirror buffer headers
ioi: channel iop0 at 7e00 online
ioi: channel dc0 at 800 online
ioi: channel dc1 at c00 not present, dci cc=2
ioi: channel dc2 at 400 not present, dci cc=2
ioi: channel tc0 at 1000 online
ioi: channel en0 at e00 online
-- CHECK AND RESET THE DATE!
swapping on the b partition
dmmax 512 mbswap 3576
Checking root filesystem
Check commented out, uncomment once you have edited /etc/fstab!
Automatic reboot in progress...
Mon Aug 30 05:35:46 CDT 2021
/etc/fsck -p /dev/rdk0d
/etc/fsck -p /dev/rdk0e
/etc/fsck -p /dev/rdk0f
File systems OK
Mon Aug 30 05:36:06 CDT 2021
Mounting file systems
/dev/dk0d mounted on /usr.POWERNODE
/dev/dk0e mounted on /home
/dev/dk0f mounted on /usr/local
Starting line printer daemon
Starting standard daemons: update cron.
Adding swap partitions
Standard setup functions
Invoke local rc file
dumpdirectory: No such file or directory
Starting Syslog Daemon
Starting local daemons: inetd.
Starting NFS/RPC daemons: portmap sund.
Mounting NFS filesystems
Checking aliases file
Preserving editor files
Clearing /tmp - does not remove directories
Clearing pseudo terminals
Mon Aug 30 05:36:07 CDT 2021
GOULD UTX/32 2.1B (noname) (console)
It’s very BSD feeling on the boot and in the /usr directory there is 5bin 5lib
Sadly transferring stuff by just pasting on the console reveals that there is some IO issues in the simulator:
syncing disks... done
dumping to dev 101, offset 11776
ioi: channel dc0 at 800 online
As a matter of fact doing anything too fast can/will panic the simulator. That goes for Ethernet and additional serial ports.
Interesting highlights of the platform:
Produced by hard-params version 4.1, CWI, Amsterdam
Compiler does not claim to be ANSI C
Char = 8 bits, signed
Short=16 int=32 long=32 float=32 double=64 bits
Char pointers = 32 bits
Int pointers = 32 bits
Alignments used for char=1 short=2 int=4 long=4
Obvious issues with the platform is a lack of GCC. The PCC compiler while standard for early 80’s non PDP-11/VAX machines is a bit lacking as the years went on. I was unable to build gzip due to the following error:
cc -o gzip gzip.o zip.o deflate.o trees.o bits.o unzip.o inflate.o util.o crypt.o lzw.o unlzw.o unpack.o unlzh.o getopt.o
ld: warning: near subsegments too big for static base spanning
no base for reloc of memref instruction at .nbtext+0x18 relative to symbol _progname
1221 more 'no base ' errors
gmake: *** [gzip] Error 4
Sadly I don’t find much on Altavista other than this & this. It only offers this terse comment:
The constraints on address space on a Gould are quite severe.
Bummer. Additionally neither Hack 1.0/1.03 or PDP-11 Hack will build either. Surprisingly bash-1.14.7, make-3.75 and ircii-2.5 compiled. Obviously with no networking IRC is kind of pointless.
It’s an interesting time capsule of life outside of AT&T/CSRG or SUN, going in a different direction. It seems like a larger lost opportunity to take their ‘it runs both’ approach software and not have it available on different platforms. Granted for a hardware company once the software leaves the compelling reason to buy the hardware evaporates. Hello NeXT.
If anyone wants to try to re-create it, download and build the SEL32 emulator from github, and I put my vague instructions here.
Or for like minded OS tourists, you can give it a spin here: UTX32_2.1B.7z. I included a ‘9346-UTX-blank.disk’ file which is already prepared if you don’t want to go through the 15 questions to prep a disk. Likewise I made a ‘9346-UTX-biga-blank.disk’ image which is just a single large ‘a’ partition as it’s trivial to just add a bunch of big disks these days.
Full 32bit Unix machines from Ft Lauderdale! Who knew?
I was inspired by NCommander’s MinGW to Solaris cross compiler so I thought I’d dig out the one that got me started decades ago, cross compiling to the RS/6000 from Linux some time back in 1993. For this experiment I was able to beg/borrow a copy of /usr/lib & /usr/include from AIX 3.2.5 and wanted to use that as a base. I decided to use GCC 22.214.171.124 and Binutils 2.11.2 as these were old enough t build somewhat easy enough from MinGW/MSYS 1, but I figured they also had the best luck of being able to parse the headers without needing ‘fixinc’.
I was able to build both binutils and GCC with this simple incanation
sh configure --target=ppc-ibm-aix325 --prefix=/aix3
One weird thing was that binutils completely sidestepped ld, so I had to configure that manually like this:
Also ‘eaixppc.c’ didn’t generate properly I had to rebuild binutils from Linux to get it to pick up and build that file, copy that back in to get a working cross linker. Older stuff has some issues with CR/LF from time to time, and sometimes it’s easier to deal with builds from other systems and pluck files as needed.
exec(): 0509-036 Cannot load program /cdrom/demo/hello/hello because of the following errors: 0509-150 Dependent module libc.a(shr.o) could not be loaded. 0509-022 Cannot load module libc.a(shr.o). 0509-026 System error: A file or directory in the path name does not exist.
In the previous post we managed to install a Compaq-branded version of SCO Open Desktop. One of the recommendations was to use a small hard drive and avoid LBA, since SCO Unix does not recognize it.
It turns out, however, that SLS UOD429A, the bootdisk + patch that we used in the first post of this series to install ODT, also adds LBA support (as found out on A.P. Lawrence’s excellent website).
Apart from enabling you to fully use larger disks (you can install on a disk larger than 2048 cylinders, as long as you set its size to 2048 cyls during installation; you are of course going to “waste” a lot of space), LBA is more convenient if you want to have a large root partition, since the root partition has to be entirely in the first 1024 cyls.
So of course I tried repeating the installation of the Compaq version by booting off UOD429A, inserting the N2 from SCO ODT, and… I quickly found out that it would not recognize the CD as a valid installation media. Annoying.
Eventually I found out that the N1 disk from Compaq has a ramdrive compressed in the kernel, from where the initial installation script is run, while the rest of the files (mostly installscript) are on the CD itself.
The fix was, in the end, relatively simple. All I needed to do was mounting the N2 floppy in the VM I had created before, copying “N2.Z” on my harddrive. I then uncompress-ed it, extracted it (it’s a regular tar file), and replaced the installation script with the one provided on Compaq’s CD. Then, the reverse process can be done: recreate the “N2” tar file, compress it, and copy it in the mounted N2 disk. If you don’t want to go through the same process again, you can download the patched disk.
The installation process is then simple: boot off UOD429A, insert the updated N2 disk when requested, and proceed with the rest of the installation as usual.
This way I managed to install SCO Unix on a TI TravelMate 6050, alongside DOS and Windows 95. It took a bit of trial and error (reading SCO technical support documents was, again, very helpful), but in the end this is more or less what I did:
install Unix as LBA with a ~20mb DOS partition
hide DOS partition & create a new one as primary active partition
install Win95 on that
install boot manager (I used Paragon’s Boot Magic) on first DOS partition (the hidden one)
Steps 1 and 2 were done in 86box, after creating a disk with the same cylinders, heads and sectors found in the BIOS of my TravelMate (using the LBA setting in the BIOS of both laptop and emulated machine, of course). After installing DOS and SCO Unix (I’m not sure anymore in which order), I copied the Win95 installation files on the new partition and finished the installation process on the laptop, after dd-ing the image to the CF card I’m using as hard drive.
After configuring Boot Magic (and creating a custom background and icon), now I’m greeted with this every time I boot up the laptop:
Since Windows 95 is installed in a FAT16 partition, I can mount it or access it via dosls/doscp inside SCO Unix too, which is convenient for sharing files (I tried installing a 3Com 3C589 PCMCIA card directly in Unix, since according to the docs it’s supported; unfortunately, the provided drivers only work with IBM PCMCIA controllers).
SCO Unix software
A large collection of ports for SCO Unix can be found at ftp.celestial.com, but it’s faster to use the ISO with all the ports I uploaded on archive.org. To mount the CD with lowercase filenames, run #mount -rf HS /dev/cd0 /mnt
It’s worth noting that, before using the CD, we need to install it with mkdev cdrom (yes, even if we did install the whole system from a CD). In the process we will be asked whether we want a CD-ROM/TAPE device, which can be used to install more components for the system (CD-ROM/TAPE is the format used by the setup CD), and if we want to add to the kernel ISO9660 support, which of course we need. As usual, SCO documentation has a lot of information about this.
Gzip is included in the Celestial ports, but I also managed to compile an early version of bzip2 (here is the binary). If you compile it yourself use gcc, the code will be faster. The provided Makefile undefines __STDC__; gcc sets the flag and this creates problems at linking time, resulting in a call to a missing “__unlink” function.
Bonus content: recovery disks
In the process of getting more familiar with the installation process of SCO Unix, I realized I could benefit from having a set of spare bootdisks that would allow me to mount the hard drive and modify files at will (including after the first part of the installation process). So, I created them, using a ramdrive + compressed disk (similar to what SCO’s install process does, but also the boot floppy of Windows 98) to pack as many utilities as possible on a single disk.While I was at it, I did the same for Xenix 386.
In the previous post we saw how to install SCO Unix 4.2 and SCO ODT on a virtual machine. Sadly, both distributions lack the development system, making them a very limited toy.
At some point I noticed that the filesize of the ISO of SCO ODT 3.0 branded by Compaq (found again on the Internet Archive or WinWorld) is way larger than the other available distributions: could it be that it includes the Development System as well? I decided to find out.
Inside the ISO we can find a N1.IMG file, and we can start the installation by booting from that.
At the serial request I discovered that this version is not the same as regular ODT, and thus the serials I had did not work. I tried extracting a to-be-serialized file from inside the CD.IMG file found on the ISO by opening it with a hex editor (the file is not in ISO9660 format; it’s specific to SCO and somewhat emulates a tape drive, with multiple tar files in it. Opening it with a hex editor, it’s easy to see where one of these tar files starts and ends), extracting it with tar, and running it through brandy to generate a new serial.
Brandy, however, generated the same serials/activation I had already, indicating that the validation mechanism used by the installer in this release is different. I was afraid it would be a Compaq-specific addition, thus almost unrecoverable, but after searching Usenet I found this post (mirror) which suggests that different versions of ODT have different generation mechanisms; in any case, the keys provided in the “OSE” (Open Server Enterprise) column work.
Anyway, after inserting the serial the installation proceeds smoothly, and we can even select to install the Development System:
The DevSys also requires a serial, and for that I used one found on the archive of Tenox. The installation started with the incredibly slow process of badtracking the hard disk (and I had selected the “quick” check!) and proceeded smoothly, until it tried to install the “Compaq EFS for SCO Unix”:
The error interrupts the installation scripts and leaves the system in a half-baked state: we can reboot from the HD and load the kernel, but instead of getting to a terminal or login prompt we are dropped in a broken installation script that won’t proceed.
To fix the issue, I opened up again the ISO with a hex editor and looked at the install script (/inst5/customize). The fix is easy: search for the string “cleanup $FAIL” inside the CD (line 238 of the customize script), and replace the initial “c” with a “#” to comment out the line entirely (a neater solution would be to change the script so that it won’t install the Compaq EFS in the first place; I tried to do that as well, but it didn’t work). Since we are at it, we can also modify the params.stz file in the ISO and disable badtracking completely (search for badtrk_none) and speed up the next installation considerably.
Restarting the installation once again with the same settings will still give the error, but this time it won’t kill the installation script and it should now complete successfully (with some warning messages since it’s not an EISA machine).
After the reboot, we should be finally welcomed into “SCO Open Server (From Compaq) Enterprise System Release 3.0”.
We can now remove the whole Compaq EFS using custom, or just the UPS drivers /etc/rc.0d/*ups and /etc/rc2.d/*ups, in addition to /usr/bin/compaq. We can also apply the patch to the disk driver to run on faster machines, as mentioned in the previous post. Finally, we can install SCO supplements from SCO’s FTP, and in particular:
uod374a – better CD support (you can run programs from ISO-9660 CDs, for example from early SCO Skunkware releases; you can also mount CDs forcing each name to lowercase, instead of the annoying default where everything is in uppercase);
Now we have a working SCO Unix 4.2 system with the development system! The good thing about SCO Unix is that the C compiler is more modern than the one provided by SCO Xenix, but can still target Xenix (with the -l2.3 directive). This means we can compile slightly more recent software for both systems, for example bash 1.13.5 and bzip2 0.1pl2.
I’ve been messing around with SCO Xenix for about 10 years now, and in the process I have been playing with OpenServer 5/6 as well (mostly as a mean to copying big/many files to a Xenix VM: I’d just create an ISO file, mount that in OpenServer, then share the Xenix HD with OSR5 and copy the files over); however, I never got around to use SCO Unix.
A while ago I decided to change this, but it took many tries to get to install everything, especially the Development System; so, when I eventually managed, I decided to do a writeup of what I did (and part of what stumbling blocks I encountered along the way).This is the “first episode”, which should give you enough info to install SCO OpenDesktop 3.0 as found on WinWorld or on archive.org, and the ODT Server 3.0 version from BetaArchive. ODT is nothing else than SCO Unix 4.2 bundled with X11 and TCP/IP (while on Xenix these are separate products).
Installing SCO ODT, floppy version
The secret to installing the 4.2 floppy version was to use the updated N1 boot diskette (SLS uod429a from SCO). Once you have it, the installation process is quite straightforward and self-documenting, especially if you are used to the slightly more convoluted Xenix install. This version can even be installed in VMWare.
The serial/activation is included in the release files; create a VM with an hard drive <2gb, during the setup process select “Floppy” as the install media, a “quick” bad track scan type and then simply confirm every step. You will be asked to insert all the disks in order, and the only challenge should be surviving the mind-numbing boredom of handling more than 40 floppies. Unfortunately, the network and graphics card are not supported on VMWare (I suggest to boot the first time in single-user mode and disable the GUI from starting automatically with “scologin disable”), so it’s a good idea to install on 86box instead.
While we are at it, we can even spare ourselves some of the boredom by using the CD version instead.
Installing SCO ODT, CD version
For the ODT CD version, I looked up at what SCSI devices are supported (mostly by running ‘strings’ on the kernel inside the boot floppy image, looking at the device driver names and comparing them with those of OpenServer 6), and created a machine on the latest unstable 86box build (126.96.36.19983) like this:
i486-socket 2 and 3: [i420EX] ASUS-PVI-486AP4 (many other boards work as well, but faster CPUs/machines would give me issues… more on this later)
Intel i486SX 33mhz + 487SX
32 Mb RAM
Serial Logitech mouse, 3buttons
Video: ISA16 Orchid Farenheit 1280 [note for the setup: the emulated bios is 2.0 – supports 1024×[email protected] colors]
IDE hard drive, <2Gb, non-LBA (check the BIOS settings)
If you want Ethernet, use WD8013EBT (drivers are included) IRQ3 address 240
The OpenServer release I found on BetaArchive was missing the N2 disk, but the one from the floppy release works fine. The process is simple: boot from N1, the SCSI adapter should be recognized by the kernel (a line that starts with “%adapter” and then the IRQ settings etc.), and so should be the disk drive (%disk):
You can use the same serial as for the floppy release, but this time indicate “SCSI CD-ROM” as the install media, and it should install fine. You should however deselect the DOS Services, as Unix will crash after the first reboot while trying to install them.
Once the installation is complete and the system restarted, it will greet you with this very dramatic login screen (and ironic too: SCO and Open Systems in the same logo) and its pastel-colored UI:
Running on faster machines
The 33 mhz CPU is surely not a beast by today’s standards, and the emulated system feels sluggish enough also under ODT; however, switching to a faster CPU would crash the system. Luckily, SCO’s former support website (I created a mirror of the tech articles on archive.org) has a solution for this: we can modify a driver to avoid kernel panics on quick systems. After booting into single-user mode, we can run
Finally we can safely reboot, this time with a better CPU. The fastest machine I could test is a Socket 5 (i430NX Gigabyte GA-586IP) Pentium MMX Overdrive 200Mhz. When a faster system is selected (e.g. those based on Socket 7), the mouse stops registering the vertical axis.
In the next post, we’ll see how to install ODT with the development system.
(This is a guest post by Antoni Sawicki aka Tenox)
In a few recent projects such as QNX 1.2 (and demo disk), Interactive Unix (also older post ) and Caldera (and older post) I have tried the 86Box emulator. Unlike others, now I could utilize an emulated video and network cards of wide variety. As everything I did simply worked out of the box I instantly fell in love. Truly awesome 86Box is now my daily drive for running old PC operating systems. As such I have decided to revisit some of previously half assed posts with the new weapon.
I have virtualized Dell Unix back in 2012 using Bochs and QEMU. Even with community support we have struggled to get a decent video resolution and had to use SLIP for networking. Today let me present Dell Unix more properly, with 1024×768, 256 colors video and proper networking using emulated VGA and NIC.
I started with allsoft.img which is Dell Unix and all packages installed from the tape on Bochs. I have disabled a few services in /etc/rc2.d namely mouse daemon (mse), sendmail, uucp, lp, etc.
For X Window I have edited /usr/lib/X11/Xconfig, enabled serial mouse (Microsoft) and 1024×768 mode. I have used Tseng ET4000AX VGA which is detected by Xmach server. This allowed X / xinit to run correctly. However for startx to work you need to edit /usr/lib/X11/xinit/xserverrc as it seems to be using slightly different configuration. For graphical login you can probably add x:3:respawn:/usr/bin/X11/xdm -nodaemon to /etc/inittab. However I have noticed that when ran from init, xdm seem not to pick up the Dell customized config files. Perhaps rc startup script should be created instead.
As a final note on X, the system has virtual consoles, like other SVR4 you access them by pressing SYSRQ and F keys. F1 is a text mode console, F2 is Xserver. This is my Dell Unix hero shot:
Networking was even easier. Dell Unix supports WD8003 and 3C503 NICs. I wanted to first try the WD one. In /etc/conf/pack.d/wdn/space.c you can find the predefined hardware probes. I have picked one of supported modes and the card was detected on subsequent reboot. That’s it. No need for kernel rebuild or any configuration. I have not tried 3C503 but if you want the driver for it is named ie6. For TCP/IP configuration you set your IP address in /etc/hosts and gateway in /etc/inet/rc.inet file.
I was able to quickly compile Mosaic, which curiously had Makefile settings for Dell Unix, and take it for a spin on the web with help of WRP:
One could probably want to compile more recent version of Mosaic with PNG support or maybe some more recent browser all together.
The system comes with a bunch of open source software in /usr/dell however as there was no bash or even gzip I have compiled some essentials. They are available here and as a /usr/local tarball.
For the lazy, as usual you can get a complete os image for 86Box here. Make sure to attach pcap to your local network interface and set IP address / gateway / dns server accordingly.
If you port some cool software or find any interesting gems in Dell Unix please comment!
Have fun with virtualization!
Update: I have been looking at contents of various distribution media for Dell Unix that have surfaced here and there. On a DAT tape I bought on eBay a few years back I found this file:
Whoa! Of course I want to install all of it! This is how FrameMaker 3.0 looks on Dell Unix:
I have updated the disk image for 86Box to have this included. You can run demo mode of FrameMaker by executing /usr/frame/bin/demomaker. I also imagine that this can be installed on pretty much any x86 SVR4 and above, maybe even Linux. If anyone has a license code / serial number please let me know!