Baby AT Pentium

Last modified: 2023-08-05 20:01


Overview

Some years ago I was stupid enough to pay a short-lived computer store to build a PC for me.  It was never particularly stable, and when the 2 GB hard drive failed catastrophically I gave up on it.  I put a new 17 GB hard drive in it, tried unsuccessfully to sell it, and finally left it for years in non-climate-controlled storage.  But after my other spare computers all got jobs, I resurrected the Pentium to have an extra computer to tinker with.

A new PS2/USB combo card, an old CD burner and a second, 20 GB hard drive from the spare parts drawer went a long way toward making it usable again, but there were some glitches to deal with:

Once the system was stable, I succeeded in installing Windows 98 SE, FreeDOS, and Slackware Linux in a triple boot configuration, with Linux running off of a RAID-0 root file system.  However, it soon became clear that the best use for this old PC was running classic DOS video games.  A bit more tinkering was needed to make a new optical USB trak ball visible from DOS.

Vital statistics


VintageProbably Q3-Q4 1996
Form factorBaby AT
CPU166 MHz Pentium, sSpec SL24R? (a)
CPU socketSocket 5? (b)
CPU maximum power dissipation14.5 W
MotherboardASUS P/I-P55TP4XE, rev. 2.1? (c)
ChipsetIntel 430FX
Last BIOS version1998-11-25 (0302)
RAM96 MiB (2 × 16 MiB + 2 × 32 MiB)
L2 cache256 KiB SRAM module

Question marks

(a)  SL24R is the only plausible sSpec number that came up in Intel's Processor Finder (no longer available), but I can't confirm it.  The only markings on the top of the processor are "Intel Pentium i166."  These top markings (or lack thereof) match those documented by Intel for "cC0-Step Production PPGA Units."  The Pentium Processor Specification Update (January 1999) lists no fewer than 11 sSpec numbers with the same combination of processor speed, bus speed, and stepping.

(b)  On the motherboard, the socket is quite clearly marked "Socket 5."  However, the motherboard manual came with a technical update saying that it was newly upgraded to Socket 7.  Socket 7 is backward-compatible to Socket 5 CPUs, so the "Socket 5" indicia might be an anachronism.  The cited Wikipedia article claims "All desktop Pentiums from P54CS onwards used Socket 7."  For SL24R, Intel's Processor Finder said "Package Type:  Socket 5/7."

(c)  The motherboard came with documentation discussing revs 2.1 and 2.4.  The jumper configuration agrees with rev. 2.1 as amended by a technical update that ostensibly applied only to rev. 2.4, but which altered portions of the documentation that applied only to rev. 2.1.  Unclear what happened to revs 2.2 and 2.3.

Pathological case

The case design really sucks.  You have to take the motherboard out just to install a hard drive.  This seems to be the way it is with Baby AT cases unless you have a short mobo that doesn't go all the way across.  Unfortunately, this one does.  Some new cases claim to be Baby AT compatible but I don't see how they could really work.

CPU throttling

You wouldn't think a mere 14.5 W would be enough to overheat anything, but sure enough, the darned thing went from slow to super extra slow after the CPU was loaded for a while.  Or so it seemed.  I have no proof since neither the temperature nor the throttling state were accessible from software.  However, I am pretty sure that Pentiums of this vintage do support thermal throttling, and it certainly did get hot.

Issue #1:  no air.  Those tiny slits at the bottom of the front panel were the only intake vents, unless you count the keyboard port, and they didn't work too well blocked by carpet and dust.  For lack of a better plan, the air found a way in through the 5¼″ floppy drive, which quickly filled up with dust and failed in 1997 or 1998.  When that happened I drilled air holes in one of the bay blanks, which saved the floppy drive but short-circuited the airflow past the CPU.  I should have drilled bigger holes near the bottom of the front panel instead.

Issue #2:  dead CPU fan.  This 4 cm fan was attached to the heat sink by driving screws between the fins haphazardly.  It was completely frozen up.

Detail on the dead fan.  Definitely not from an Intel retail box package.  There were no indicia on the heat sink.

Despite the intrusive overhang of the hard drive cage, the heat sink easily unscrewed from the surrounding socket to reveal the top of the processor, untainted by thermal interface material.  I put a dab of left-over Arctic Silver on it and screwed the heat sink back on as tightly as I dared.  With this design you could easily break the CPU or the socket just by overtightening the heat sink.

Subsequently I discovered that the heat sink got really hot to the touch even when the CPU was just idling.  According to Intel, the "typical" power dissipation is only 5.4 W (versus the maximum of 14.5 W).  All that heat from only 5.4 W?  Yeeeesh!  So much for that silent fanless PC idea.

Rather than simply replace the 4 cm fan, I decided to cut a hole in the case and install a powerful 8 cm, 52.8 CFM case fan (AeroCool X-Blaster) where it would blow outside air directly onto the CPU heat sink, simultaneously cooling the CPU and fixing the overall ventilation problem.  This fan is a beast, running at 4000 RPM instead of the 2000–2700 RPM that is typical for its size.  If you want even more overkill, there is one more powerful (Vantec Tornado), but its thickness is 38 mm instead of the normal 25 mm.

There are competing theories on what is the best way to cut a hole in a steel computer case.

Hmmm...

It was tempting to try the tungsten carbide cutter, but I knew it was beyond my abilities to make an even cut freehand, so I went with a 3″ (76.2 mm) bi-metal hole saw and the people's choice of cutting oil.  Of course, WD-40 may be the people's choice because people are stupid and they do stupid things like saturate a possible ignition source with a flammable liquid.  So don't try this at home.  My years of stupidity keep me in such constant peril that death by WD-40 doesn't even make the top 100 list of hazards.

They say that lard is better than WD-40 for steel cutting, but I don't want rancid pork fat smell blowing out of my PC.

There were a number of false starts until I got the hole saw really level against the work surface, but once it was properly engaged I gunned the drill and it was all over in a few seconds amid a cloud of vaporized WD-40.  The four screw holes took much longer—I think my 7/32″ bit is shot.  Afterward, I used the Dremel to grind down the humongous burrs that the drilling created.

The fan hole ended up slightly off-center.  The tiniest sliver of light shows on the wrong side of the duct in one spot.  Although I did mark the center by estimating from the fan grille instead of measuring meticulously, I think the primary cause of the misalignment was walking of the hole saw pilot bit.  I should have drilled an even smaller pilot hole for the pilot bit.  I had to do this for the screw holes to keep my dull 7/32″ bit from walking.

I knew the fan was strong from open-case testing, but only after it was fully installed did the extent of CFM overkill become apparent.  The case was not designed to be a pressure vessel, but it functioned as one.  I knocked out all of the unused serial port blanks, releasing a steady breeze out the back, yet there was still enough pressure to force a noticeable stream of air out the front vents, the drillium panel, the keyboard port, and even the cracks around the CD burner.

Eventually I swapped the X-Blaster for a more normal 2700 RPM, 37.87 CFM fan (MASSCOOL FDC08025S1M) to reduce the noise level.  There is still plenty of air coming out everywhere, but it is much quieter.  It would be quieter yet if the fan were balanced, but for $2.99 it's hard to complain.  (Hmmm, now they are only $2.49.)

Hard drive errors

Jan 21 14:58:22 darkstar kernel: hda: dma_timer_expiry: dma status == 0x20
Jan 21 14:58:22 darkstar kernel: hda: DMA timeout retry
Jan 21 14:58:22 darkstar kernel: hda: timeout waiting for DMA
Jan 21 14:58:22 darkstar kernel: hda: status timeout: status=0xd0 { Busy }
Jan 21 14:58:22 darkstar kernel: ide: failed opcode was: unknown
Jan 21 14:58:22 darkstar kernel: hda: drive not ready for command
Jan 21 14:58:22 darkstar kernel: ide0: reset: success

The first thing to try was a different cable.  But when I went to replace the cable, I found that the IDE headers had all 40 pins.  Pin 20 is supposed to be a key, and all of my "good" cables had it blocked out.  So I got to do my first pinectomy.  (In this photo, the top header is "before" and the bottom header is "after."  This operation soon became old hat for me as all PCs that predate UDMA/66 have the same issue.)

Then I remembered that I had an extra Promise Ultra66 controller with nothing better to do (see Curse of the Large PATA Drive), so I went for broke and gave every PATA device a shiny new 10″ cable and an IDE channel all to itself.  I also moved one of the hard drives up into a 5¼″ bay to improve ventilation.  The case left no air gap whatsoever between drives installed in the lower drive cage, tempting the wrath of the hard drive gods.  (Discus, Chapter 1:  "Thou shalt not cover this hole, lest ye die."  Presumably there are different gods for Western Digital versus Seagate... but I digress.)

After that, the IDE errors went away for a while, but came back when I replaced the CD burner with a DVD-ROM drive.  The optical drive was the only thing still connected to an IDE header on the motherboard.  Switching it to the other header made the problem go away, so I concluded that the primary IDE header is flaky.

In addition to the two IDE headers on the motherboard and the two on the Ultra66 card, there is a single IDE header on the ISA SoundBlaster card for use with an ATAPI CD-ROM.  It is only accessible via ISA PnP.  While not useful in this case, I made use of such an interface later, when I rebuilt a 486.

Non-repeating failures

Fluke #1

The first time I powered up the PC after installing the new fan, the boot process went off the trolley while I was fully distracted checking out the airflow.  Before I got around to reading the screen, Linux took matters into its own hands and rebooted.  On the second boot, the problem did not repeat, and it has not repeated since.

The only thing I saw before it all scrolled away was a failure report saying that it did not find a file system where it expected to.  Based on this, my guess is that the flaky primary IDE interface flaked out, preventing the hard drive containing the root file system from initializing.

Fluke #2

While I was zeroing out the hard drives in parallel one day, running off of the Slackware install CD, I got two errors of the form Bad page state in process '...'.  These appeared on the screen when I turned the monitor on after having hit the Ctrl key twice thinking that the screen blanker had kicked in.  Subsequently the PC went several passes in Memtest86 3.4a with no failures, so I'm inclined to blame the errors on a kernel fluke that was triggered by the weirdness of the install CD's runtime environment rather than a memory fault.

OS installation

I settled on a triple boot configuration of Windows 98 SE, FreeDOS and Linux, with most of the hard drive space going towards a RAID-0 root file system for Linux.  Getting all that to work at the same time required a surprisingly complicated lilo.conf.

I wiped out the original partition tables and disklabels without bothering to note any vital statistics.  When I recreated them with fdisk (and failed to use the -c=dos compatibility option), the geometry changed and I ended up with the infamous "inconsistent partition table" error coming from both LILO and the FreeDOS kernel.  FreeDOS has LBA support and still boots and runs OK from cylinder 5035, but Windows 98 SE does not read the FAT16 file system correctly.

The partition tables and lilo.conf are included below.

Disk /dev/hde: 20.5 GB, 20525137920 bytes
16 heads, 63 sectors/track, 39770 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hde1   *           1        5034     2537104+   c  W95 FAT32 (LBA)
/dev/hde2            5035        6025      499464   1e  Hidden W95 FAT16 (LBA)
/dev/hde3            6026        6035        5040   83  Linux
/dev/hde4            6036       39770    17002440    5  Extended
/dev/hde5            6036        6229       97744+  82  Linux swap
/dev/hde6            6230       39770    16904632+  fd  Linux raid autodetect
Disk /dev/hdg: 17.4 GB, 17410498560 bytes
16 heads, 63 sectors/track, 33735 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdg1               1         194       97744+  82  Linux swap
/dev/hdg2             195       33735    16904664   fd  Linux raid autodetect
# lilo.conf for Quake 2008-02-18

# Neither fdisk nor cfdisk would create a partition table that did not result
# in the "Inconsistent partition table" error from LILO; nor did lilo -P fix
# actually fix it.
ignore-table

boot=/dev/hde         # LILO goes in the MBR.
compact               # Boot fast,
vga=normal            # and skip the foo-foo.
prompt                # Prompt with no timeout.
lba32                 # Silence warning about assuming LBA32.

# Definitions for partition hiding.
change-rules
  reset
  type=FAT16
    normal=0x0e
    hidden=0x1e
  type=FAT32
    normal=0x0c
    hidden=0x1c

# /dev/hde3 is mounted as /boot, so /boot/vmlinuz is on the non-RAIDed
# partition /dev/hde3.
image=/boot/vmlinuz
  # The kernel will automatically assemble the partitions of type 0xfd
  # into a RAID array on /dev/md0.  Use that as the root file system.
  append="root=/dev/md0"
  label=linux
  read-only

# Need to hide Win98 partition from FreeDOS, which has the classic
# DOS/Windows fault of assuming that it owns C:.
other=/dev/hde2
  label=FreeDOS
  change
    partition=/dev/hde1
      set=FAT32_hidden
    partition=/dev/hde2
      set=FAT16_normal

# Need to hide FreeDOS partition from Win98 because it doesn't read it
# correctly (probably the inconsistent partition table).
other=/dev/hde1
  label=Win98SE
  change
    partition=/dev/hde1
      set=FAT32_normal
    partition=/dev/hde2
      set=FAT16_hidden

¡Cuidado!  ¡Hay llamas!

I originally hoped to use the old Pentium PC as a testing ground for new Linux distributions, but as it happens, the Linux distributions that are currently the most popular are so bloated that not even their install disks can run in 96 MiB of RAM.  (Slackware, my distribution of choice since MCC Linux died off, has no such problems.)

Instead, I soon found myself playing old DOS video games like DOOM and Llamatron: 2112 they way they were meant to be played, with a real SoundBlaster 16 and real VGA video.  No emulation is quite the same.

Unfortunately, the PS2/USB combo card didn't have DOS drivers, which meant I was stuck using an old serial mouse or track ball under DOS.

The ASUS motherboard came with a header for a PS/2 mouse port but not the parts necessary to use it.  I obtained a part with a matching connector from eBay ($9.31 with shipping), plugged it up, moved jumper JP7 to pins 1 and 2 to enable the port, crossed my fingers, and luckily it worked.  Now with the help of a USB-to-PS2 adapter and the CuteMouse mouse driver, I can play DOOM with a modern optical track ball.

Case badge

Hmmm...  Nature abhors a void.

Much better.

PCI video cards

When this PC was new I bought an ATI Mach64 card because it was one of only a few cards available at the time that could do 1024×768×24bpp under Linux with acceleration.  Since driver support for the Mach64 unfortunately evaporated, I tried to find a replacement that would work properly with the current version of X.org.

CardResults
ATI Mach64No support anymore from ATI (AMD).  X.org ati driver doesn't work anymore.  Generic vesa driver works but is unaccelerated and therefore too slow.  Windows 98 driver from Microsoft doesn't support preferred resolution and color depth.
Tseng Labs ET6000No vendor support anymore.  X.org tseng driver can do 1024×768×24bpp but not accelerated (insufficient memory on card); 1024×768×16bpp has glitches with acceleration.
nVidia TNT2Appears to be hardware-incompatible with PC.  (Why?)
3dfx Voodoo3 2000We have a winner.  X.org tdfx driver works great.  No vendor support anymore, but final official driver release for Windows 98 works great.


KB
Home