IBM XENIX 1.0 Incompatibility Details

Some time ago I wrote about IBM PC XENIX 1.0 and why it won’t work on 386 and later processors. Thanks to a kind reader, I’ve been able to analyze the object files used to link the kernel, and I believe I now understand exactly how XENIX uses the reserved space in LDT descriptors and why my patched kernel doesn’t fully work. This problem is likely common to all early editions of Microsoft XENIX 3.0, not just the IBM-branded release.

What XENIX stores in the reserved word is the size of the corresponding segment on disk; the value for a given descriptor is returned by a kernel-internal function called dscrsw(). This is used when an executable file gets loaded and also when swapped out. The latter is likely the reason why the segment size on file is stored in the descriptor table at all.

Incidentally, why is the troublemaking routine called dscrsw anyway? The answer to that riddle can be found in /usr/include/sys/relsym86.h: The last word of the descriptor table structure is defined as d_sw, or “software defined word, unused”. If only. Continue reading

Posted in 286, 386, Microsoft, Xenix | 19 Comments

Top of the Class 478

So I have that old Intel D865PERL board, which is a Socket 478/AGP board. There’s a 3.2 GHz Northwood in it but of course I was wondering, what’s the fastest CPU this board supports? And it turns out to be a question which is not so easy to answer.

The fastest clock speed supported by the board is easy to figure out: 3.4 GHz, with 800 MHz FSB speed. But there are three different 3.4 GHz CPUs that the board supports: Intel calls them Pentium 4 3.40 GHz, Pentium 4 Extreme Edition 3.40 GHz, and Pentium 4 3.40E GHz. These are also known as Northwood, Gallatin, and Prescott, respectively—with the minor caveat that Intel’s ark calls the Extreme Edition variant Northwood while others call it Gallatin.

3.4 GHz/800MHz FSB Northwood/Gallatin/Prescott

What’s not in question is that the first (Northwood) has 8 KB L1 cache and 512 KB L2 cache; the second (Gallatin) has 8 KB  L1 cache, 512 KB L2 cache, and 2 MB L3 cache; and the third (Prescott) has 16 KB L1 cache and 1 MB L2 cache. Continue reading

Posted in Intel, PC hardware, PC history, Pentium 4 | 3 Comments

More Peripherals

Remember this post from a while ago? Several new peripherals have turned up, but what are they? This time, the manufacturer names vanished together with the model numbers, but it shouldn’t be too hard.

Five unknown peripherals

Do you know these peripherals?

PS: Apologies for the poor photo quality.

Posted in MIDI, Sound | 11 Comments

Shiniest x86 Chip

While there have been many shiny new chips in the metaphorical sense, x86 (and x87) chips have never been known to be literally shiny. The typical packaging is ceramic or some form of brushed metal, and neither of these surfaces is shiny. But there was one x86 (or rather x87) chip which was actually very shiny, with a gold sheen to it:

33 MHz C&T J38700DX (1992)

It’s a Chips & Technologies SuperMathDX chip aka J38700DX, a 387-compatible math coprocessor. It’s a relative of the similarly obscure C&T Super386 CPU (which is not shiny at all). Continue reading

Posted in 386, C&T, PC hardware | 6 Comments

Finally Free

For a while I’ve been toying with the idea of buying the full official MIDI specification, but never went through with it. Not so much because of the cost ($100 for the core spec) but because of the hassle. Only fax or snail mail? Really? Not to mention that ordering from outside of the US seemed unreasonably complicated. The MIDI association site kept hinting that electronic versions of the documents would be available soon, but that message had been there for at least a year.

So I randomly went to the site today to check if anything changed and and lo and behold, it looks completely different! And what’s more… it no longer offers the printed MIDI specs for sale. Instead, there are PDFs for download (free registration required). That’s a heck of a lot better than $100 worth of dead tree matter.

So now I have a couple hundred pages to read. Thanks, guys!

Posted in Documentation, MIDI | 6 Comments

Gravis Ultras

While researching 1990s sound cards with wavetable synths, I came across an interesting resource called Rich Heimlich’s Patch Set Overview, namely issue #5 from July 1995.

When I tried to unearth older issues of same, I stumbled upon a curious PDF file. It looks like an Ensoniq Soundscape manual, but it’s in fact mostly filled with hundreds of posts from, capturing a major flame war in response to the innocently named Patch Set Overview. The flame war was basically Rich Heimlich vs. the united forces of Gravis Ultrasound fandom.

Gravis UltraSound (late 1992)

With the distance of 20+ years, it’s fascinating to read. And it’s hard to escape the conclusion that Mr. Heimlich was right and the GUS fans were wrong, and often extremely rude about it (although Mr. Heimlich certainly did not hold back). Continue reading

Posted in Creative Labs, Internet, PC history, Sound | 9 Comments

Getting Organized, Finally

After years of looking for a good storage solution for 386 chips, I accidentally stumbled upon it:

A slightly repurposed CPU tray

This is a relatively modern CPU tray, designed for—I believe—Socket G processors, It turns out that old ceramic PGA 386s fit in the tray rather well. Continue reading

Posted in 386, PC hardware | 10 Comments

Tahiti + Rio = Monterey

The talk is, of course, about Turtle Beach sound cards. I finally got hold of a 1994 Turtle Beach Rio daughterboard which came mounted on an ISA sound card. On closer inspection the card turned out to be a Turtle Beach Tahiti, the second generation of Turtle Beach’s famous MultSound line of semi-professional cards. And while the Tahiti ($259) and Rio ($139) were available separately, they were also sold as a combo called Monterey ($349).

Tahiti + Rio = Monterey

The first MultiSound (retroactively renamed to MultiSound Classic) was a 1991 design combining high-quality 18-bit converters, a Motorola 56001 DSP, and an E-mu Proteus 1/XR synthesizer. It is worth mentioning that the Proteus 1/XR was a very close relative of the original Wave Blaster and appears to be some variant of the E-mu SoundEngine.

In 1993, E-mu was acquired by Creative Technology, and the SoundEngine was no longer available to OEMs. In an unrelated development, Turtle Beach was bought by ICS, and ICS marketed the WaveFront synthesizer chipset.

With the Proteus 1/XR no longer available, Turtle Beach was forced to redesign the MultiSound for a 1994 release. The new board, MultiSound Tahiti, had minimal differences from the original, except it had no onboard synth at all and instead there was a 26-pin Wave Blaster connector. That connector ideally carried Turtle Beach’s own Rio, a General MIDI daughterboard based on the ICS WaveFront with a 4 MB ROM. More about the Rio later. Continue reading

Posted in MIDI, Sound, Wave Blaster | 16 Comments

Mystery NetBurst

Some time ago, a mysterious CPU showed up at the OS/2 Museum:

Intel CPU, S-spec SL7HY

Intel CPU, S-spec SL7HY

It is a Socket 775 CPU with a Pentium 4 label and the following markings: 3.73 GHZ/1M/1066/A4. In other words, 3.73 GHz clock speed, 1 MB L2 cache, 1066 MHz FSB, and A4 power/TDP requirements (should be mere 84W TDP according to Scott Mueller). The S-spec of the CPU is SL7HY. The processor was manufactured in week 22 of 2004, long before the fall of the evil heat-dissipating NetBurst empire.

Okay, so this is one of the faster-clocked Pentium 4 CPUs, perhaps with an “extreme” FSB speed, but what’s so unusual about it? Continue reading

Posted in Intel, Pentium 4 | 20 Comments

Alt Insanity

Several times, a question came up how to synthesize keyboard input to a remote system given a text string. The remote system is typically but not necessarily a VM. That sounds like something which should be trivial, yet it is anything but.

The basic problem is that keyboards send scan codes which reflect the position of the key on the keyboard, not the character which a key press generates. The compounding problem is that there is a nearly infinite number of key to character mappings, also known as keyboard layouts.

And even for the most basic alphanumeric input, the keyboard layouts are crucial, because entering something as simple as ‘abc123’ requires a different sequence of keystrokes on US, German, and French keyboards.

If the sending system runs a Windows OS, the problem scope can be greatly reduced through several APIs: OemKeyScan, VkKeyScan, VkKeyScanEx, MapVirtualKey, and MapVirtualKeyEx. These all translate characters or virtual key codes into scan codes, either using the current keyboard layout or given a specific keyboard layout. Sounds great, right? Not so fast… Continue reading

Posted in Virtualization, Windows | 13 Comments