Oddware: ASUS P4B card reader and talking BIOS

The year is 2001. Digital cameras, audio players (especially after the introduction of the iPod), PDAs and other then-high-tech consumer electronics are on the rise. These gadgets helped fuel the market for memory cards: little flash-based devices which store an astonishing amount of data for their size, increasing every year - some people still can’t get over the fact you can store half a terabyte of data in a fingernail-sized card. This led to a format war, where the Secure Digital and (to a lesser extent) Memory Stick formats prevailed in the consumer space.

Meanwhile, ASUS was probably looking for gimmicks to put on their motherboards for the Pentium 4 and Athlon XP, so they decided to build SD and Memory Stick card readers into these boards, as well as a talking BIOS.

It’s not USB

I’ve recently rescued an old Pentium 4 PC built around the P4B motherboard, and while performing a visual inspection to make sure no capacitors are blown, I found two headers labeled “SD” and “MS” and immediately thought: did they build some kind of proprietary card reader hardware onto the board? Seasoned PC builders will know internal SD card readers usually connect over USB 2.0 through a front panel USB header, but this system only supports the not-so-great USB 1.1.

The manual (still available from ASUS) confirmed my suspicion. These headers are intended to interface with a series of front panel card reader accessories, which they did make, but apparently in limited quantities - there are forum posts from 2002 questioning the availability of these accessories, and the only 3rd party picture I could find is on this Japanese website. The headers and the Winbond W83L518D card reader controller they are driven by appear on the P4B, P4B266, P4S333, P4S533, A7V333 and possibly other models.

The card reader is disabled by default and must be enabled through the Advanced > I/O Device Configuration menu on the BIOS. There is no way to enable both readers at once, even though they’re on separate headers, and the W83L518D supports both SD and MS on separate pins unlike the smaller W83L519D which shares pins.

Once enabled, the card reader is recognized as an ISA PnP device with ID WEC0518 by the operating system, as the W83L518D is an LPC (Low Pin Count) bus device. LPC is essentially a serial version of ISA used to maintain compatibility with legacy I/O devices such as PS/2, serial and parallel ports - modern systems still use it for the Super I/O controller handling the aforementioned legacy I/O, as well as (optionally) a Trusted Platform Module - so attaching a card reader to this bus is quite odd.

At least I tried…

Since there appears to be no actual hardware to plug into those headers, I’ve built a really janky contraption using a microSD to pin header breakout board, originally designed for interfacing said cards with an Arduino board through the SPI bus. Figuring out what pin goes where was a challenge, as both the motherboard’s manual and the W83L518D datasheet refer to the SD card pins as SDCLK and SDn (n=1..5), instead of the more familiar CLK, CMD and DATn (n=0..3) - I ended up matching them through the SD card socket pin numbers on the W83L518D datasheet’s sample circuit, and a pinout diagram for SPI mode for the breakout board’s pins.

The headers are JST connectors with 2mm pitch instead of the typical 2.54mm, so lots of SMD grabber probes (as well as stealing 3.3V and ground from nearby headers) were involved. The probes have two ends, so I connected one end to the breakout board through jumper cables, and the other end to a Kingst LA1010 logic analyzer.

At first I tried using Linux, which is supposed to support the W83L51xD chips through the wbsd driver. The driver registered its MMC interface despite failing to recognize the controller’s vendor ID, however, it failed to detect a known good 2 GB microSD card, with nothing on the kernel log even with debugging turned on (dyndbg module parameter) and even after a reboot.

[ 1274.723554] wbsd: Winbond W83L51xD SD/MMC card interface driver
[ 1274.723559] wbsd: Copyright(c) Pierre Ossman
[ 1274.723655] wbsd [wbsd_pnp_probe()]: PnP resources: port 248 irq 5 dma -1
[ 1274.723691] wbsd: Unknown hardware (id 8708) found at 2e
[ 1274.723702] wbsd: Unknown hardware (id 8708) found at 2e
[ 1274.723715] wbsd: Unknown hardware (id 5181) found at 4e
[ 1274.723726] wbsd: Unable to confirm device presence - you may experience lock-ups
[ 1274.762600] mmc0: W83L51xD
[ 1274.762607]  at 0x248 irq 5
[ 1274.762611]  FIFO
[ 1274.762612]  PnP

Thinking it could be an issue related to the vendor ID, I added the 0x8708 ID to the driver’s valid_ids array and recompiled the kernel - a task which probably should have been done on something other than a 1.6 GHz Pentium 4 with 512 MB RAM, taking upwards of 16 hours only to lock up during the linking stage and require a second attempt - but no change was observed, other than a warning about the chip being unconfigured.

Moving on to Windows XP, I installed “Winbond MS/SD Memory Card Reader Drivers for Windows 2000(V1.0.2000.0822) and Win98/ME(V1.0.98.0827)” (also still available from ASUS under the Windows 2000 section), which did recognize the reader as an ISA device and did create a new Removable Disk (S:) drive, though it still didn’t recognize the card.

Looking through a logic analyzer, SD1 starts out as low and is set to high when the driver is loaded, although there’s no activity afterwards. SD2 and SD3 are always high. The issue could be the wiring, the pinout, the breakout board (which does have pull-up/pull-down resistors), or the Winbond chip being incompatible with single-bit SDIO mode, which is all I can manage with that SPI-specific breakout board. I could have spent more time trying to chase this issue down - maybe by soldering the jumper wires directly to the pins of a microSD adapter as some SD-card-related DIY mods do - but there’s really no point in doing so for such a novelty device.

In practice, this card reader would probably have terrible bandwidth. According to Intel’s specification, the LPC bus’s total bandwidth is in the order of single-digit MB/s, which would have been faster than USB 1.1’s theoretical maximum of 1.5 MB/s half-duplex and probably just enough for the slow SD cards of the time, but is quickly overtaken by USB 2.0’s theoretical maximum of 60 MB/s half-duplex, as well as newer, higher-speed cards (eventually standardized under the Speed Class rating system). It also wouldn’t be compatible with SD cards above 2 GB, which use the incompatible SDHC protocol - that 2 GB microSD card is the only non-SDHC card I happen to have.

Speech POST Reporter: the talking BIOS

The I/O Device Configuration BIOS menu has one more interesting option, called “Speech POST Reporter”. With this option enabled, a compressed female voice reports on the system’s startup status over the onboard audio’s line output. That gimmick stuck around longer than the card reader did, because to be honest, anything is better than beep codes.

The voice is generated by the Winbond W83791SD chip, located not far away from the card reader circuit. Despite being marketed as a “speech synthesis” device, that chip is not actually capable of performing text-to-speech conversion, and instead relies on pre-recorded audio samples loaded from the nearby W55F10A flash chip - a socketed DIP8 device with an unusual protocol and pinout which no cheap programmers (like the MiniPro) support as far as I know.

Winbond developed a “Voice Editor” Windows utility for replacing these samples with any .wav file, as long as it fits in the 128 KB flash chip. That utility is reportedly included in the driver CDs for motherboards equipped with the Speech POST Reporter. At least two versions are available, and each one works on a different set of motherboards - the P4B requires version 1.0, still available from the ASUS download server as of writing.

Any replacement samples must be located in C:\Program Files\Winbond\Voice Editor\english, as there is no “Browse” button to select arbitrary .wav files. The “Write” button applies all changes by slowly reprogramming the entire flash chip over SMBus. Replacing the “computer now booting from operating system” sample with the Windows XP startup sound took me just over 14 minutes in “safe” programming mode, and of course, the finished product sounded pretty terrible - there’s definitely some kind of voice-optimized downsampling going on behind the scenes.