Virtual archaeology: Recreating the very first PC I ever used#retrocomputing #packardbell #preservation #hardware #emulation
There are some things in life you will remember forever. In case you are just like me, then the very first PC you ever used is most likely one of these things.
I still remember the specifications of the family computer 6-year-old me used in 1999, even though its mainboard died around 15 years ago.
It was a Packard Bell PC, powered by an Intel Pentium II @ 233MHz, 32 MB of RAM, a 20x CD-ROM-Drive (no DVD!), and a Matrox Mystique GPU.
I knew that the system was running Windows 95 with a custom OEM software bundle. For years, I thought that rebuilding the system with the original software was impossible. The recovery CD was long gone and there was no copy to be found on any archival site.
By pure luck, I recently found a copy of the original recovery CD for sale online - I simply had to get it. It turned out that trying to recreate the system on a virtual machine was quite an adventure involving a deep dive into the inner workings of the Packard Bell recovery process.
The system in detail
Even though I still know most of the specifications, the exact model of the system was unknown, so I couldn’t easily try to find a recovery CD based on the model number or name. According to the specs I had, the most likely candidate is a Packard Bell Platinum 3000 from late 1997. Looking at the picture of the case, I was sure that this was the model I had. Luckily, this case model (codenamed ‘Milano’) was pretty rare and this model was the only one I could find with this exact case and system specifications.
The specifications don’t match exactly though, e.g. I remember that the hard disk was a bit smaller and closer to the 2 GB range. Furthermore, the included software listed on that page doesn’t match, but this might be caused by regional differences.
Finding some detailed information about the exact hardware used for this model turned out to be more difficult than I initially thought. After some research, I think the most accurate match I could find is a system with the codename Pulsar 24 based on the ‘Hermes’ platform.
Since Windows 95 is horribly broken in any modern virtualization environment, I used 86Box instead. Choosing 86Box also allowed me to pick the hardware I wanted to emulate, helping to recreate the system as closely as possible. 86Box doesn’t support the exact hardware though, so I had to improvise a bit.
|PB Pulsar 24
|Original model unsupported, same chipset (Intel 440LX), same mainboard?
|Pentium II (Klamath) @ 233 MHz
|Pentium II (Klamath) @ 166 Mhz
|Host system limitations
|Allowing for future experiments and upgrades
|Matrox Mystique 200
|S3 Vision964 (ELSA Winner 2000 Pro/X)
|Original model unsupported
|Aztech Sound 16C
|Sound Blaster 32 PnP
|Original model unsupported
|USR X2 Winmodem
|Realtek RTL 8029AS
|Original model unsupported, no networking with Host
|NEC CD-ROM drive, 20x
|HITACHI CDR-8130, 20x
|Original model unsupported
|3.5in, 1.44 MB
|3.5in, 1.44 MB
This configuration was still very close to the original machine, thanks to the Micronics Spitfire I could emulate, which is likely the same mainboard as the one used for the Packard Bell Platinum 3000. It even shares the same BIOS revision.
The other components are pretty sane defaults, offering good driver support in Windows 95.
Luckily, I remembered parts of the software collection that was bundled with the system I used back in the day. The online listing for the CD I bought only referred to the software collection, so I wouldn’t have been able to locate it just by the system’s model name.
Unfortunately, the part number for the Master CD listed for the Hermes platform doesn’t exactly match the copy I have, but it is still a very close match. While Hermes is supposed to have a Master CD with the part number 6709881101, the copy I have has the part number 6709880503.
The last two digits are not important because they are indicating the language used on the CD. While 01 marks an English release, 03 is the language code for Germany. All in all, I wasn’t too worried about the part numbers because the most likely explaination is a regional difference again.
A much bigger problem was the missing accompanying boot floppy that initializes the system restore process, and the fact I couldn’t find a copy online. I tried to start with a different period-correct Packard Bell boot floppy from archive.org, but all I got was an installer that immediately crashed.
Thinking it was a bad boot floppy that caused the issue, I started the system with a generic Windows 95 boot floppy and launched the setup file on the CD manually. For some reason though, the installer started and immediately told me the restore process was completed. Unsurprisingly, it was not. The hard drive was as empty as before.
This meant that I had to find another way to start the installation, bypassing the original setup file.
A first look at the Master CD
To be able to understand how the recovery process works, I started by examining the file layout on the recovery CD.
│ │ 3DMOUSE.INF
│ │ NOFILE.TXT
│ │ AZT472.CAB
│ │ AZT480D.CAB
│ │ ANSI.SYS
│ │ ATTRIB.EXE
│ │ CHKDSK.EXE
│ │ CHOICE.COM
│ │ COUNTRY.SYS
│ │ DEBUG.EXE
The file layout doesn’t look too complicated.
ARJ contains the main archive with the base installation,
CABS contains all the additional software. By looking at the names of the .cab files, I was able to verify that the entire preinstalled software library as I remembered was there. Yay!
TSRC directory, we find some additional drivers and what looks like a very basic DOS installation. The
WIN95 directory holds the installer and restoration executables I didn’t manage to get up and running previously.
Looking into the
WINDOWS.ARJ archive was very promising. Considering the filenames and folders present in the archive, it looked like a complete factory image of the hard drive. In theory, all I had to do is uncompress it to the hard drive and start working from there.
Moments later, I was incredibly disappointed when I noticed a very small, but very important detail in WinRAR’s file listing.
Do you see the
* at the end of each file? This means that the files are encrypted and you can’t uncompress them without the proper password. And unfortunately, I don’t have the password.
Back to square one.
Great. With all the files encrypted, there is no way to simply extract the archive as I initially wanted to do. I had to take a closer look at the executables for the restore process itself.
A quick examination of the non-matching-but-close boot floppy revealed that the file for starting the system restore process is
\WIN95\OEMSETUP.EXE. Not sure where to begin, I quickly ran
grep "WINDOWS.ARJ" OEMSETUP.EXE - and there was a match in the binary file. This was very promising because it meant that there was at least a reference to the magical archive file in the setup program.
The next step was to try to find some more valuable information in the executable by using the
strings command provided by my MinGW64 environment. While looking through the program output, I found something amazing:
%c:\win95\arj.exe x -y -i -gP127A783D %c:\arj\windows.arj c:\
%c:\win95\arj.exe x -y -i -gP127A783D %c:\cabs\inf.arj c:\cabs
%s %c:\cabs\*.* C:\cabs /S
There it is! The archive password and all the instructions I needed to get the base installation up and running.
Extracting the base archive
With the instructions I found in the OEMSETUP file, it was time to start the manual reinstallation process. I booted the system using my generic Windows 95 floppy and prepared the hard drive using
FORMAT. Since the archive contains the files
COMMAND.COM, I made the hard drive bootable by running
FDISK /MBR immediately after partitioning to get a bootable system.
Time for the moment of truth.
I started the extraction process by running
D:\WIN95\ARJ.EXE x -y -gP127A783D D:\ARJ\WINDOWS.ARJ C:\, not exactly knowing what to expect. After all, it wasn’t an exact match for the Master Boot Floppy, so all I could do was hope for some sort of password-sharing.
Needless to say, I was very happy after seeing the following lines scrolling by:
WIN95\WINDOWS.ARJ archive finished without further issues, so I continued by extracting
CABS\INF.ARJ the same way. And luckily, this archive extracted just fine as well.
With both archives extracted, I was ready to copy over the remaining bits and pieces I previously figured out by examining the OEMSETUP executable. To document the process, I created a batch file that performed all the steps I knew the original installer would do.
echo Prepare drive...
FORMAT C: /Q /U /V:PACKARDBELL
echo Extract encrypted archives...
D:\WIN95\ARJ.EXE x -y -gP127A783D D:\ARJ\WINDOWS.ARJ C:\
D:\WIN95\ARJ.EXE x -y -gP127A783D D:\CABS\INF.ARJ C:\CABS
echo Copy remaining cab files
D:\TSRC\COMMAND\XCOPY.EXE D:\CABS\*.* C:\CABS /S
echo Extraction done, please reboot!
After copying over the remaining .cab files from the CD, I was ready to remove the boot floppy and reset the system, hoping for a flawless recovery process.
For the fraction of a second, things looked pretty promising as I was greeted with the “Starting Windows 95…” banner.
However, instead of getting a successful boot I was confronted with an image telling me that the hard drive was locked and the boot process stopped. I tried resetting the system multiple times, but I couldn’t get the system to boot.
Not to be sold seperately
Back in the day, Packard Bell invented a couple of methods to ensure their recovery disks would work on the original system only. After some research, I learned that this led to the introduction of a hidden sector that is placed on the hard drive during manufacturing that holds some critical information.
The setup process checks if this sector is present which would indicate a genuine Packard Bell system. Moreover, this allowed Packard Bell to use the same Master CD for multiple system variants, e.g. by shipping various software bundles depending on the exact system specifications.
I realized that this also means easily swapping the hard drive wasn’t possible back then because of the missing hidden sector. In theory, a copy of the hidden sector could be placed on the Master Boot Floppy, but since I don’t have a valid copy, I can’t confirm that theory.
On the other hand, the service technicians had to have a way to rebuild the hidden sector in case the original software was lost and the hard drive had to be replaced.
The tool that was used for managing this hidden sector is called
HSCENTER. I was pretty surprised that this tool was included in the base image of the restore CD, so I didn’t have to find a third-party source.
I booted the system from my Windows 95 boot diskette again. HSCENTER is hidden in the
C:\DRIVERS\ directory after the initial uncompressing stage is completed. Using
HSCENTER /? revealed quite a lot of options:
Without a proper manual for the application, I had to figure out how to use the tool.
/CREATEHS wasn’t an option because I didn’t have the
SAUDIT.TXT file (I guess that this holds the sector information in case you have a proper Master Boot Floppy). Instead, I had to build the hidden sector by myself.
Since none of the options seemed like an obvious solution, I simply launched HSCENTER without any additional options.
My first choice was to select the
HS MANAGER option, so I could check if the tool was supposed to do what I needed.
Reading and modifying an existing hidden sector seems to be possible from within this menu. But currently, there is no sector to modify and I have to create it.
The next obvious choice was to try the
ENTER HS PARAMETERS FOR BURNIN PROCESS option. After selecting the manufacturer (this was around the time when Packard Bell was sold to Zenith Data Systems), I seemed to have hit a dead end again.
The main issue is that I don’t have the necessary information to proceed with the setup process. This means that the validity checks for the entered fields will fail, potentially causing a broken hidden sector and triggering the disk lock.
A FIELD trip to the service technicians
Additionally, the setup process uses the part number and format switch to determine the exact machine configuration, so even in the best-case scenario, I would likely end up with a bare-bones system without any additional software or drivers.
The command line switches
/MASTERCD both sent me to the same screen where I had to enter the missing manufacturing details.
/FIELD looked like a way better option. According to the description, this was meant to be used by the technical support department - e.g. after replacing a failed hard drive.
I then realized that the various options were primarily targeted toward the different service departments.
/MASTERCD refers to the Master CD development process itself,
/BURNIN is meant for a technician that assembles and prepares the system, while
/FIELD is referring to a field-service technician.
This was exactly what I was looking for. With the
/FIELD option, HSCENTER guided me through a simple interface where I could pick some of the components and software collections, presumably based on the different model variants sold at the time.
After completing the process by using the
SAVE AND QUIT option, I started HSCENTER again to verify if the hidden sector had been written properly.
Finally! I was confident that I now had a properly written hidden sector. But there was only one way to find out.
I rebooted the system again without the boot floppy attached, noticed the “Starting Windows 95…” banner again, and prepared for yet another failure. Much to my surprise, the boot process finally continued, starting the usual Windows 95 setup procedure.
Flawless victory and a pretty usual setup procedure
The remaining installation was pretty simple. After the initial hardware detection and the first Windows 95 bootstrap setup, the machine started into an additional unattended installer that performed all further installation steps.
After each reboot, you can see parts of the build environment that is running in the background before it launches the ‘Please Wait’ overlay. The text message in the editor refers to this environment as ‘Audit mode’, allowing for additional tests.
Unfortunately, I couldn’t find any additional information about this environment, so I don’t know if this was only meant for the installation steps or if there was an additional service environment the service technicians could use.
After about 30 minutes, the installation was complete and I could enter my username and password as well as the OEM product key.
And there it is. I had to reboot the system one more time before I was greeted by this ugly yet still somewhat familiar desktop. Even though I hadn’t seen the icons for more than 15 years, I immediately recognized the “Packard Bell Navigator” and the “CyberTrio” icons.
Surprisingly, the system overview dialog claimed that the machine I was emulating is powered by a Pentium Pro CPU, even though I was running a Pentium II emulation. I’m not sure if this is a flaw caused by the emulation itself (it is properly detected in the BIOS though) or if the version of Windows 95 that shipped with the system was a bit too old in order to be able to properly detect the CPU.
Obviously, I didn’t do this whole restoration process just for a minimal Windows 95 installation. I was looking for the software that was originally bundled with the system.
While skipping through the various categories of the Start menu, there was only one thing left to say: “This is it.”
Was it worth it?
Well, technically: Totally not. For retro-gaming purposes, it would have been way easier to just install Windows 98 (SE) without having to worry about this rather complicated process.
But personally: Absolutely.
This was the machine I used to learn how to use a computer. The machine I used to play my very first games, the machine I used to learn for school, and the machine I later used for my first Linux experiments.
I’d say this machine was pretty important for me.
I miss it.
Do you have any comments or suggestions regarding this article? Please drop an e-mail to firstname.lastname@example.org!