The Memory Map Reveals Itself

The firmware's chip-select writes told us everything about the hardware layout — we just had to listen to the I/O traces.

Chip-Selects Tell the Story

After getting the CPU to boot and execute the first instructions — the MOVE #$2700,SR that kicked off the Resurrection story — we turned to the emulator's I/O logging output. Every bus access to an unmapped address was captured. And the firmware's very first act after masking interrupts was configuring the 68302's chip-select registers at FC6830 and above.

Each chip-select write is a declaration: "there is a device at this address, with this size, and these access properties." The firmware was literally drawing us a map of its own hardware.

Four chip-select registers, four memory regions, and already a complete picture of the base hardware layout. But the interesting part was what came next.

The ROM Remap Trick

On a 68000, address 0x000000 is sacred — it holds the reset vectors (initial SSP and PC). The ROM must be there at power-on, or the CPU has nothing to execute. But after boot, you want RAM at address 0 so the vector table can be modified at runtime (to install interrupt handlers, trap vectors, etc.). Every 68k system faces this chicken-and-egg problem, and the ASR-10 solves it with an elegant trick.

The firmware copies a tiny 14-byte stub — just 7 words of 68000 machine code — to the 68302's internal RAM at FC6200. This RAM is always accessible regardless of chip-select configuration, because it's part of the 68302 itself. Then the firmware jumps to the stub.

The stub reconfigures CS0 to move the ROM from 0x000000 to 0xF80000. On the 68302's 24-bit address bus, this maps to the physical range 0xF80000–0xFBFFFF. The stub then jumps to the same code it was just executing, but at the new ROM address. From this point on, RAM occupies address 0 and the vector table is writable.

This is why the stub must live in internal RAM — it's the only memory that doesn't move when the chip-selects are reconfigured. If the stub were in ROM, it would be remapping the memory out from under its own feet.

ROM Mirroring

With the ROM at 0xF80000, we expected it to occupy exactly 0xF80000–0xFBFFFF (256 KB). But the I/O trace showed successful reads from 0xFF8xxx — well outside that range. What was going on?

The answer: partial address decoding. The chip-select logic doesn't decode all 24 address bits. The CS0 option register configures a 256 KB window, which means only address bits A0–A17 are used to select bytes within the ROM. The upper bits (A18–A23) are only partially matched, causing the ROM to appear at multiple mirror addresses in the bus space.

Code at 0xFF8xxx was actually reading ROM data from the same physical chip as 0xF8xxxx. Our emulator had to account for this — any address where the low 18 bits matched a ROM offset and the upper bits matched the chip-select mask was a valid ROM access. Getting this wrong produced hard-to-diagnose crashes where firmware reads returned garbage instead of instructions.

Four Chips on the Bus

With the ROM and RAM sorted out, the emulator's I/O logger began capturing accesses to the peripheral address space at 0xFC0000 and above. By analyzing the access patterns — which addresses were read, which were written, what values were used, and what the firmware did with the results — we identified four separate chips on the bus.

The four chips, identified from their address ranges and access patterns:

• FC20xx = Ensoniq ES5506 DOC (Digital Oscillator Chip) — A 32-voice wavetable synthesizer. We initially mistook this for the 68302's built-in SCC (Serial Communication Controller), which also lives in the FC2xxx range. The access pattern gave it away: writes to voice frequency, volume, and start/end address registers, in a loop that iterates exactly 32 times. This is the chip that generates the raw audio waveforms from sample data in RAM.
• FC30xx = Ensoniq ES5510 DSP — The effects processor. The firmware uploads microcode through a specific protocol: write to offset 0x80 (read-select GPR), 0xA0 (write GPR), 0xC0 (write instruction), 0xE0 (write both). We watched it upload all 160 instruction words of the DSP program.
• FC48xx = Motorola 68681 DUART — A dual UART for serial communication. Channel B handles the front panel (LCD display and buttons). The tell: odd-byte addressing (FC4813, FC4817) — the 8-bit DUART sits on the low byte of the 16-bit bus.
• FC6xxx = 68302 SIM (System Integration Module) — The microcontroller's own internal registers: chip-selects, timers, DMA, and 2 KB of internal SRAM at FC6200.

The Mystery Peripheral

After the chip-selects were configured and the main peripherals initialized, the I/O log showed a curious sequence of writes to an address we hadn't seen before:

Write 0x1111, read back. Write 0x2222, read back. Write 0x3333, read back. This is a textbook RAM test pattern. The firmware was probing whether memory existed at this address. And the same register appeared at three aliased addresses — 0x408000, 0x808000, and 0xC08000 — due to partial address decoding, just like the ROM mirrors.

The nature of this peripheral remained unclear at this stage. It could be sample RAM, a secondary I/O device, or expansion memory. But the firmware's own test routine told us exactly how to respond: echo back whatever was written. For now, that was enough to pass the test and let boot continue.

The Complete Map

After analyzing the full boot trace, we reconstructed the ASR-10's complete memory map. Every entry was discovered empirically — not from a schematic, not from documentation, but from the firmware's own initialization code telling us where its hardware lives.

This map became the foundation for everything that followed. Each chip needed a mock implementation that responded correctly to the firmware's initialization protocol. Getting any address wrong — even a single bit in a status register — would send the firmware into an infinite retry loop.

The beauty of emulation-driven reverse engineering is that you don't need the schematic. You don't need the service manual. You don't even need to own the hardware. The firmware is the documentation — every chip-select write is a declaration of what exists, every I/O read is a question you can learn to answer. Let the code tell you what it expects, and build the world around it.