Nintendo Wii

Broadway is a PowerPC 750CL at 729 MHz—the same microarchitecture as Gekko (PowerPC 750CXe at 486 MHz) with no new user-visible instructions. CPU version register (PVR) reports 0x00087102 versus Gekko's 0x00083410. The silicon moved from 180 nm to 90 nm SOI (later 65 nm), yielding a die area of just 18.9 mm² and roughly 20% lower power draw despite the 50% clock increase.

Cache hierarchy is identical32 KB L1 I-cache (8-way set-associative), 32 KB L1 D-cache (8-way set-associative, 16 KB lockable as scratchpad via DMA), and 256 KB unified L2 cache (2-way set-associative). L2 supports three fetch modes: 32-byte, 64-byte, and 128-byte bursts. The write-gather pipe address remains at 0xCC008000 (physical 0x0C008000), used for streaming GX FIFO commands to the GPU.

The front-side bus runs at 243 MHz, 64-bit wide, yielding a peak bandwidth of 1.9 GB/s. The bus-to-core multiplier is 3.0×. In GameCube compatibility mode, Broadway downclocks to 486 MHz with a 162 MHz bus.

Broadway-specific register differences from Gekko

Most SPRs are inherited from the 750CXe. Broadway adds HID4 (SPR 1011), not present on Gekko

HID0 and HID2 are functionally identical to Gekko. HID2 bit 29 controls the write-gather pipe enable, and bit 30 controls locked-cache DMA enable—unchanged.

Broadway boots from physical address 0xFFF00100, which is mapped to the EXI boot vector. This vector is initialized by Starlet when bootstrapping the PowerPC.

Console clock constants (stored at 0x800000F8–FC)

• Bus speed: 0x0E7BE2C0 (243 MHz = 242,999,040)
• CPU speed: 0x2B73A840 (729 MHz = 728,997,120)

The Wii's memory is split across two physical pools with fundamentally different characteristics. MEM1 is about 3× faster than MEM2 for CPU reads, which is why code and game-logic structures live in MEM1 while assets, textures, and audio buffers go in MEM2.

Physical memory map (PPC view)

Comparison with GameCube

MEM2 IOS reservation

IOS reserves the top 12–16 MB of MEM2 for its own use. Key addresses from global memory locations

In GameCube compatibility mode (MIOS), the bottom 16 MB of MEM2 emulates ARAM; the rest of MEM2 is inaccessible to GameCube code.

Global memory locations (MEM1 low area)

The first 0x3200 bytes of MEM1 contain OS globals shared between Broadway and IOS

Hollywood's graphics core is functionally identical to Flipper—same fixed-function pipeline, same TEV architecture, same vertex and pixel processing units—running at 243 MHz versus Flipper's 162 MHz (exactly 1.5×). The TEV unit and its capabilities are explicitly confirmed as unchanged across multiple authoritative sources. There are no programmable shaders.

Pipeline architecture (inherited from Flipper)

The GX pipeline processes commands from a FIFO ring buffer in main memory. The CPU writes to the FIFO via the write-gather pipe at 0xCC008000:

Command Processor (CP) → receives 8-bit commands from FIFO → routes to internal units

• 0x08: CP register write (8-bit + 32-bit)
• 0x10: XF register write (16-bit addr + N × 32-bit data)
• 0x61: BP register write (8-bit reg + 24-bit value)
• 0x80–0xB8: Primitive draw commands (vertex data follows)

Transform Unit (XF) — handles vertex transforms, lighting, and texture coordinate generation. Processes up to one 16-byte vertex per cycle.

Setup/Rasterizer — triangle setup and rasterization. Four parallel pixel pipelines can output up to 2×2 pixels per cycle.

Texture Unit — four texture mapping units, each processing up to 8 textures per cycle via multi-texturing loops. Supports hardware S3TC (SRTC) decompression, mipmapping, and anisotropic filtering. 1 MB texture cache (1T-SRAM) can be split between cache and scratchpad.

TEV (Texture Environment Unit) — 16 programmable stages of fixed-function color blending. Each stage can combine texture colors, vertex colors, rasterized colors, and constants using configurable blend equations. TEV enables shader-like effects (cel shading, bump mapping, environment mapping) without programmable shaders. Games configure TEV at runtime via BP registers.

Pixel Engine (PE) — handles fog blending, Z-compare, alpha blending, and EFB writes.

Hardware register bases

eDRAM: 3 MB vs Flipper's 2 MB

Hollywood increases the embedded framebuffer (EFB) from 2 MB to 3 MB of 1T-SRAM, mapped at physical 0x08000000 (virtual 0xC8000000). This eDRAM provides ~12.8 GB/s internal bandwidth and is used for the Z-buffer, color buffer, and copy-out operations.

The extra 1 MB does not change the fundamental EFB architecture—games still render to the EFB then copy to an external framebuffer (XFB) in main memory for VI display. However, the additional space enables more room for anti-aliasing sample buffers at standard resolutions. At 640×528 with 24-bit color + 24-bit Z, a single framebuffer+Z consumes ~1.93 MB; the extra MB gives breathing room for multisampling.

Video output

The Wii outputs 480i/480p (NTSC) or 576i/576p (PAL) via the AV Multi Out connector. Component video (YPbPr) is supported for 480p progressive scan. Maximum framebuffer resolution is 640×528 (NTSC) or 640×574 (PAL). The VI generates a standard-definition analog signal—no HD output is possible.

Widescreen is implemented via anamorphic renderingthe projection matrix widens the field of view, the TV stretches the 4:3 signal to 16:9. The framebuffer dimensions remain unchanged.

The Wii retains the identical Macronix custom 16-bit DSP from the GameCube, clocked at 121.5 MHz (up from 81 MHz on GameCube—again the 1.5× factor). Architecture, instruction set, and register interface are unchanged.

DSP specifications

Key DSP registers (base 0x0C005000)

DSP_CONTROL_STATUS bit fieldsbit 0 = RES (reset, triggers DMA of 1024 bytes to IRAM), bit 2 = HALT, bit 3 = AIDINT, bit 4 = AIDINTMSK, bit 7 = DSPINT, bit 8 = DSPINTMSK, bit 11 = BOOTMODE.

ARAM DMA registers (still present but non-functional on Wii)

The ARAM DMA registers at 0xCC005020–0xCC00502A exist for backward compatibility but return zeroes on read. In MIOS mode, the bottom 16 MB of MEM2 emulates ARAM and these registers become functional.

Audio Interface (AI) registers

The only meaningful audio difference from GameCubeARAM does not exist. The DSP accesses MEM1 or MEM2 directly for audio sample data. Games (and the AX library) store DSP-ADPCM samples in MEM2 instead of ARAM.

DSP-ADPCM format

4 bits per sample, 8-byte frames (1-byte header + 7 bytes = 14 samples). Header encodes a scale value (bits 3:0) and coefficient index (bits 7:4) selecting from 8 pre-computed coefficient pairs. Compression ratio is ~3.5:1 versus 16-bit PCM. Coefficients are stored in the sample header structure in main memory, not in the audio data stream itself.

Wii discs use a full-size 12 cm DVD with proprietary formatting (burst cutting area prevents standard DVD readers from accessing content). Capacity is 4.7 GB (single-layer) or 8.54 GB (dual-layer), versus the GameCube's 8 cm Mini-DVD at 1.5 GB.

Partition structure

Wii discs contain multiple partitions (typically Update + Data). The partition table lives at offset 0x40000:

Each partition contains a Ticket (with AES-encrypted title key), TMD (Title Metadata with content SHA-1 hashes), and encrypted partition data.

Encryption

Partition data is encrypted with AES-128-CBC using the title key (decrypted from the Ticket using the console's common key from OTP). Data is organized in 32 KB clusters: 0x400 bytes of encrypted SHA-1 hash data + 0x7C00 bytes of encrypted user data. A three-level hash hierarchy (H0→H1→H2→H3) provides integrity verification, with the H3 table's SHA-1 stored in the TMD.

On GameCube, disc access was direct hardware I/O via DI registers. On Wii, all disc I/O goes through IOS via /dev/di IPC calls—games never touch disc hardware directly.

The Wiimote communicates over Bluetooth 2.0 using the HID protocol on L2CAP PSM 0x11 (control) and 0x13 (data). It's built around a Broadcom BCM2042 SoC with 16 KB EEPROM. The HID descriptor reports only payload sizes, not data semantics—all data formats are reverse-engineered.

Button bitmask (2 bytes, big-endian, present in all reports except 0x3d)

Bits 5–6 of both bytes carry accelerometer LSBs (see below).

Accelerometer: ADXL330

Three-axis, ±3g range. Data is 10-bit for X axis, 9-bit for Y and Z. Zero-g offset is approximately 0x80 (midpoint). Calibration data is stored in EEPROM at addresses 0x0016–0x001F (two copies for redundancy). Each calibration block stores 0g offsets and 1g reference values for all three axes with a checksum byte.

In standard reporting modes (0x31, 0x33, 0x35, 0x37), accelerometer data occupies 3 bytes (XX YY ZZ), with LSBs packed into unused button bits: byte 0 bits 6:5 = X[1:0], byte 1 bit 6 = Z[1], byte 1 bit 5 = Y[1].

IR camera: PixArt sensor

A 128×96 monochrome camera with on-chip blob tracking, providing 1024×768 sub-pixel resolution via 8× interpolation. Tracks up to 4 IR points simultaneously. Field of view: ~33° horizontal, ~23° vertical. The sensor bar provides two IR LED clusters separated by 20 cm.

IR camera initialization sequence(1) enable pixel clock via report 0x13, (2) enable logic via report 0x1a, (3) write 0x08 to register 0xB00030, (4) write 9-byte sensitivity block to 0xB00000, (5) write 2-byte sensitivity block to 0xB0001A, (6) write mode to 0xB00033, (7) write 0x08 to 0xB00030 again.

Three data modes (must match report mode byte count exactly)

Missing objects return 0xFF in all fields.

Data reporting modes

Mode is set via output report 0x12(a2) 12 TT MM where bit 2 of TT enables continuous reporting, MM is the mode ID. Default on power-up is 0x30.

Speaker

21 mm piezoelectric, supporting 4-bit Yamaha ADPCM or 8-bit signed PCM. Configuration via 7 bytes at register 0xA20001–0xA20008: byte 1 = format (0x00=ADPCM, 0x40=PCM8), bytes 2–3 = sample rate (little-endian; adpcm_rate = 6000000/value, pcm_rate = 12000000/value), byte 4 = volume. Audio data sent via report 0x18 (up to 20 bytes per report). Standard config: 3000 Hz 4-bit ADPCM.

Rumble

Controlled by bit 0 of byte 0 in every output report. Setting this bit activates the rumble motor; clearing it deactivates. The bit must be set correctly in every report to avoid inadvertently toggling the motor.

Extension controllers

Connected via 6-pin I²C port at 400 kHz, slave address 0x52. Register space mapped at 0xA40000 in Wiimote address space. Initialization: write 0x55 to 0xA400F0, then 0x00 to 0xA400FB (disables encryption, returns plaintext data). Extension ID read from 6 bytes at 0xA400FA.

Nunchuk data format (6 bytes at 0xA40008)

Classic Controller reports 6 bytes with packed analog stick data (LX/LY 6-bit, RX/RY 5-bit, triggers 5-bit) and a 16-bit button bitmask (active-low). Higher-precision data format 0x02 provides 10-bit sticks and 8-bit triggers in 9 bytes.

GameCube controller (SI protocol)

Four GC controller ports on top of the Wii connect via the Serial Interface (SI) at register base 0x0C006400. Each port has a 32-byte buffer. The GC controller protocol uses a proprietary single-wire serial interface at 200 kHz with a standard polling command (0x400300) returning 8 bytes: buttons (16 bits), stick X/Y, C-stick X/Y, left trigger, right trigger—all 8-bit unsigned.

Hardware

An ARM926EJ-S (ARMv5TEJ) clocked at 243 MHz, embedded inside the Hollywood SoC. It has 96 KB internal SRAM, access to MEM2 (reserves ~12 MB for itself), and hardware AES-128 and SHA-1 accelerators. It manages all Wii-specific I/O: disc drive, USB 2.0, Bluetooth, Wi-Fi (802.11 b/g via SDIO), NAND flash (512 MB), and SD card.

IPC mechanism (Broadway ↔ Starlet)

Communication uses four hardware registers

IPC request structure (0x40 bytes, 0x20-aligned)

struct ipc_request {
u32 cmd;     // 0x00: 1=open, 2=close, 3=read, 4=write, 5=seek, 6=ioctl, 7=ioctlv
u32 ret;     // 0x04: return value
u32 fd;      // 0x08: file descriptor
u32 arg[5];  // 0x0C: command arguments
};

Transaction flowPPC writes request pointer to HW_IPC_PPCMSG → sets X1 flag → Starlet receives IRQ #31 → routes request to appropriate /dev/ handler → sets Y2 (acknowledge) → processes → writes reply to HW_IPC_ARMMSG → sets Y1 → PPC receives IRQ #30.

Device nodes

Games access all hardware through file-like IOS device nodes: /dev/di (disc), /dev/es (title management), /dev/fs (NAND filesystem), /dev/usb/, /dev/net/, /dev/sdio/slot0 (SD card), /dev/stm/* (power management). Each uses open/close/ioctl/ioctlv semantics.

NAND flash

512 MB total. Page size 2048+64 bytes. Uses SFFS (Secure FAT FileSystem) with AES-128-CBC encryption (per-console NAND key from OTP) and HMAC-SHA1 integrity. Directory structure: /title/ (installed titles), /ticket/ (title tickets), /shared1/ (shared content), /sys/ (system data), /tmp/.

Transition sequence

When a GC disc is detected, the System Menu launches the BC title (0x0000000100000100), which: (1) lowers Broadway from 729→486 MHz and Hollywood from 243→162 MHz via hardware clock registers, (2) loads MIOS (a minimal IOS containing the GameCube IPL). MIOS locks down all Wii-specific hardware (USB, Bluetooth, Wi-Fi, NAND, SD) and gives Broadway direct hardware access to legacy registers—no IPC, no IOS mediation.

State comparison

What MIOS patches

MIOS includes known game-specific patches for ZeldaWind Waker, Zelda: Collector's Edition, Tony Hawk's Pro Skater 3, and Pokémon Colosseum—fixing video timing issues and DVD read hooks. It blocks Datel/Action Replay discs from MIOS v5 onward.

Limitations

No GameCube Broadband/Modem Adapter (Wii lacks serial ports). No Game Boy Player. GameCube memory cards required (Wii NAND cannot save GC data). Wii Remote is disabled.

For a Wii-targeting static recompiler, the critical architectural facts are

Instruction setIdentical to GameCube. PowerPC 750CL with paired-single extensions. No new instructions. A Gekko recompiler handles Broadway with zero ISA changes—only timing behavior differs due to the 1.5× clock.

Memory modelThe recompiler must handle two disjoint physical memory regions (MEM1 at 0x00000000, MEM2 at 0x10000000) with BAT-mapped virtual addresses. Games typically use MEM1 cached at 0x80000000 and MEM2 cached at 0x90000000.

I/O abstractionUnlike GameCube games (direct hardware access), Wii games interact with hardware exclusively through IOS IPC. The recompiler must provide equivalent /dev/ services—particularly /dev/di for disc reads, /dev/es for title operations, and /dev/net for networking.

GPU commandsThe GX FIFO command stream is identical to GameCube. Commands are written through the write-gather pipe at 0xCC008000. BP/CP/XF register formats are unchanged. The 3 MB EFB (vs 2 MB) only affects framebuffer size calculations, not command formats.

Controller inputWiimote data arrives via IOS Bluetooth stack, not direct hardware registers. The recompiler must emulate the WPAD library's IPC calls or provide equivalent input abstraction. GC controller input via SI registers is identical to GameCube.

Content decryptionWii disc images must be decrypted (AES-128-CBC per partition) before the recompiler can access game code. The title key is extracted from the partition Ticket using the common key.