Mega-CD Word RAM: 1M and 2M Modes, Ownership, and Safe Handoffs

The Sega/Mega-CD adds a second processor and a shared Word RAM region that can be mapped in more than one arrangement. The important engineering question is not simply “how much RAM is present?” but which processor owns which view at a given time, how software requests a handoff, and when writes become visible to the other side. The hardware manual describes both a 2M mode and a 1M mode; their names refer to the size of the visible partition in bits, not to two different physical RAM chips.

The Mega-CD has a 2-megabit Word RAM, or 256 KiB. In 2M mode, the full area is presented as one large work region to the selected processor. In 1M mode, the physical memory is divided into two 1-megabit halves, allowing separate working regions and exchange patterns. The exact register-controlled mapping and access permissions should be implemented from the Sega hardware manual for the target revision. Do not infer ownership from a game-specific library name.

Mode and ownership are separate pieces of state

Mode answers how the RAM is divided and exposed. Ownership answers which side can access a particular view right now. Software-visible control bits allow the processors to coordinate access; a request or return indication is not an instantaneous rewrite of all outstanding bus transactions. An emulator should track mode, owner, pending handoff, and completion separately, and document which event makes the new mapping visible.

In 2M mode, one processor may use the whole Word RAM while the other is directed to a different communication path or waits for ownership. In 1M mode, the halves can support alternating or concurrent producer-consumer work, such as one side preparing data while the other consumes the other bank. The 1M mapping includes bank selection and an exchange process; software must obey the prescribed sequence before changing the active bank or returning access. These are not merely address-mask choices.

A useful abstract model records:

mode = 2M | 1M
owner[bank] = main_cpu | sub_cpu
pending_request[bank] = none | requested
bank_select[processor] = 0 | 1

This is a software state model, not the hardware register layout. Its value is that it prevents a single Boolean word_ram_available from collapsing partitioning, visibility, and transfer state into one ambiguous flag.

Handoffs need a protocol, not shared-memory optimism

Before one processor reads data written by the other, it must observe the documented ownership transition. Use a producer-consumer protocol: producer writes a complete block, publishes its ready state through the documented handoff mechanism, and does not reuse the bank until the consumer returns it. The consumer waits for ownership, validates the block, processes it, and returns the bank. If the transfer uses an interrupt or semaphore register, keep that signal’s lifecycle distinct from the data bank itself.

Do not rely on the host CPU’s cache coherence or memory barriers to stand in for the console’s handshake. The emulator’s two CPU cores may execute on separate host threads, but their communication must follow emulated timing and register semantics. A host atomic can prevent a C++ data race while still delivering the Word RAM contents a cycle too early to guest software. Use a deterministic scheduler event or versioned memory view that makes ownership changes visible at the console-defined point.

The 1M mode’s two halves make ping-pong buffering attractive, but bank switching is not free. An application can overwrite the bank still in use, read an incompletely prepared block, or wait on the wrong bank. Diagnostic traces should log processor, address, selected mode, physical bank, owner before and after access, and the relevant request/return bits. A write by a non-owner should follow the documented behavior, which may be a blocked or ignored access rather than a host exception.

Address translation should be explicit

Keep a translation function separate from CPU memory access. Given mode, processor, address, and selected bank, it should either return a physical Word RAM offset plus permission or identify an inaccessible mapping. Check bounds before applying a mask. Avoid using modulo for invalid addresses unless the hardware’s address wiring demonstrably wraps there.

The map should be tested at the start and end of each visible region, across bank exchanges, after reset, and while ownership is being requested. Test byte, word, and long-word accesses only according to the bus access rules for that processor. The hardware manuals can define different access paths and timing for the 68000-side and sub-CPU-side maps, so a single shared pointer is not always enough.

Save states have to preserve both memory and protocol state. Store the RAM bytes, mode, bank selection, current owners, pending request/return transitions, interrupts, and any delayed visibility event. Restoring only the RAM contents can cause one processor to believe the other still owns a bank, which produces a hang that looks like bad game data.

Validation cases for an emulator or diagnostic tool

Start with a pattern test in 2M mode: the writing CPU stores a sequence with bank and offset markers, yields ownership, and the other CPU verifies the sequence. Repeat with the first and last locations and with blocks crossing the middle of the memory region. In 1M mode, write unique patterns to both halves, exchange access in the documented order, and verify that bank identity stays stable while ownership changes. Include request while busy, return without request, reset during a handoff, and simultaneous requests if the hardware defines such a case.

For each case, capture the control-register writes, memory reads and writes, owner transitions, and interrupt state. Compare the physical RAM offset derived by each processor. If data mismatches only after exchange, investigate bank-selection semantics; if the wrong region is visible from startup, inspect mode setup and reset defaults. Avoid adding title-specific patches before the generic mode map passes.

Word RAM is the shared boundary between two asynchronous processors. The reliable model is therefore a small protocol state machine backed by byte-accurate memory, not one array visible everywhere at all times. Mode, bank, ownership, and timing each deserve their own tests.

Use a debugger view that labels both the CPU-visible address and the physical Word RAM offset. In 1M mode, show the current half and its owner; in 2M mode, show which processor has the full-window mapping. This prevents a breakpoint at a shared logical address from concealing that two processors are reading different physical halves. Also keep Word RAM separate from the Mega-CD’s other shared areas and from its backup memory: similar producer-consumer patterns do not imply identical access registers or persistence. A test harness should reset the machine between mode cases, because stale selection bits from an earlier run can make a mapping test pass accidentally. Record every mode transition and wait condition in the trace. If software spins waiting for access, report which request bit, return bit, or opposite-CPU state remains unsatisfied. That turns a deadlock into a protocol diagnosis and helps distinguish incorrect emulated ownership from a guest program that failed to release the bank.

When reviewing a hardware trace, correlate accesses from both CPUs on one emulated timeline. A main-CPU write followed by a sub-CPU read should be represented as two bus events separated by the ownership transition, not as an instantaneous shared-memory observation. Log the selected mode with each access because the same logical address can map differently after a mode switch. For a title that streams graphics or audio data through Word RAM, compare block sequence numbers and checksums at producer and consumer boundaries. A checksum mismatch before handoff points to the producer or translation; a mismatch only after ownership changes points to visibility or bank mapping. This turns one broad symptom, “the second processor sees corrupt data,” into a sequence of independently testable causes.

Related:

Sources:

Mode and ownership are separate pieces of state

Handoffs need a protocol, not shared-memory optimism

Address translation should be explicit

Validation cases for an emulator or diagnostic tool

Comments