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.
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?
One OS/2 driver set offered a clue in the form of the following error message:
RM: IRQ 65535 (Resource Conflict)
Now, 65535 is obviously -1 in 16-bit two’s complement arithmetic, probably indicating an erroneous or unassigned interrupt. Googling that error message found someone who not only had the exact same problem 18 years earlier, but actually solved it.
The other person had a slightly newer Thinkpad 770Z, but my 770X has the exact same Crystal CS4239/CS4610 audio chips and clearly also the same problem, namely Plug and Play.
PnP Audio Hell
I have had enough run-ins with ISA PnP sound cards over the years that I hate them with a passion. The trouble with audio and especially Sound Blaster audio is that there is no real plug and play. Software, especially DOS games, tends to be very inflexible; I/O base 220h, DMA 1, and IRQ 5 or 7 is generally supported (Creative’s old Sound Blasters defaulted to IRQ 7, newer ones to IRQ 5, which is why both values are well supported). Going anywhere beyond that is iffy and may or may not work.
The gist of the problem is that in theory audio is configurable with a wide range of I/O bases, IRQ lines, and DMA channels, but in practice it is much, much closer to VGA or IDE fixed resources. For most likely historical reasons, audio did not get the same special treatment as VGA or IDE, presumably because it is not as critical to system operation (which, together with very problematic DMA support, makes Sound Blaster emulation on PCI cards another special circle of hell).
The upshot is that audio is a non-essential PnP function, and ISA PnP never seems to have functioned all that well outside of perhaps Windows 9x.
One of the best solutions/hacks for ISA PnP audio I’ve seen was on Terratec’s EWS64 cards. These are fully ISA PnP devices, but instead of offering a range of resources and letting the BIOS/OS configure them, they have an EEPROM which can be configured to provide one configuration to the PnP manager—exactly the one the user desires. While that certainly violates the spirit of PnP, it actually works very well in practice.
ThinkPad 770X Audio Configuration
The 770X seemingly has absolutely no PnP-related configuration options in its BIOS setup. But only seemingly, as that old newsgroup posting made me realize. There is an option called Quick Boot; the 770X User Guide notes the following: “If you are going to use a non–Plug and Play–capable operating system, disable this function so that the BIOS will configure hardware resources.”
This option is normally called “Boot Non-PnP OS” or something similar in conventional BIOS setups. IBM made it much less obvious but it still does the same thing: When Quick Boot is enabled, the BIOS only sets up critical devices (disk, video) and leaves everything else, including audio, disabled. The manual is clear that when using DOS or OS/2, the Quick Boot option needs to be turned off. So I disabled it (by default it’s enabled)… and it made absolutely no difference.
Now, there are other audio configuration options, but those are not in the BIOS setup. They are accessible through the PS2 utility (old naming that goes back to the original Microchannel PS/2 branded ThinkPads). Said utility can enable or disable the audio chip and set the I/O base addresses, IRQs, and DMA channels.
I checked everything in the PS2 utility and found no obvious problem, everything was supposedly correctly configured and enabled. Yet DOS and OS/2 were still completely unconvinced. Notably the OS/2 Resource Manager (RM) did not show any trace of the audio device.
Finally I read through the old discussion again. There was a suggestion to “initialize” the BIOS settings, in addition (or perhaps prior to) turning off Quick Boot. So I did that, and lo and behold—or maybe hear, hear!—there was audio! Suddenly both DOS/Windows 3.1 and OS/2 audio started working.
I am not at all sure what initializing the firmware configuration did, but it did something. Whatever it was, it sounds good. The ThinkPad 770X user manual only says that the “Initialize button sets all device settings to their default values”. What those device settings might be or what the default values are is anyone’s guess.
Another win for Plug and Pray…
>I am not at all sure what initializing the firmware configuration did
ESCD cleaning?
Entirely possible, but that just raises the next question: Why should clearing the ESCD do anything?
I had both a 770X and 770Z back in the day and ran OS/2 (and Linux) on them. I don’t recall having much problems getting audio working in OS/2.
Regarding DOS and ISA PnP sound cards, I suggest you have a look at UniSound
https://www.vogons.org/viewtopic.php?f=62&t=72553
It seems that the behavior depends on what state the ThinkPad is in and what had been done to it in the past. My impression is that this was not a common problem, but clearly I wasn’t the first one to run into it.
I very much doubt that UniSound would have worked when the utilities from Crystal didn’t, but I can not prove or disprove that anymore.
I worked for IBM back in the day in software development, and we had the hardware guys responsible for testing (baking, drop tests, etc) next to us. And I would on occasion be offered “new” ThinkPad models that they no longer needed, but could not do anything with other then to scrap them. They would have weird serials, such as “GOLD1”.
One of these was a 770Z with all the bells and whistles (MPEG module, DVD, max RAM, etc.). A few months later, silly me, I decide to do a BIOS update for some issue.
After the update the system would no longer boot, only showing some error code which according to the HMM meant to replace the main board. Replacing the main board was not an option as the system did not have a valid serial, so I could not call it in for service. Talking to the hardware guys, I found out some security eeprom had been erased or contained garbage. Got some special boot disk from them, and had to jumper some pins on the parallel port, and instead of an error, it booted from the disk, re-flashed the eeprom, and the system worked again.
That sounds like the password EEPROM causing trouble. I’ve had run-ins with those, but without the secret knowledge (and someone to ask) I resorted to a screwdriver and strategically shorting EEPROM pins. From what you’re describing I wonder if the EEPROM actually got scrambled or if it was some prototype version such that the contents were no longer supported by the updated BIOS.
The magic boot floppies I heard about (there’s some special signature in the boot sector I believe) but not the parallel port pin tweaking.
Its likely that IBM chose to store the default PnP configuration data profiles for on-board devices in NVRAM somewhere and that got corrupted. Normally a set of default configurations is stored on ISA PnP cards in a tiny ROM which a PnP BIOS can read to setup cards. This is likely a non-issue for PnP aware OSes since all they really need is the card ID that matches to a driver. I think the driver has to be able to handle the rest.
If I remember correctly, if you did not short those pin(s) on the parallel port, it would not check for a diskette.
Ah, interesting. The magic floppies I saw were for older ThinkPads (something in the 760 series I believe). Either those were different or shorting the pins provided even more magic power. I unfortunately don’t remember the details but I think there was some way to boot from a special floppy even when the boot was password protected.
I have worked on uncountable number of ThinkPad systems, including the PS/2 P70 luggable, pretty much every model in the 600 and 700 series, and the later T and X series… Including the rare 850 PowerPC ThinkPad with AIX. But I never had a need for any special ‘magic’ boot disks, other then that one occasion. I also don’t know if there was anything ‘magic’ about the boot sector of the disk, from what I recall it booted DOS and directly ran the flash program.
I originally kept a copy of the disk, and the pin(s) to be shorted, but that was lost when I changed job, and had changed to a T41p.
We also had a “sandalfoot” system with OS/2 for PowerPC, but never did anything with it.
I was also involved for a short period with OS/2 development in Austin during the OS/2 Warp Server for eBusiness development, for writing a redbook. And because I was an IBM employee in software development, I was given access to the source code repository and the build servers. They would do a nightly build every day, and I would (assuming a successful build) grab the latest build in the morning for my work.
I unfortunately can’t find the details but I definitely came across some kind of a magic ThinkPad boot floppy which was able to boot even when (I believe) a password was set. The details were on some website, which unfortunately appears to be gone. It’s possible that the shorted pins did the magic in your case and the floppy was not unusual in any way.
I have one of those Sandalfoot machines… there’s not a lot one can do with them 🙂 But it can run OS/2 for PowerPC. Which not a lot of machines can. I’m pretty sure it can also run some version of AIX and maybe even Solaris (ThinkPad 850 can run Solaris for sure).
Years ago I saw one of those Austin OS/2 builds. Wonder where all that code is now.
Okay, after a lot of searching I found the reference: https://matt.ucc.asn.au/thinkpad.html There is a “magic boot sector” which allows certain ThinkPads to boot from a floppy even when the machine is not set up to boot from a floppy and even when the machine uses an unknown supervisor password.
The datasheets for these crystal audio chips reveal some interesting things. The chips even support firmware upgrades…
I believe they generally had downloadable firmware, yes. I guess something was on the chip but drivers could upload newer firmware at start-up. I never saw detailed documentation (it was likely never public) but I got the impression the chips had some pretty nifty programmable DSPs in them and a fair amount of flexibility. Perhaps not unlike M-Audio, except Crystal Semi never tried to turn them into more general-purpose devices.