Every Bit Matters

Posted on December 4, 2020 by Michal Necasek

A couple of months ago the OS/2 Museum got hold of a 13.6 GB Fujitsu MPE3136AT IDE drive from 1999. The drive was working… more or less. It behaved quite strangely; the drive was detected and readable, but seemed oddly slow. It should have been capable of Ultra DMA transfers but delivered data at just under 2 MB/sec.

Fujitsu MPE3136AT IDE drive

Looking through Linux dmesg output, it was apparent that the system was trying to communicate with the drive at Ultra DMA speeds, but kept falling back to slower PIO speeds due to CRC errors. Oddly, the drive vendor was also shown as FUBITSU, rather than FUJITSU as one would expect.

And looking at the data the drive returned, it was clear that it was somehow corrupted. For example messages in the boot sector clearly had some letters wrong, but only some.

What could possibly cause such a problem?

Continue reading →
Posted in Fixes, PC hardware, Storage | 7 Comments

Decoding Seagate Date Codes

Posted on November 27, 2020 by Michal Necasek

More or less everyone knows that throughout the 1990s and 2000s, Seagate did not label their drives with a date of manufacture like everyone sane would do, but instead used a custom and somewhat mysterious/confusing “date code”. For reasons that I’m sure made sense to Seagate, but definitely made no sense to Seagate’s customers, the date code refers to Seagate’s fiscal year rather than a calendar year.

The good news is that Seagate no longer uses the cryptic date codes and prints a full date of manufacture on their drive labels, just like everyone else. The bad news is that there are countless millions of Seagate drives made before 2016 or so out there, and most of those drives only have the hard to decipher date code.

When was this Seagate drive made? It’s a mystery…

The four- or five-digit date code consists of a two-digit year, one- or two-digit week number (starting with 1), and one-digit day of the week (again starting with 1). If the week number is less than 10, the leading zero may be left out; that seems to have been the case on older drives, but later Seagate apparently switched to consistent five-digit codes.

Now, there are several online Seagate date conversion tools. So far, I have not found one that actually works properly. That is, they produce a date which is close but very often off by several days or even a week. While the few days probably don’t really matter in the end, I find it unnerving and sloppy, especially because it’s obvious that one can do better than that.

Continue reading →
Posted in PC history, Seagate, Storage | 9 Comments

Percussive Maintenance

Posted on November 25, 2020 by Michal Necasek

A couple of weeks ago this antique 1997 Cheetah 9 drive showed up at the OS/2 Museum:

A fat Cheetah

It was effectively a freebie, a faulty drive bought together with another, more desirable, and working drive. (Well, initially working, but that’s a whole different story.) Now, the model ST19101W Cheetah is historically an interesting drive, since it’s the first generation Cheetah, and those Cheetahs were the first 10,000 RPM drives ever. There were two models, Cheetah 4LP (1″ high) and Cheetah 9 (1.6″ high), with 4 and 9 GB capacities, respectively. When the Cheetah first became available, it was “unquestionably the fastest hard drive ever made” according to Red Hill.

This particular Cheetah 9 was quite sick and would not spin up. It was clearly trying to spin but failing, resulting in an endless cycle of attempted spin-up, beep, attempted spin-up, beep, and so on. The beeping was most likely resonance from the voice coil actuator, since the drive has no built in beeper.

Continue reading →
Posted in Hardware Hacks, Seagate | 7 Comments

Those Lot Numbers are Old

Posted on October 24, 2020 by Michal Necasek

The other day I was trying to decode the “lot numbers” printed on certain Seagate drives. In the meantime, I realized that those lot numbers have been in use for quite some time. They were in use around 2000, like on this Cheetah 73 made in 2001:

Seagate Cheetah label (2001)

They can be found on Seagate’s drives going back into the early 1990s, but always only on some of them—typically on higher-end enterprise drives, almost exclusively using SCSI/FC/SAS interfaces. One older example is this 1994 DEC-branded RZ25-E drive, which is definitely a Seagate-made drive and almost certainly a model ST1480N:

Digital RZ25-E (Seagate ST1480N) label

As it turns out, those lot numbers aren’t a Seagate invention. It’s something that Seagate adopted when it acquired (1989) the drive maker Imprimis, a subsidiary of CDC (Control Data Corporation).

Continue reading →
Posted in PC history, Seagate | 12 Comments

Not MSX, Either

Posted on October 7, 2020 by Michal Necasek

Further examining the mystery of boot sectors supposedly starting with byte value 69h, I considered the possibility that the check could have been added for MSX machines. The MSX platform ticks a lot of boxes: It wasn’t 8086 (but rather Z80), used 3.5″ floppies, used FAT format, appeared around 1985, and Microsoft was involved in it.

But looking closer, MSX is quite unlikely for one simple reason: Microsoft was clearly concerned about data exchange with PCs, and solved the problem differently. MSX floppy boot sectors actually start with the usual 8086 instructions, and if they’re booted on an MSX machine, the boot sector starts execution at offset 1Eh.

Not only that, but the MSX BIOS in fact requires that the floppy boot sector must start with byte EBh or E9h to be considered bootable at all.

The above is clearly documented in the MSX Technical Data Book (published by Sony in 1984). Extant MSX floppy images confirm the documentation—MSX floppies use 8086 opcodes in the first three bytes.

But wait, there’s more…

Continue reading →
Posted in IBM, Microsoft, PC history | 15 Comments

Return to Stormville

Posted on September 29, 2020 by Michal Necasek

A while ago I griped about a strangely ill-behaved Intel DX79SR Stormville board. To recap, the board simply refused to take any memory in the 4th memory channel. Since then, there have been very interesting new development in the story.

I found another complaint about these boards that exactly matches my symptoms. I missed it at first because it doesn’t mention the DX79SR board (it’s about DX79SI/TO). To recap, in 2011, Intel came out with two boards based on the X79 chipset, DX79SI (Siler) and a slightly stripped down and cheaper DX79TO (Toler). In 2012, the DX79SI was replaced by DX79SR with more USB 3.0 ports and more 6Gbps SATA ports. The three boards all use the same PCB, same BIOS, and are for most intents and purposes identical. It is therefore unsurprising that they’d also have the same problems.

Worth noting is that near the end of the discussion, a user claimed to have fixed just such problem by straightening a bent pin in the CPU socket. Since the memory controller is on the CPU, that is not implausible, although I could not find any sign of a bent pin on my Stormville board.

Continue reading →
Posted in Bugs, Intel, PC hardware | 3 Comments

Really Atari ST?

Posted on September 21, 2020 by Michal Necasek

This blog has previously examined a very very strange code fragment in the BIOS module of DOS. To recap, when deciding whether a boot sector might have a valid BPB, DOS checks whether the first byte is a relative jump (opcode E9h) or a short jump (opcode EBh), both used by different DOS versions. But it also checks for a “direct jump” with 69h opcode.

The code looks like this in the MS-DOS 3.21 OAK, source file dated May 1, 1987:

         cmp    byte ptr cs:[DiskSector],069H   ; Is it a direct jump?
         je     Check_Signature                 ; don't need to find a NOP
         cmp    byte ptr cs:[DiskSector],0E9H   ; DOS 2.0 jump?
         je     Check_Signature                 ; no need for NOP
         cmp    byte ptr cs:[DiskSector],0EBH   ; How about a short jump.
         jne    BadDisk
         cmp    byte ptr cs:[DiskSector]+2,090H ; Is next one a NOP?
         jne    BadDisk

The code is not materially different in the MS-DOS 3.3 OAK, source file dated July 24, 1987:

         cmp    byte ptr cs:[DiskSector],069H   ; Is it a direct jump?
         JE     Check_bpb_MediaByte             ; DON'T NEED TO FIND A NOP
         cmp    byte ptr cs:[DiskSector],0E9H   ; DOS 2.0 jump?
         JE     Check_bpb_MediaByte             ; NO NEED FOR NOP
         cmp    byte ptr cs:[DiskSector],0EBH   ; How about a short jump.
         JNE    INVALIDBOOTSEC
         cmp    byte ptr cs:[DiskSector]+2,090H ; Is next one a NOP?
         JNE    INVALIDBOOTSEC

The labels are different but the logic is identical. But of course there is no such “direct jump” on x86, and the 69h opcode (undocumented on 8086, IMUL on later CPUs) makes no sense whatsoever. So what is it?

Continue reading →
Posted in DOS, Microsoft, PC history | 18 Comments

Seagate Serial Talk

Posted on August 5, 2020 by Michal Necasek

Some time ago, the OS/2 Museum obtained a 10 GB Seagate ST310014ACE hard disk (IDE 3.5″ low profile). The disk was unusable because it was locked. That is, it needed an unknown password to gain access to the medium.

Seagate ST310014ACE drive

After a few quick searches it turned out that this problem is surprisingly common. The particular model of hard disk was used in the first generation Xbox consoles and indeed it was locked there, which meant that after taking it out of the Xbox the disk was no longer usable.

Except there is a way to unlock these drives, using a serial terminal, a special adapter, and a couple of magic commands. How does that work?

Continue reading →
Posted in Hardware Hacks, PC hardware, Seagate | 23 Comments

Breaking Into ASOS

Posted on August 1, 2020 by Michal Necasek

The OS/2 Museum recently acquired a Quantum Bigfoot TS hard disk in mint condition. The Bigfoot drives, as some readers may remember, were rather oddball late-1990s 5.25″ IDE drives that were cheap, slow, and relatively big. There was a sticker on the disk that suggested the drive once lived inside a Compaq machine. After attaching the disk to a Linux system, it turned out that the drive was not empty but the contents were too foreign for Linux to handle.

After hooking up the image of the drive to a VM, it turned out that the drive is not only bootable but actually boots into some… bizarre thing that Compaq and SCO cooked up. Here’s what the screen looks like when booted up:

Some kind of Microsoft/SCO/Compaq server?

Not much to see there. At all. After switching the virtual terminal (with Alt-F2, where did you think Linux stole that idea?) it turned out to be a curious mix of an off-the-shelf OS with some heavy custom tweaking:

Compaq ASOS, a customized SCO OpenServer

Okay, so it’s SCO OpenServer Release 5, but with some sort of Compaq modifications. With the “ASOS” keyword there’s something to search for. It turns out the hard disk came out of a Compaq Prosignia NeoServer, an oddball late-1990s network server. In other words, a low-powered cheapo Celeron PC running a web server, file server, print server, etc., all remotely manageable. For whatever reason, Compaq decided to base that on top of SCO OpenServer. The NeoServer looked a bit like a shredder or a trash can but it was 1999 and it said “network” and “internet” so it had to be good. A significant chunk of the NeoServer functionality relied on a product called VisionFS, which was roughly similar to Samba.

Continue reading →
Posted in Compaq, PC history, SCO | 4 Comments

X7DBE WTF

Posted on July 23, 2020 by Michal Necasek

Several years ago I got two Supermicro X7DBE boards at a bargain price. These are nice dual Socket 771 boards of circa 2007 vintage, built around the Intel 5000P Blackford chipset and using FB-DIMMs with up to 32GB memory supported.

Recently I pulled one of the boards out of storage and installed two quad-core Harpertown Xeon E5450 processors in it, primarily for the purpose of verifying that newly arrived FB-DIMMs work. The memory worked just fine… but something else didn’t.

The CPUs ran at only 1.2 GHz (instead of 3.0 GHz), and even worse, one of the CPUs was not recognized. I swapped the CPUs around but that didn’t change anything—one was still not recognized. I plugged in two slightly slower Xeon E5430 CPUs… and one still wasn’t recognized, and instead of 2.66 GHz the CPUs ran at 1.06 GHz. I thought the board perhaps got damaged during moving and didn’t investigate further.

Sometime later I pulled out the other X7DBE board. It had two E5430 Xeons installed already. When I first tried it, both CPUs were recognized, running at 2.66 GHz as they should. Board clearly working.

So I thought, let’s put the faster E5450s in it. I did… and one of them wasn’t recognized, while the other ran at 1.2 GHz! I put the original E5430s back, but oops, one wasn’t recognized and the other ran at 1.06 GHz.

Okay, this is really weird. In desperation, I put in two Dempsey 5080 Xeons, the latest and greatest (if such a thing can be said) NetBurst Xeons. And again, one of them was not recognized, although the other at least ran at the full 3.73 GHz. Hmm…

Continue reading →
Posted in PC hardware, Supermicro, Xeon | 18 Comments