Resurrecting the Ensoniq ASR-10: A Reverse Engineering Journey

From raw EPROM dumps to a running CPU emulator — cracking open a legendary 90s sampler one byte at a time.

The Ensoniq ASR-10 was a legendary sampler/synthesizer from the mid-1990s, a machine that defined the sound of an era. Under the hood, it was powered by a Motorola 68302 microcontroller — a member of the 68000 family with integrated peripherals — paired with an Ensoniq ES5510 (DOC II) DSP chip for real-time audio processing. The 68302 ran the show: managing the user interface, the floppy disk controller, SCSI, MIDI, and orchestrating data flow to and from the DSP.

With original hardware aging — capacitors leaking, floppy drives dying, displays fading — and no modern driver or emulation support, we set out to fully reverse engineer the machine: the boot ROM firmware, the disk-loaded operating system, and the DSP audio pipeline. The goal: build a working software emulator from scratch, preserving this instrument for future generations.

The ROM Puzzle

Our starting point was two separate EPROM dumps, each 128 KB. The ASR-10 uses a 16-bit data bus, but the ROM chips are 8-bit — meaning one chip holds the high bytes and the other holds the low bytes of each 16-bit word. The question was: which is which, and how do we interleave them?

We tried every combination systematically: HI-LO interleave, LO-HI interleave, straight concatenation in both orders. For each attempt, we ran two validation checks. First, we examined address 0x000004 — on a 68000-family CPU, this is the initial PC vector, and it must point to a valid ROM address. Second, we searched the entire binary for readable ASCII strings.

The answer came quickly. With the HI-LO interleave, address 0x000004 contained a plausible reset vector pointing into the ROM's address space, and a search for ASCII strings yielded clean, readable results:

"SOUNDBANK" appearing perfectly in the HI-LO interleave confirmed it beyond any doubt. The other orderings produced nothing but garbage. We had our ROM image: 256 KB of 68302 firmware.

Loading it into Ghidra with a Motorola 68000 processor profile, we set the base address to match the 68k vector table and let the auto-analyzer do its work. After recursive disassembly from the reset vector and careful manual intervention at ambiguous branch targets, Ghidra identified 157 functions in the ROM — the entire boot-stage firmware.

The OS Disk

The ASR-10 doesn't run entirely from ROM. The ROM is essentially a bootstrap loader — the real operating system lives on a proprietary-format floppy disk. Ensoniq used a custom disk format: 80 cylinders, 2 heads, 20 sectors per track — for a total of 1.6 MB, squeezing 60% more data out of a standard HD floppy than a typical 1.44 MB PC format.

Decoding the filesystem required careful analysis. The disk uses a FAT (File Allocation Table) with 3-byte entries, an unusual choice that packs block chain pointers efficiently into the limited disk space. After the FAT comes the directory structure, which revealed the disk's contents:

The OS binary itself occupied 412 blocks. We extracted it, loaded it into Ghidra at the address where the ROM's loader copies it into RAM, and let analysis run. Result: 577 functions — the entire ASR-10 operating system, including the floppy disk driver, SCSI handler, MIDI engine, waveform editor, effects management, and the full user interface.

First Boot

With the ROM image validated and loaded, we built a minimal emulator around the Musashi Motorola 68000 CPU core — a cycle-accurate, battle-tested open-source emulator used in MAME and other projects. We wired up a flat memory map with the ROM at address 0, 512 KB of RAM, and I/O stubs that log every access to unmapped regions.

Then we hit run. The first instruction trace was immediately recognizable to anyone who has worked with 68k hardware:

MOVE #$2700, SR — the classic 68000 boot. Set the status register to supervisor mode with all interrupts masked. What followed was a textbook 68302 initialization sequence: the firmware configures the SIM (System Integration Module) registers at 0xFC0000, setting up chip-select lines to define the memory map.

But then came the clever part. The ROM copies a tiny relocation stub — just 32 words — into the 68302's internal SRAM at 0xFC0800, then jumps to it. This stub's sole purpose: reconfigure CS0 to remap the ROM from its boot address at 0x000000 to its final address at 0xFFF80000, freeing up the low memory region for RAM. The stub then executes a final JMP to the same routine at its new address in high memory.

The eureka moment: when we updated our emulator's memory map to handle the dynamic CS0 remapping, the CPU seamlessly continued execution at 0xFFF80210 and began running real firmware initialization code — configuring RAM, testing memory, and setting up peripherals. The ASR-10 was booting.

The Memory Map Reveals Itself

One of the beautiful things about emulation-driven reverse engineering is that the firmware tells you the hardware layout — you just have to listen. Every write to a chip-select register defines a new memory region. Every read from an unmapped address reveals a peripheral the firmware expects to find there.

After the ROM remapping, the boot trace continued to configure the complete memory map. The 68302's SIM registers at 0xFC0000 appeared first — these are the microcontroller's own configuration space. Then came the serial controllers: the 68302 integrates three SCC (Serial Communication Controller) channels, used for MIDI and communication with the front panel. The DMA channels were configured next, along with the system timers.

The most interesting moment came when the firmware made its first access to external peripheral space:

Address 0x408000 — our first external peripheral. The access pattern — write a command byte, read back status, test a ready bit in a tight loop — is the unmistakable signature of a floppy disk controller. The firmware was already trying to boot the OS from disk.

After letting the emulator run for 100,000 cycles, we had accumulated over 50,000 I/O access log entries, painting a detailed picture of the hardware:

Every address in this map was discovered automatically by the firmware's own initialization sequence. We didn't need a schematic — the code is the schematic.

What's Next

We have a 68302 CPU emulator that successfully boots the ASR-10 ROM through its entire initialization sequence. The memory map is mapped. The I/O peripherals are identified. But the road ahead is long:

• Mock the floppy disk controller — The firmware is stuck in a loop waiting for the FDC to respond. We need to implement enough of the WD1772 (or compatible) FDC protocol to feed it sectors from our decoded disk image. Once the OS loads into RAM, we'll have access to all 577 functions and the full UI logic.
• Implement the LCD display — The ASR-10 has a 40x2 character LCD driven through memory-mapped I/O at 0x400000. The firmware is already writing characters to it; we just need to capture and display them. Seeing "ASR-10 v2.00" appear on a virtual LCD would be a major milestone.
• Integrate the ES5510 DSP emulator — The MAME project already has a foundation for ES5510 emulation, developed for their Ensoniq sound card drivers. The DSP interface registers at 0x300000 are where the 68302 uploads microcode and audio parameters. Connecting a working DSP emulator would bring the sound engine back to life — filters, effects, sample playback, the entire audio path.
• MIDI and front panel — Implementing the SCC serial channels for MIDI I/O and the button/encoder matrix for the front panel. This would make the emulator interactive — load sounds, play notes, edit parameters.

The ASR-10 was a machine built by people who understood both music and engineering at a deep level. Every byte of its firmware reflects that craftsmanship. Reverse engineering it is not just about preservation — it's about understanding the ingenuity that went into making a machine that could turn samples into art.