Mega Drive Z80 Bus Handoff: BUSREQ, Reset, and Shared Sound RAM

The Mega Drive uses a Z80 as an audio and peripheral processor alongside the 68000. The Z80 has its own address space, including sound RAM and sound devices, but the 68000 can access parts of that space through the system bus. It cannot safely assume that the Z80 has stopped using the bus just because the main CPU wrote a request register. The handoff is a hardware protocol with a request, a wait for acknowledgement, a bounded ownership interval, and a release.

Sega’s technical overview describes the 68000 writing a bus request to $A11100, polling the status bit until the Z80-side access is stopped, then accessing the Z80 area and clearing the request. A separate control register at $A11200 requests or cancels Z80 reset. Reset and bus ownership are related during initialization but are not substitutes for one another: holding the Z80 in reset is not the documented proof that the 68000 owns the shared bus.

This distinction affects more than sound startup. Games load Z80 sound drivers, update commands in shared RAM, inspect status, and sometimes bank cartridge data into the Z80 address space. A core that grants immediate simultaneous access may hide races. A core that permanently suspends the Z80 while the 68000 touches sound RAM can break timing and leave the audio engine stale.

The bus-request register is a handshake

The 68000 requests the Z80 bus through the control register at $A11100. The technical overview specifies a word write with $0100, followed by polling status bit D8 until it becomes zero, then accessing the Z80 area. The main CPU clears the request after the access. The request is a demand for ownership; polling the status confirms the handoff.

The practical pattern is:

write_word(0xA11100, 0x0100)
while (read_word(0xA11100) & 0x0100):
    wait_for_emulated_bus_progress()
access_z80_memory_or_registers()
write_word(0xA11100, 0x0000)

This is a schematic timing sequence from the documented word-access convention. Do not paste it into a byte-oriented program without checking which byte lane and bit position the CPU bus uses. The hardware documentation notes byte access is possible, but the visible status location differs with access width. A byte read of the wrong lane can look like an immediate grant or a permanently busy processor.

The polling loop must yield emulated time. In an emulator, implement the request as a state transition that allows the Z80 to complete the documented bus cycle and then exposes grant status. A host mutex or CPU thread lock is not the same as the physical handshake and can deadlock when the Z80 needs the shared bus to finish an instruction.

Reset is a distinct control path

The Z80 reset control register at $A11200 holds or releases the Z80 from reset according to the documented request/cancel state. It is useful when initializing an audio program, but it does not replace BUSREQ when the 68000 needs direct memory ownership. A robust startup sequence follows the official reset and bus-request rules for the hardware revision and uses the status register to confirm actual bus grant.

Many software examples combine reset and bus request because the 68000 must initialize sound RAM before releasing the audio processor. The exact order of reset changes, request writes, and release should be checked against the Sega software-development documentation for the target machine. Avoid asserting that one universal sequence is safe for every access: code may also update a live sound driver while the Z80 continues to run between short ownership windows.

The emulated reset line should reset the Z80 core and any devices whose hardware reset is actually tied to it, while preserving registers or RAM that real hardware does not clear. Do not interpret a reset request as a power-on reset of the whole console. Sound RAM, the YM2612, PSG, timers, and bank state have their own reset and persistence rules.

Z80 memory is an address-space view, not a host pointer

The Z80 area appears to the 68000 at an address window beginning at $A00000. It includes the sound RAM mapping, sound chip access area, and bank register regions described in Sega’s technical overview. The Z80’s own address space is not identical to the 68000’s address window. A core should route accesses through the appropriate bus mapping rather than expose a pointer into host memory.

Address decoding depends on access size, alignment, and the active bank register. The 68000 may issue word or byte cycles while the Z80 bus is eight bits wide. Preserve byte-lane semantics and avoid accidentally writing both adjacent Z80 locations when software intends a single byte. Writes to sound devices may have side effects; a read-modify-write performed for convenience is not necessarily safe.

Bank control is another boundary. The Z80 can see a banked window into the 68000 address space, with the bank value written through the sound-area mapping. Do not confuse that bank with BUSREQ status or with a cartridge mapper bank. Record both the ownership state and bank value in traces so that a correct bus handoff to the wrong bank is distinguishable from a missed grant.

For initial loading, software commonly prevents the Z80 from executing an incomplete image, obtains bus access, copies the sound program and data, initializes the sound hardware as required, then restores the intended processor state. For live updates, keep the ownership interval as short as practical. A long hold can stop music ticks, delay commands, or miss audio-side events even if the shared memory writes themselves are correct.

Use a small transfer routine with explicit length, destination range, and release path. If a copy aborts, an interrupt fires, or validation fails, the routine must still clear BUSREQ and leave the Z80 in a deliberate reset/run state. A timeout in software should report failure rather than continuing to write through an ungranted bus. In an emulator test harness, timeouts should be based on emulated cycles, not wall-clock time.

Never let the main CPU and Z80 write the same sound-RAM byte concurrently in the model. If both processors execute in parallel host threads, the implementation needs a deterministic hardware arbitration model that serializes the shared bus at emulated timing points. A host-language atomic variable protects memory integrity but does not reproduce which CPU wins or when the data becomes visible.

Audio symptoms that point to a handoff defect

A bad handoff can present as silence, a sound driver that initializes inconsistently, music that stops after one command, or sporadic corruption in a live update. Start with a trace of writes to $A11100 and $A11200, status reads, Z80 instruction progress, bank state, and the exact 68000 accesses while grant is active. Confirm that the status bit transitions only after the Z80 reaches a state where bus release is legal.

Compare cold boot, soft reset, game reset, and state restore separately. A cold-boot-only success suggests that a reset assumption differs from the state-preserving reset path. If an image works when the Z80 is held in reset but fails during live updates, the bus grant or data visibility is more likely than the sound chip configuration.

Use audio output as corroborating evidence, not as the only test. A driver may continue playing buffered samples for a short period after its CPU is stuck. Conversely, audio backend latency may delay an audible result after the Z80 has resumed correctly. Inspect emulated register writes and CPU execution before tuning host audio buffers.

Validation and acceptance criteria

Test a request made while the Z80 is executing, verify that the 68000 waits for grant, then access sound RAM and release the bus. Test word and byte register accesses independently with lane-sensitive diagnostics. Verify reset assertion and release separately from bus ownership. Exercise banked visibility, a live command update, interruption during a copy, and save/load while the two processors have different ownership states.

The acceptance condition is not merely that a sound driver boots. The 68000 must only access Z80-owned resources after the documented grant, the Z80 must resume from the right state after release, and the trace must show deterministic ordering across reset, banking, and shared-RAM operations.

Related:

Sources: