Building a Beavis Ultrasound ISA PnP Clone: From InterWave to EEPROM

The moment you realize it’s not “just another sound card”

A lot of retro hardware projects begin with nostalgia. This one starts with a different kind of feeling: frustration with the numbers.

The Beavis Ultrasound project is an open-source replica of a specific era of PC audio hardware: the Gravis UltraSound PnP line, implemented as an ISA Plug and Play sound card. The repository’s angle is what makes it exciting. It doesn’t only publish a PCB layout; it includes the full schematic and the reverse-engineered GAL source code (GAL = “Generic Array Logic”, a small reprogrammable logic chip). (github.com)

If you’ve never built a piece of ISA-era hardware before, it helps to know the secret: most of the “sound card” magic is baked into a single chip. That means the board is less a pile of discrete audio blocks, and more a careful wiring harness around one important IC.

Meet the cast: InterWave, ROM, EEPROM, and GAL

Let’s translate the names into plain language.

1) InterWave (the “does the real work” chip)

The heart of the card is an AMD InterWave audio processor—specifically the AM78C201 family (the Gravis UltraSound PnP redesign is based on that InterWave approach). Wikipedia summarizes the Gravis UltraSound as featuring 1MB of sample ROM and 8MB of RAM for wave-table style sample playback. (en.wikipedia.org)

In the Beavis Ultrasound clone, the README makes the intention explicit: the PCB design is relatively straightforward because “essentially all sound card functionality is built into the AMD chip.” (github.com)

Plain-English takeaway: InterWave is the programmable engine that outputs audio, handles voices/samples, and exposes the right behaviors to DOS/Windows-era drivers.

2) Sample ROM (where the built-in sound bank lives)

A sound card often needs a starting set of samples. This board’s README calls out a dedicated ROM chip:
- U8 (IW78C21M1): 1MB sample ROM

If you can’t find the exact chip, the project suggests burning the sample ROM into a 27C800 (a common 5V-era EPROM/flash family) and installing it (ideally in a socket). (github.com)

Why ROM matters: before you load custom instruments, the card needs something immediately usable.

3) EEPROM (how the card identifies itself and gets configured)

Here’s where ISA Plug and Play stops being “mystical” and starts being very practical.

The project uses:
- U6/U60: a 93C66 EEPROM holding the PnP configuration data.

The README says you should program it using a TL866-class programmer, loading contents from ultrasound_pnp.bin. It also warns about a subtle trap: the order of bits is reversed in 16-bit chunks. It even gives an example where the bytes you expect (1E 56) are stored swapped (6A 78). (github.com)

EEPROM, defined: Electrically Erasable Programmable Read-Only Memory. It’s non-volatile storage for configuration data.

And because 93C66 is a serial EEPROM type, the datasheet behavior matters too. One common 93C66-family behavior is that the data field clocks out MSB first during writes/reads (MSB = “most significant bit,” meaning the “top” bit in the word). (rhinopower.org)

That’s why “dump it and write it” isn’t always the whole story.

4) GAL (the glue logic that talks to the bus)

Sound hardware chips rarely connect to a computer bus perfectly “by themselves.” There’s glue: buffering, decoding, chip-select logic, and isolation so timing and voltage domains behave.

The Beavis Ultrasound clone uses a GAL (the README names U14) “used for several purposes,” including:
- buffering IOCS16 from the IDE port to the ISA bus
- buffering bus reset to the IDE port
- decoding address lines for primary/secondary drive select
- controlling buffer enable signals for ISA to IDE data buffers (github.com)

GAL, defined: A small reprogrammable logic device. Instead of building custom logic from dozens of gates, you describe logic in a file and program the chip.

ISA Plug and Play: what’s actually happening on the wiring

So what makes ISA Plug and Play so fiddly?

ISA Plug and Play (often abbreviated ISA PnP) was designed to solve the manual pain of IRQs and I/O addresses in the ISA era. The system BIOS (the firmware that boots the machine) enumerates ISA PnP cards and allocates “resources” like I/O ports and IRQ lines to avoid conflicts. (tldp.org)

In practice, this means your sound card isn’t just waiting for the CPU—it’s participating in a configuration handshake:
- The card must provide identifying info.
- The BIOS assigns addresses/interrupts.
- The card firmware (or configuration data) must allow the device to map itself into those resources.

The EEPROM on the card is a big part of that: it typically stores a configuration “personality” so setup tools and PnP BIOS can program the device consistently.

Programming the 93C66 EEPROM: the byte-order booby trap

The README’s note about the EEPROM layout is the kind of thing that can waste an entire weekend.

They specifically say the EEPROM contents have reversed bit order in 16-bit groups, so “first two bytes are actually 1E 56 but are stored as 6A 78.” (github.com)

Here’s a beginner-friendly way to think about it:
- Many programmers and dumps represent data as sequences of bytes.
- But the target EEPROM’s serial interface and the card’s expectation of bit/word order may not match how the binary file was produced.

Even if you never “fully understand” it, you can handle it deterministically.

A tiny Python sketch of the idea

This demonstrates the core transformation the project mentions: swapping each 16-bit chunk.

# Swap byte order within each 16-bit word
# Example: stored bytes [b0, b1] represent intended word as [b1, b0]

def swap_u16_words(data: bytes) -> bytes:
    if len(data) % 2 != 0:
        raise ValueError("EEPROM image length must be even")
    out = bytearray(len(data))
    for i in range(0, len(data), 2):
        out[i] = data[i+1]
        out[i+1] = data[i]
    return bytes(out)

That’s not the only possible form of “reversal” you might encounter across old hardware projects. But it matches the spirit of the README’s warning and gives you a controlled way to test hypotheses.

The GAL: why bus glue belongs in the PCB story

If you’ve built modern boards, you might expect a microcontroller or FPGA to “mediate everything.” In this era, glue logic did the job.

The GAL here isn’t making sound by itself; it’s making sure the ISA bus and the IDE/CD-ROM interface signals behave correctly relative to the rest of the system. The README’s list of responsibilities reads like a checklist for “signals that must be buffered or decoded” rather than “audio DSP features.” (github.com)

This is a pattern you’ll keep seeing when you study vintage designs:
- The “big” chip handles audio.
- Smaller programmable logic handles compatibility.

PCB practicalities: size, layers, and parts substitution

Even the most elegant schematics can fail if the PCB details don’t match what the machine expects.

The Beavis Ultrasound README includes practical fabrication and assembly notes:
- Board size: 8.2 × 4.2 inches (208 × 107 mm)
- Stackup: 4 layers
- Suggestions: use ENIG plating on edge fingers if you want a reasonable cost/benefit compared to hard gold (github.com)

On the analog side, the README calls out that dual op amps may be substituted. The BOM lists LM833, but JRC5532 is mentioned as working, with an expectation of roughly similar low-noise behavior and input/output constraints. (github.com)

There’s also a realism check: the README admits certain items (like ferrite beads) were missing on the initial card, meaning values aren’t known and can be replaced with 0-ohm links if you’re restoring or iterating. (github.com)

That candor matters. Builders learn faster when the project also states what’s assumed, what’s uncertain, and what’s “build at your own risk.” (github.com)

Testing: the “first power on” mindset

A sound card replica usually fails in ways that feel unfairly random: no detection, wrong IRQ, silence, distorted playback, or only working in one environment.

With an ISA PnP card, a common failure mode is configuration mismatch:
- EEPROM programmed with the wrong bit/word order
- PnP data not matching the expected format for the card’s firmware expectations
- glue logic (GAL) programmed incorrectly so bus timing/address decode doesn’t line up

The good news is that these problems are often narrower than they look. The Beavis Ultrasound clone is explicitly engineered around a known structure: InterWave does the audio work, EEPROM stores configuration, GAL does compatibility glue, and ROM provides the sample bank. (github.com)

Once you see those roles, debugging becomes less of a haunted-house experience and more of an engineering checklist.

Wrapping it up: why this clone is a great learning project

The Beavis Ultrasound ISA PnP replica sits at a sweet spot for technical learning. You get to touch real hardware concepts that most modern developers never meet:
- how ISA Plug and Play relies on firmware configuration data
- how a 93C66 EEPROM image can break when “byte order” assumptions don’t match hardware expectations
- how a GAL can replace a handful of glue gates with programmable logic
- how a sample ROM is the bridge between “a card exists” and “sound actually plays”

And yes, there’s still the joy of the absurd name. But underneath that: a very practical reminder that building vintage hardware is really the art of making decades-old expectations line up, signal-by-signal, bit-by-bit.