Originally by Michael Steil, 20 January 2004
The goal of the GameCube Linux project is to port the Linux operating system to the GameCube gaming console.
Certainly the GameCube is not a full computer. It has no hard disk, and the DVD unit is a bit selective with media. Still, there are some reasons why you would want to run Linux on a GameCube.
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.
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 or on dvd media.
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 or libogc, two Open Source libraries for the GameCube, which are quite advanced, but nevertheless only provide 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.
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
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 (completed)
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 (completed)
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 (completed)
The Expansion Interface (EXI) bus is a three-channel serial bus that connects the CPU to the memory card slots, the mask ROM, RAM and the RTC, and the BroadBand Adapter (see next point) if available.
Network Driver (completed)
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 (broken, abandoned)
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 (completed)
The GameCube real-time clock on the EXI bus needs to be used as the Linux hardware clock.
SRAM Driver (partial)
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 (completed)
The Serial Interface is a bus that connects each gamepad through a separate channel to the CPU.
Gamepad Driver (completed)
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 (completed)
The GameCube has a very sophisticated 81 MHz DSP that can use the AUX memory for storage.
AUX Memory Driver (completed)
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.
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.