C128 MMU, memory organization, banking and DMA

The Commodore 128 (C128) uses the MOS 8722 memory-management unit (MMU) to turn one physical machine into several different processor-visible memory environments. Rather than supplying a single fixed memory map, the MMU selects RAM banks, controls ROM and I/O overlays, provides configuration registers, participates in processor and operating-context selection, and supplies translated addressing for selected functions. The service documentation describes outputs for translated addresses, RAM-bank CAS selection, and ROM-bank selection, as well as control of C128, C64, and Z80 contexts. This arrangement is central to the relationship between the Commodore 128's native environment, its C64-compatible context, and its Z80-based CP/M context. It also means that an address written in hexadecimal does not, on its own, identify a unique physical resource; the active configuration matters.

Main RAM, banks, and overlays

The C128's 128 KiB of processor-addressable main dynamic RAM is organized as two 64 KiB banks. A processor with a 16-bit address space cannot normally display both complete banks at once, so the MMU determines which bank or shared portion is visible for an access. The service manual distinguishes this main RAM from the 16 KiB display RAM local to the 8563 video-display controller and from VIC colour RAM. Those video resources should not be counted as further banks of the MMU-controlled 128 KiB main-RAM model.

The RAM Configuration Register (RCR) supplies a way to make a lower or upper portion of bank 0 common to both processor-bank selections. The documented common areas are 1 KiB, 4 KiB, 8 KiB, or 16 KiB, and their placement can be at the bottom or top of the address space. This design allows a program to keep selected data visible while it changes the bank used for other addresses. It does not make every byte of both banks simultaneously visible through one unqualified 64 KiB CPU map. The same register has a stock-machine function for selecting the RAM bank used by the VIC independently of the processor's bank selection.

RAM-bank selection is only one part of a configuration. The Configuration Register (CR) determines whether the $D000–$DFFF region presents I/O, ROM, or RAM in a documented context, and it also controls the documented low-, middle-, and high-ROM selections and character-ROM visibility. Thus, a physical RAM byte may remain present while a processor instead sees an I/O register or a ROM overlay at the corresponding CPU address. Memory maps for C128 mode, C64 mode, and CP/M therefore need to be read as configuration-qualified views, not combined into one unconditional list of addresses.

Registers and controlled changes

In a C128 configuration with the I/O area available, the principal MMU register group occupies $D500 through $D50B. It includes the CR, four Preconfiguration Registers (PCRs), the Mode Configuration Register (MCR), the RCR, two page-pointer pairs, and a version register. The CR is also accessible at $FF00 in C128 mode, and the four Load Configuration Registers (LCRs) occupy $FF01 through $FF04. The split access scheme is important: removing the I/O block hides the $D5xx group, so a program cannot safely assume that every MMU control remains reachable through the I/O address range after it changes a configuration.

The PCR/LCR arrangement supports prepared changes. A PCR can retain a configuration value, and a write to its paired LCR transfers that stored value to the active CR. The programmer reference uses this mechanism to explain why software should arrange a reachable configuration before switching an I/O region out of view. It is a controlled state change, rather than a general-purpose substitute for every memory access.

The MMU also provides page-pointer pairs for pages zero and one. They can relocate the physical pages used for those accesses, subject to the documented bank and common-area rules. This feature is especially significant for 8502 software because page zero and page one are normally heavily used for addressing and stack activity. The pointer mechanism is not limited to a simple whole-bank switch: the documentation describes its interaction with translated addressing and notes special treatment when the relevant page is common RAM.

Processor and operating-context selection

The MCR at $D505 links memory configuration to the C128's two-processor design. On the documented stock system, MCR bit 0 low selects the Z80 path and bit 0 high enables the 8502 path; the active-low naming of the underlying Z80-enable signal helps account for the polarity. Bit 6 selects the C128 or C64 operating configuration. The manuals further state that in C64 mode the MMU is removed from the memory map and C64-style banking rules apply, rather than the C128 CR controls. This is why the C64-compatible context is more than a choice of BASIC or display behavior: it has a different documented memory-control regime. For processor timing and bus hand-off, see MOS Technology 8502.

A secondary technical book contains a contrary statement about the MCR bit-0 polarity. The primary service manual and programmer reference give the stock-C128 behavior described above, so that primary documentation is the basis for the register interpretation here. C128, C64, and CP/M maps should consequently be treated as different stated contexts, with their own processor and mapping restrictions, rather than as modes that can be freely mixed.

Video, high-speed operation, and DMA

The MMU cooperates with other C128 hardware rather than replacing it. Its translated addressing and ROM-bank signals connect to memory-selection logic that includes the PLA, while its RAM controls coordinate with the video path. The RCR's VIC-bank selector is independent of the processor bank, whereas the 8563's local display RAM remains distinct from main RAM. In the documented 2 MHz condition, the 80-column path is used while the VIC's normal 40-column display activity is disabled; the distinction is a video and bus condition, not a third MMU memory bank.

The user-facing FAST facility expresses only part of these timing limits. The programmer reference states that FAST disables the 40-column VIC display and that the documented FETCH, SWAP, and STASH operations must take place at the slow, 1 MHz rate. It is therefore inaccurate to equate a selected high-rate state with an unrestricted high-speed condition for I/O, display work, or memory transfer.

Expansion-bus direct memory access (DMA) has additional restrictions. The service manual says that a DMA request causes the MMU to use its VIC-cycle configuration because the request brings AEC low. The required memory map must be selected before the transfer, since the DMA source cannot access MMU registers to revise it during DMA. It must also respect VIC priority and BA timing. These conditions describe an external bus-transfer arrangement, not a general assertion that all C128 DMA occurs at one clock rate. The programmer reference's DMA-call description adds the software-facing warning that its I/O context has to be considered when a transfer is invoked.

There is also a narrower documentary difference concerning RCR bit 7. The service manual describes bit 6 as the stock VIC-bank selector and bit 7 as unused, while a BASIC-reference cross-reference mentions bits 6 and 7 in connection with a DMA(VIC) RAM bank and an Abacus explanation discusses an expansion-oriented two-bit scheme. For the stock two-bank machine, the service-manual account supports treating bit 6 as the active selector and bit 7 as unused. Claims about expanded memory or later board variants need their own model-specific evidence.

Programming consequences

The practical rule for native code is to select a context deliberately, then access the address within that context. Code that changes an overlay must retain a documented route to the control needed for the next change; code that depends on common RAM or relocated pages must account for the selected bank and page-pointer state. Code that moves between native, C64, and CP/M contexts must also respect the MCR's processor and mode restrictions. Commodore BASIC's BANK facilities are one user-level expression of this configuration model, but they do not remove the underlying distinction between visible overlays, physical banks, and mode-specific maps.

The MMU is therefore best understood as the C128's coordinating memory mechanism. It makes the two-bank main memory useful while preserving ROM, I/O, compatibility, processor, video, and bus constraints that differ by active context. A reliable account of a C128 address or transfer needs to state that context rather than assuming that the same hexadecimal location has one unchanging meaning.

See also

• Commodore 64 memory map