Supporting imagery
A quick introduction
Even though the Wii lacked the state of art graphics its competitors enjoyed, new types of control and innovative software gave this console new areas to brag about.
Here we will analyse every aspect of this console, from its already-familiar hardware to its overlooked security system, including its major flaws.
Quick Note: Some sections overlap part of the previous article about the GameCube, so instead of repeating the information I will just put a link to the respective part of the article.
Next-gen controllers
Let’s start by discussing one of the most iconic aspects of this console: The controllers.
The main device is no other than the Wii Remote (also called ‘Wiimote’), a gadget with a similar shape of a TV remote that contains many types of input controls:
- For starters, it has a set of physical buttons which are used like any conventional controller.
- It also contains an accelerometer to detect orientation changes, this is the main component used to achieve motion sensing.
- Finally, it includes an infrared camera that, combined with the accelerometer and some Wii processing, can be used to point at the screen.
- This sensor requires the Sensor Bar (included with the console). The bar contains two sets of infrared LEDs which the camera can sense, the Wii uses triangulation to calculate the position of the Wiimote from the TV.
The remote is powered by Broadcom’s BCM2042 [1], a chip that includes all the necessary circuitry to become an independent Bluetooth device (CPU, RAM, ROM and, of course, a Bluetooth module). While the Wiimote is programmed to follow the ‘Bluetooth HID’ protocol to be identified as an input device, it doesn’t comply with the standard method of exchanging data (possibly to disallow being used on non-Wii systems).
Lastly, the Wiimote also includes 16 KB of EEPROM to store user data and a small speaker limited to low-quality samples (3 kHz 4-bit ADPCM or 1.5 kHz 8-bit PCM).
Expansions
Nintendo shipped this system with another controller to be used on the opposite hand, the Nunchuk, this one comes with its own accelerometer, joystick and two buttons. It’s connected to a 6-pin proprietary port on the Wiimote.
Other accessories were also built for this port, each one provided different types of input.
CPU
After the success of Gekko, IBM presumably grabbed this design and re-branded it as ‘750CL’ for other manufacturers to use [3]. Then, when Nintendo requested a new CPU to use with their new console, still known as ‘Revolution’ (hence the RVL prefix on their stock motherboards), IBM and Nintendo agreed to use a 750CL clocked 1.5 times the speed of Gekko. This CPU is known as Broadway [4] and runs at 729 MHz.
After having reviewed Gekko, I’m afraid there aren’t many changes found in the new CPU. However, this may be an advantage: GameCube developers were able to start developing their new Wii games right away thanks to all the experience they gained with Gekko. Moreover, the fact that Broadway runs 1.5x the original speed will allow them to push for more features and quality.
What about memory?
This one is an interesting bit, the old GameCube memory layout has been re-arranged and enhanced with the following changes:
- Splash (24 MB of 1T-SRAM) now resides inside the Hollywood SoC (explained later) and it is now called MEM1 [5].
- ARAM (16 MB of serial SDRAM) is long gone, however…
- There’s a new memory chip, MEM2, which includes 64 MB of GDDR3 SDRAM for general purpose.
- This type of memory is based on the traditional DDR2 system but revamped with higher bandwidths (~2 times the original transfer rates) and reduced power consumption, which is ideal for GPUs.
Backwards compatibility
For now, you can think of this console as a superset of the GameCube and as such, compatibility with the previous generation of games is naturally inherited. That being said, in order to make the Wii fully backwards compatible, the old set of external ports were brought to the Wii, these include the GameCube controller and memory card ports. However, there’s a new constraint: The new memory map is incompatible with the old one. Thus, a thin ‘emulation’ layer was implemented in software (more details in the ‘I/O’ and ‘Operating System’ section).
Regarding the GameCube accessories using the Serial/Hi-Speed socket, I’m afraid the Wii didn’t include these ports, so those accessories can’t be used here.
In later years, new revisions of the Wii saw these ports removed, unfortunately.
Graphics
Similarly to the GameCube (where the graphics component, I/O interfaces and audio capabilities were combined into a single package called ‘Flipper’), the Wii follows suit and houses a big chip next to Broadway called Hollywood. In here, we find the graphics subsystem which, to be fair, is identical to Flipper’s albeit with minimal corrections.
Thus, Hollywood’s GPU still performs the same tasks that Flipper’s counterpart did back in the day but now enjoys 1.5x the clock speed (243 MHz). This increase means that more geometry and effects can be processed during the same unit of time.
Functionality
As the 3D engine is still Flipper’s, instead of repeating the same pipeline overview, I will mention some interesting design changes that games had to undergo:
Standardised Widescreen
GameCube games lacked proper support for widescreen displays (that is, composing 16:9 frames, departing from the traditional 4:3). Nevertheless, Flipper’s GPU was already able to do so and a handful of games provided options to activate it, although this was still considered an exclusive feature.
Be as it may, the framebuffer remains identical and the video encoder still outputs a PAL or NTSC-compliant frame, so this ‘widescreen’ feature is instead accomplished by widening the field of view in the projection matrix. The result is a scene rendered with a larger view angle that now appears squashed horizontally. However, the widescreen TV also plays a part in this process, as it will subsequently stretch the 4:3 frame (coming from the console) and the displayed image will thus look more or less in the correct ratio. If you are curious, this technique is not new, it’s been used in film projection and it’s referred to as anamorphic widescreen. Also, it’s amusing how SNES developers had to deal with the opposite effect.
Back to the point, the Wii standardised this feature by allowing a ‘widescreen mode’ to be activated from its system settings, which in turn promoted its wide adoption (pun intended).
Screen Interaction
You can pick up the stars by pointing at them.
The new and disruptive controller design meant new types of interactions on Wii games. Since the Wiimote enabled users to point at the screen, some games like Super Mario Galaxy or The Legend of Zelda: Twilight Princess used this feature to allow the player to interact with the scenery.
In the report titled Myth Debugging: Is the Wii More Demanding to Emulate than the GameCube? [6], developers of the Dolphin emulator explain that games like Super Mario Galaxy and other first-person shooters rely on the embedded z-buffer to identify the object the Wiimote is pointing at and/or check how far the object is from the Wiimote cursor.
This is not a new feature per se, but a novel use of current capabilities. GameCube games didn’t depend on a multi-use controller with pointer functionality. Now, players can control the character and point at the screen at the same time.
Updated Designs
The extra megahertz of Broadway and Hollywood, combined with avant-garde designs, brought some improvements to character models. It may not be as significant as other generations, but it’s still noticeable and appreciated.
Video Signal
Surprisingly enough, this console doesn’t use the old Multi Out port anymore, but a variation of it called AV Multi Out (so much for a name) with a slightly different shape. This one carries all of the previous signals plus YPbPr (known as ‘component’) [7]. It also includes some data lines that the system uses to identify the type of cable plugged in.
Unfortunately, this medium inherits the same limitations of the GameCube. That is, no S-Video on PAL systems and no RGB on NTSC ones. Also, RGB can only broadcast interlaced signals (no progressive). On the other side, Nintendo finally shipped a SCART cable (as an extra accessory) which finally makes use of the RGB lines (remember they were ignored since the times of the SNES).
Audio
The Wii includes the same Macronix DSP found in the GameCube, you can take a look at that article for the detailed analysis.
Compared to the GameCube, the only major change is that, since ARAM is gone, either MEM1 or MEM2 can be used as audio buffer.
I/O
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.
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.
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 [8]:
- 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
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 Ga
