Dreamcast Maple Bus: Device Discovery, Packet Framing, and Peripheral State

The Dreamcast’s Maple bus connects the console to controllers, VMUs, vibration units, keyboards, mice, and other peripherals. It is a packet protocol over a serial physical connection, not a generic “controller port read.” Devices identify their supported functions, respond to commands, and can expose additional peripherals through expansion arrangements. A useful emulator consequently models discovery, packet framing, command handling, device state, and errors as separate concerns.

Maple traffic is initiated by the console and answered by a device. The system controller’s Maple DMA engine transfers packet data to and from memory, while software may poll or use interrupts around transfer completion. This means a device’s current buttons are only one part of observable state: the guest can also inspect device identity/capabilities, request conditions, access storage, and observe a transfer error or retry.

Frame the packet before interpreting its payload

A Maple message contains a command/response code, recipient and sender addressing, a length, command-specific data, and a checksum at the wire-protocol layer. The first stage should validate framing and length; only then should a device-specific handler interpret payload words. Do not let each device class invent its own header parser. Central framing code makes malformed lengths, unsupported commands, and checksum failures consistent.

Addressing reflects the physical bus and port topology. A response’s sender and recipient fields must agree with the request and the identified device. Expansion devices can expose logical subdevices, so “port number” and “device address” are not always the same concept. Preserve both physical attachment and protocol address in the emulator model. If a device is disconnected or hot-plugged, invalidate the appropriate discovery state rather than leaving a stale response object alive.

On the wire, Maple uses defined symbol timing and line states. The packet bytes are not simply UART bytes with an arbitrary baud rate. A hardware-level emulator or microcontroller implementation needs the protocol’s wire timing and bit encoding; a high-level console emulator can process decoded packets but should still preserve packet order, deadlines, and completion behavior. Document which abstraction level is implemented so “Maple emulation” does not imply cycle-perfect electrical signaling when it is only command-level compatibility.

Discovery describes functions, not a product-name string

Device Request and related status commands return a structured identity record with function bits, descriptive strings, region/connection information, and current or maximum power values. The function descriptor indicates interfaces such as controller input, storage, display, or vibration. A device can implement multiple functions; the emulator should not assume that one product name maps to one hard-coded capability.

Discovery is a lifecycle. On attach, query and validate the device record, then enable only the functions the emulated device implements. Poll or receive input through the appropriate function command. On reset or removal, clear transient state and stop outstanding operations. A VMU, for example, has storage and display-related behavior beyond a controller’s Get Condition packet. A vibration pack adds a control function and should not be treated as merely an extra button bit.

The controller condition response contains digital button state and analog values in a defined layout. Keep raw protocol fields separate from host mappings. Host gamepad APIs may report signed axes, triggers, deadzones, and button indices differently; translate those values at the host boundary, clamp according to the Dreamcast field width, and then serialize a Maple response. This makes input mapping testable without changing protocol semantics.

DMA completion and peripheral response are different events

The Maple DMA engine moves packet buffers between main memory and the bus. DMA completion tells software that a transfer transaction finished; it does not guarantee that a device command succeeded. The response code in the packet conveys command-level success or failure. Likewise, a timeout or retransmit response should not be translated into a valid neutral controller state.

Keep a transaction record containing the outbound bytes, expected recipient, deadline, DMA state, retry count, and response buffer. Validate response length before reading function-specific words. For a command that may transfer a variable amount of data, check the packet’s actual size against the command’s minimum and maximum before copying. This prevents malformed or stale packets from becoming host memory overreads.

A compact diagnostic event might look like this:

{
  "frame": 481,
  "bus": "A",
  "recipient": "A1",
  "command": "GetCondition",
  "response": "DataTransfer",
  "payload_bytes": 8,
  "dma_complete": true
}

The schema is illustrative: exact encoded lengths and command values belong to the Maple specification, and the example does not replace a wire capture. Include raw words and checksum result in a production trace so packet decoders can be compared byte for byte.

Device state and save data need explicit persistence rules

The controller’s current buttons and axes are transient input. VMU flash contents are persistent data. LCD contents may persist or be refreshed according to device behavior. Vibration state is time-dependent output. Store each according to its own lifecycle instead of serializing an entire device object indiscriminately. A save state should capture the current protocol transaction and any in-flight DMA, while ordinary game saves should preserve only the emulated peripheral’s persistent storage.

When host input changes during an outstanding Maple poll, decide whether that response samples state at request time or response time based on the hardware model. Do not allow a high-level asynchronous host event to mutate a packet after serialization. Snapshot the condition data when building the response and retain that snapshot through DMA completion.

Test discovery, topology, and failure paths

Start with a single controller: device request, identity validation, repeated condition polls, neutral state, each button, analog endpoints, and reset. Then add an expansion path and verify routing to each logical device. Add a VMU and test media information, block reads/writes, data persistence, checksum/length errors, and unplug during an outstanding transfer. Test unsupported commands and explicit retry/error codes. Include DMA address alignment, packet buffer boundaries, interrupt masking, and save-state reload mid-transaction.

Use packet captures or a known-good emulator implementation to compare raw bytes before comparing game behavior. If a controller works but a VMU fails, inspect function discovery and block transfer rather than modifying the controller condition format. If a game ignores input intermittently, check packet deadlines and DMA completion ordering before changing deadzones. Keeping each layer observable turns a mysterious controller port into a protocol that can be validated systematically.

Maple’s elegance comes from describing a device’s functions and exchanging framed commands, not from reducing every peripheral to one controller structure. Accurate topology, response semantics, and transfer state are what make unusual devices behave like real hardware.

For hot-plug and multi-device tests, make attachment a topology change with a timestamp. A bus scan should discover only devices reachable through the current root/expansion path, and a removed device should not answer a later request from a cached object. Verify that two devices with overlapping function bits still have distinct addresses and identity records. For checksum handling, inject a single-bit error into a captured packet and confirm that the receiver rejects or retries it according to the specified layer instead of returning a plausible controller condition. Fuzz packet lengths and command codes under a memory-safe decoder, but keep malformed input isolated from the emulated guest’s normal transactions. This is especially valuable for peripherals with storage commands, where a length bug can corrupt a VMU image or host save file. A protocol test can use synthetic devices to exercise the bus engine before any analog controller mapping is added, then add real input and storage as independent device classes.

Related:

Sources: