I've always owned computers that don't use Intel CPUs or run Microsoft
operating systems, ranging from a Radio Shack Color Computer 3 running
OS-9 in 1986, through an AT&T 3b1 in 1988, NeXT M68040 "black" hardware
in 1991, and a Sun SPARCStation IPC in 1995. Throughout my home computer
experience, people (in real life and on usenet) have told me that Wintel
hardware and software was both more plentiful and cheaper than, albeit
possibly not of the same quality, as the `proprietary' hardware I had on
the kitchen table.
Between January and March of 1997, I pieced together a computer with
a Digital Equipment Corporation Alpha
CPU and got it operable under the Linux
operating system. The DEC computer, a "Universal Desktop Box" (UDB), although
not an Intel 80x86-based CPU, uses "industry standard, easily obtainable"
PC peripherals. I could now test the assertions about Wintel "industry
standard" hardware in practice. This is a record of my experience.
Before reading my story, you should be aware that I'm not inexperienced.
I have worked as a programmer for the past 6 years, mainly in a variety
of Unix environments. One of my computers (a SPARCStation IPC) is running
another freely-available Unix clone, NetBSD,
so I have some small experience in what problems these operating systems
have. The computers I own are not so-called "standard", or mass-market
hardware so I've done all maintenance and upgrading myself.
I purchased a remaindered Digital Equipment Corporation VX40A-F2
Universal Desktop Box (UDB) from Starship/Computer Guys. I did this
via an on-line auction run by www.onsale.com. Although I received
the goods I paid for, I'm not sure I can recommend onsale.com. I have already
gotten several email spams because either Starship or Onsale.com gave out
their list of email addresses to unscrupulous scumbag email advertisers.
This UDB was strictly barebones. It had no memory, no disk, no monitor
or keyboard. It did come with a mouse, a Red Hat Linux/Alpha 4.0 CD-ROM
set, and some minimalistic instructions, however.
After the UDB arrived, I proceeded to purchase the other pieces I needed
to make it into a useful computer. The first episode involved memory.
I called several used and do-it-yourself type computer shops in the
Denver metro area to find 36-pin, 70 nanosecond or better, "true parity"
SIMMs. All of them quoted me a price. One Saturday, I drove over to purchase
some. In 3 of the stores, I got exactly the same treatment: I asked for
the memory, they looked up the price, then told me to bring my PC to their
shop to let them install the SIMMs. I waved the DEC documentation at them,
told them I just want to buy it, and I'll sign away my right to return
ruined memory. Reluctantly, each counter jockey went to the back rooms,
only to discover that they had no SIMMs like the UDB needs in stock.
I eventually purchased the SIMMs I needed from a mail-order concern,
Memory Shippers of San Francisco, California. I was able to install
it without ruining it, despite the fears of the used computer shops in
I went to the local Computer City mass-market personal computer
store to purchase a "PS/2 compatible" keyboard. The used computer stores,
was reluctant not only to sell me SIMMs, but also didn't want to sell me
a keyboard. There was a dazzling array of keyboards at Computer City, each
clearly marked with some set of buzzwords. I was able to spot two signs
saying "PS/2 compatible", but the only boxes behind those signs had labels
on them saying "Not PS/2 Compatible". I was eventually able to find a keyboard
that was "PS/2 compatible", in spite of some non-help from Computer City
sales people. Apparently putting on a pastel-yellow Computer City polo
shirt causes the IQ to drop about 20 points. The keyboard I purchased was
one of the middle-priced ones. The cheapest ones are still only "AT Compatible".
I discovered that the UDB must have a "multi-synch" SVGA monitor because
of its built-in video capability. None of my other monitors are "multi-synch".
During my search for memory and keyboard, I had also noted prices and availability
During 1996, I had purchased a 19-inch genuine Sun
Microsystems monitor via a usenet newsgroup for $350, so I was shocked
to see used 17-inch multi-synch monitors going for $450 and up. New monitors
at the mass-market PC stores were quite pricey.
I finally decided that I'd buy a 14 or 15 inch monitor. I got the same
run around on monitors as I did during my memory acquisition. After looking
in the back room, one used computer store would sell me the monitor the
repairman was using. Another used computer store only dealt in 17-inch
and larger monitors. The third store had only one monitor for sale
by itself (outside of the full systems they sold) a Compaq "Presario
1410". This monitor is apparently something of a white elephant, since
the speakers only work with Compaq computers or some such excuse. As a
long-time NeXT owner and user, I am familiar with the lack of benefits
of sound, so this wasn't a real factor in my decision.
Digital Equipment Corporation stopped manufacturing the UDB (a.k.a.
"Multia") product line sometime in 1996, but they've put the hardware service
manual out for ftp. This isn't quite as gracious as it sounds, since
it contained no diagrams that showed the position of the various jumpers
that control aspects of the UDB's behavior. Fortunately, Red Hat has made
its mailing list archive public and searchable.
Armed with the oddly-typeset documentation from "Starship Computer",
(the company I bought the UDB from) and numerous chunks of documents from
the Digital service manual, the Red Hat mailing list and other web pages,
I was able to get the UDB to boot the MILO mini-loader. The "SRM" boot
PROM doesn't synch with the monitor, so part of the boot is blind. After
that, I was able to install Red Hat Linux for Alpha, 4.0 on a Fujitsu model
M1606SAU SCSI disk. I had a Toshiba XM-3301TA CD-ROM drive that I had previously
hacked to work with the Sun SPARC boot PROM, which requires 512 byte disk
sectors. I used this CD-ROM drive to install Linux from the Red Hat CDs.
I find it remarkable that the hardware and software worked with a modified,
5-year-old CD-ROM drive.
One difficulty I encountered was having to use "fdisk" to build a cheesy
MS-DOS partition table. It strains credibility to believe that Digital
makes boot PROMs that require a "FAT" filesystem to boot from, but it is
so. I also found out that the various partitions have to start on a divisible-by-4
number of cylinders.
A second difficulty I encountered was that the fool-proof instructions
from Starship/Computer Guys implicitly assumed that the hard disk is at
SCSI Target 0. Experience with Sun's boot PROM over the years allowed me
to spot where the UDB boot PROM code assumed Target 0.
It took me two complete install cycles to get a satisfactorily working
Linux. I made an incorrect choice of packages to install the first time
around. I thought that getting a system up and running was paramount. Getting
that installation to start networking would be easy. Getting IP networking
to start when the whole system isn't configured to start is quite difficult.
I ended up re-installing as a "networked workstation".
There may be something wrong with the Linux networking code. The default
installation causes the boot process to hang, but there's a deeper flaw:
every 3.5 seconds, the Linux/alpha kernel fires off a 46-byte packet to
itself. The ethernet frame has the machine's own MAC address as both source
and destination. Maybe this is a heartbeat or a way of checking that the
network wiring is intact, but it's very puzzling.
After getting the system to boot from the hard disk, the rest of the
set up was moderately difficult. I had to scour the Red Hat mailing list
archives for hints about how to keep the boot process from hanging, and
I had to fiddle with the XFree86 configuration file. Having purchased a
cheesy 14-inch monitor was a mistake: everything is really tiny.
I quickly encountered a bug related to the 64-bit Alpha CPU. I wanted
to keep all my machine's clocks synchronized, and `rdate' seemed like a
cheap and easy way. I was already using it on two other machines, and it
seemed like it would be easier to compile and use than alternatives like
NTP (I've set up and administered NTP in the past).
Compiling 'rdate' from the NetBSD 1.1 sources was pretty easy. It insisted
on telling me that the time on my other machines (SPARC IPC and M68040
NeXT) was sometime in 1861. It turned out to be a sign extension "feature"
of the Alpha CPU: the `rdate' protocol is supposed to give out a 32-bit,
"network" byte order, 2's complement number of seconds since 12:00 AM Jan
1, 1900. The `rdate' code uses the library routine ntohl() to get back
to its own byte order. This ended up setting the 32nd bit of the numerical
representation of the date to a `1'. This 32-bit value gets sign-extended
when loaded in the Alpha CPU's 64-bit wide registers. The `1' bit in position
32 made the number in the register negative.
My guess is that I spent 35 to 45 hours on this project, spread out
over 3 months wall-clock-time. I think that in a corporate, 9-to-5 "work"
environment, the same project would have amounted to about double those
hours. Since I was doing it on my own time, I could (for example) start
the install process and go cook dinner. In a "work" environment, you often
must grind away at a task, despite the fact that its not going well.