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?
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.
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…
So after some furious disassembling, assembling, and linking, things got this far:
Freshly built GW-BASIC
It took longer than it ought to have because although IDA is great, I couldn’t figure out how to make it work with GW-BASIC’s bizarre segment usage. The problem is that the BASIC data segment is tacked onto the end of the code, and during initialization, CS equals DS and variables have high offsets in the segment. But after initialization, CS no longer equals DS and DS points at the beginning of the data, which means variables are at low offsets within DS. I failed to convince IDA that the same data is accessed through completely different offsets at different points in the code. After a lot of trying and failing, I’m still unsure if I’m doing something wrong or if it’s really a situation that IDA can’t adequately handle.
At any rate, I ended up with a bit over four thousand lines of a GW-BASIC OEM module, lovingly borrowed from Compaq’s BASICA.EXE version 1.13.
The Object Module Format (OMF), used by most DOS development tools, and eventually displaced by COFF/ELF in the 32-bit world, is quite old. It is a somewhat strange format because of its age, and it is quite complex, both because it was designed for the segmented 8086 architecture and because it evolved over many years.
The LINK.EXE linker supplied with DOS 1.0 (1981) used OMF as the input format and Microsoft’s development tools (MASM, Pascal, etc.) produced it. Just about all major 16-bit 8086 compilers use OMF by default. OMF must be at least as old as DOS then.
Wikipedia claims that OMF “was originally developed by Intel in 1981” and bases the claim on the fact that Intel published an 8086 OMF specification in 1981. Anyone actually reading that specification will wonder why a specification supposedly developed in 1981 and published that year is already at version 4.0.
The answer is of course that OMF is several years older than that and was likely developed closer to the mid-1970s than to 1981.
When I learned that Microsoft released the GW-BASIC source code, I was mildly curious to find out what is or isn’t there. The short answer is that there’s a whole lot, but a lot is also missing. Spelling note: Both “GW-BASIC” and “GW BASIC” can be found in the source code. The hyphenated spelling will be used here for consistency.
The first question is: When is the source code from? Microsoft marked the source files February 10, 1983, but that’s almost guaranteed to be wrong. The date comes from comments in the code: “This translation created 10-Feb-83 by Version 4.3”. That reflects running some sort of master BASIC source code through a translator generating 8086 code. The source code was almost certainly modified after that date.
My current best guess is that the source code is roughly from mid-1983. But that’s only a guess.
Not long ago the OS/2 Museum acquired a boxed copy of the IBM PC LAN Program (PCLP) version 1.3 (1988) on 3.5″ floppies. The IBM PC Network Program (1985), later renamed to the IBM LAN Program, was IBM’s first PC LAN networking software, notable for using NETBIOS and the SMB protocol. Because of its reliance on the NETBIOS software interface, PCLP survived the transition from the original IBM PC Network hardware to Token Ring and later to Ethernet (“later” because IBM supported Token Ring first, not because Token Ring is older than Ethernet).
Rather unusually, it is easy to find a copy of the original PC Network Program and PC LAN Program 1.1 online, but not version 1.2 or the last one, 1.3. PC LAN Program 1.3 is notable for being sold by IBM until 1997 and overlapping with the OS/2 LAN Server in the market. In fact either the DOS LAN Requester shipped with LAN Server or PCLP 1.3 could be used as a LAN Server client.
PCLP 1.3 is also significantly different from the earlier PCLP releases in that it can still be used as a more or less unstructured peer-to-peer network, but also supports “Extended Services” with domains, dedicated servers, user logons, and remote booting (RPL/RIPL) of diskless workstations. At $225 (or $90 upgrade), PCLP 1.3 was not even all that expensive.
The catch with PCLP 1.3 is that came out in 1988, very shortly after DOS 4.0. It supports DOS 3.3 or 4.0 servers and workstations. Now the problem is that DOS 3.3 (at least IBM’s) only supports 32MB partitions, and DOS 4.0 is a memory hog. PCLP itself consumes quite a lot of memory and it is next to impossible to start a PCLP server and still run the user interface required to manage it (the interface can be also run remotely, but that’s an extra inconvenience):
The obvious solution would be to run PCLP 1.3 on top of DOS 5.0 with UMBs. But of course that does not work out of the box because PCLP is too tightly integrated with DOS (notably using the DOS 4.0 IFS interface which is not present in DOS 5.0). And, of course, given that PCLP was sold into the mid-1990s, IBM did have updates that made PCLP 1.3 compatible with DOS 5.0, and the updates are even mentioned in the IBM DOS 5.0 announcement letter. It is finding those updates that turned out to be nearly impossible.
It is well known that Win9x variants prior to Windows 98 have a tendency to crash on fast CPUs. The definition of “fast” is of course fuzzy but the problems were known to occur on AMD K6-2 processors running at 350 MHz or faster as early as 1998. This led to some acrimony when Microsoft attempted to charge $35 for the fix. The crashes were intermittent on the 350 MHz parts but harder to avoid with faster clock speeds.
The problem soon started affecting other CPUs with higher frequencies, but it didn’t affect Intel processors for a while. Were Intel CPUs somehow better? Not exactly, but there was a reason for that; more about it later.
I have been long aware of this problem but never looked into the details. And when I did, at first I didn’t realize it. An acquaintance mentioned that Windows 3.11 for Workgroups no longer works in a VM.
That’s as far as WfW 3.11 would get
After some investigation it turned out that the issue is related to the host CPU. An older Intel i7-2600 host exhibited the crash, but rarely. A newer Ryzen 7 3800X crashed every time. Some unexpected Intel/AMD difference? Well, yes and no…
Lately I found myself in the possession of several Seagate Cheetah 15K.7 SAS drives. These represent the pinnacle of hard disk engineering; with 15,000 RPM, the drives deliver up to around 200 MB/s sustained throughput (both read and write!) and have average access time approximately 5 milliseconds. They run a bit warm but are surprisingly quiet.
Naturally I’m interested in knowing when the drives were made. But only one of four drives has a clear “DOM: 08/2011” printed on the label:
Seagate Cheetah 15K.7 a Date of Manufacture on the label
The other three drives have nothing on the labels that would clearly identify a date of manufacture:
Seagate Cheetah 15K.7 with no apparent date of manufacture
That is different from most Seagate consumer drives which have a “date code” on the label.
Now, it’s possible to punch the serial number into Seagate’s warranty lookup. But that only works for drives directly sold by Seagate, and two of my drives weren’t (one of them is Dell branded, the other has no other identifiable branding). And even when the warranty lookup does work, it does not determine the actual date of manufacture. For the drive manufactured in August 2011, the five-year warranty expired in November 2016. Since the warranty period starts counting from the date of purchase, it makes sense that it only gives a ballpark estimate—basically if the warranty expired in Nov 2016, the drive was likely manufactured several months prior to Nov 2011.
These Seagate drives do not appear to report the date of manufacture through software (some other drives do), and although Seagate knows exactly what the drives are based on the serial number, the date of manufacture is not shown there either.
But there is one other piece of information on the label—the lot number—that looks like it might include the date of manufacture. Does it?
The other day I pulled an old ThinkPad 770X (300 MHz Pentium II, good old 440BX chipset, released in late 1998) out of the closet to see if it still works. It does, but I had the terrible idea to get audio support (Crystal Audio CS4239 chip) working in DOS and OS/2. That turned out to be far more difficult than it should have, thanks to Plug and Play.
The laptop has DOS, Windows 98 SE, and OS/2 installed. I never even considered that there might be something physically wrong with the audio chip because it works fine under Windows 98. But it just would not work under OS/2, and when I tried installing audio support in DOS/Windows 3.1, it wouldn’t work either.
IBM ThinkPad 770X badge
As an aside, the ThinkPad 770X actually has two audio chips: Crystal CS4239, an ISA PnP audio controller with Windows Sound System (WSS) and Sound Blaster compatibility, as well as an OPL3-compatible FM synthesizer. The 770X additionally has a Crystal CS4610 PCI audio accelerator, essentially a DSP capable of multi-channel mixing or MPEG-2 audio and AC3 decoding. The output of the CS4610 chip is routed to the CS4239’s codec. For the problem at hand, the CS4610 is not really relevant as it’s not used by OS/2, Windows 3.1, or DOS.
I tried three slightly different sets of OS/2 Crystal Audio drivers: The ones that came with the OS (MCP2), the ones that Lenovo still kindly offers on their site, and another set from the web. The driver that comes with MCP2 is dated newer than the one from Lenovo (version 2.08), but is in fact an older version (1.x) with a slightly different structure. The set that I randomly downloaded somewhere is a slightly newer version (2.09) of the drivers that IBM/Lenovo provided.
All the OS/2 driver sets have essentially the same problem: They see that a Crystal chip is there, but can’t set it up. The DOS/Windows 3.1 drivers from IBM/Lenovo have that trouble as well, just with slightly different error messages.
A rather bizarre conundrum is the fact that under DOS, Sound Blaster emulation works but not the native Crystal drivers. In practice that means DOS games work with Sound Blaster audio, but the native Windows 3.1 crystal drivers refuse to load. What gives?
