Booting Windows XP, Or Not

Posted on January 22, 2021 by Michal Necasek

For a number of years now I’ve been using a SATA SSD with a “portable” Windows XP installation on it. Portable in the sense that it was capable of booting on a number of my machines, either in IDE mode or in some cases, in AHCI mode. But not anymore—now it no longer booted on some boards either in IDE or in AHCI mode, and failed with everyone’s favorite, bug check 0x7B (INACCESSIBLE_BOOT_DEVICE). I couldn’t make heads nor tails of it; it still worked perfectly fine on a number of boards, but on some it just wouldn’t boot.

I suspected that this was triggered by my failed attempts to get the XP install booting on my DX79SR Stormville board in AHCI mode. In the end I concluded that it couldn’t be done, but not before I tried installing several different AHCI drivers; to be clear, those drivers did make a difference—they made the OS crash at boot-up with bug check 0x7E (completely different from 0x7B and indicating a buggy driver). The Stormville board has a somewhat uncommon IDE/AHCI chip (related to the C600 chipset rather than any Intel desktop chipset) and it was released late enough (2011) that XP support was not provided.

After my failed experiments, I was no longer able to boot on the Stormville board even in IDE mode. I was also no longer able to boot that XP install on an older Intel D975XBX2 (Bad Axe 2) board, which previously worked fine in AHCI mode. But now it just sulked and gave me INACCESSIBLE_BOOT_DEVICE in both IDE and AHCI mode.

I attempted various fixes including a number of attempts of fix_hdc from Hiren’s boot CD. It did something, but that definitely did not include getting rid of the INACCESSIBLE_BOOT_DEVICE bug checks.

In desperation, I hooked up the XP install to a kernel debugger. It was already set up for kernel debugging (not that it would have been hard to do) and the Bad Axe 2 board is old enough to have a real serial port on the back panel. I booted up with the SATA controller in AHCI mode and kernel debugger attached. What the kernel debugger told me was odd.

Continue reading →
Posted in Debugging, PC hardware, Windows XP | 16 Comments

Seek and Ye Shall Find…

Posted on January 20, 2021 by Michal Necasek

…in the strangest places!

Lately I’ve been digging up marketing materials related to Intel’s desktop boards (I’ve long been toying with the idea of writing up a brief history of the circa 10 years of Intel Extreme Series boards).

There is no real archive of the information but random PDFs from years ago pop up in various places, most often various computer resellers around the world, sometimes academic institutions. But this Intel desktop board product matrix from 2004 really takes the cake—check out the URL. It is not fake.

Also note that this is the only copy of said PDF (Intel Confidential!) on the web. It only survived because of Al Qaeda and CIA. $DEITY sure works in mysterious ways.

Posted in Archiving, Intel, PC hardware, PC history | 2 Comments

It’s In Style Now

Posted on January 10, 2021 by Michal Necasek

Retrocomputing has now made it to the Style section of the New York Times. There is nothing particularly new about the article, except where it appeared. I guess people have noticed that retrocomputing is a thing, and that old gear is quickly turning into collectibles.

For my own part, I was very lucky that the OS/2 Museum acquired some equipment before retrocomputing was a thing. For example PS/2 machines are now worth hundreds of dollars, and I got a few at a time when shipping cost more than the machine.

These days, I find that prices of 5-10 year old server gear can be surprisingly low, although high-end desktop boards and CPUs still sell for surprisingly high prices (Core 2 Extreme, Core i7 Extreme) that never dropped down enough to reflect their actual practical value. Interesting times.

Posted in PC history, PC press | 10 Comments

Disabling Quick Edit Mode

Posted on December 18, 2020 by Michal Necasek

Last week I decided to finally solve a minor annoyance that’s been pestering me since I switched my main development machine from Windows 7 to Windows 10 over a year ago. As it is with these things, a certain threshold of pain needs to be reached before delving into the unknown, because one never knows how many rabbit holes it will lead to.

The problem: Every now and then, I use the Open Watcom tools, often for cross-development to DOS or OS/2. When I do that, I tend to use the console-based tools, including the vi editor and wd debugger, in part because they work the same across platforms. Both tools can work with a mouse, and especially the debugger is just much productive when used with a mouse. On Windows 7, that works fine. Not so much on Windows 10, because instead of sending mouse events to the application, Windows tries to select text in the console window. Not helpful:

Quick Edit Mode makes the mouse unusable for a console application

Anyone who has fought with this problem probably knows the answer: Quick Edit Mode. When Quick Edit is enabled, mouse selects text from the console window, Enter copies, right-click pastes. Great for a shell, much less so in a mouse-driven text mode UI. On Windows 10, Quick Edit mode is on by default, and that is what caused me grief.

Continue reading →
Posted in NT, Undocumented, Watcom | 22 Comments

The Answer To 0x49: Fujitsu FMR

Posted on December 11, 2020 by Michal Necasek

This is a guest post by A. N. Other.

The following was originally intended as a comment to “Not MSX Either“, the 4th installment in the hunt for the mysterious 0x69 FAT VBR-start byte which was allowed in DOS. Due to the length and content I was asked to turn it into a guest-post, presented below.

Definitive answer to 0x49, leading to new speculations about 0x69.

First let me thank Octocontrabass for the golden tip that got things rolling!
Also bleuge for your marvelous effort (I’m very curious to some info about [46; 2E; 262]…).

I got into this matter as my fuzzy tester uncovered 0x49. Further testing did indeed show that MS was checking for 0x49 for >25 years and that it indeed still does so for Win10, instead of 0x69 as stated on Wikipedia (and corresponding talk page, in fact there is currently no mention of the reality of 0x49).

It is this 0x49 that, for practical reasons, interested me the most. And who knows, it might give some insight into the 0x69 (and I will end with some new theories about this based on the facts regarding to 0x49).

Continue reading →
Posted in DOS, NT, PC hardware, PC history, Undocumented | 7 Comments

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 | 5 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 | 11 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