The HP-UX installation was successfully finished with a large text over a half of the screen saying “FAILURE!” written in ASCII art. The whole process took about ten hours and after an automatic restart, the system booted up in the graphics environment.
The CDE GUI is not as intuitive as the one on SGI IRIX but I can live with it. I was more surprised that all color schemes (about 20) looked ugly as hell. The guys who were responsible for this were probably on LSD. Otherwise, I cannot understand the color combinations they created.
On the bright side – although the CPU runs only on 100MHz, the overall feeling of speed is better than on 200-MHz SGI O2. I have only a low-end graphics card capable of 1280×1024 in 256 colors (actually it can combine one 256-color palette for an active window and second 256-color palette for the rest), it is very fast and has no problems with refreshing windows while moving.
Btw the system cannot use audio in the CDE until the network is fully configured. It wouldn’t be a true UNIX without such jokes.
My C100 is not as nice as the one on Wikipedia, but it’s fully working. The machine was used in a small GIS company as a server for two X terminals (probably HP 700X). It is equipped with 100-MHz PA-7200 CPU, 256 MB of RAM, 2-GB SCSI HDD, two additional 100-Mbit/s network NICs and a single-head version of the HP 8-bit frame-buffer card. The original owners used it with an external SCSI drive for user data and did regular backups using the internal tape drive. They didn’t delete anything from the internal system drive when they stopped using it (the drive has only about 10 megs of free space).
Owners were probably smokers so I had to clean the internals of the machine from the greasy dust. Fortunately, there was no visible corrosion on logic boards. Now it is ready for a fresh installation of the HP-UX operating system including the complete aC++ development environment.
Yay! I accidentally found an Itanium-based blade server that had never been used. I already removed the original root password that nobody knew and started with HP-UX configuration over a virtual serial connection.
I’m surprised how uncomfortable the terminal is. Although I have a very recent version of the system, even backspace/delete doesn’t work the way the world is used to for decades. Looks like UNIX guys like it rough…
We have three SGI Octane2 workstations in our “lab” but none of them were in the ready-to-use state. I’ve decided to take a look on the one which looked like it could work (the only one with hard drives). Already installed IRIX was somehow corrupted and was accessible only by using a serial terminal. I realized after a few hours that the original installation couldn’t be fixed with my knowledge although the hardware (graphics card) was ok. The only way was to install a fresh IRIX.
I used a laptop with a serial terminal emulator instead of local peripherals and SGI O2 as a server containing all the installation files. For the first time I used BOOTP and TFTP to boot a computer over network. I was surprised how easy it was. The former (BOOTP) is intended to get a boot program to the memory of a target computer (to be executed then). The latter (TFTP) is intended for simple file transfer. Good thing is that you don’t need properly configured Ethernet interface to get this working. A server just needs to know the MAC address of a client and a file to be sent.
It took me more than ten hours but I have one fully working Octane2 now. Surprisingly, booting and accessing all files over the network was the easiest part. Most of the time was spent on identifying the initial issue, “package dependency hell” (typical for UNIX systems) and the fact that the IRIX 6.5.22 boot file didn’t work. I had to start with IRIX 6.5.5, install a special patch and then install IRIX 6.5.22 (which correctly recognized all the hardware inside Octane2).
It was definitely an interesting experience… but I hope I won’t need to do this all again soon. Anyway, for a moment I felt like a real UNIX geek.
SGI O2 was designed as a small low-cost workstation. This is clearly visible on its internal hardware architecture with unified memory shared between the graphics chipset, CPU, and add-on video grabber. I like the smart design of the case. Everything is easily accessible (except for the CD-ROM drive which needed to be fixed). You can replace the mainboard or hard drives quickly and without any tool.
Btw two of the three mainboards are alive so at least two machines will work. Two working boards are equipped with 180-MHz MIPS R5000 (one in a version without L2 cache). These CPUs were the lowest available options.
IBM PC was not intended as a high-performance workstation back in early 80s. It could hardly be so with its slow CPU, limited graphics capability and a single-task operating system. However, IBM had an answer for performance demanding users requiring multi-tasking UNIX workstations. It was called IBM RT (known also as IBM RT PC) and was introduced in 1986.
There is some interesting history behind this computer. IBM had a RISC technology way before others (early 70s) but it required to pass a lot of internal processes and bureaucracy stuff to get it working in a custom chipset – IBM 801 CPU. IBM RAMP was introduced in 1986 and it was a spin-off project of the original CPU architecture. This 32-bit CPU was made of multiple chips on a single board and the computer needed another board to handle floating-point calculations in hardware (which was optional).
The first (6-Mhz) version of the system was quite underpowered in comparison with workstations based on MIPS R2000 RISC CPUs. This was not the only issue on the competitive market with well-established players like Apollo, DEC, HP and Sun. AIX* (IBM’s UNIX implementation) was not 4.2BSD compatible which resulted in limited software availability. IBM didn’t give much support to this product and company salesmen had no reason to push it due to low commissions.
The system used custom 32-bit bus for CPU cards and memory. Other cards like graphics adapters or storage (ST-506, ESDI) and network (token ring, Ethernet) controllers were designed for standard 16-bit AT slots fully compatible with PC line.
There were four graphics adapters available. Two with resolution of 720×512 in monochrome (black & white) or with 16 colors (out of palette of 64 colors) which were combined with 15-inch CRTs. Other two adapters offered 1024×768 (1-bit monochrome) or 1024×1024 with 256 colors out palette of 4096 colors and were combined with 19-inch CRTs (with 60hz refresh rate). Unlike standard PC graphics cards, these supported BitBlt transfers, line draw and image copy/merge to offload graphics operations from main CPU.
IBM RT was used for certain CAD applications and for shopping store control but it was not very successful on the workstation market.
I’m always surprised how little I know about old UNIX computers. I started with Linux in late-90s but it was just a low-cost/low-end alternative. Silicon Graphics Inc. was the only company that came to my mind when somebody said: “UNIX graphics workstation”. Thanks to a nice article about BZFlag history (which began in 1992) I’ve realized that there were hi-end graphics workstations even from HP and they had impressive 3D capabilities. In addition to that, HP had four times bigger market share than Silicon Graphics Inc. (workstation market, 1991).
The PC market is more about stand-alone components. These UNIX workstations were about perfect integration of hardware and OS and that’s why even today it is very pleasant to work/play with them. I would be very happy to have modern Linux looking and behaving like old IRIX on SGI computers. After playing a lot with SGI Indigo2 (1995) and O2 (1998) I consider the system very intuitive, stable and easy to configure in comparison with modern Linux distros.
