Gone are the days of ‘3D-attempts’, Nintendo’s new offering consists in a clean and powerful break from its predecessor that will open the door to new, original and unseen content.
It’s worth pointing out that the design of this architecture pave the way to one of the most compact hardware of this generation, attributing at the lack of slims or lite revisions.
After the loss of SGI’s dominance in the graphics market, Nintendo needed new players to partner up.
A promising candidate seems to be IBM: Apart from their famous work on mainframes, they recently formed an alliance with Motorola and Apple to create a CPU powerful enough to compete with Intel’s ruling in the PC market. The resulting product is a series of processors carrying the name PowerPC, which were selected to power 99% of Apple’s Macintoshes and some embedded systems.
Fast forward, Nintendo required something powerful but cheap, so in order to comply with those red lines, IBM grabbed one of its past designs, the PowerPC 750CXe (found on the late iMac G3, known as the Early-Summer 2001), and beefed it up with capabilities that would please game developers. The result was the PowerPC Gecko and runs at 486 MHz.
Let’s find out what makes Gecko so special, and to do that we need to first have to look at the offerings of the 750CXe:
Additionally and due to its RISC nature, this CPU also includes dedicated units to speed up specific computations:
And, of course, some cache is also included to speed up memory bandwidth:
While the previous lists of features are very appreciated (compared to previous generations), this CPU still falls behind others on gaming performance (let’s not forget that this is still a general-purpose CPU, good at spreadsheets but average at physics). To compensate, IBM added the following tweaks that will constitute Gecko:
With all of this, game developers will be able to fit code which takes care of generating and/or transforming our geometry (vertices in this case), and this is really important, since the CPU can now perform some operations of which the GPU can’t do (more details later on).
During the design of the next-gen architecture, Nintendo’s architects performed a post-mortem analysis of their previous design and discovered that using a Unified Memory architecture together with some high-latency components (RDRAM) resulted in one of the biggest causes of bottleneck (almost 50% of CPU cycles were wasted while idling), in addition, the inclusion of multiple independent units contributed to a concerning competition for the memory bus.
For that reason, Gamecube architects came up with a new memory system strictly based on providing dedicated memory space and using low-latency chips. With the new design, GPU and CPU will no longer compete for the same RAM (causing fill-rate issues) since the GPU will now have its own internal and amazingly fast memory. On the other side, the GPU will still be in charge of arbitrating access to I/O too.
The result was a system organised with two main buses:
Additionally, this design contains an additional (yet unusual) bus where more memory can be found:
This is one of the most critical sections of this console, it basically makes the Gamecube, a Gamecube.
The history of this consoles’s GPU has some interesting connections: Wei Yen, the director of N64’s GPU (the RCP), later founded Artx and landed a contract with Nintendo to develop their next-gen GPU: Flipper.
There were lots of advancements done from the previous iteration, for instance, the subsystem was severely simplified down to a single (but powerful) core.
During the development process, ArtX got acquired by ATI, which in turn was sold to AMD six years later. Hence, this is why you see an ATI sticker stamped on the front of the case.
Flipper handles multiple services, so let’s focus on the graphics component for now (since it’s the one responsible for bringing our geometry to life). If you’ve been reading the N64 article, just letting you know that the core is now functional out of the box, so programmers won’t need worry about injecting code to make it work, nonetheless, there will some interesting parts that are customisable.
As always, in order to draw a frame on the screen, our data will be pumped through Flipper’s pipeline. The data goes through lots of different components which we can group in four stages:
The CPU and GPU communicate to each other using a fixed-length FIFO buffer in main RAM, this is basically a reserved portion where the CPU will write drawing commands that the GPU will read (and eventually display), this functionality is natively supported by the CPU and GPU.
Furthermore, the CPU and GPU don’t have to be pointing at the same FIFO at the same time, so the CPU can fill another one will the GPU is reading the first one (which can avoid waiting states).
Issuing individual commands to construct our geometry can get very tedious with complex scenes, so official libraries included tools that generated the required Display Lists (pre-compiled set FIFO commands) from our assets, this chunk only needs to be copied to RAM in order to let the GPU effectively display them.
The GPU contains a command processor which is charge of fetching commands from FIFO.
Here primitives are transformed to shape accordingly for the desired scenery. The engine uses a dedicated Vertex unit or ‘VU’ to accomplish this.
There are two vertex modes available to handle primitives issued through FIFO:
Once loaded, the primitives can be transformed, clipped, lighted (each vertex will have an RGB value that also can be interpolated for Gouraud Shading purposes) and finally projected.
Now it’s time to apply textures and effects to our models, and for that Flipper includes multiple units which will process our pixels. Now, this is a very sophisticated (yet quite complex) procedure, so if you find it difficult to follow, just think of it as a big assembly line that process pixels. Having said that, there are three groups of units available:
All of this is assisted by 1 MB of Texture memory (1T-SRAM type) which can actually be split into cache and Scratchpad memory (fast RAM). Real-time hardware decompression for SRTC (S3 Texture Compression) textures is also available to fit more textures in that single meg. of memory available.
The final stage of the rendering process includes applying some optional but useful touches to our scene:
The resulting frame is finally written to the Embedded Frame Buffer or ‘EFB’, but this is still locked inside Flipper. So in order to display it on our TV, we have to copy it to the External Frame-Buffer or ‘XFB’, which can be picked up the Video Interface or ‘VI’. In addition, the copy process can apply effects like Antialiasing (reduces blocky edges), Deflicker (smooths sudden changes in brightness), RGB to YUV conversion (a similar format that occupies less space in memory) and Y-scaling (vertically scales the frame).
It’s worth mentioning that the XFB area can also be manipulated by the CPU, this enables to combine previously-rendered bitmaps with our just-rendered frame, or when certain games need to render very colour-rich frames which can’t fit in the EFB, so they are rendered in parts and merged by the CPU afterwards (always keeping in-sync with the VI).
Time to put all of this into perspective, check out how programmers evolved the designs of their previous games to take advantage of the new graphic capabilities of this console. Don’t forget the examples are interactive!
The famous Mario model which had to be stripped down due to polygon counting on the previous generation got completely redesigned for this one, take a closer look of how the model evolved from plain faces to wrinkled sleeves.
In this case, Sonic Team already designed a Sonic model for their own and unique console, but after porting their game to the Gamecube they found themselves able to add more polygons to their model, achieving better detail.
It’s really impressive how much detail has been gained in just two years, eh?
As you can see from the inner working of this pipeline, graphics technology has been evolving to point that programmers can now take control of certain functions of the rendering process.
During the same time, PC graphics cards were starting to discard fixed-function pipelines in favour of shader cores (units that run small programs which define how pixels are operated). Flipper is still a fixed-function GPU, however by including components such as the TEV unit, one could argue that Nintendo provided their own shader-like solution.
I guess one of the best examples of games that exploited this new capability is The Legend of Zelda: Wind Waker which implements a unique colour/lighting technique known as Cel shading to make its textures look cartoonish.
The video signal outputs a resolution of up to 640x480 pixels (or 768×576 px in PAL) with up to 16.7 colours (24-bit depth). Additionally, the system could broadcast its signal in progressive mode (which has a clearer image, but not every TV may have supported it during that time).
The XFB can have multiple dimensions, so for compatibility reasons, the Video interface will try its best to display the frame by re-sampling the XFB to fit the TV screen based on the region.
The console included not one but two video output connectors:
Nintendo finally delivered some dedicated audio circuitry to offload the huge task from the CPU-GPU and provide richer sounds. Their new solution is an independent Digital Signal Processor or ‘DSP’ manufactured by Macronix running inside Flipper.
The DSP’s job consists in performing different operations over our raw audio data (e.g. volume changes, sample rate conversion, 3D sound effects, filtering, etc) and at the end output a 2-channel sample. It doesn’t work alone however, the DSP delivers audio with the help of other components.
Its first companion is the Audio Interface or ‘AI’, a 16-bit stereo digital-to-analogue converter responsible for sending the final sample through the audio signal that ends on the TV. The AI can only process 32 bytes of audio data every 0.25ms, so if we take into account that each sound sample weights 2 bytes and we need two to create stereo sound, the AI will be able to mix up to eight stereo samples with up to 32 kHz of sampling rate, sound!
Finally we have the Audio RAM or ‘ARAM’ block, which is a large (16 MB) but very slow spare memory that can be used store raw sound data. There’s quite a lot of space, so the GPU can also use it store additional material (like textures). The CPU doesn’t have direct access to this memory so it will need to use DMA to move content around.
That being said, the process of generating sound works as follows:
While we’ve already reached the sampling age and we are not locked to specific waveforms any more, the new sound system is still a huge improvement. Let me show you an example using two games, one released for the Nintendo 64 and its sequel released for the GameCube. Both have different music scores but the context (enemy battle) is the same. Take a look of how different both tracks differ in sound quality, taking into account the limitations of each system (shared vs dedicated).
As you can hear, Gamecube’s sound has a bigger sampling rate and a larger range of frequencies, which attributes to a better sense of surrounding and sound richness.
It seems that this generation is putting a lot of work in expandability and accessories, the Gamecube included a couple of new interesting ports, although some of them remained unused.
Flipper is in charge of interfacing the CPU with the rest of components so apart from including sound and graphics circuitry, it also provides a collection of hardware named (internal) Northbridge composed of:
Each interface includes its own set of registers that allows to alter some of its behaviour.
On the bottom of the Gamecube’s case you’ll find two external sockets to connect some widgets.
Both are technically identical (serial bus running at 32 MHz), yet they are presented with a different external shape in order to accommodate different accessories:
These ports are operated on the EXI stack.
You’ll notice I still haven’t mentioned another available socket found next to the serial ports: The Parallel Port. This port happens to be much faster (8-bit at 80 MHz vs 1-bit at 32 MHz) which may be the reason Nintendo called it Hi-Speed Port. But the most unusual part is that this port is not interfaced through EXI, but through ARAM!
The only official accessory known to date is the famous Game Boy Player which plugged in as an extra floor under the Gamecube, it contained the necessary hardware to natively play Game Boy and Game Boy Advance games. The Player works by doing all the heavy work itself and then sending the results (frames and audio data) to ARAM which the GameCube forwards to the respective components for display/sound.
I found it worth pointing out that no matter how many accessories you connect, the console will always keep its cubic shape (or at least attempt to).
Upon turning on the console, the CPU will start loading an operating system called Dolphin OS found on the BIOS/IPL chip, this is a very minimal OS that will take care of initialising the hardware and providing some convenient system calls and global variables for games to use. Games developed using the official SDK will implicitly execute these calls during low-level operations.
After finishing the boot process, the OS will load a small program unofficially called Main Menu.
This program is responsible for displaying the famous splash animation (the wee cube drawing a Gamecube logo) and loading the game if there is one inserted. In the absence of a valid game, it will then provide a simple cube-shaped menu with various options to choose from:
Nintendo provided developers with lots of tools to assist (and encourage) the development of games for their console:
Apart from the software, the company supplied different hardware kits (which range in price) before and after the console was publicly released.
Probably the most popular one worth mentioning is the Dolphin Development Hardware or ‘DDH’ which consisted in a PC-like tower containing some of the Gamecube’s I/O and lots of dev-assisting hardware, it was mainly used as a debugging station while the game was being developed on a Windows PC.
Games are loaded from a proprietary disc called miniDVD, it’s almost half the size of a traditional DVD disc and can hold up to 1.4 GB of data.
As an interesting fact, the disc reader operates in a Constant Angular Velocity or ‘CAV’ meaning that its data will be read at a faster rate if its found in the outer area of the disc (3.125MB/s) and slower if it’s found in the inner area (2MB/s). This differs from Constant Linear Velocity systems (used by traditional CD/DVD readers) where the effects are the opposite.
Game saves are stored in a proprietary external accessory called Memory Card and there are enough slots for two of them.
Nintendo shipped an accessory known as the GameBoy Link Cable which plugged a Game Boy Advance into the GC controller port, so games could upload small programs to the GBA and treat it as a special controller. This interesting feature enabled unique interactions and content in some games.
Well, unlike the competition, not only Nintendo required users to buy extra accessories to access online content, but they also didn’t deploy any internet service that publishers could rely on, making developers solely responsible for providing the necessary internet infrastructure.
As a result, while online gaming was a possible feature, it didn’t get widely adopted and only a tiny amount of games made use of this.
Nintendo has been in this game for quite some time, so it’s no news that they included security mechanisms to prevent running unauthorised software or games from a different region. However in this case, due to the wide range of I/O that the Gamecube provides, the attack surface got significantly larger. We can group this in two areas:
Even though this is the first Nintendo console to use the disc medium, attempting to play pirated copies of games just wasn’t going to be easy. The miniDVD is protected by using proprietary bar-codes on the inner side of the disc in addition to having its data encrypted. The validation and decryption process works seamlessly: The DVD controller takes care it while the system is limited on just requesting the data.
The hardware composing the DVD reader can be imagined as a fortress wall which is only accessed using a series of commands, the DVD controller features a proprietary CPU that will take care of deciding if the inserted disc is genuine or not, and if it’s not, no command issued by the main CPU will convince to read it otherwise.
As any other cat-and-mouse game, it was just a matter of time before third-party companies successfully reverse-engineered the controller to build mod-chips that could trick the reader. But bear in mind that no mod-chip can make this console magically fit a conventional CD/DVD without altering the case!
Another possible path consists in using the external I/O available to load Homebrew programs, however without cracking the DVD reader the only other option available is to try to take control of the first program that the Gamecube loads, and that is… The IPL.
That means that by reversing engineering the BIOS and replacing the chip with a modified one, one would be able to run, let’s say, a file reader, and from there execute programs received from the accessory ports (obviously requiring extra hardware).
Although at first this is not that simple: The IPL chip is encrypted using XOR conditionals and a Ciphertext, making it ‘impossible’ to reverse engineer.
However! Some people eventually discovered that the hardware that handles the decryption of the IPL contained a bug that allowed to capture the Ciphertext used. With this, another ROM could be constructed and encrypted with the same cypher so the Gamecube could boot it as its own!
As if that wasn’t enough, hackers discovered methods to trick the miniDVD reader into loading conventional DVDs.
Before those two mechanisms were discovered, there was actually a much simpler way of loading arbitrary code without any modification whatsoever, it simply consisted in hijacking the online protocol.
Some games like Phantasy Star Online used online functionality to download an updated executable (DOL file) from the company’s servers, so as you can see, this was a man-in-the-middle attack waiting to happen…
Long story short, by spoofing a fake server the Gamecube would just download (and execute) whatever DOL you could provide. That means hackers only needed the original game and the broadband adapter. This technique is known as PSOload.
Well, this is it, the 10th article!
I really tried to set a rough limit on the length of this article but you have to understand, technology has gotten so complex that if I accidentally skip anything important, the whole topic gets impossible to follow.
Anyway, I’d like to thank the #dolphin-dev irc community for helping me understand the complicated pipeline of Flipper, these guys have been developing the Gamecube emulator for quite some years now and it’s really impressive how much they had to put up with.
And finally, please consider contributing if you found it an interesting read. I strive to make it as complete as I can, and in the progress I forget how much time it’s suddenly costing me, I find it a good investment nonetheless.
Until next time!
This article is part of the Architecture of Consoles series. If you found it interesting please consider donating, your contribution will be used to get more tools and resources that will help to improve the quality of current articles and upcoming ones.
A list of desirable tools and latest acquisitions for this article are tracked in here:
## Interesting hardware to get (ordered by priority) - Any IPL mod (?) - RAD2X (£47.99) ## Acquired tools used - (While ago) Gamecube with controller (£20) and some games (if I remember correctly, no more than £20...)
Always nice to keep a record of changes.
## 2020-02-26 - Added mention on anisotropic filtering ## 2020-01-09 - Improved the write gather pipe explanation ## 2019-11-22 - Corrections and more info added, thanks @phire from #dolphin-dev and /r/gamecube ! ## 2019-11-20 - Corrections here and there ## 2019-11-19 - Public release!