You know, one thing that I’ve come to realize is that doing data recovery from a vintage
system can be a lot less straightforward than it seems.
This is especially true of this Intel Professional Workstation which proved to be one of those
“two steps forward, one step back” types of projects.
In my quest to both preserve the hard drive and to get this system up and running again,
I would end up fighting floppy drive problems, using Novell NetWare to archive data, struggle
with Linux for a bit, and ultimately end up coding a custom utility from scratch.
Strap yourselves in folks, because we’ve got a lot to cover today.
For those who haven’t seen it, this is Part 2 of getting this EISA-based Intel Professional
Workstation up and running here.
Last time we were here, I had gotten the system partially running only to be stymied by a
lack of equipment, and a dead Dallas timechip.
For those who want to check it out, I’ve placed a card on screen to Part 1, and also
placed a link in the description.
Before we get going, I do want to bring up a few minor points from last time.
On Discord, I’ve been asked a few times just what the exact system specifications
are, so without further fanfare, this system has a 33Mhz 486DX, a 1 GiB DIGITAL SCSI HDD,
and 8 megabytes of RAM.
The onboard graphics appears to be a variant of Western Digital’s Paradise VGA adapter,
or at least something that uses the WD90C31 drivers under Windows.
As I previously mentioned, I did work on this system quite a bit more before I was forced
to wait for parts, so let’s pick up from where I left off.
After closing out last time, the largest problem I was facing was the fact that due to the
dead Dallas time chip, the system was unable to save CMOS settings.
As a side effect of this, the EISA configuration had also been lost, meaning that quite a bit of
the onboard hardware was simply non-functional.
From what I could gather via Google, EISA systems usually have a special configuration
utility to set system parameters in a manner similar to the reference disks used on IBM’s
PS/2 line of systems.
I will never know who to thank, but someone actually had saved the EISA Configuration
Utility for this specific machine to the Internet Archive.
From a look at the files, it was clear that this was intended to be loaded as a boot disk.
In truth, I didn’t actually expect this utility to work due to the dead Dallas module, but
it was still worth trying.
Unfortunately, it’s at this point that I learned that the disk drive on this system
seemed to have died.
My first instinct was to simply swap the drive with a replacement, but this turned out to
be impossible: this drive has a non-standard floppy connector with integrated power.
As an additional complication, due to the way the connector is mounted, it would be
non-trivial to wire an adapter.
This was clearly going to be a headache.
My best bet was to try and rehabilitate the dead drive.
From my testing under DOS, the drive would generally fail with sector read errors, with
an occasional moment of success.
This suggested that the drive heads might have been dirty, but cleaning them by hand
showed no improvement.
I then wondered if it was a problem with the disks I was using and here I made an unexpected
discovery: low destiny 720k disks would read just fine.
Infact, I was so surprised by this that I thought it was a fluke.
Not only could I boot off a DOS 5.0 SETUP disk, I could even run a surface scan with
SCANDISK and it would complete without issue.
The drive itself was labeled as a Teac FD-235HF, and this scan of the service manual did confirm
it was a high destiny drive.
It didn’t take me too long to realize what must be going on.
3.5in disks have a special notch that determine if they’re low destiny or high destiny.
High destiny disks are denoted with a notch in the top right corner which low destiny
disks lack.
Depending on the drive, this notch can be detected with either a mechanical pin or light
sensor of some sort that tells the drive what type of disk has been inserted.
If that sensor was blocked or jammed, it could be creating the symptoms I was seeing.
With that in mind, I carefully disassembled the drive to its bare essentials, and managed
to find the media destiny pin.
Just as I suspected, it was stuck in place, but with a little mechanical persuasion, I
managed to free it.
I then carefully put the drive back together.
Did it work?
Nope!
In fact the drive actually died all together, and I could no longer hear the motor spinning up.
Obviously I broke something.
I disassembled everything again and went as far to entirely dismantle the drive looking
for the problem.
The obvious suspect was this ribbon cable that connects the two primary PCBs.
I carefully reseated every component and then using a multimeter, ensured that every connection was good.
With all that done, did we have a working floppy drive?
Yes!
Not only could I fully read and write to high destiny media, SCANDISK’s surface scan passed
meaning that every track could be read from.
Now we’re getting somewhere.
Unfortunately, I was stymied by the fact that I didn’t have the equipment on hand to go
further. I hinted at my plan in the previous video which was to use the DOS INTERLNK and
INTERSRV utilities with my ThinkPad hooked up by the parallel port.
INTERLNK allows two computers to share files and data via a special connection commonly
known as a laplink or parallel null cable.
However, the genius in-charge of this data recovery effort accidentally ordered the wrong
item: what came was a straight through DB25 cable.
After confirming my screw-up with the multimeter, I was very tempted to take a hatchet to the
straight-through cable and rewire it, but before that was necessary: a package arrived
from DigiKey: the replacement Dallas chip modules had arrived.
Now, as I had said in the previous video, this isn’t a 100% match for the dead onboard
Dallas chip, but it was supposedly compatible.
The Dallas chip was already socketed, but getting the chip out was a bit of a challenge.
Unlike most ICs, the Dallas chip is overhanging the chip socket, and there wasn’t enough
clearance to get a flat-tipped screwdriver in to remove it.
What I did find is I could however get a finger under the chip, and I was able to gently rock
it out of its socket.
With the old Dallas chip out, let’s put the new one in, and see if it works.
With the system partially re-assembled, it’s time for Smoke Test 2.0.
Well, that’s definite progress.
Putting aside the fact that the system did power on, we can now see that the “clock
not running” message has been replaced with “time not set”.
Furthermore, after a quick trip into SETUP, we can see that not only settings are being
retained, but all the POST error codes are gone!
That’s not to say we’re out of the woods yet.
We’re still seeing a hang with HIMEM, which suggests that something isn’t right, but
I was able to load the NetWare LP486E driver off the hard disk!
We’re definitely moving in the right direction.
Before I dive into that Ethernet driver though, I want to know if the system’s memory was
actually good.
If I had a faulty bit of memory, it could corrupt any attempts at dumping the hard drive.
Confusing the issue, the BIOS memory test had consistently passed every time.
My usual go-to-tool on finding memory issues is MemTest86.
For vintage machines in particular, the DOS based version can be quite handy, and I’ve
used it before when I did the memory upgrade on the ThinkPad 380D.
Unfortunately, Memtest86 went down in flames the moment I tried to launch it, but this
is not proof of failed memory.
The memtest crash may be due to the fact that this system, as unusual as it seems, does
not seem to have a full 640 kilobytes of conventional memory.
Instead, both mem, and Microsoft Diagnostics report “635k total”.
The missing five kilobytes of memory is likely due to the fact that parts of conventional
memory can be used for DMA, memory mapped I/O, or simply set aside by the system BIOS
for its own use.
Misconfigured hardware settings can also result in these types of crashes and may explain
why both Memtest and HIMEM systems are going belly up.
On most PCs of this era, this would be time to examine the hardware configuration, DIP
switches, and jumper blocks.
This however is not your typical early 90s PC: this is an EISA system, and thus is supposed
to be a tad smarter than your typical “plug and pray” PC of the era.
As previously mentioned, EISA is configured via software utilities, and the old configuration
was lost when the Dallas battery had died.
Although the EISA configuration error had disappeared, it was possible that the hardcoded
defaults are incorrect, so at this point, it was a good time to try running the EISA
configuration utility and seeing if that would help.
Of course, it didn’t take too long to run into problems.
The EISA utility prompted for a “system configuration” disk that I didn’t have.
On my second attempt, I used F8 to break to a command line, and launched the CF binary
directly.
This was quickly proven to be the right move as this brought me to an interactive menu
to configure EISA settings.
The program itself is pretty straight forward, although at first glance, I didn’t see anything
that I couldn’t set outside of the SETUP screens.
That being said, it was surprisingly user friendly.
Among other things, it had an introduction to EISA, step by step prompts, and even asks
the user at points to check and confirm jumper settings with diagrams.
Considering how terse most SETUP utilities can be, this is a step above and beyond.
Anyway, after following through, and confirming that all the jumpers were indeed set properly,
the only remaining question was: did it make a difference?
Yes!
HIMEM now passes it’s extended memory test!
Surprisingly, memtest86 still crashes at startup though.
If anyone has any info, let me know in the comments.
With that said, while I’m not entirely sure that I’ve exercised the memory gremlins
from this system, it is at least it’s not kneeling over trying to start up.
I was reasonably confident that we were in a good position to attempt to begin data recovery.
My plan was to approach this in steps, first, we were going to save the files, then do what’s
known as a sector or raw dump of the drive so we could look for any potentially deleted data.
Ideally, I would have liked to have a SCSI enclosure to simply connect the drive to a
more modern system, but those enclosures are surprisingly expensive.
Even if I had one on hand, I’d still have to buy a PCI-E SCSI card, and the requisite
adapters that such setup would need.
I might still pick all that up, but let’s see what we can do with what I had on hand.
Fortunately, the next step was relatively easy to figure out: a few months ago, I did
a video on running DOS and Windows remotely from a Novell NetWare server.
In that video, I created a special bootdisk that could load the Novell ODI client, and
then pivot to a DOS directory on the server.
As it so happened, I still had all the virtual machines from that video, and the DOS RAMDRIVE boot disk.
In the end, it only took just a few minutes to get things working to let this system boot
up across the network.
Now, as they say, we’re cooking with gas!
Now, I’m betting a lot of you are expecting that I used XCOPY to read all the files, but
you’d actually be wrong about that.
While XCOPY can indeed recursively copy files from one directory to another, the version
available for DOS 6 has some limitations.
More specifically, it will skip any files marked as hidden or system, nor will it preserve
the read-only flag, or other file metadata.
It’s partially due to this reason that I hit on the idea of using MSBACKUP to dump
everything.
By using MSBACKUP, I could save all the files to a single catalog as well as quickly verify
that everything archived successfully.
That also meant when I restored the backup to check integrity, the installed copy of
Windows would also remain functional.
In hindsight, this wasn’t the best way I could have solved this problem, and past me
should have remembered this.
I suspect it’s because I was feeling rushed for one very good reason: I was concerned
that the SCSI hard drive might seize up on me.
While SCSI drives are somewhat uncommon in PCs, they were pretty universal in Macintoshs
of the era, and it seems to be an universal constant that these types of drives just quit without warning.
Not helping matters is that this particular drive is fairly noisy which may be caused
by the lubricant on the bearings starting to fail with age.
For past-me’s peace of mind, it was important that I managed to at least preserve some of the data.
The problem here is that MSBACKUP actually makes relatively subtle changes to the files it archives.
The FAT filesystem used by both DOS and early WIndows have a small number of special attributes
that can be set on files which can seen here in Windows File Manager.
While the Read-Only, Hidden, and System bits are essentially self-explanatory, the Archive
bit tends to be a point of confusion.
That’s because Archive is meant for use by backup software.
When a file is created or modified under DOS, the Archive bit is automatically set.
Backup software then clears said bit to denote that a file has been saved.
This is to let incremental backups to be easily created.
That meant by using the MSBACKUP command to backup the filesystem, I inadvertently reset
the Archive bit on every file on the filesystem.
Now, fortunately, this didn’t override or destroy the unallocated data I was hoping
to preserve, but I’m slightly annoyed that past me didn’t remember this.
I will give a minor spoiler and say that I now have a tool that can handle this exact
situation much better in the future.
Now that past-me’s screw up has been properly documented and MSBACKUP is done running, it’s
time to restore the files.
For this, we’re going to use the NetWare administration box DISCOVERY, and I’ll add
a second hard drive to restore the files for.
For a bit of variety, I’ll use the Windows GUI to get the restore going.
A few minutes later, and can see in FILEMAN that all the data has been extracted.
Well, would you look at that, it’s objective 1 complete!
I have all the files dumped, even if it wasn’t a perfect archiving job.
Now, next up was getting a sector dump of the hard drive.
To be honest, I expected to write a custom tool for this, and in the end, that’s what
I ended up doing, but let me explain how I got here.
Originally, when INTERLNK was still the backup plan, I would have needed to use a DOS based
tool to read every raw sector and then write them to a standard file.
As it so happened, I had been in a similar situation before, and I had to dump a hard
drive through a serial port.
The code for that had been archived to github, and it meant that I had already done the hard part.
That being said, I honestly would have preferred something a bit more robust, so I actually did try to get Linux working;
In part 1, I had noted that the kernel had a driver for the non-standard onboard Ethernet.
The problem I ran into is that while I could start Linux, I could not get it usable in
any meaningful sense.
To frustrate matters, the necessary LP486E driver had only been committed to the kernel
mainline in the early 2000s; almost a decade after this system was made.
That meant no period-correct Linux distribution would work.
I tried various scenarios to do diskless Linux, but the very short version is trying to use
a NFS root partition on 8 megabytes of memory appears to be a bridge too far.
There are ways to do swap memory over the network with NBD, but I couldn’t successfully
boot a kernel new enough to do that.
It didn’t help matters that LOADLIN simply caused a system crash, so I was limited on
what I could physically fit on a 1.4M floppy disk.
In short, while it MIGHT be possible to do diskless Linux on this box, I’d probably
need 16 megabytes of RAM if not more to actually get anywhere.
That being said, Plan A was still on the table.
Since I already had 90% of the functionality I needed coded, I simply pulled my old serial_dumper
repo off github, and got to work.
To be frank, this was pretty straight forward, with OpenWatcom, it was trivial to cross-compile
to a DOS binary.
I also fixed a bug relating to CHS commands that caused the dump to run far slower than
it should have.
After doing some testing in a VM, it was showtime.
Less than an hour later, I had an image file waiting for me, so of course now the question
is: did it actually work?
Well, after copying it off the NetWare system, and onto my Linux desktop, I can happily say
I can kpartx it and mount the first partition, which is a definitive good sign, but to verify
I actually had made a good dump, I took the sha256 hash of every file from the MSBACKUP
I took, and compared it to the files in the disk dump.
In short?
We have a winner!
Rather notably, there’s an additional file in the disk dump that isn’t in the MSBACKUP.
This is the Windows 3.1 swap file which MSBACKUP seemingly skipped, but is non-critical.
As an additional test, I did a run the forensic data recovery tool autopsy, and it is reporting
it can read the unallocated metadata, and I was indeed able to recover additional data.
Anyway, we’re out of time for this video, but in the next and hopefully final part,
I’ll go into more details on just what I found on the hard drive, we’ll run some
benchmarks, clean up the case pieces, and do some stress tests to see how this early
piece of 90s equipment is really holding up.
As usual, I can be found on Twitter, or Discord, and I have a new blog with all my write-ups
to date.
If you enjoyed this video, please leave a like, and subscribe, it really makes a huge
difference for the channel.
Until next time, this is NCommander, signing off!
Have a great day!