The I/O subsystem of this console is truly a game changer (if you'll pardon the pun). The interfaces are now controlled by a single module that will take care of security too. I'm talking about Starlet.
The hidden co-processor
Starlet is just an ARM926EJ-S CPU wired up to most of the internal components of this console. It resides inside Hollywood, runs at 243 MHz (same as Hollywood) and contains its own ROM and RAM too. Thus, you can consider Starlet an independent computer running alongside the main CPU.
Main diagram of the Wii's architecture. Notice how Starlet is able to control most of the I/O, and even hide some from Broadway.
The core is similar to the one used on the Nintendo DS, except for including two 'special' additions:
- A 'J' in its model name, which denotes the inclusion of Jazelle: A dedicated unit that executes 8-bit Java Bytecode. Java programs would still depend on the virtual machine (known as 'JVM'), but some opcodes may get executed directly from the CPU. Overall, this could accelerate the execution of compiled Java code.
- A dedicated Memory management unit (MMU) to enable virtual memory. Useful for general-purpose operating systems.
These enhancements are a bit 'weird' since they are completely unused on the Wii. Nonetheless, Nintendo selected that core for Starlet. This reminds me of the first iPhone (2G), which also included an ARM CPU with Jazelle (wasted as well).
If you're wondering, Jazelle never took off. After some iterations it was discovered that Java Bytecode just ran better on software. Later on, ARM succeeded Jazelle with 'Thumb-2EE' and, at the time of this writing (June 2021), both of these units have been phased out.
External I/O on the Wii.
The dark & small front slot is an SD card reader.
Moving on, this 'I/O CPU' is tasked with arbitrating access between many I/O and Broadway, and in doing so it also takes care of security (which decides whether to allow access or not). This is especially crucial when it comes to granting access to NAND, for instance, which is where the main operating system and user data are stored.
The chip also inherits some technology from ARM, such as the Advanced Microcontroller Bus Architecture (AMBA), a protocol that facilitates the communication between devices using a set of specialised buses.
Having said that, Nintendo wired up the I/O in a way that makes use of two AMBA buses :
- The AHB Bus (AMBA High-performance Bus): As the name indicates, it's designed for high-speed communication. Here we find:
- The NAND Interface: Accesses 512 MB of NAND Flash that stores the operating system and user data.
- Two Secure Digital Input Output (SDIO) interfaces: SDIO is a protocol mainly designed for accessing an SD card, but in this case, a second one is used to control the Wi-Fi module (802.11 b/g) as well.
- A USB 2.0 Controller: Interfaces two external USB sockets and an internal Bluetooth 2.0 daughtercard.
- A SHA-1 and AES module: Reserved for security tasks (more details in the 'Anti-Piracy' section).
- The APB Bus (Advanced Peripheral Bus): This one is restricted to low-performance components, including:
- The Drive interface: Connects the disc reader.
- The Serial interface: Connects the GameCube controllers.
- The External Interface (EXI): We've seen this one before. It communicates with other GameCube hardware, used for backwards compatibility.
Maintaining compatibility
Wii using GameCube equipment .
The Wii maintains full backwards compatibility with GameCube games even though the I/O system has changed drastically. This is because Starlet can be reprogrammed when a GameCube game is executed to virtually re-map the I/O, just like the original GameCube would expect to find.
Additionally, the Real-Time Clock chip includes some spare ROM that stores bitmap fonts (the Latin and Japanese set) used by GameCube games; and SRAM to save IPL-related settings.