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
This might save someone a bit of head scratching…
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
An interesting piece of hardware popped up at the OS/2 Museum not long ago. It’s an E-mu SoundEngine General MIDI sound module from 1993. This module has very close ties to the original Creative Wave Blaster upgrade module, even though that’s not very apparent from the outside.
E-mu SoundEngine
The module is Mac-centric with Mac-style serial connectors and a way to daisy-chain Mac serial printers or modems. But it also has standard MIDI IN/OUT/THRU connectors so an antique Mac isn’t required to use it.
Looking inside, a certain similarity with a Wave Blaster emerges:
SoundEngine guts
Yes, that card with chips on it is the size and shape of a Wave Blaster. Continue reading
This is a follow-up to a previous post. I’ve had a chance to spend more time recovering the two dead PS/2 Model 80s. The first step was replacing the CMOS batteries because without a functioning backup battery, a PS/2 is more or less a brick (a 40-pound brick no less).
Although the Model 80 uses very unusual (for desktop computers) batteries, sourcing them is luckily no problem in 2016. For reference, the original batteries IBM used— Panasonic BR-P2 in my case—lasted upwards of 20 years.
New (left) and old (right) IBM PS/2 Model 80 CMOS backup batteries.
The next problem was recreating the system configuration, which requires a reference diskette. Finding a reference diskette image and additional adapter descriptor files (ADF) is not hard. Using them with a half-dead floppy drive is. Continue reading
I’ve been a Synology DiskStation NAS user for four years now and used them as a SMB file server which is, among other things, accessed from various vintage clients (OS/2, DOS, Windows 9x, etc.). After upgrading to DSM 6, I found that these clients no longer work. That is to say, any attempt to connect fails because the credentials are rejected.
The problem is that DSM 6 (essentially customized Linux + Samba) by default no longer accepts old-style LAN Manager passwords. Fortunately it is not difficult to fix, but it is a multi-step process.
/etc/samba/smb.conf with sufficient privileges (with sudo vi, for example). In the [global] section, add a new line which says lanman auth = yesmin protocol = LANMAN1 (not needed for Windows 98 or NT 4 but required for DOS or OS/2)sudo smbcontrol smbd reload-config or rebooting the DiskStation).The final step is not very obvious. One reason why servers do not like old-style LAN Manager authentication is that the server needs to store a cryptographically weak password hash. Okay, you don’t care about that. But if old-style authentication is enabled, the password hashes need to be re-created because they won’t exist.
It may be enough to re-set the password in the DSM user interface. If it is not, run sudo smbpasswd -L -U <username> on the DiskStation. To check if passwords have LAN Manager hashes or not, you can run sudo cat /etc/samba/private/smbpasswd on the DiskStation. If the third colon-separated field has lots of XXXs there is no LANMan hash.
Note that this problem applies to fresh DSM 6 installations as well as DiskStations upgraded from DSM 5. With upgraded systems, there is a possibility that existing LANMan hashes might survive in the Samba password file; on new installs the hashes definitely have to be re-created.
On some systems, Windows 3.1 and 3.11 in Standard mode crashes when it is configured to use APM, i.e. POWER.DRV is loaded. The crash only happens in Standard mode, not the typical default 386 Enhanced mode.
Windows 3.1 APM Crash
Since POWER.DRV is involved (“MS-DOS System with APM” vs. “MS-DOS System” in Windows setup), it’s obvious that power management/APM is somehow significant, but how, and why is only Standard mode affected? The explanation is a bit complicated. Continue reading