Skip to content
RetrogamingDeep Dive Published Updated 6 min readViews unavailable

Sega 32X SH-2 Bus Ownership: ROM Arbitration, Framebuffer Roles, and Display Composition

Trace how the 32X shares cartridge access, assigns framebuffer roles, and combines its output with Mega Drive video without guessing at ownership.

The Sega 32X is often summarized as two SH-2 processors attached to a Mega Drive. That description misses the engineering problem most likely to break a port or emulator: several processors can address shared resources, but they do not all own those resources at the same time. The 32X hardware manual describes distinct paths for the 68000, the master and slave SH-2s, cartridge ROM, shared SDRAM, and the two framebuffers. Treating those paths as one flat pool of memory obscures both arbitration and display timing.

This walkthrough follows Sega’s 32X Hardware Manual, document MAR-32-R4-072294, dated July 22, 1994. The document is a primary source, not a promise that every later board revision or software library uses identical setup code. Before relying on a register-level detail, compare the manual revision and hardware target in use.

Separate shared memory from cartridge ownership

The 32X adds two SH-2 CPUs, shared SDRAM, and two framebuffer memories to the Mega Drive. These resources have different roles. Shared SDRAM is general working memory visible through the 32X system; the framebuffers are video storage whose active display role is controlled separately. Cartridge ROM is another shared resource, and the manual describes arbitration rather than simultaneous unrestricted reads by every processor.

The SH-2 pair is not a symmetric pair of independent masters. The hardware design assigns a master and a slave role, and the master has the coordination responsibilities described in the manual. Sega’s manual also specifies SH-2 priority when its bus access conflicts with 68000 cartridge-ROM access. Software should therefore not assume that the 68000 can read the cartridge concurrently with an SH-2 ROM transfer, or that the slave is a second independent bus master. An emulator should model the documented access and startup relationships, not simply launch two SH-2 interpreters with identical permissions.

The manual’s startup description also distinguishes mapping from ownership. The 68000-side control configuration affects when the SH-2 can see the cartridge ROM region. A program must establish the intended 32X mapping and release conditions before assuming that a ROM read will complete. A diagnostic that only verifies an address translation can miss a stalled or arbitrated access.

For an emulator, keep at least three questions separate:

  1. Which CPU issued the access?
  2. Which physical resource does the current mapping select?
  3. Does the hardware permit that master to complete the access now?

An address map answers the second question. It does not, by itself, answer the third.

Treat the framebuffers as alternating display roles

The 32X includes two framebuffers so software can prepare one image while the video hardware displays the other. In the Framebuffer Control Register (FBCR), the FS bit selects the display-side buffer. Sega’s manual specifies that an FS write made during active display waits until vertical blank before the switch; reading FS reports the buffer currently selected for display. The read is therefore a report of current display ownership, not merely an echo of a pending request.

The important invariant is not “buffer zero is always the back buffer.” The selected buffer is a role, not a permanent identity. After the FS change takes effect, the buffer that was being drawn becomes the displayed image, and the former display buffer becomes the next drawing target. Software that hard-codes one memory bank as permanently safe can overwrite pixels still being scanned out. Use FS readback when tracking the actual display-side selection.

An implementation can express the schedule without assuming a particular game loop:

back = buffer_not_currently_displayed()
render_scene(back)
write_fbcr_fs(back)
while read_fbcr_fs() != back:
    wait_for_video_progress()
front = back
back = other_buffer(front)

This is a design sketch, not a drop-in register routine. A write during active display can complete on the bus before the FS change becomes visible. Polling the documented readback tells the producer when the requested buffer has actually become the display-side buffer.

The manual also distinguishes framebuffer pixel organizations. Indexed-color modes use a palette lookup; direct-color modes store more color information in each pixel. Those are different storage and conversion contracts, not interchangeable interpretations of the same bytes. A renderer should derive row stride, pixel width, and palette handling from the configured mode instead of guessing from a nominal screen resolution.

The visible image can contain more than the 32X framebuffer

The 32X does not replace the Mega Drive’s video hardware in every game. Its output is combined with the Mega Drive picture according to the documented priority and transparency behavior. This means that a black or missing-looking region in the final picture is not enough evidence that the 32X framebuffer is wrong: the source image, mode, transparency value, priority state, and underlying Mega Drive planes can all affect what the user sees.

When debugging composition, use a small test pattern with deliberately different colors in the 32X image and Mega Drive background. Change one visibility property at a time and record whether the output is absent, covered, or incorrectly indexed. This isolates pixel production from the final video composition path. For cycle-sensitive emulation, then add tests around frame-boundary buffer selection and any interrupts or DMA modes the title actually uses.

Section 5.3 documents concrete restrictions for SH-2 auto-request DMA. The manual requires masking interrupts on both the master and slave SH-2 during that DMA operation, notes that simultaneous DMA activity slows one side, and forbids access to the 32X VDP from the H-interrupt handler during the stated DMA case. It also lists combinations with PWM and H-interrupt operation in which auto-DMA must not be used. An emulator should model the specific combination it implements rather than assuming every pair of DMA, interrupt, and CPU actions may overlap.

These are 32X SH-2 scheduling constraints. They are distinct from the Mega Drive VDP’s own DMA and FIFO rules and from the Z80 BUSREQ protocol; neither is a substitute for the §5.3 conditions. A compatibility report should name the exercised feature and revision rather than claim that a general 32X timing model is complete because one framebuffer test passed.

A practical debugging checklist

If the picture tears, freezes, or shows the wrong bank, inspect the problem in layers:

  • Confirm the configured pixel mode and the memory bank being written.
  • Read back or otherwise track the current display selection using the documented mechanism.
  • Verify that the role switch is scheduled for vertical blank, not merely after rendering finishes.
  • Confirm that the SH-2 and 68000 mapping assumptions match the manual revision.
  • Separate framebuffer contents from priority and transparency effects in the composed Mega Drive output.
  • Reproduce any DMA or interrupt interaction against the manual’s concurrency restrictions.

The key design lesson is modest but useful: processor access, memory mapping, and visible display ownership are three different pieces of state. Keeping them separate makes both hardware code and emulators easier to reason about.

Related:

Sources:

Comments