Some time ago, a mysterious CPU showed up at the OS/2 Museum:
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 →
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.
So I’m looking at an ASUS M3A32-MVP Deluxe board that stopped working some time ago and I had no time to figure out why. The board is from early 2008, not exactly vintage hardware, or at least not just yet. It gave up the ghost approximately in 2013.
I was about to fire up the board when I noticed that about half of the capacitors look like they’re trying to poop out the rubber seal at the bottom. It’s not terribly obvious at first glance and I also can’t find any traces of leaked electrolyte, but those capacitors look very sick.
The interesting thing is that the caps near the CPU, which I would think (perhaps naively) get stressed the most, look just fine. And I’m reminded of another board, an Intel DG965RY, which still works but has 3 or 4 rather unhealthy looking capacitors far away from the CPU. Continue reading →
Several months ago, I retook possession of a PC which I had built back in 2003 (I think—it’s been a while). It is based on an Intel D865PERL (Rock Lake) board and a Northwood 3.2 GHz Pentium 4 with hyper-threading (HT). I newly upgraded the machine to 4 GB DDR400 RAM, something I didn’t want to invest in back in 2003 but is affordable now.
Unfortunately the system had serious trouble with graphics. The machine was equipped with an ATI Radeon 9700 Pro (R300), a card I got as a freebie at an ATI event in San Francisco back in 2002 or so. The card served me very well for years (until it was replaced by a Radeon 1950 XT in a completely new system), but now it just tended to lock up a lot. Closer inspection revealed that at least one of the RAM chips on the card is almost certainly loose, which is not that easy for me to fix (BGA chips).
Radeon HD 3850, one of the fastest AGP cards.
The Intel 865 chipset is more or less the pinnacle of Intel’s AGP support, with AGP 8x capability. The next chipset, the Intel 915, was already based on PCI Express. On the other hand, the Radeon 9700 Pro is old enough that it works even in older AGP 2x systems.
As an intermediate solution, I stuffed a fan-less Radeon HD 3450 into the system. That took care of the stability, but I wasn’t very happy with performance. I didn’t do direct benchmarks but the card seemed slower than the old Radeon 9700 Pro. Part of the problem was that years ago, I used an analog CRT and ran games in 1024×768 resolution. Now the system has a 1600×1200 IPS LCD hooked up, and that more than doubles the number of pixels the GPU needs to push.
My test case was Half-Life 2. It’s a 2004 game (yes, that old!) and the 3.2 GHz Pentium 4 is a perfectly adequate CPU for it. But the HD 3450 graphics card was not. The game ran okay with reduced settings, but turning on the flashlight or encountering smoke brought the frame rate down to almost nothing.
Replacing the graphics card with something faster should take care of the slowdowns. But what to replace it with, that’s the question. Continue reading →
While pondering the DXP44Q mystery again, I realized that one of my sound cards most likely could be equipped with a DXP44Q. Here’s the card:
OPTi 924 with LS-262/LS-512, possibly optional DXP44Q
It’s a pretty standard Sound Blaster clone. Note that the OPTi 924 chips is only a “controller” with no DACs or ADCs, hence there is a separate AD1845 SoundPort codec. So where would a DXP44Q go? Continue reading →
The Pentium II OverDrive, released in August 1998, was the swan song of the OverDrive product line. It is suitable for Socket 8 systems as an upgrade of 150-200 MHz Pentium Pro processors. Only one model was sold with a PODP66X333 designation.
Pentium II OverDrive Box
The Pentium II OverDrive upgrades a Pentium Pro system with 66 MHz bus to a 333 MHz Pentium II, or a 60 MHz bus system to a 300 MHz processor. In other words, the processor uses a fixed 5× multiplier.
The Pentium II OverDrive is a curious beast. It’s perhaps closest to a Pentium II Xeon processor: it combines the Deschutes Pentium II core with a full-speed 512 KB L2 cache of a Pentium II Xeon. Why is that? Continue reading →
Several times, I tried to install Windows NT Advanced Server (NT 3.1 server) straight from CD-ROM (well, ISO) into a clean VM. The installation failed every time, asking for a nonexistent disk.
NT Advanced Server installer asking for nonexistent media
Yet going the longer route—boot DOS, copy files from CD-ROM, create boot floppy, boot from that floppy—worked just fine. The ISO looked legitimate, with no striking signs of being thrown together from random files (notably the metadata in the volume descriptor contained Microsoft information like the real CD-ROM should). What’s more, the same procedure worked for NT 3.1 workstation, so I was reasonably certain I was not doing anything outrageously wrong. So why wouldn’t it work? Continue reading →
This is a follow-up to an earlier post. Some interesting information turned up in reader comments and elsewhere. To recap, certain operating systems (notably Windows) behave unreasonably when using and especially when installed on CF drives that report themselves as removable.
CF cards were designed to be electrically and logically compatible with both PCMCIA (PC Cards) and IDE. Cheap and largely mechanical adapters exist for both CF to PCMCIA and CF to IDE applications.
The CF+/CompactFlash specification 2.0 (2003), and I believe earlier versions as well, mandates that the first word (Word 0) of IDENTIFY DEVICE response is 848Ah. That (specifically bits 6 and 7) indicates a removable device, which causes CF cards to be identified as such by operating systems, and generates interesting problems. Continue reading →
This is from the “learn something new every day” category. I’ve been using CompactFlash cards together with IDE adapters for several years now. It’s a terrific way to manage storage for vintage PCs. CF cards are cheap, fast, (relatively) capacious, and widely supported. It’s trivial to plug a CF card into a modern PC (typically using a USB adapter), copy files, and plug it into an old 486 or Pentium.
I’ve been using CF cards with DOS, Windows 3.x, and Windows 9x and never noticed much difference. Just recently I also tried using CF cards with Windows XP. The results were interesting.
Industrial (left) and consumer (right) CompactFlash cards.
The first card I tried was a weird 16GB Unigen Enterprise CF card. The card works, but it has very undesirable performance characteristics. Basically the card is very fast… except for writing small blocks. In practice it means that performance kind of sucks, but XP had no trouble using it.
The second card was SanDisk Ultra 32GB. This one subjectively performs much better, no doubt because writing small blocks isn’t penalized nearly as much. But the card had very very strange problems with XP. Straight after installation, XP kept complaining that it didn’t have a swap file, and it was impossible to create one.
After some head scratching, I realized that XP thought it was installed on a removable drive, and refused to create a swap file. OK, I understand the logic of not wanting to have removable-media swap files, but then again the boot drive isn’t really going to be removed, is it. Anyway, clearly the two CF cards were behaving differently—XP considered the SanDisk a removable drive, but the Unigen was fixed. But why? Continue reading →
30 years ago, in September 1986, Compaq announced the Deskpro 386, a PC as revolutionary as it was conservative. Compaq decided to forge its own path and not wait for IBM to introduce a 386-based PC. At the same time, Compaq made only minimal changes to the PC/AT architecture and essentially added a 32-bit CPU (a 16 MHz Intel 80386) to a 16-bit system.
Compaq Deskpro 386 illustration. PC Tech Journal, March 1987, page 53.
In retrospect, the Deskpro 386 did much more—and much less—for bringing PCs to the 32-bit era than contemporary observers expected. It was justifiably considered one of the most important new PC products of 1986; for example the PC Tech Journal honored the Deskpro 386 with its 1986 Product of the Year award.
The Deskpro 386 unquestionably set a standard for 386-based PC/AT compatibles, and in hindsight it’s obvious that it was much more successful than IBM’s far more radical 386-based PS/2 machines (we are nowadays running successors of the Deskpro 386, not of the IBM PS/2 systems). Continue reading →