So, I’m starting to think I’m cursed to own equipment that is quite frankly possessed.
In this case, we’re picking up once again with the Intel Professional Workstation 486,
an EISA-based system made by the chip maker itself.
Since last time, I have learned that this system has proven to be quite a bit of a basket
case internally, and I had only scratched the surface in my previous videos.
What I would eventually find out is that due to several factors, this system suffered greatly
from architectural design issues, and Intel had essentially abandoned it from the get go.
Despite the flaws, this 486 has a fairly interesting history, and today, we’re going to do a
bit of archaeology and piece together the life and times of one of the most unusual
486s I have worked with.
As usual, this is host NCommander, and today, I need a shovel.
For those who haven’t seen it, this is Part 3 of this restoration series.
To recap, in Part 1, we took a look at the hardware and the problems preventing this
system from starting, and in Part 2, we got everything running again, and I ultimately
successful in dumping the onboard SCSI HDD by using Novell NetWare, MSBACKUP, and some
custom utilities.
I had ended that video discussing my concerns about the hard drive dying on me, as well
as a promise to give a tour of the system.
Before we dive into that however, I want to ask you all a question: How many years do
you think this 486 was kept in service?
As we get into this system’s life story, I want you to keep that question in the back
of your mind.
Just as a side note, I will be obscuring a few details here to prevent leaking any personal information.
With that being said, let's start with the most obvious place.
Since I haven’t shown it on camera yet, here’s the system starting up from its hard disk.
Beside some basic drivers, we can see McAfee Anti-Virus load up.
Amusing, it’s an evaluation version which expired in 1998.
Beyond that, it doesn’t take too long to get thrown to this prompt by a program called
Cyber Ra asking for which serial port to use.
There is no obvious way to quit Cyber Ra, but I found that I can hit Ctrl-Break to drop
to a command line, but it isn’t obvious at first glance what this program may be.
We’ll come back to this a bit later, but exploring the file system quickly showed that
there were quite a few layers to be found here.
First off, I noticed a copy of DOSSHELL was present, and this is a tell tale sign that
the system had been upgraded from DOS 5.
This is because DOSSHELL was not included with DOS 6 out of the box, and was only available
on a supplemental disk.
That being said, there aren’t too many DOS applications on the hard disk with two notable
exceptions: the first being Norton Utilities 8, which was a very popular set of power tools,
and they are something we’ll be using later.
The other program of note is CompuShow 2000, a photo viewing application that works with
nearly any graphics adapter.
Beyond that, since there isn’t much to be said from the command line, let’s jump into Windows.
It’s not too surprising that we have Windows for Workgroups here, but, oddly, we don’t
have any networking support installed.
Beyond that, the installed software load is a bit odd to say the least.
Strangely, we are also missing the drivers for the MediaVision sound card present in this system.
Right from the start, we can see quite a bit of modem-based software is installed, such
as ProComm Plus and Hayes SmartModem along with American Online.
PowerPoint is installed, and there is an icon for Excel but the rest of Office is missing.
Trying to launch Excel just causes an error.
A quick look at the hard drive reveals Excel itself appears to have been partially deleted.
In fact, I got the sense that someone had tried to delete quite a bit of data off this system.
For instance, Microsoft Project was installed, but there wasn’t a Program Manager group for it.
Flipping through the file system, I also found a utility called ARCserve, which from some
Googling appears to be a NetWare based backup solution.
Beyond that, we also had label making software, the Eudora email client, and a few other odds
and ends.
I did find it a little ironic that a copy of LapLink was installed given my previous
experience with parallel cables in Part 2.
However, I couldn’t shake the feeling that parts of the system felt missing.
While I’m aware that Office was sold as individual components, I find it a little
odd that Word is missing, and Excel is just broken.
Pieces of the puzzle however begin to fall into place as dug deeper.
For instance, remember that CYBER RA software I was talking about?
Well, that’s where it gets a bit interesting.
It’s a control program for some sort of lab equipment, and I found both it’s source
code and Borland’s Turbo Basic in it’s folder.
It’s not the type of program I’d expect on someone’s desktop.
It was became clear that this system had a long and very complex life.
What confused me though is it looks like it has been used in multiple environments that
appear unrelated to each other.
For instance, the NetWare client I found had been configured as though it was part of a
large network, but that was inconsistent with what I knew about this machine's history.
To be honest, I wanted to know the full history here, and thus, it was time to dig deeper.
The reconstruction of a computer’s history is a field known as digital forensics, and
is typically associated with information security, not retro-computing, but if you want to know
the Life and Times of a 486, well, you end up in the same place.
My choice of tool here is known as Autopsy, which is part of the Sleuth Kit, and can essentially
help reconstruct the history over time of a given machine.
It does this analyzing artifacts found on the file-system, and even provides an interactive
timeline of events.
All I had to do was point it at the disk image we made in Part 2 and let it run.
Remember at the start of this video when I asked you all how long you thought this system
might have been used for?
Well, if you said “decade plus”, have yourself a cookie.
For a system that was made in 1992, this 486 had an exceptionally long service life.
It appears to have been in use almost daily until 1998, with some periodic use until 2000.
Afterwards, it was briefly resurrected in 2002 where for a short time, it was used to
operate lab equipment - that’s the Cyber Ra software I found.
Beyond that point, there were two blips in 2005, and 2010, but it's hard to say, what,
if anything was being done with the machine at those points.
Furthermore, by working backwards, I was also able to find an explanation for why this system
appears to have been used in drastically different environments: it had changed hands throughout its life.
As best I can tell from Autospy’s timeline, this system was initially owned by a group
we’ll call University X, likely from purchase until 1996.
At some point in this period, the hard drive was replaced.
While at University X, this system was primarily used with NetWare, and most of the data and
applications were stored on the network and not on the hard drive.
From the configuration files, this system was used with Lotus Notes, and seems to have
been used as a fax server.
It appears that University X decided to divest themselves of this system sometime in 1996,
as a lot of data and applications were deleted, and Windows was reinstalled.
It is likely that neither NetWare nor the onboard Ethernet were in use past this point
as the ODI configuration file was still set up for University X.
From that point forward, it was used for basic office tasks, and Internet surfing before
it was finally decommissioned.
So, there you have it, the abridged history of this Intel Professional Workstation.
Now that we’ve looked at the past, it’s time to look at the future, and that future
began with running more diagnostic tests.
Since the last video, a lot of folks have written in to tell me that I used a too new
version of MemTest86, and I’m pleased to report that those folks are indeed correct,
MemTest 2.1 starts just fine.
That being said, I’ve been stuck with a surprising conundrum: If MemTest86+’s progress
bar goes past 100%, but is still reporting no memory errors, does that mean the system
memory is good or bad?
While I still haven’t found a definitive answer to this deeply philosophical question,
this would be a wonderful prelude for the headache that would follow.
What I would eventually find is that if I let it keep running, MemTest’s progress
bar would get to about 200%, and then declare no errors so I’m going to assume my system
memory is in fact good.
As stated earlier, I had noticed that Norton Utilities was in fact installed, and this
seemed like an excellent starting point.
Back in the late 90s and early 2000s, I remember using it, and more specifically its rather
comprehensive diagnostic software, NDIAGS to flush out issues.
Since it was already here, I figured it was as good a place as any to start.
Among other things, Norton Diagnostics tests basic functionality of the main CPU, the floating
point unit, DMA, real time clock, video modes and more.
On top of that, it also does tests on both conventional memory, and extended memory which
both passed.
In short, everything checked out OK.
However, one thing I had noticed is that system felt rather sluggish.
In addition to its diagnostics program, Norton Utilities also ships with SYSINFO which has
a few basic benchmark tests and was showing that this system was running much slower than
it should be.
A little bit of trial and error showed that the L1 cache was disabled, and after fixing
that, we’re now getting the proper performance.
The next thing on my list was the SCSI hard drive, and during Part 2, I had mentioned
that I had some concerns about the longevity of this drive.
Unfortunately, it's at this point where things start going downhill for me
I know there are quite a few utilities to run SCSI diagnostics under Linux, but I hadn’t
figured out why the SCSI controller wasn’t showing up, and to be honest, after the experiences
I had in Part 2, running a diskless Linux distribution new enough to have sg3_utils
seemed impossible 8 megabytes of RAM.
To further complicate matters, I didn’t really know what I could do to test the overhaul
health of a SCSI hard drive under DOS.
Contrary to common belief, SCSI drives may not automatically mask errors, and they are
potentially capable of being low level formatted.
Originally, I was going into a long discussion about the SCSI protocol and go into more detail
on how the FORMAT UNIT command works, but I hit something of a rather ugly stumbling block.
At its heart, this system has a NCR 53C700 SCSI controller chip, which is a seemingly
common enough piece of hardware.
NCR’s early SCSI controllers have a somewhat interchangeable driver set known as SDMS,
or the SCSI Device Management System.
Amid my search for the SCSI drivers for this system, I ended up finding a set of NetWare
DSK drivers, as well as the SCSIFMT program, which could initiate a low level format under DOS.
This lead seemingly simple plan: low level format the drive back to factory defaults,
and then unleash NetWare’s comprehensive surface test, or COMPSURF, against the drive
to shake loose any bad sectors.
The first part of this plan went smoothly: I was able to make a boot disk with the necessary
drivers, launch SCSIFMT, and 40 minutes later, had a freshly formatted drive.
That’s where the good news ends.
The bad news starts with NetWare.
I made a minimal boot disk with SERVER.EXE, the NCR driver, and INSTALL.NLM which is just
enough brains to run COMPSURF.
While the NCR driver would seemingly load, I would quickly get errors anytime trying
to do anything with the hard drive.
In my attempts to debug this issue, I actually caused NetWare to ABEND.
This was a lot more concerning because I was now 0-2 on trying to make this system work
with protected mode operating systems.
Out of desperation, I tried to launch the Windows NT installation, but no version I
tried would let me install with 8 megabytes of RAM.
Frustratingly, this system needs fast page 72 pin parity SIMMs, so for the moment, I’m
stuck with what was already installed.
Further digging eventually led to a collection of notes by Ard van Breemen, the person who
wrote the original Linux Ethernet driver for this machine.
From his webpage, he noted that Intel had essentially abandoned this machine shortly
after it had been released, and that officially, only NT 3.1, released in 1993, and the 16-bit
versions of Windows were supported.
Intel apparently went as far to say that if you wanted to use NT 3.5, which was released
the following year, you had to install a replacement SCSI controller!
That’s a truly abysmal level of support, and especially for a system that I’m fairly
certain that Intel sold for a small fortune in 1991.
The question on my mind was simply, “is this situation really as bad as it looks?”.
For example, during Parts 1 and 2 quite a few people wrote in to tell me that this system
should be compatible with NeXTstep.
While I don’t have the necessary SCSI CD-ROM drive to install, in theory, I should be able
to start from the boot floppies, and see if it can detect anything.
Unfortunately, that too joins the pile of protected mode failures.
From what I can tell, Intel had two machines with the name “Professional” in the title,
my Professional Workstation, and the broadly similar “Professional GX”.
Both of these systems are listed in the NT 3.1 hardware compatibility list, and may explain
much of the confusion.
From what I could piece together, there were software enablement kits for this machine
to allow NetWare and SCO UNIX to be used, however, neither of these have been archived,
and it’s pretty unlikely they’ll ever turn up.
On a slightly more optimistic note, I was able to dig up a OS/2 LAN Manager driver for
the onboard Ethernet.
That being said I’m not certain if OS/2 would run “as is”, as I can’t tell if
it has the necessary SCSI driver built in.
Even if it does, it is likely limited to OS/2 1.3
Between the SCSI controller and the onboard Ethernet, this system was pretty close to
dead-on-arrival as far as most 32-bit operating systems go.
To be honest, I’m tempted to give it the title of “least compatible 486 PC” but
I’m pretty sure the comments section would find some Lovecraftian horror if I said that.
The bad news is tempered by a bit of a silver lining though.
That being said, there is one operating system that this machine is uniquely suited to running
and that is QNX.
If you’ve never heard of QNX, that’s OK, because frankly, we’re getting into fairly
obscure territory here.
QNX is a real-time message passing system, and one of the most successful examples of
a microkernel system.
I won’t go into QNX too much here, but from what I can tell, this system was a small number
of “certified” QNX systems, and if I can track it down the right version, there is
a reasonable chance it should “just work”, and give a unique look into an operating system
almost no one knows exists.
In a broader sense, I also do have some additional options, since this system can be fitted with
an IDE hard drive.
I missed it during my original teardown, but this system has an IDE connector hidden under
the SCSI cable, so as a last resort, I could replace the drive.
However, by doing so I would simply be sidestepping the fundamental issue, which is why there
are so many SCSI issues on this system.
I can at least understand the Ethernet controller; the chip Intel used seems to have only ever
been used in a handful of systems before being replaced, but the NCR 53C700 SCSI controller
is a common chip.
Almost everything has a driver for it; even modern day versions of Linux still retain support.
I spent quite a bit of time tracing the history of this chip, reading through driver source code and more.
The official NCR datasheet says that the 53C700, and I’m quoting here, “can be integrated
directly on the motherboard, or externally adopted to EISA, Micro Channel, or other buses”.
There is also an included block diagram that shows how the 53C700 can be wired directly
to a 386 without a bus controller.
From stepping through the Linux NCR driver, it is clear that this implementation is intended
for use with PCI cards that have this chipset, with a variant version of the driver being
used for Microchannel machines.
That explains why Linux didn’t see the SCSI controller: it simply wasn’t looking in the right place.
A search through the kernel shows that support is essentially hardcoded for a small list of machines.
This can be clearly seen in the Amiga A4000T driver which was a system that shipped with
a very similar 53C710 SCSI controller.
However, Linux isn’t the only free and open source system available.
Among others, there is the famously portable NetBSD’s, whose slogan is simply “of course
it runs NetBSD” meaning it should run on almost any available machine.
Infact, NetBSD claims that the 53C700 is supported on several EISA based systems.
Sorta.
The claimed support is for the NetBSD/arc port, and the machines listed are a specific
type of machine powered by a MIPS processor.
These MIPS machines are built around Microsoft's Jazz architecture, and are essentially a MIPS
processor connected to PC compatible parts and were built for use with Windows NT.
I wasn’t optimistic this would work, but I wrote the NetBSD 2.0 boot disks and gave
it a go.
At the very least, I was confident NetBSD would boot, right?
You know, at this point, I really shouldn’t be surprised that I would have the one 486
that can claim that “No, it doesn’t run NetBSD”.
I’m not certain why it is boot looping, but the failure mode is very similar to what
I saw while running LOADLIN with extended memory.
Upon a deeper examination of the NetBSD kernel, it simply hardcoded in support for the 53C700
on the systems that needed it.
In short, I’m not going to have a properly working hard drive unless I write some patches
or get insanely lucky and find the proper NetWare or SCO UNIX drivers for this system.
Honestly, at this point, I’ve been debating what to do with this machine, and I’d love
suggestions below.
In theory, I could slot in a replacement NIC and SCSI controller and that would fix a large
number of the hardware compatibility issues at the cost of eating both expansion slots.
Another option would be to go the other direction, and see what it takes to get some version
of Linux and NetBSD working on this system.
We could even go full turkey and see what it takes to recompile one of the mainline
distributions like Ubuntu to run on a 486-class processor.
Meanwhile, I’m going to clean up the case as best I can, and look into 3-D printing
a replacement eject button for the floppy drive.
I’ll be installing replacement screws and a card blank to put this system in as good
of condition as I can manage it.
Beyond that, if you have any other suggestions on what I should do, let me know your thoughts below.
As usual, if you want to follow my projects in real time, hit that subscribe button to
get community posts, follow me on Twitter, and come join me on Discord.
Until next time, this is NCommander, signing out, and wishing you all a pleasant day.