Nintendo GameCube Linux

Nintendo GameCube Linux

OS family	Linux
Latest release	Build 14 / 2005-05-31
Platforms	Nintendo GameCube, Wii
Official website	www.gc-linux.org

Nintendo GameCube Linux is a project to port Linux to the Nintendo GameCube (and now the Wii) in the same manner as Xbox Linux.

The GameCube was seen to be a less attractive system to port Linux to since it not only lacked an on-board ethernet port and internal hard drive, but also an optical drive natively capable of reading DVDs.

Nintendo GameCube Linux also recognizes SD Cards and Multimedia Cards and is able to use them normally, given the appropriate adaptor.^[1]

Early development

Development began with the release of a code loading method based on a hack for the game Phantasy Star Online. Upon going online PSO would contact a Sega server. By using a local DNS server under the owner's control, it was possible to make the Sega server's domain name resolve to a computer on an internal network and upload code to the GameCube using a program such as PSOload or PSUL (Later editions of PSOload had a DNS server built in).

Challenges

Running Linux allowed other homebrew programs to run, some of which were illegal. Numerous programs were written for the platform of varying quality. Homebrew emulators for systems such as the Nintendo, Super Nintendo and Nintendo 64 were produced. A port of MAME was also produced, however it ran poorly due to the limited amount of RAM available.

GameCube Linux only had 24 MBs of RAM available for the entire system which greatly limited its usefulness. A block driver was written to provide access to the 16 MB ARAM buffer so that it could be used as fast swap space. This was still not enough for most uses, so users had to rely on nbd to provide additional network-backed swap space.

Piracy was also widespread, since the PSO exploit could be used to stream games both to and from the GameCube, which some people would argue was for backup and archival purposes. However, the games ripped this way were notoriously unreliable, and in the end numerous release groups dumped games using PC DVD drives with modified firmware. Those using the streaming function encountered a technical issue with the ethernet adapter throttled its function to 10Mbit, resulting in laggy gameplay and music. Improvements allowed the adapter to be set to 100Mbit, but due to hardware limitations this speed was never achieved.

Modchip influence

The kernels produced by the project originally booted their root file system over NFS, though this was later extended to allow booting over a network block device. Ironically, however, one of the major developments came about due to piracy. A modchip called the "Viper" was released, quickly followed by a BIOS from another team, who were unaffiliated to the Viper team and yet were able to encrypt the BIOS specially for the modchip, which permitted the booting of pirate games from standard DVDs. (The GameCube could only read the first 1.4GB, but because the original games were produced on these discs, that was sufficient). However, after the reverse engineering work by the 'utopia' group, an assembly language recode of the trick used by the cobra BIOS was released.^[2] Essentially, a debug command is sent to the GameCube's DVD drive which allowed its firmware to be rewritten in memory (in this case in order to allow it to read from a standard DVD+/-R). However, as soon as the drive is again reset, these changes are lost, meaning one had to use either the cobra BIOS or the asm recode every time.

These debug commands were implemented in the Nintendo GameCube Linux kernel as the 'cactus firmware extension'.^[3] Essentially, this allowed it to read the first 1.4GB of any standard DVD. However, the GameCube's laser is fairly picky resulting in some disc read errors. Nevertheless, this opened some very interesting opportunities. For example a completely standalone Media Player Frontend ("MFE") distro was produced—a fully functioning Linux distribution booting entirely without computer networking.

Alternate loading methods

As the kernel can start the root filesystem from any of a number of different sources (over a network, from an SD card or from a DVD for example), the initial challenge is to load the kernel; although the original mechanism grew from the original PSO exploit, its later development was shaped by the development of first the anaconda recode, and then a method called SDLoad. SDLoad was reliant upon the fact that the Action Replay disc, produced by Codejunkies, allows the user to alter code in a game in Memory. By inserting the appropriate Action Replay codes, it was possible to modify the action replay software in memory to allow booting from an SD card.^[4]

References

External links

• Official Site