I recently picked a Acer FX-3D sound card with integrated radio from my box of old ISA cards. It's a typical late ISA age sound card featuring the AD1816 sound chip. This card is special in that it also contains an FM radio receiver in the shielded box.

A typical AD1816 sound card doesn't need any discrete logic compontents, everything is integrated in the main chip by Analog Devices. The small 24LC04 chip contains a setup byte for the AD1816 and the ISA plug and play identification data. The UTC2025 is the "speaker out" amplifier. This card does have three extra logic components: An 74HC374, an 74HC125 and a 74HC02. These three chips are used to interface the radio to the ISA bus.

When I plugged the card into an EISA main board, the system did not POST at all. When I plugged the card into a PCI mainboard with an PCI video card, the system started to POST (I got some codes on a port 80 card), but also didn't work. Furthermore, the CMOS contents got corrupted on this POST attempt. So the card clearly didn't behave as it should. To understand the problem, one needs to understand how the radio/ISA interface is designed: The AD1816 chip supports I/O decoding for a modem integrated on the same sound card, for example as "chip select" input for an 16C550 UART chip.

This "modem chip select" output has been repurposed as "radio chip select", which is perfectly OK, especially if the Plug-and-Play data doesn't identify that logical device as serial port. This is the point where the custom logic kicks in: The 74HC02 combines the "modem chip select" signal from the AD1816 with the /IOR and /IOW signals from the ISA bus to generate "radio read" and "radio write" signals. The "radio write" signal is used to latch the ISA data into the 74HC374 chip. The outputs of that latch are connected to control pins on the radio module. This has no potential of disturbing the ISA bus. The opposite is true for the "radio write" signal: This one is enabling the 74HC125, which forwards up to 4 status signals from the radio bit (likely a "tuning" indicator and a "stereo" indicator) to the ISA bus. If the 74HC125 would be enabled when it shouldn't be enabled, it would cause ISA bus conflicts, which perfectly fit the symptoms. And indeed, this is what happens on this card: For some reason (see below), the "modem/radio chip select" is permanently enabled. This makes the radio status port to respond to all ISA read cycles instead of radio read cycles only. Oops!

The cause of the problem: The "modem chip select" output of the AD1816 is routed to a multi-function pin. It could also be part of an I2S interface for an external digital audio source that gets mixed into the output of the chip. If the pin is configured as I2S input, it is not actively driven high or low by the AD1816. The default configuration of that pin is I2S input, whereas the modem chip select signal needs to be configured from the configuration byte in the EEPROM. So let's see what the EEPROM signals look like when the card powers up.

The cyan signal is the I2C clock, the yellow signal is the I2C data signal. The lower red text row shows the interpretation of single bits in the I2C transfer: "0" and "1" are plain data bits. "S", "R" and "T" are the I2C start, restart and stop condition. "A" and "N" are I2C "ack" and "nack" cycles. The upper row is a higher level interpretation, showing the address of the configuration EEPROM (0x50) with the read/write bit set to "write". This cycle is used send the address of the byte to read to the EEPROM. The next byte is 0, requesting the first byte of the EEPROM, followed by an restart condition. The restart condition is used to terminate sending data to the EEPROM, so the following byte is a new address byte. This time, the address 0x50 is combined with a read indication, so this is a request to the EEPROM to output data. The data received from the EEPROM is 0x01, which is purposefully not acknowledged by the AD1816 chip, to terminate the read operation, which is followed by a stop condition to free the I2C bus.

The data sheet of the AD1816 indicates that the top bit of the configuration byte is required to be set for the EEPROM to be considered valid. This means the contents of the EEPROM are obviously corrupted. The corrupted EEPROM makes the chip to fall back to the default configuration with no radio/modem support. This wouldn't be a problem, if there were a pull-up resistor on the radio chip select line. Acer omitted that resistor, so I added one.

And voilà, now the card no longer breaks the system when it is inserted into an ISA slot. This doesn't fix the broken EEPROM contents, though. The AD1816 allows in-system reprogramming of the EEPROM, but this can not work if the write protect pin of the EEPROM is enabled. On this card, the write protect pin is enabled (which makes me wonder, how the EEPROM got corrupted at all). As I had to desolder the EEPROM anyways to unprotect it, I then read it in an external EEPROM reader, and analyzing the data (by hand), I found the first three bytes to be corrupted. These are the configuration byte for the AD1816, which can be reconstructed from the AD1816 datasheet, and the PnP card Vendor ID, which should be "ADS" (EISA encoded) for "analog devices". I fixed them and obtained the attached 512-byte file. Reprogramming the EEPROM, the card works again perfectly, including the radio part.