======================
== fabulous.systems ==
======================
Welcome to the world of fabulous.systems

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.

TypeOriginal hardwareEmulated hardwareExplanation
Base machine PB Pulsar 24Micronics SpitfireOriginal model unsupported, same chipset (Intel 440LX), same mainboard?
CPUPentium II (Klamath) @ 233 MHzPentium II (Klamath) @ 166 MhzHost system limitations
RAM32 MB32 MB./.
Hard Drive~2 GB~8 GBAllowing for future experiments and upgrades
GPUMatrox Mystique 200S3 Vision964 (ELSA Winner 2000 Pro/X)Original model unsupported
Sound cardAztech Sound 16CSound Blaster 32 PnPOriginal model unsupported
NetworkUSR X2 WinmodemRealtek RTL 8029ASOriginal model unsupported, no networking with Host
CD-ROMNEC CD-ROM drive, 20xHITACHI CDR-8130, 20xOriginal model unsupported
Floppy drive3.5in, 1.44 MB3.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.

Getting started

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.

[ROOT DIRECTORY]
│   CRCLOG.DAT
│
├───ARJ
│       ARJ.EXE
│       ARJ.PIF
│       WINDOWS.ARJ
│
├───CABS
│       ACROREAD.CAB
│       ADIBOU.CAB
│       AIMS.CAB
│       AUTOEXP.CAB
│       CDEXTRA.CAB
...
│       WORD8_5.CAB
│       WORD8_6.CAB
│       WORKS_1.CAB
│       WORKS_2.CAB
│       WWHACKE.CAB
│
├───TSRC
│   ├───3DMOUSE
│   │       3DMOUSE.INF
│   │
│   ├───ATI
│   │       NOFILE.TXT
│   │
│   ├───AZTECH
│   │       AZT472.CAB
│   │       AZT480D.CAB
...
│   │
│   ├───COMMAND
│   │       ANSI.SYS
│   │       ATTRIB.EXE
│   │       CHKDSK.EXE
│   │       CHOICE.COM
│   │       COUNTRY.SYS
│   │       DEBUG.EXE
...
│
└───WIN95
        ARJ.EXE
        ARJ.PIF
        BIOSLOCK.EXE
        BIOSLOCK.PIF
        KILL.COM
        KILL.PIF
        MASTCOUN.INI
        OEMSETUP.EXE
        PBHOUSE.PCX
        PBRESTOR.EXE
        PCXDUMP.EXE
        PSCRIPT.EXE
        PSCRIPT.PIF
        ROMAN.FON
        SVGA256.BGI
        TREECRC.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!

In the 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.

Listing the contents of the WINDOWS.ARJ archive
Listing the contents of the WINDOWS.ARJ archive

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:\
md c:\cabs
%c:\win95\arj.exe x -y -i -gP127A783D %c:\cabs\inf.arj c:\cabs
%c:\content.txt
[switches]
%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 FDISK and FORMAT. Since the archive contains the files MSDOS.SYS, IO.SYS, and 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:

Uncompressing WINDOWS.ARJ
Uncompressing the WINDOWS.ARJ archive to the hard drive

Extracting the 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.

Uncompressing INF.ARJ
Uncompressing the INF.ARJ archive to the hard drive

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 off
echo Prepare drive...
FDISK
FDISK /MBR
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.

Disque Dur Protégé
Disque Dur Protégé - the disk protection is kicking in

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.

Introducing HSCENTER

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:

HSCENTER help command
Command overview of HSCENTER

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.

HSCENTER.EXE main menu
HSCENTER.EXE main menu

My first choice was to select the HS MANAGER option, so I could check if the tool was supposed to do what I needed.

HSCENTER Manager Menu
The main menu of the HSCENTER Manager Menu

HSCENTER READ AND MODIFY CURRENT HS
HSCENTER: READ AND MODIFY CURRENT HS

HSCENTER Hardware Information
HSCENTER Hardware Information

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.

HSCENTER.EXE manufacturer selection
HSCENTER.EXE manufacturer selection

HSCENTER.EXE manufacturing parameters
HSCENTER.EXE showing an input field for the manufacturer information

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 /BURNIN and /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.

HSCENTER Menu (language selection)

HSCENTER Menu (country selection)

HSCENTER Menu (motherboard selection)

HSCENTER Menu (zipdrive selection)

HSCENTER Menu (radio card selection)

HSCENTER Menu (mouse selection)

HSCENTER Menu (additional graphics card)

HSCENTER Menu (Keyboard selection)

HSCENTER Menu (Infrared receiver)

HSCENTER Menu (Selecting the software pack)

HSCENTER Menu (overview)

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.

HSCENTER Menu (sector overview)

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.

First Windows 95 setup stage

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.

Windows 95 hardware detection (stage 1)
Performing an initial hardware detection step. This also installs some additional drivers that were not present in a stock Windows 95 installation

Windows 95 hardware detection (stage 2)
Windows 95 detecting the installed Plug-and-Play compatible hardware

First successful boot of Windows 95
And we have our first successful boot! Note the custom Packard Bell branding and the Internet Explorer addition!

Installing additional software (part 1)
Installing additional software (part 1)

Installing additional software (part 2)
Installing additional software (part 2)

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.

Starting the unattended installer

After about 30 minutes, the installation was complete and I could enter my username and password as well as the OEM product key.

Closing words

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.

Finished setup (screenshot 1)

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.”

Finished setup (screenshot 2)

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 feedback@fabulous.systems!