Recently my employer has been clearing out old hardware and equipment that has gone unused for quite some time. A now fairly anchient Dolch PAC 64 was among the long list of items that almost made the chopping block. Fortunately, I managed to convince one of my overlords that the box was at least worth keeping around for me to play with and freshen up my skills with legacy equipment.
When asking around about the machine I learned that it was deemed “broken” around 15 years ago and never sent off for repair due to an extremely high repair cost. Aside from its brokenness the unit is pristine and shows very little wear.
I decided to power it up and have a look at the issues myself. To my surprise the unit powered right up and even retained the CMOS and RTC settings. Less surprising was the error message telling me no boot device was detected. I messed with some BIOS settings and re-detected the HDD and managed to get the box to boot to Windows 95. After playing around some more I went to reboot the box but got the dreaded disk error again. Easy fix I thought – just a bad hard drive that needs to be replaced.
It has been a while since I’ve messed with IDE devices, but I do remember replacing a spinning disk with a compact flash card back when such tech was more prevalent. After a quick search I found a popular CF/IDE adapter by StarTech and hit up eBay for some 4GB Transcend CF200I industrial CF cards. I also picked up a 4-pin to floppy cable adapter so the adapter could be powered by the connector freed up by removing the original HDD.
A short wait later all the parts arrived and I got to work tearing the PAC 64 apart. The interior was easy to get to by removing some screws on the back of the case and pulling the back half off like a lid. Under the plastic casing was a metal frame that bolts together to form an electrical shield around the internals. Removing this layer exposed a standard PC motherboard sporting a Pentium processor and an abundance of PCI and ISA slots.
Further buried in another metal casing was the CD drive, floppy drive, and the hard drive that needed to be replaced. I removed this casing and unbolted the drive from it. Even though it was failing I still wanted a backup of the original image on it so I could try to restore it later.
The original disk is a 3.5” 2GB Quantum Fireball ST. I hooked the drive up to
my USB IDE adapter and tossed it on my main Linux box to image it with dd. My
first attempt was to run
dd if=/dev/sdb of=./image conv=sync,noerror to pull
what data I could and fill the errors with zeroes. After transferring about
1.5GB dd froze and became unresponsive to Ctrl+C. I let the process sit for
about an hour but eventually killed it because the output file stopped growing
long before that point.
My second attempt used
ddrescue /dev/sdb hdimage mapfile but again the disk
stopped giving data after about 1.5GB was transferred. I noticed this time
around that the disk emitted a harsh “screech” just before locking up. I waited
another hour for any console output to change, but no values advanced at all.
At this point I tried killing ddrescue with Ctrl+C but the program was entirely
unresponsive just like dd was. After doing some internet searching I found
another person that had a simmilar issue that was related to their USB IDE
adapter. I tried the same solution that worked for them – power cycling the
drive and restarting ddrescue in direct access mode to copy the bits missed by
the first attempt:
ddrescue -d /dev/sdb hdimage mapfile.
This advanced the ddrescue percent from 75% to about 76% then froze hard again
with no console output updates. I tried simply replugging the USB adapter and
found this had the same effect as power cycling the disk (but is probably less
harmful than spinning up and down over and over). Slowly I was able to build up
the rescued image a few percent at a time until the disk decided to cooperate
and give me almost all of the rest of the data in one go (screeching happily
every few seconds for about half an hour). At this point I had 99.99% of data
recovered and made one last attempt to grab the few unrecovered sectors with
ddrescue -d -r3 /dev/sdb hdimage mapfile but even after many hours I didn’t
manage to get any more.
Overall I was only unable to recover about 2048 bytes of data which I’m pretty pleased with for a drive that only boots about 50% of the time. Admittedly there are probably better approaches than killing the transfer every time IO locked up, but using this workaround I was able to work past the troublesome areas of the disk and make a nearly complete backup image.
I used the backup image to populate the new CF card by running
ddrescue -f hdimage /dev/sdb and popped the card into the IDE adapter. The
placement of the original HDD makes it difficult to access without removing the
cage that the drives are in so I placed the adapter on top of the drive cage
to allow access by simply removing the back cover of the PAC. The original IDE
cable was a little too short to re-locate the CF adapter so I replaced it with
a longer spare I had on-hand.
The hard part was done (or so I thought). I rebooted and ran the BIOS utility for detecting drives and that’s where the fun ended. I was presented with 3 options for CHS values in the detection utility (Normal, Large, LBA), all of which result in the machine hanging at “Verifying DMI Pool Data” which can indicate some hardware isn’t initializing properly. Since I was working with a backup I decided to try a fresh install of DOS in case the issue was related to a mismatch in geometry of the original and replacement disks.
I verified the correct CHS values from the
datasheet of the CF card I’m using
which matched the “Normal” autodetect option so I tried that setting first.
For a easy test I decided to install DOS 6.22 and see if I could manage to get
that to boot. I found some
6.22 install floppy images
and wrote them with my Sony USB floppy drive using dd:
dd if=DiskN.img of=/dev/sdb bs=1024 conv=sync && sync.
The PAC 64 booted the first floppy and allowed me to run through a full install
with the new disk detected. After the install I rebooted and got the dreaded
“Non-system disk or disk error”. I searched around for some quick fixes and
found that several sources recommended trying to rewrite the MBR using
fdisk /MBR. I booted back up to the first DOS install floppy and ran fdisk
but I was still unable to boot into the installed system afterwards. I thought
the issue could be related to the mode the disk was in, so I repeated a fresh
install using “LBA”, “Normal”, and “Large” mode options that were presented by
the BIOS. Every attempt resulted in the same disk error and a non-booting
As a sanity check I tried to install Windows 95 from CD. Upon hitting the eject button on the CD drive nothing happened. No lights, no sounds, nothing. I took the PAC back apart and sure enough the IDE connector for the CD drive was partially pulled out from where I wrangled the CF reader and cable into place. I reconnected the drive and rebooted right into the installed DOS system from earlier! The cause of some of my strage boot issues was a hardware issue all along. I (re)learned a valuable lesson to check all hardware before going down the software rabbit hole.
I made another attempt at booting the original image now that the hardware was
sorted. I restoring the image to the CF card using my host machine
ddrescue -f hdimage /dev/sdb and moved it to the PAC to boot, but ended up
with the same issue as the first attempt where the system hangs at “Verifying
DMI Pool Data”. I also tried fiddling with the CHS setting and selecting all
detected “valid” modes as well as manually setting the values of the original
disk, but the image written to the CF card just wouldn’t boot.
At this point I did some reasearch on my DMI pool “error”. I don’t actually receive an error so it seems that the BIOS is either stuck at a.) the DMI verification stage or b.) just after the DMI stage when the MBR is being executed (in this case the DMI data has been verified and there is simply no output by the MBR/bootloader to indicate an error state). I also did some research about how the Windows MBR boots the installed system and learned that some files withtin the boot partition need to be arranged in a specific way within the FAT.
I had previously tried rewriting the MBR with
fdisk /MBR but I did nothing to
correct the position of the key boot files after restoring the backup. When
searching for the DMI error I found a thread
with someone having the same issue and a few proposed solutions. One answer
advised booting from floppy and running
SYS C: to copy the key files to the
correct positions within the boot partition.
The SYS Command places essential
boot files in the correct FAT positions but is tied tightly to the version of
DOS (Windows) it’s modifying. I decided to play it safe and make a boot floppy
from the original hard drive since the OS on the machine has been customized
by an OEM (and because I dont know which version of Windows 95 it’s running). I
plugged the original drive in one last time and booted up to Windows to create
a boot floppy. After it finished writing I manually copied
the root of the floppy and placed a copy of
C:\COMMAND.COM in a directory called
SYS on the floppy. Finally I shut down
the system and replaced the original drive with the CF card once again.
With the boot floppy prepared I rebooted to it and got a DOS prompt. I ran
SYS A:\SYS C: and immediately received the error “Incorrect DOS version”.
Weird. I booted into the existing system to create a boot disk to avoid this
exact scenario. Since the boot floppy version of DOS didn’t work I decided to
go with one that had a bundled
SYS.COM and use it to reinstall the files
already present on the original hard drive.
I used the DOS 6.22 install floppy images I found to create a recovery disk to
reinstall the boot files. I wrote a copy of the first DOS disk and deleted
QBASIC.EXE to make room for the
SYS folder I created
earlier. I booted up the PAC with the floppy and ran
SYS A:\SYS C: only to
be repeatedly prompted to insert a system disk. It appears that simply copying
the boot files to a directory isn’t good enough to make
them for copying (or I might have copied the wrong collection of files –
finding documentation that details the inner workings of
SYS.COM has proven
As a last resort I ran
SYS C: which installed the boot files included on the
DOS 6.22 boot disk instead of the ones I pulled from Windows 95. I rebooted and
got further in the process but couldnt move past an error during the Windows
bootup that said the version of DOS I’m running was too old to start Windows. I
tried reflashing the CF card and repeating the
SYS command with the C drive
as the source and the A drive as the target in an attempt to create a backup of
the existing boot files. I received an error that stated the C drive didn’t
contain the boot files at all even though I see the files when browsing the
card on my Linux box. While I didn’t get a fully booting system, I did manage
to move past the DMI pool hang point and make it into the Windows boot process.
It seems like the issue lies within the initial boot files; I just need to find
a good way to re-install those files to test that theory.
After many hours of troubleshooting I gave up on attempting to restore the original disk image and accepted the DOS 6.22 install as confirmation that the CF card is working. I intend to install Windows 98 on this computer anyway, so a fully working restore of the original software is just a bonus. I might feel compelled to take another crack at it in the future, but as of now I’ve spanned more than 4 days trying to restore a “simple” backup and I’m out of patience. If you are reading this and have ideas of what I’m doing wrong, please let me know. I would love to make the original OS boot from a newer medium even if it’s just to prove that it can be done.