Roadmap

The goal of the GameCube Linux project is to port the Linux operating system to the GameCube gaming console.

Motivation

Certainly the GameCube is not a full computer. It has no hard disk, and there is no possibility to read standard CDs or DVDs. Still, there are some reasons why you would want to run Linux on a GameCube.

Thin Client

A thin client is a computer that is supported by a stronger server. A GameCube could be used as a desktop computer, which stores its data on a server on the network.

Multimedia Terminal

The GameCube has a CPU that is powerful enough to decode common multimedia data like MPEG-4/DivX and MP3. It can server as a display unit for content stored on a server.

Development Environment

Professional GameCube developers use Metrowerks Codewarrior as a compiler, and a quite simple set of Nintendo libraries as a runtime environment. Homebrew developers currently have no choice other than using GCLIB, an Open Source library for the GameCube, which is quite advanced, but nevertheless only provides a DOS-like, flat environment.

With Linux available for the GameCube, developers can target the powerful Linux environment and make use of technologies such as SDL or OpenGL, without the user needing to know about it. This also makes it a lot easier to port existing applications to the GameCube. In addition, developers can test their code on more powerful hardware, such as Apple Macintosh computers running Linux.

Goals

These are the milestones we want to meet:

• a .DOL bootloader
• the Linux kernel booting on the GameCube
• a framebuffer driver
• an EXI driver
  • a network driver
  • a memory card driver
  • an RTC driver
  • an SRAM driver
• a SI driver
  • a gamepad driver
• an audio driver
• an AUX memory driver
• an X-Window driver
• 3D support for the X-Window driver

.DOL Bootloader

PSOload already makes it possible to load GameCube executables in .DOL format and run them. A .DOL bootloader is supposed to run a Linux kernel and an initial RAM disk, which are both linked into the .DOL file.

Linux Kernel

In order for the kernel to work, the timer and the interrupt controller of the GameCube's Flipper chipset need to be supported. Everything else should run out of the box.

Framebuffer Driver

The framebuffer driver is needed to show the Linux text console on the screen. Without a dedicated X-Window driver, the framebuffer driver can also be used for X-Window. The GameCube framebuffer is located in main RAM, so the bootloader will have to reserve this memory at the very beginning.

EXI driver

The Expansion Interface (EXI) bus is a three-channel serial bus that connects the CPU to the memory card slots, the serial ports, the mask ROM, RAM and the RTC.

Network Driver

Nintendo sells the "Broadband Adapter" for the GameCube, which is a 10/100 Ethernet interface with a Macronix chipset. It connects to serial port 1 and is thus connected to the EXI bus.

Memory Card Driver

Memory cards are connected to the EXI bus as well. A driver to access the raw data, as well as additional code to read and write the structures stored on it is needed.

RTC Driver

The GameCube real-time clock on the EXI bus needs to be used as the Linux hardware clock.

SRAM Driver

The SRAM (NVRAM/CMOS RAM) holds non-volatile configuration. A Linux driver to access this data is needed, so that applications can read these settings.

SI Driver

The Serial Interface is a bus that connects each gamepad through a separate channel to the CPU.

Gamepad Driver

The driver for the gamepad needs to be versatile enough to either be a keyboard driver, or a mouse driver (or both), or a joystick driver.

Audio Driver

The GameCube has a very sophisticated 81 MHz DSP that can use the AUX memory for storage.

AUX Memory Driver

The additional 16 MB of AUX memory might be too much for some applications, so it makes sense to make parts of it available as a RAM disk, which can also be used as swap space to effectively increase the amount of main RAM.

X-Window Driver

A native X-Window driver will speed up graphics compared to a kernel framebuffer driver. In addition, it serves as a base for 2D and 3D acceleration.

3D Support for X-Window

Once we have an X-Window driver, code that redirects 3D operations to the graphics processor can be implemented in it, in order to have hardware-accelerated OpenGL.