GC-Forever Wiki - User contributions [en]

Phantasy Star Online Episode I & II

2024-08-21T05:41:09Z

Lumina33: bolded title

{{Infobox VG
|title=Phantasy Star Online
|image=[[File:Phantasy Star Online.jpg|266px|Phantasy Star Online art]]
|developer=[[Sonic Team]]
|publisher=[[Sega]]
|director= Takao Miyoshi
|producer= [[Yuji Naka]]
|series= ''[[Phantasy Star]]''
|artist=Satoshi Sakai
|composer=[[Hideaki Kobayashi (composer)|Hideaki Kobayashi]] Fumie Kumatani
|engine=
|released = ''Sega Dreamcast'' '''Phantasy Star Online''' {{vgrelease|JP=December 21, 2000}}{{vgrelease|NA=January 29, 2001}}{{vgrelease|EU=February 23, 2001}}'''Phantasy Star Online Ver 2''' {{vgrelease|JP= June 7, 2001}}{{vgrelease|NA= September 24, 2001}}{{vgrelease|EU= March 1, 2002}}

|genre=[[Action-RPG]], [[Massively multiplayer online role-playing game|Multiplayer online RPG]]
|modes=[[Single player]], [[multiplayer game|multiplayer]]
|ratings= {{vgratings|CERO=All ages|ESRB=T|PEGI=12+}}
|platforms=[[Dreamcast]], [[Microsoft Windows]], [[Nintendo GameCube]] (PSO Ep I&II), [[Xbox]] (PSO Ep I&II)
|media=[[GD-ROM]], [[CD-ROM]], [[DVD]], [[Nintendo optical disc|GameCube Optical Disc]]
|requirements=
|input=[[Gamepad]], [[Computer keyboard|Keyboard]] and [[Mouse (computing)|Mouse]]
}}

'''Phantasy Star Online''' (Japanese: ファンタシースターオンライン Hepburn: Fantashī sutā Onrain) is a series of Massively multiplayer online role-playing game|online multiplayer Action role-playing game|action RPG video games released by Sega. It is a subset of Sega's [[Phantasy Star|''Phantasy Star'' series]] of games that began in 1987.

The ''PSO'' series began with the release of ''Phantasy Star Online'' on the Dreamcast in 2000, and was followed in 2001 by ''Phantasy Star Online ver. 2'', also initially released for the Dreamcast and later ported to Microsoft Windows. In 2002, ''Phantasy Star Online Episode I & II'' was released for the [[Nintendo GameCube]] and Microsoft Xbox. Subsequently, ''[[Phantasy Star Online Episode III: C.A.R.D. Revolution]]'' was released for the GameCube in 2003, using gameplay mechanics that were different from the preceding titles. ''Phantasy Star Online: Blue Burst'', a port of the Xbox version of ''Episode I & II'' with the addition of a new ''Episode IV'', was released for Microsoft Windows in 2004 through digital distribution. ''[[Phantasy Star Online 2]]'' was released in Japan for Windows in July 2012, and released for the iOS and Android (operating system)|Android in late 2012 and is due to be released for the PlayStation Vita in 2013.

With the exception of ''Episode III'', the ''PSO'' games are hack and slash role-playing games in which the player slays monsters, levels up, buys new equipment, etc. The ''PSO'' games differ from earlier ''Phantasy Star'' titles by offering a real-time – rather than turn-based – approach to combat, seamlessly integrating this with exploration and plot developments.

==Development==
Development of Phantasy Star Online began after the completion of Sonic Adventure. Sega's Chairman Isao Okawa had a strong belief that internet gaming would come to be important, and the company's Sonic Team division was instructed to develop an online title. As there was no precedent for online gaming on console, the developers looked to Blizzard's PC RPG Diablo for inspiration on the game's mechanics. During development, the game was initially known as The Third World and had a vague sci-fi theme, before art director Satoshi Sakai produced a piece of concept art featuring a dragon and the decision was made to link it to the Phantasy Star series.
Phantasy Star Online was released bundled with a demo disc for Sonic Adventure 2.

==Plot==
Endless warring on the homeworld of Coral is so devastating to the environment, it becomes uninhabitable. The Alliance of Nations bands together to plan a mass exodus to another planet, eventually deciding on Ragol. They then construct and launch the first of the colonization vessels, Pioneer 1. Hearing favorable results, they follow it with a second vessel, Pioneer 2. When Pioneer 2 arrives, however, they witness an enormous explosion on Ragol's surface and find that the colony's entire population has apparently vanished.

===Episode 1===
When the citizens on Pioneer 2 observe the explosion on Ragol, the Principal sends down a team of Hunters - the player characters - to the surface to investigate what happened. The investigation takes them through a forest, which is teeming with native animals (such as Gray wolf|wolves), then to the base of the "Dome" that Pioneer 1's inhabitants lived in. Eventually, the hunters enter the dome and find a dragon. Once the hunters defeat the dragon, they enter a series of caves which go below the Dome, filled with heavily mutated lifeforms. At the end of the caves, the hunters defeat "De Rol Le", a large mutant that was infected by Dark Falz cells and by the scientists of Pioneer 1. "De Rol Le" had escaped from the pioneer 1's lab via a sewer system into the rest of the world. "De Rol Le" is responsible for mutating the wildlife in the forests into the wildlife found in the caves by poisoning and infecting the wildlife with its tentacles. At the end of the caves the hunters delve deeper into the planet, to an automated mining complex, which is filled with machines that attack the hunters on sight. After battling through the levels of the mine, the hunters defeat "Vol Opt", a sentient Artificial Intelligence that corrupted and took over the machines in the mines. At the end of the mines, the hunters find an entrance to the ruins of an ancient, living spaceship. Inside the spaceship, the hunters combat slightly demonic lifeforms. Throughout the entire game the hunters follow the story of Red Ring Rico, a hunter from Pioneer 1 that had followed the same path previously and left various messages of advice. Rico had found the source of the monsters that had destroyed the colony on Ragol, only to be devoured by Dark Falz, a godlike entity which the players defeat in the final battle of the episode, which was the end of the game's single-player video game|single-player mode in the original Dreamcast version.<ref>http://www.phantasy-star.net/pso/pso.html</ref>

===Episode 2===
Episode 2 takes place after the ancient spaceship is discovered. The Chief of the Government Lab of Pioneer 2 asks the hunters to go down to Ragol and investigate a secret laboratory that had recently been discovered on Gal Da Val Island. Before leaving on the mission, however, the player characters are required to complete a pair of training simulations. The first simulates a maze of ruins, the second a space station, and both stages feature enemies based on those seen in Episode 1.

Once the training is complete, the hunters are sent to the planet's surface with the task of finding the security terminals that grant access to the facility. The search is broken up into three stages: a seaside region, a mountain region, and a jungle region, in no particular order. Along the way, the hunters come across a number of data terminals, which contain details about the new enemy creatures that they are fighting as well as several entries by Heathcliff Flowen. A military commander from the Pioneer 1 colony, Heathcliff, was injured while fighting alongside Rico and had apparently become infected by the life form that had turned the local wildlife into monsters. Believing himself to be dying, he admitted his body to the custody of one Dr. Osto for research purposes.

Having deactivated the security terminals, the hunters finally manage to get inside and begin investigating the facility, which is home to its own automated security system as well as a new set of monsters. The investigation turns up more of Heathcliff's entries, including more details on the events that led to the colony's destruction. Rather than warning anybody about the hazard the life form posed, Dr. Osto used samples from Heathcliff's wound to create mutant creatures and other biological weapons, eventually merging Heathcliff's body with an artificial intelligence and allowing it to be consumed by the wound. The result became Olga Flow, the final monster encountered in the game.

==Gameplay==
Players choose one of three classes - Hunter, Ranger or Force. Hunters are adept with close-range weapons such as sabers, two-handed swords, dual daggers, halberds, and are more suited for up-close and personal confrontations. Rangers are best at ranged combat and excel with weapons such as pistols, rifles, shotguns, and machine guns. Forces are the magic class of the game and are able to learn a variety of attack and support techniques.

There are three races in Phantasy Star Online: Human, Newman (bio-engineered 'elves'), and CASTs (androids). Each type of race have advantages and disadvantages, such as CASTs being physically stronger than the other two races, but unable to use techs (magic). Gender choice is also a factor, which slightly affects stats and can affect the types of techniques able to be learned.

===Offline mode===
In Offline mode, players fight through a number of levels spread over four distinct areas. Each area has a Boss (video gaming)|boss at the end. The four areas are (in order) the forest, the caves, the mines, and the ruins. Upon defeating the final boss, Dark Falz, the credits roll and in some cases, an extra feature will be unlocked.

In addition to the main story, players can also take Hunters' Guild sidequests, which explore the lives of Pioneer 2's citizens and further delve into the backstory of the game. The rewards for these sidequests include a payment of meseta for the job, the chance to explore the stories behind Pioneer 2's Non-playable character|NPC residents, the opportunity to obtain special weapons that can't be found anywhere else (such as the Soul Eater and Akiko's Frying Pan), and whatever weapons, experience, and meseta one can get while fighting on these missions.

In Phantasy Star Online, normal mode is available to play at four different difficulty levels. Normal is available from the start, while Hard, Very Hard and Ultimate become available once Dark Falz has been defeated on the previous difficulty. Ultimate mode, however, was not included in the Version 1 release of PSO on Dreamcast.

===Online mode===
For online gameplay, instead of having the final boss be defeated in order to select a higher difficulty, there is a specific minimum experience level required to join or create a game. For Hard mode, it is level 20. For Very Hard mode, it is level 40. And for Ultimate, the minimum level requirement is 80.

In Blue Burst, the game's main story is broken down into separate missions, accessed via a special desk in the Principals Office or Lab. Each area of the game is divided into three or four missions that must be completed for the story to progress. Items such as weapons and techniques are awarded after certain missions are completed. Other players are able to join the mission at any time, even if the mission is in progress or finished. The final mission in each area is a standard run through the level's areas to the boss battle, essentially 'clearing' the area and unlocking the next one.

===Challenge mode===
Challenge mode sets all participants to a set level with set equipment at the beginning of each mission, lasting only until the end of the mission, and requires the team to reach a predefined goal in a series of specially designed levels that are modified versions of areas seen in normal mode. The aim is to complete the missions in the shortest time possible. New level objects can include laser barriers, buttons, and so on, and sometimes strategically placed enemies/types of enemies. If anyone on the team dies, then the challenge is immediately terminated and the team is returned to the Hunter's Guild, so teamwork is essential if the levels are to be completed successfully. Everyone starts with a 'Scape Doll' revival item in their inventory, enabling them to die once without consequence (the harder the stage, the more scape dolls one receives). Once all stages have been completed, players are given a rank based on their total time, with "S rank" being the best. If they achieve this in online mode, players are awarded rare weapons which can be customized and named. Challenge mode is available for Episodes 1 and 2.

===Battle mode===
This is a deathmatch (gaming)|deathmatch mode. In this mode, players are permitted to attack each other. A team may play while being able to attack each other and monsters to fulfill their goals, or they may play one of several predefined sets of battle rules, including goals of meseta, points, or time limitations.

===1-Player mode===
1-Player mode allows Blue Burst players to play the offline mode online, complete with Episode I & II's side story quests. Two official 1-player quests are available for the Blue Burst-exclusive Episode 4.

A number of gestures can be performed by holding down the Alt (alternate) key and pressing certain letter, number, or function keys. Holding down the Shift key at the same time allows players to perform the gestures of the opposite sex, but only while they are in any of the online lobby areas.

===Communication system===
[[File:Pso cover.jpg|thumb|right|150px|Phantasy Star Online PC boxart]]
Communication between players is achieved via a combination of direct 2-line text entry, ''Symbol Chat'', ''Word Select'', and/or by keyboard (optional.) As PSO servers support international co-operative play, the ''Symbol Chat'' and ''Word Select'' features encourage players to attempt communication with others regardless of [[language]]. Symbol Chat allows the player to define a collection of symbols within a speech bubble, in order to convey an emotion or simple instruction. These symbols can be used by the press of a key, or accessed via an in-game menu. Word Select acts as a limited phrasebook, allowing sentences to be constructed through a hierarchy of menus. Once complete, a sentence is automatically translated into the configured language of other nearby players, thus bridging the language gap encountered in cross-cultural multiplayer games.

==Releases==
[[File:Phantasy Star Online Ver.2.PNG|thumb|right|230px|Phantasy Star Online ver.2 Dreamcast boxart]]
'''''Phantasy Star Online ver. 2''''' is a [[video game]] that was released for [[Dreamcast]] and [[Personal Computer|PC]] on July 6, 2001 in [[Japan]], on September 24, 2001 in [[North America]] and on March 1, 2002 in [[Europe]]. This version features battle mode allowing other members to battle one another, a new difficulty titled "Ultimate Mode", a new soccer game within the lobby, and allowing Players to reach a maximum level of 200.<ref>{{cite web| url = http://www.gamespot.com/news/phantasy-star-online-version-2-unveiled-2697096| title = Phantasy Star Online Version 2 unveiled| publisher=Gamespot| accessdate = 2012-10-05}}</ref> Official servers have since been taken offline.

A [[Nintendo GameCube]] version titled '''Phantasy Star Online Episode I & II''' was released in 2002. An online [[role-playing video game]], its focus is online gameplay with a strong offline storyline, offering diverse online and offline gameplay. Offline mode is available for single player and multiplayer. Multiplayer split-screen mode can be played with up to four players. Official servers have since been taken offline, however it is still possible to connect to private servers thanks to an individual named SCHTHACK. More info on connecting to a private server can be obtained at his site.

http://www.schtserv.com/info.php

An upgraded version of the Nintendo Gamecube version titled '''Phantasy Star Online Episode I & II Plus''' was released for the [[Nintendo GameCube]] on November 27, 2003 in [[Japan]] and on September 15, 2004 in [[North America]]. This version added various quests to Offline Mode that were originally available exclusively to Online Mode, while also fixing certain bugs and exploits that could be used in the previous release, such as being able duplicate various items from one's inventory.<ref>{{cite web| url = http://www.ign.com/articles/2004/07/13/pso-episode-iii-plus| title = PSO Episode I&II Plus| publisher=IGN| accessdate = 2012-10-05}}</ref>

{| class="wikitable"
!Version
!Platform
!Release Date
|-
| Phantasy Star Online Episode I & II (ver 1.0)
| [[Nintendo GameCube]]
| September 12, 2002 (Japan)2
|-
| Phantasy Star Online Episode I & II (ver 1.1)
| [[Nintendo GameCube]]
| October 29, 2002 (North America), November 2002 (Japan)2, March 7, 2003 (Europe), March 14, 2003 (Sweden)
|-
| Phantasy Star Online Episode I & II Plus
| [[Nintendo GameCube]]
| November 27, 2003 (Japan), September 15, 2004 (North America)
|}

===Sequels===
{{Main|Phantasy Star Online Episode III: C.A.R.D. Revolution|Phantasy Star Online 2}}

==Reception==
{{VG series reviews
|game1 = Phantasy Star Online
|gr1 = 89.87%<ref>{{cite web| url = http://www.gamerankings.com/dreamcast/198288-phantasy-star-online/index.html| title = Phantasy Star Online| work = [[GameRankings]] | publisher=CBS Interactive | accessdate = 2012-06-20}}</ref>
|mc1 = 89 of 100<ref>{{cite web| work = [[Metacritic]] | publisher=CBS Interactive | title = Phantasy Star Online Reviews at Metacritic.com | url = http://www.metacritic.com/game/dreamcast/phantasy-star-online | accessdate = 2012-06-20}}</ref>
|game2 = Phantasy Star Online Ver.2
|gr2 = 83.96%<ref>{{cite web| url = http://www.gamerankings.com/dreamcast/472540-phantasy-star-online-ver-2/index.html | title = Phantasy Star Online Ver.2| work = [[GameRankings]] | publisher=CBS Interactive | accessdate = 2012-06-20}}</ref>
|mc2 = 80 of 100<ref>{{cite web| work = [[Metacritic]] | publisher=CBS Interactive | title = Phantasy Star Online Ver.2 Reviews at Metacritic.com | url = http://www.metacritic.com/game/dreamcast/phantasy-star-online-ver-2 | accessdate = 2012-06-20}}</ref>
|game3 = Episode I & II
|gr3 = 81.80%<ref>{{cite web| url = http://www.gamerankings.com/gamecube/516243-phantasy-star-online-episode-i-and-ii/index.html | title = Phantasy Star Online Episode I & II| work = [[GameRankings]] | publisher=CBS Interactive | accessdate = 2012-06-20}}</ref>
|mc3 = 85 of 100<ref>{{cite web| work = [[Metacritic]] | publisher=CBS Interactive | title = Phantasy Star Online Episode I and II Reviews at Metacritic.com | url = http://www.metacritic.com/game/gamecube/phantasy-star-online-episode-i-ii | accessdate = 2012-06-20}}</ref>
|game4 = Episode III:C.A.R.D. Revolution
|gr4 = 74.03%<ref>{{cite web| url = http://www.gamerankings.com/gamecube/914716-/index.html | title = Phantasy Star Online III:C.A.R.D. Revolution| work = [[GameRankings]] | publisher=CBS Interactive | accessdate = 2012-06-20}}</ref>
|mc4 = 71 of 100<ref>{{cite web| work = [[Metacritic]] | publisher=CBS Interactive| title = Phantasy Star Online Episode III:C.A.R.D. Revolution Reviews at Metacritic.com | url = http://www.metacritic.com/game/gamecube/phantasy-star-online-episode-iii-card-revolution | accessdate = 2012-06-20 }}</ref>
}}

The game was number 21 on [[1UP.com|1UP]]'s 'The Greatest Games of Their Time' list, making it the highest ranking RPG on that list. It has an aggregrated score of 89.87% on the [[Gamerankings]] website. [[IGN]] gave it a 9.3 out of 10, [[Eurogamer]] a 9 and [[GameSpot]] an 8.2, also out of 10. In Japan, ''[[Famitsu]]'' magazine scored the original Dreamcast version of the game a 37 out of 40,<ref>''ドリームキャスト - ファンタシースターオンライン''. Weekly Famitsu. No.915 Pt.2. Pg.44. 30 June 2006.</ref> and gave the GameCube re-release a 35 out of 40.<ref>''ニンテンドーゲームキューブ - ファンタシースターオンラインエピソード1&2''. Weekly Famitsu. No.915 Pt.2. Pg.100. 30 June 2006.</ref> The game's graphics were praised, with IGN stating that "This is among the best games, visually, across all platforms. There's really nothing that compares to the visual quality of PSO."<ref>Chau, Anthony, [http://www.ign.com/articles/2001/02/01/phantasy-star-online-2 Phantasy Star Online Review], IGN, January 31, 2001.</ref> GameSpot stated: "The main draw of the game is the ability to get online, hook up with three other players in one of the game's many lobbies, and take on the planet Ragol as a team. Obviously, this is where the game shines." 1UP likened aspects of ''Phantasy Star Online'' to ''[[Diablo (video game)|Diablo]]'', but described ''Phantasy Star Online'' as more of "a reinvention of an established PC adventure concept into something perfectly suited for the tastes and demands of console gamers."<ref name="1up_essential_pso"/>

The userbase for the game reached over 200,000 in 2001 and 600,000 in 2003.<ref>{{cite web|url=http://www.gamespot.com/news/phantasy-star-online-worldwide-user-base-surpasses-200000-2705689|title=Phantasy Star Online worldwide user base surpasses 200,000|last=Ike Sato|first=Yukiyoshi|date=6 April 2001|publisher=[[GameSpot]]|accessdate=11 January 2013}}</ref><ref>{{cite web|url=http://www.rpgfan.com/news/2003/2174.html|title=Phantasy Star Online Reaches Userbase of 600,000 Worldwide|last=Winkler|first=Chris|date=23 November 2003|publisher=RPGFan|accessdate=11 January 2013}}</ref>

==Legacy==
Hiroshi Matsuyama, president of [[CyberConnect2]] and developer of the ''[[.hack (video game series)|.hack]]'' series, cited ''Phantasy Star Online'' as an influence for the MMORPG world of ''.hack''.<ref>{{cite web|title=E3 2003: .hack Interview|url=http://ps2.ign.com/articles/403/403483p2.html|date=May 16, 2003|publisher=[[IGN]]|author=IGNPS2|accessdate=July 1, 2010}}</ref> [[1UP.com]] ranked the game at #3 in its list of "15 Games Ahead of Their Time," due to its introduction of online gaming to consoles and for pushing console gamers "to dial up with the Dreamcast to play online and to experience a new style of play."<ref>{{cite web|last=Furfari|first=Paul|title=15 Games Ahead of Their Time|url=http://www.1up.com/features/15-games-time?pager.offset=2|publisher=[[1UP.com]]|accessdate=26 September 2011|page=2}}</ref>

1UP also included ''Phantasy Star Online'' in their list of five "Essential Newcomers" of the decade, describing it as one of "five revolutionary new games" of the past 10 years, for its impact in taking "consoles online" and defining "small-scale multiplayer RPGs." It was the first console game to bring [[Massively multiplayer online game|MMO]] gaming to consoles on a smaller-scale, paving the way for larger-scale [[Massively multiplayer online role-playing game|MMORPG]] efforts such as ''[[Final Fantasy XI]]''. The small-scale template established by ''Phantasy Star Online'' was later copied by [[Capcom]]'s ''[[Monster Hunter]]'' series, which in turn influenced every major [[History of Eastern role-playing video games|Japanese RPG]] franchise, including ''[[Dragon Quest]]'' and ''[[Final Fantasy]]''. ''Phantasy Star Online'' also gave rise to "an entire pantheon of multiplayer [[dungeon crawl]]ers that continue to dominate the Japanese sales charts." More generally, the game was responsible for making "both online gaming and the concept of fee-based services a reality for consoles," paving the way for the online gaming services later provided by all three of the [[History of video game consoles (seventh generation)|seventh-generation consoles]].<ref name="1up_essential_pso">{{cite web|last=Parish|first=Jeremy|title=Phantasy Star Online|work=The Decade That Was: Essential Newcomers - We close our look back at the {{sic|the}} past 10 years with five revolutionary new games|url=http://www.1up.com/do/feature?pager.offset=1&cId=3178082|page=2|publisher=[[1UP.com]]|accessdate=23 September 2011|month=February|year=2010}}</ref>

==References==
<references />

==External links==
{{Phantasy Star series}}

[[Category:2000 video games]]
[[Category:Action role-playing video games]]
[[Category:Cooperative video games]]
[[Category:Free online games]]
[[Category:Nintendo GameCube games]]
[[Category:Nintendo GameCube role-playing games]]
[[Category:Inactive massively multiplayer online games]]
[[Category:Multiplayer online games]]
[[Category:Phantasy Star video games]]
[[Category:Sega video games]]
[[Category:Singleplayer online games]]
[[Category:Sonic Team games]]
[[Category:Yuji Naka games]]

Broadband Adapter

2024-08-21T05:27:30Z

Lumina33: /* Closure */ shorten paragraph

[[Image:Gcbba.jpg|thumb|The GameCube BBA, attached to a GameCube]]
The '''Nintendo GameCube Broadband Adapter''' is a network adapter for the [[Nintendo GameCube]]. They were produced by [[Conexant]] and made in the Philippines. The adapters fit flush into "Serial Port 1" on the underside of the GameCube and add a RJ-45 port to the side of the console.

==Hardware==
There is a custom 100 pin MX98730EC IC and a TDK TLA-6T118 (10/100BASE-TX Pulse Transformer) which make up the BBA.
[[Image:Gcbbatop.jpg|thumb|The GameCube BBA populated PCB - top]]
[[Image:Gcbbatop2.jpg|thumb|The GameCube BBA populated PCB - top angled]]
[[Image:Gcbbabottom.jpg|thumb|The GameCube BBA populated PCB - bottom]]

==Games Supported==
{| class="wikitable" border="1"
|-
! Title
! Developer(s)
! Online/LAN Play
|-
| [[Homeland]]
| [[Chunsoft]]
| Online
|-
| [[Phantasy Star Online Episode I & II]]
| [[Sonic Team]]
| Online
|-
| [[Phantasy Star Online Episode I & II Plus]]
| [[Sonic Team]]
| Online
|-
| [[Mario Kart: Double Dash!!]]
| [[Nintendo]]
| LAN
|-
| [[1080° Avalanche]]
| [[NST]]
| LAN
|-
| [[Kirby Air Ride]]
| [[HAL Laboratory]]
| LAN
|}
Note: LAN games can be played online with third-party PC applications such as [[Warp Pipe]] and [[XLink Kai]] that allows online play of these three games by tunneling the network traffic through a computer and across the Internet.

==Possibilities for running unsigned code==
Soon after ''PSO I & II'' was released for the GameCube, it was discovered that a PC could be made to simulate the conditions of the server that the game would connect to. This information started as a method of tunneling the online service. When simulating this server, unsigned code can be streamed back to the GameCube, allowing [[homebrew]], or information could be streamed back, allowing one to play copied games. This was also implemented to allow online gameplay in games for which it is not intended. Early dumps of GameCube games were created using this technique. From there, methods of running the games off of a computer through a GameCube were created. Nintendo and Sega responded by releasing the [[Phantasy Star Online Episode I & II Plus|''Plus'']] version of the game.

==Closure==
Nintendo officially discontinued the online gaming service in April 2007 to focus more on the Gamecube's successor: the Wii and its online gaming service. Nevertheless, games can still be played online via private servers. Game that supported LAN mutiplayer can still be played on LAN mode as well and can be played online with tunneling software.

==See Also==
*[[Warp Pipe]]
*[[XLink Kai]]

==References==
* [http://en.wikipedia.org/wiki/Nintendo_GameCube_Broadband_Adapter_and_Modem_Adapter http://en.wikipedia.org/wiki/Nintendo_GameCube_Broadband_Adapter_and_Modem_Adapter]
* [http://en.wikipedia.org/wiki/File:Gcbba.jpg Picture of BBA by Ben Wood]
* [http://www.nintendo.com/consumer/downloads/broadband_english.pdf Broadband Adapter instruction booklet by Nintendo (PDF)]

==External links==
* [http://www.nintendo.com/ Nintendo of America's Online Support page]
* [http://www.nintendo.co.uk/ Nintendo of Europe (UK) Online Support page]
* [http://gear.ign.com/articles/306/306366p1.html IGN's look at the adapter]

[[Category:MiscHardware]]
[[Category:Nintendo Hardware]]

Nintendo GameCube

2024-08-09T18:42:08Z

Lumina33: more technical details

The '''Nintendo GameCube''' is a disc-based game console. It is the successor to the Nintendo 64 and predecessor to the Wii.

It has four controller ports and two [[memory card]] slots.

The CPU is called the Gekko. The GPU is called the Flipper. It is actively cooled by a fan and has 64-hole grids on the left and right sides of the cube for ventilation.

We really should have a page on this.

Write Gather Pipe

2024-08-02T20:32:37Z

Lumina33: init page

The Gekko has a 128-byte '''Write Gather Pipe''' that buffers data until it is 25% full.

=== Reference ===
* https://www.copetti.org/writings/consoles/gamecube

DVDFormat

2024-08-02T11:42:52Z

Lumina33: touching grammar

GameCube Disc Format

Please Note this is a work in progress doc

XOR Encryption is done using discID and a random seed by the Disc Controller Firmware, Panasonic MN103S and is controlled by the System Controller MN102H.

== Data Frame ==
u32 id; // PSN(Physical Sector Number)
u16 ied; // ID Error Detection Code, CRC16
u8 userdata[2048]; // Data
u8 cpr_mai[6]; // Copyright Management Information(Not used)
u32 edc; // Error Detection Code, CRC32
// 2064B

== Random Seed List ==
0 0x0003
8 0x0030
1 0x7f00
9 0x7001
2 0x0006
A 0x0060
3 0x7e00
B 0x6003
4 0x000c
C 0x00c0
5 0x7c00
D 0x4007
6 0x0018
E 0x0180
7 0x7800
F 0x000f

== Burst Cutting Area ==
// UserData(64 Bytes)
u8 optionalInfo[52];
u8 manufacturerCode[2];
u8 recorderDeviceCode[2];
u8 APMRecorderDeviceCode;
u8 discManufactureDate[2];
u8 discManufactureTime[2];
u8 discNumber[3];
// KeyData(16 Bytes)
u8 bcakey[8];
u8 bcaSerial[8];
// Encrypted(48 Bytes)
u64 psn[6]; //BCA mark positions
// 188 Total Bytes

== Disc Physical Format ==
// Leadin Area
PhysicalFormatInfo m_pfi;
DiscManufacturingInfo m_dmi;

PhysicalFormatInfo
u8 reversed[6];
u8 discMagic; // value is -1.
u8 discSizeMinTransferRate; // The value is fixed on 16.
u8 discStructure; // The value is fixed on 1.
u8 recordedDensity; // The value is fixed on 1.
DataAreaAllocation m_dataAreaAllocation;
u8 reversed2[2026];
u8 reversed3[6];

DiscManufacturingInfo
u8 reversed[6];
u8 unknown1[6];
u8 randomNumber2[6];
u8 unknown2[6];
u8 randomNumber3[6];
char mediaId[19]; // "Nintendo Game Disk"
u8 randomNumber4[6];
u8 bookTypePartVersion; // value must be 1.
u8 discSizeMinReadoutRate; // The value is fixed on 16.
u8 discStructure; // The value is fixed on 1.
u8 recordedDensity; // The value is fixed on 0.
DataAreaAllocation m_dataAreaAllocation;
u8 bcaDescriptor; // The value is fixed on 128.
u8 reversed2[1983];
u8 reversed3[6];

DataAreaAllocation
u8 reversed;
u16 startSector; // 196608
u8 reversed2;
u16 endSector; // 909487
u8 reversed3[3];
// 12 Bytes

== Disc Image Format ==
BootHeader m_header; // boot.bin
BootHeaderInfo m_bi; // bi2.bin
AppLoader m_apploader; // appldr.img
FileSystemTable m_fst; // fst.bin
u8 userdata[0]; // application is stored here, including boot file

BootHeader
u8 ConsoleID; // G = Gamecube, R = Wii.
u8 Gamecode[2];
u8 CountryCode; //J=JAP . P=PAL . E=USA . D=OoT MasterQuest
u8 MakerCode[2];
u8 DiscID;
u8 Version;
u8 AudioStreaming; //01 = Enable it. 00 = Don't
u8 StreamBufSize; // For the AudioEnable.
u8 unused_1[18];
u32 DVDMagicWord; // 3258163005
char GameName[64];
u8 unused_2[416];
u32 NKitMagicWord;
u32 NKitVersion;
u32 ImageCRC;
u32 ForceCRC;
u32 ImageSize;
u32 JunkID;
u8 unused_3[488];
u32 ApploaderSize;
u32 ApploaderInit;
u32 ApploaderMain;
u32 ApploaderExit;
u8 unused_4[16];
u32 DOLOffset;
u32 FSTOffset;
u32 FSTSize;
u32 MaxFSTSize;
u32 FSTAddress;
u32 UserPos;
u32 UserLength;
u32 unused_5;

BootHeaderInfo
u32 DebugMonSize;
u32 SimMemSize;
u32 ArgOffset;
u32 DebugFlag;
u32 DebugOffset;
u32 DebugSize;
u32 RegionCode;
u32 TotalDisc;
u32 LongFileName;
u32 PADSpec;
u32 DOLLimit;
u8 unused_6[8148];
// 8192 Bytes

AppLoader
char revision[16]; // Revision compile date (example "2001/12/17")
u32 entryPoint; // Apploader's entrypoint
u32 size; // Size of apploader code
u32 rebootSize; // Size of reboot code
u8 pad[4]; // zeroes
u8 code[0]; // PPC code

FileSystemTable
u32 entityCount;
FileSystemEntity* m_entity;
StringTable* m_string;

FileSystemEntity
u8 flags;
u16 filenameOffset;
u32 fileOffset;
u32 fileSize;

StringTable
char name[0];
char dummy;

MacroME

2024-08-01T18:15:13Z

Lumina33: init page

'''MacroME''' is a programmable [[GameCube]] controller.

=== Source ===
* https://courses.grainger.illinois.edu/ece445/getfile.asp?id=18160

Apploader

2024-08-01T18:12:21Z

Lumina33: /* Gamecube apploader reverse engineering for CubeDocumented project */ apostrophe

== Gamecube apploader reverse engineering for CubeDocumented project ==

This reversing is not pretending to be compilable, and can be used for
education purposes only. I don't hold any responsibility for damage of your
Gamecube clock settings or memory card saves or else, produced from using
code/information represented in this document.

Documented by Andrei Chestakov (org). Version 1.1. (26 Apr 2005)
Additions and corrections by tmbinc.

== Overview ==

Complete Luigi's '''Apploader'''. Reverse work by org <kvzorganic_at_mail_dot_ru>
Other games seems to contain the same code with minor changes due to revision, so you may think, that apploader is the same for all games. Except [https://www.datel.co.uk/ Datel]'s FreeLoader and ActionReplay DVDs, which are using custom apploader binary (simplified Nintendo's apploader).

Apploader is a small program layer between GC bootrom and main application. Since main application's executable binary format may vary, apploader is needed to boot executable in main memory, using bootrom's low-level DVD read routines. In practice, all known game apploaders are using Nintendo's DOL format for executable files.

Format of apploader binary is simple. First goes apploader header, and then actual apploader code.

=== Apploader header ===

typedef struct
{
char revision[16]; // Revision compile date (example "2001/12/17")
u32 entryPoint; // Apploader's entrypoint
s32 size; // Size of apploader code
s32 trailerSize; // Size of safe trailer
u8 padding[4]; // zeroes
} LDRImage;

Full apploader size is sum of size and trailerSize, rounded up to 32 bytes.
Trailer is need for future apploader versions.

Apploader is located at 0x2440 offset on DVD and loaded by bootrom at 0x81200000 address. Then bootrom jumps to apploader's entrypoint:

void AplEntry(
void (**Init)(void (*OSReportCallback)(char *msg, ...)),
BOOL (**Main)(void **addr, s32 *length, s32 *offset),
void* (**Close)())
{
// Return location of apploader's Init, Main and Close routines.
*Init = AplInit;
*Main = AplMain;
*Close = AplClose;
}

After executing of entrypoint, bootrom will call in order: apploader's Init, then Main, then Close. Main is called in loop, until it will not return 0.

== PART I. Apploader Init ==

Init call is clearing apploader's internal data, and saving there callback of OSReport call (which is located inside IPL). OSReport is used to output some debug messages, during apploader runtime.

''' Apploader's internal data: '''

// Some DVD transfers require multiple times to load.
BOOL SecondTimeForThePart;
void* SecondTimeAddr;
s32 SecondTimeLength;
s32 SecondTimeOffset;
int SecondTimePart;

DVDBB2 bb2; // DVD boot block
DolImage DolImage; // main DOL executable header

int Section; // DOL section
int Part; // Apploader's step
u32 +0x148 // ?? only cleared in Init

// OSReport routine itself is placed somewhere in IPL
void (*OSReport)(char *msg, ...);

#pragma pack(32)
// First 32 bytes of DVDBI2 will be loaded here. This is a bit hacky.
// We dont use whole DVDBI2 (its too big), to save some memory.
// 32 bytes - because its minimum DVD DMA transfer size (?)
s32 debugMonSize;
s32 simMemSize;
u32 argOffset;
u32 debugFlag;
int FSTHigh; // 1, if FST is resided on DVD above DOL
u8 dummy[12]; // ending bytes
#pragma pack(0)

void AplInit(void (*OSReportCallback)(char *msg, ...))
{
// Clear some structures
memset(&bb2, 0, sizeof(DVDBB2));
memset(&DolImage, 0, sizeof(DolImage));

Section = 0;
Part = 0;
[+0x148] = 0;

OSReport = OSReportCallback; // Save report callback

// Print apploader version info
OSReport("Apploader Initialized. $ Revision: 28 $\n");
OSReport("This Apploader built %s %s\n", __DATE__, __TIME__);
}

== PART II. Apploader Main ==

Main is called in loop by IPL, until all data not loaded. IPL is using Main output parameters, to load data from DVD. IPL keeps loading new data, until
Main will not return 0, signaling that all data loaded.
Just read through comments to understand code.

BOOL AplMain(void **addr, s32 *length, s32 *offset)
{
OSLoMem *LoMem = OSPhysicalToCached(0x0000);

switch(Part)
{
// Load BB2 structure.
case 0:
case 1:
*addr = &bb2;
*length = sizeof(DVDBB2);
*offset = DVD_BB2_OFFSET;

Part = 2;
DCInvalidateRange(*addr, *length);
break;

// Check FST length and load first 32 bytes of BI2 structure.
case 2:
u32 FSTLength = bb2.FSTLength;
u32 FSTMaxLength = bb2.FSTMaxLength;

if(FSTLength > FSTMaxLength)
{
OSReport(
"APPLOADER ERROR >>> FSTLength(%d) in BB2 is greater "
"than FSTMaxLength(%d)\n", FSTLength, FSTMaxLength );
PPCHalt();
}

*addr = &debugMonSize;
*length = 32;
*offset = DVD_BI2_OFFSET;

Part = 3;
DCInvalidateRange(*addr, *length);
break;

// Setup some OS lomem variables by BI2 values, and check memory configuration.
// Copy DVD BI2 in main memory.
case 3:
__OSDebugMonSize = debugMonSize;
__OSDebugMon = OSRoundDown32B(__OSPhysMemSize - __OSDebugMonSize);
__OSSimMemSize = simMemSize;

// Check debug monitor size alignment
if(__OSDebugMonSize & 31)
{
OSReport(
"APPLOADER ERROR >>> Debug monitor size (%d) should "
"be a multiple of 32\n", __OSDebugMonSize );
PPCHalt();
}

// Check console simulated memory size alignment
if(__OSSimMemSize & 31)
{
OSReport(
"APPLOADER ERROR >>> simulated memory size (%d) "
"should be a multiple of 32\n", __OSSimMemSize );
PPCHalt();
}

if(__OSSimMemSize == 0)
{
__OSSimMemSize = __OSPhysMemSize;
}

if(__OSSimMemSize < __OSPhysMemSize)
{
if(__OSDebugMonSize >= (__OSPhysMemSize - __OSSimMemSize))
{
OSReport(
"APPLOADER ERROR >>> [Physical memory size(0x%x)] "
"- [Console simulated memory size(0x%x)]\n"
"APPLOADER ERROR >>> must be greater than debug
"monitor size(0x%x)\n",
__OSPhysMemSize, __OSSimMemSize, __OSDebugMonSize );
PPCHalt();
}

// Move down FST address
bb2.FSTAddress = OSRoundDown32B(__OSSimMemSize - bb2.FSTMaxSize);
}
else
{
if(__OSSimMemSize == __OSPhysMemSize)
{
bb2.FSTAddress = OSRoundDown32B(__OSDebugMon - bb2.FSTMaxSize);
}
else
{
OSReport(
"APPLOADER ERROR >>> Physical memory size is 0x%x bytes.\n"
"APPLOADER ERROR >>> Console simulated memory size "
"must be smaller than or equal to the Physical memory size\n",
__OSPhysMemSize, __OSSimMemSize );
PPCHalt();
}
}

// Load whole BI2 in main memory. Reside it before FST.
__OSBootInfo2 = bb2.FSTAddress - OS_BI2_SIZE;

*addr = __OSBootInfo2;
*length = OS_BI2_SIZE;
*offset = DVD_BI2_OFFSET;

Part = 4;
DCInvalidateRange(*addr, *length);
break;

// Load FST, only if FST placed before boot file.
case 4:
FSTHigh = bb2.bootFilePosition < bb2.FSTPosition;
if(FSTHigh)
{
// Continue on part 5. Load FST later.
Part = 5;
}
else
{
*addr = bb2.FSTAddress;
*length = OSRoundUp32B(bb2.FSTLength);
*offset = bb2.FSTPosition;

Part = 5;

if(*addr > 0x81700000)
{
OSReport(
"APPLOADER ERROR >>> Illegal FST "
"destination address! (0x%x)\n", *addr );
PPCHalt();
}

DCInvalidateRange(*addr, *length);
LoadBigData(addr, length, offset, &Part);
break;
}

// Load main DOL header.
case 5:
*addr = &DolImage;
*length = sizeof(DolImage);
*offset = bb2.bootFilePosition;

Part = 6;
DCInvalidateRange(*addr, *length);
break;

// Check out DOL properties. Clear BSS.
case 6:
s32 dolSize = DOLSize();

// Halt apploader, if DOL size exceeds limit.
if( (dolSize > __OSBootInfo2->dolLimit) && __OSBootInfo2->dolLimit)
{
OSReport(
"APPLOADER ERROR >>> Total size of text/data sections "
"of the dol file are too big (%d(0x%08x) bytes). "
"Currently the limit is set as %d(0x%08x) bytes\n",
dolSize, __OSBootInfo2->dolLimit );
PPCHalt();
}

// Save DOL size in OS globals
if(FSTHigh) __OSDOLSize = dolSize + OSRoundUp32B(bb2.FSTLength);
else __OSDOLSize = dolSize;

// Address limit?
#define DOL_ADDRESS_LIMIT 0x80700000 // production boards
#define DOL_ADDRESS_LIMITD 0x81200000 // development boards
if(!(OSGetConsoleType() & OS_CONSOLE_DEVELOPMENT))
{
if(AddressLimit(DOL_ADDRESS_LIMIT) == FALSE)
{
OSReport(
"APPLOADER ERROR >>> One of the sections in the dol file "
"exceeded its boundary. All the sections should not exceed "
"0x%08x (production mode).\n", DOL_ADDRESS_LIMIT );
PPCHalt();
}
}
else
{
// Check twice : first for production mode, then for development.

if(AddressLimit(DOL_ADDRESS_LIMIT) == FALSE)
{
OSReport(
"APPLOADER WARNING >>> One of the sections in the dol file "
"exceeded its boundary. All the sections should not exceed "
"0x%08x in production mode.\n", DOL_ADDRESS_LIMIT );
// Do not halt apploader (show only warning).
}

if(AddressLimit(DOL_ADDRESS_LIMITD) == FALSE)
{
OSReport(
"APPLOADER ERROR >>> One of the sections in the dol file "
"exceeded its boundary. All the sections should not exceed "
"0x%08x (development mode).\n", DOL_ADDRESS_LIMITD );
PPCHalt();
}
}

// Clear BSS
memset(DolImage.bss, 0, DolImage.bssLen);
DCFlushRange(DolImage.bss, DolImage.bssLen);

Part = 7;

// Load text sections.
case 7:
if(Section<DOL_MAX_TEXT)
{
if(DolImage.textData[Section])
{
*addr = DolImage.text[Section];
*length = OSRoundUp32B(DolImage.textLen[Section]);
*offset = bb2.bootFilePosition + DolImage.textData[Section];

if( (*addr + *length) > 0x81200000 )
{
OSReport(
"APPLOADER ERROR >>> Too big text segment! (0x%x - 0x%x)\n",
*addr, *addr + *length );
PPCHalt();
}

Section++;
DCInvalidateRange(*addr, *length);
break;
}
}
else
{
Section = 0;
Part = 8;
}

// Load data sections.
case 8:
if(Section<DOL_MAX_DATA)
{
if(DolImage.dataData[Section])
{
*addr = DolImage.data[Section];
*length = OSRoundUp32B(DolImage.dataLen[Section]);
*offset = bb2.bootFilePosition + DolImage.dataData[Section];

if( (*addr + *length) > 0x81200000 )
{
OSReport(
"APPLOADER ERROR >>> Too big data segment! (0x%x - 0x%x)\n",
*addr, *addr + *length );
PPCHalt();
}

Section++;
DCInvalidateRange(*addr, *length);
break;
}
}
else
{
Section = 0;
Part = 9;
}

// Load FST, only if FST placed after boot file.
case 9:
if(FSTHigh)
{
*addr = bb2.FSTAddress;
*length = OSRoundUp32B(bb2.FSTLength);
*offset = bb2.FSTPosition;

Part = 10;

if(*addr > 0x81700000)
{
OSReport(
"APPLOADER ERROR >>> Illegal FST "
"destination address! (0x%x)\n", *addr );
PPCHalt();
}

DCInvalidateRange(*addr, *length);
LoadBigData(addr, length, offset, &Part);
break;
}
else
{
// Continue on part 10.
Part = 10;
}

// Init misc. low memory variables. Continue on part 11.
case 10:
InitLoMem(LoMem);
Part = 11;

// Read button state of 4th controller and save it in OS global.
// It's for testing pre-master dvds (NR Discs). But as NR discs gets
// written without change to the dvdroms the retail apploaders contains
// it, too. If you plug in a special device (dunno what it is exactly -
// controller with special id? some bit set?) the apploader starts making
// a crc of the whole disc and compare that to a crc stored on memory card.
case 11:
PADStatus padst;
PadRead(PAD_CHAN3, &padst);
__OSPADButton = padst.button;

// All data loaded. End of apploader.
return FALSE;

// This part will be called, if DVD need to load more, than 64 sectors.
case 12:
ASSERT(SecondTimeForThePart == TRUE);
LoadBigData(addr, length, offset, &Part);
break;

// Unknown part. Abort data loading.
default:
return FALSE;
}

// We need to load more data. Tell IPL to do that.
return TRUE;
}

== PART III. Apploader Close ==

Close call is executed after apploader's Main.

void* AplClose(void)
{
// Return entrypoint of main DOL executable to IPL
return DolImage.entry;
}

Now IPL jumps to DOL's entrypoint (__start).

== Appendix A: Helper calls ==

''' Calculate full size of DOL text and data sections '''

s32 DOLSize(void)
{
DolImage *dol = &DolImage;
s32 totalBytes = 0, i;

for(i=0; i<DOL_MAX_TEXT; i++)
{
if(dol->textData[i])
{
// Aligned to 32 byte boundary
totalBytes += OSRoundUp32B(dol->textLen[i]);
}
}

for(i=0; i<DOL_MAX_DATA; i++)
{
if(dol->dataData[i])
{
// Aligned to 32 byte boundary
totalBytes += OSRoundUp32B(dol->dataLen[i]);
}
}

return totalBytes;
}

''' Return FALSE, if any DOL section, including BSS exceed address limit '''

BOOL AddressLimit(u32 limit)
{
DolImage *dol = &DolImage;
s32 i, end;

// Text sections
for(i=0; i<DOL_MAX_TEXT; i++)
{
if(dol->textData[i])
{
end = dol->text[i] + dol->textLen[i];

if( ((dol->text[i] < 0x81100000) || (end > 0x81300000)) && (end > limit) )
{
return FALSE;
}
}
}

// Data sections
for(i=0; i<DOL_MAX_DATA; i++)
{
if(dol->dataData[i])
{
end = dol->data[i] + dol->dataLen[i];

if( ((dol->data[i] < 0x81100000) || (end > 0x81300000)) && (end > limit) )
{
return FALSE;
}
}
}

// BSS
end = dol->bss + dol->bssLen;
if( ((dol->bss < 0x81100000) || (end > 0x81300000)) && (end > limit) )
{
return FALSE;
}

return TRUE;
}

''' Some big transfers requires multiple load times for single apploader part '''
(Limit is set to 64 DVD sectors - WHY?).

void LoadBigData(void **addr, s32 *length, s32 *offset, int *part)
{
if(SecondTimeForThePart)
{
SecondTimeForThePart = FALSE;

*addr = SecondTimeAddr;
*length = SecondTimeLength;
*offset = SecondTimeOffset;
*part = SecondTimePart;
}
else
{
if(*length > 64*2048) // 64 DVD sectors
{
// Initiate multiple DVD load.
SecondTimeForThePart = TRUE;

SecondTimeAddr = *addr + 64*2048;
SecondTimeLength = *length - 64*2048;
SecondTimeOffset = *offset + 64*2048;
SecondTimePart = *part;

*length = 64*2048;
*part = 12;
}
}
}

''' Init some OS low memory variables '''

void InitLoMem(OSLoMem *LoMem)
{
LoMem->bi.magic = OS_BOOTINFO_MAGIC; // 0xD15EA5E
LoMem->bi.version = 1;

// Clear debug interface (db/DBInterface.h)
LoMem->db.bPresent =
LoMem->db.exceptionMask =
LoMem->db.ExceptionDestination =
LoMem->db.exceptionReturn = NULL;
}

''' Read PAD input buffer (buttons state). If PAD is not polled, return zeroes '''

void PadRead(int port, u32 *buf)
{
// If controller polling enabled
if(SI_POLL & (0x80 >> port))
{
// Read SI input buffer
buf[0] = SI_CHAN_INBUFH(port);
buf[1] = SI_CHAN_INBUFL(port);
}
else
{
buf[0] = buf[1] = 0;
}
}

== Appendix B: DVD structures ==

#define DVD_BB2_OFFSET 0x420
#define DVD_BI2_OFFSET 0x440

#define OS_BI2_SIZE 0x2000 // Size of BI2 structure

// DVD Boot Block
typedef struct
{
u32 bootFilePosition; // offset of main DOL executable
u32 FSTPosition; // offset of primary FST
u32 FSTLength; // primary FST size (in bytes)
u32 FSTMaxLength; // size of biggest additional FST
u32 FSTAddress; // FST address in main memory
u32 userPosition;
u32 userLength;
u8 padding0[4]; // reserved, should be 0
} DVDBB2;

FST is File String Table. User area on DVD is where all files are placed. On some DVDs, user area is configured wrong. To know correct user area, you should parse whole FST and find min and max file offsets.

// DVD Boot Info
typedef struct
{
s32 debugMonSize; // size of debug monitor
s32 simMemSize; // simulated memory size (in bytes)
u32 argOffset; // command line arguments
u32 debugFlag; // debug present (set to 3, if CodeWarrior on GDEV)
u32 TRKLocation; // target resident kernel location
s32 TRKSize; // size of TRK
u32 countryCode; // country code
u32 ? +1C
u32 ? +20
u32 ? +24
u32 dolLimit; // maximum total size of DOL text/data sections (0 - unlimited)
u32 ? +2C

u8 padded0[OS_BI2_SIZE - 0x30]; // reserved, should be 0
} DVDBI2;

Somewhere in +1C, +20 or +24 must present :
u32 longFileNameSupport; // 1: use long file names, 0: use 8.3 names
u32 padSpec; // controller version for PADSetSpec

== Appendix C: Used OS low memory variables ==

s32 __OSPhysMemSize AT_ADDRESS(OS_BASE_CACHED | 0x0028);
s32 __OSDebugMonSize AT_ADDRESS(OS_BASE_CACHED | 0x00E8);
void* __OSDebugMon AT_ADDRESS(OS_BASE_CACHED | 0x00EC);
s32 __OSSimMemSize AT_ADDRESS(OS_BASE_CACHED | 0x00F0);
DVDBI2* __OSBootInfo2 AT_ADDRESS(OS_BASE_CACHED | 0x00F4);
s32 __OSDOLSize AT_ADDRESS(OS_BASE_CACHED | 0x30D4);
u16 __OSPADButton AT_ADDRESS(OS_BASE_CACHED | 0x30E4);

== Strange Things ==

What's [+0x148] in apploader data? Its only cleared in Init, but not used.

Why FST loading is so strange : if FST placed above DOL, then its loaded after DOL, otherwise its loaded before DOL.

if(FSTHigh) __OSDOLSize = dolSize + OSRoundUp32B(bb2.FSTLength);
else __OSDOLSize = dolSize;
Why so?

Why FST is loaded in pieces, if its greater than 64 DVD sectors, but big DOL sections are not loaded in same way?

Some code is placed after apploader data. Is it garbage or what?

== ToDo ==

* Need more BI2 details.

* Get Zelda apploader and crosscheck it with current reversing. Maybe some interesting things will be discovered.

* Count how many apploader revisions are present today.

== Source ==
This information was found at: [http://dolwin.emulation64.com/docs/Apploader.txt]

[[Category:CubeDocumented]]
[[Category:Technical Info]]
[[Category:Reverse Engineering]]

Memory Card

2024-08-01T16:22:58Z

Lumina33: devices that are not memory cards can be inserted

The Gamecube has two slots for '''memory cards''' where game information is stored. A common memory card capacity is 59 blocks. ''Animal Crossing'' was shipped with one of these 59-block cards. 251 blocks is also common.

A block is 8192 bytes.

Some devices that are not memory cards can be inserted into the slots.

Memory Card

2024-07-30T09:28:33Z

Lumina33: block size

Sarah

2024-07-26T15:20:39Z

Lumina33: linkify

{{Infobox/homebrew
| title = Sarah
| image = [[File:Sarah_game.png]]
| type = Game
| author = Cyndanera
| version = 1.0
| licence = Proprietary
| website = https://www.cyndanera.com
}}
'''Sarah''' is a Metroidvania Platformer game currently in development & will be released on a bootable disc for the [[GameCube]].

[[Category:Homebrew_Software]]
[[Category:Homebrew_Games]]

Qoob

2024-07-25T13:05:09Z

Lumina33: removed unnecessary word; parens

{{Infobox
|name = Infobox/doc
|bodystyle =
|title = Qoob
|titlestyle =

|image = [[File:qoob.jpg|200px|alt=Qoob Modchip]]
|imagestyle =
|caption = Qoob modchip
|captionstyle =
|headerstyle = background:#ccf;
|labelstyle = background:#ddf;
|datastyle = background:#ddf;

|header1 = Specification
|label2 = Generation
|data2 = [[IPL Replacement]]
|header3 = Flash Size
|label4 = PRO Series
|data4 = 2Mb (16MBit)
|label5 = SX Series
|data5 = 128Kb (1MBit)
}}

The '''Qoob''' modchip surfaced around late 2004-2006. It came quite late in the [[IPL Replacement]] era of modchips and was one of the last to be produced (with the exception of the Extreme series of [[Viper GC]]).

The Qoob chip came in two varieties - Pro & SX. They were both very feature rich and were similar to the [[Viper GC]] series, each acting as an [[IPL Replacement]], with 2Mb & 128Kb programmable ROM receptively. The Qoob Pro was an improved variant of the tmbinc [[IPL Replacement]] with added security, USB flashing support for the Pro series and DVD/ELF flashing for the SX. It was initially bundled with a full size case replacement for around $99 USD and sold very well.

The Qoob was succeeded by the [[Qoob Lite]], which was a [[drivechip]].

==Features==
===Pro version===

The pro version of the Qoob chip is intended for developers and/or advanced users. The biggest differences from the sx version is the USB upgrade feature and 16Mbit flash memory.
A Qoob Pro modchip installed inside of a Gamecube.

List of features:

* Direct booting of all media.
* Support for all regions (PAL, USA and Japan).
* Upgrades via USB, DVD or network (network upgrade requires a Nintendo GameCube Broadband Adapter).
* 16Mbit on-board flash memory for application storage.
* BIOS selection/control.
* Support for all retail hardware, including Panasonic Q.
* Fastboot of original GameCube discs.
* Integrated media compatibility check.
* IPL replacement compatibility via SD card or network.
* Streaming Audio Fix.
* MP3 player software included. (removed in later BIOS revisions)
* Status LED
* Support for DVD-R, DVD+R and MiniDVD
* Support for multiple games per disc
* Support for multi-disc games.
* Support for Datel Action Replay.

===SX version===

Released after the pro version, the sx version is a stripped down version of the Qoob Pro chip, missing the usb upgrade feature and containing only 1Mbit of flash memory. The sx is equipped with a backup read-only bios preventing users or malicious code from "breaking" the chip.
A Qoob SX modchip installed inside of a Gamecube.

List of features:

* Direct booting of all media.
* Support for all regions (PAL, USA and Japan).
* Upgrades via DVD and network (requires a broadband adapter).
* BIOS selection/control.
* Support for all retail hardware, including Panasonic Q.
* Fastboot of original GameCube discs.
* IPL replacement compatibility via SD card or network.
* Streaming Audio Fix.
* Integrated media compatibility check.
* Support for DVD-R, DVD+R, and MiniDVD
* Support for multiple games per disc
* Support for multi-disc games.

==DVD Ripping==
Qoob offers the ability to rip DVD backups via LAN with a Nintendo GameCube Broadband Adapter. 
PC IP Address: 192.168.1.100 
GAMECUBE IP Address: 192.168.1.32 (automatically set) 
 
Start Internet Explorer, in the navigation bar type: <tt><nowiki>http://192.168.1.32/DVD</nowiki></tt> 
A window will open allowing the ability to save the file. Rename the file appropriately. ( FireFox is not recommended due to interface issues ) 
Once ripping is completed, manually add the ."iso" or ".gcm" file extension 
Average ripping speed: 600KB p/s 

==BIOS==
[http://www.gc-forever.com/forums/viewtopic.php?f=4&t=23 BIOS files available at gc-forever.com]

==Further Info==
[http://en.wikipedia.org/wiki/Qoob_chip Qoob Chip @ Wikipedia]

{| border="3" align="center"
|-
! colspan="2" style="background:lightblue;font-size:10pt" width="800"| Qoob
|-
! scope="row" width="200" | Developers
|
|-
! scope="row" | CPU
| Actel ProASIC Plus APA075
|-
! scope="row" | Modchip Type
| [[IPL Replacement]]
|-
! scope="row" | Features
| [[Gamecube BIOS]]
|-
! scope="row" | Installation
| 6 wires
|-
|}

[[Category:Modchips]]

Nintendo GameCube

2024-07-24T08:10:51Z

Lumina33: front panel info

NPDP Cartridge

2024-07-24T08:09:24Z

Lumina33: linkify GC

NPDP Cartridge

== Background ==
The '''NPDP Cartridge''' interfaces with the [[Nintendo GameCube]] DVD interface. These can be used on a NPDP Console or GDEV-NPDP, these were used during the testing part of the development life-cycle for rapid version changing by simply writing a version of the game to a slot on the HDD in around 3-5 minutes and plugging it into the console.

== Hardware ==
The cartridge itself has the bulk of the optical drive emulation hardware, while the port on the NPDP Console/GDEV is just redirecting the custom connector to a few switches/LEDs to change "disc" or simulate a disc open then finally to the console.

6GB Hard disk drives are used, which is enough storage for 4 GameCube games.

It has a SH-3 CPU and a Spartan (more info).

=== Hard drive specifics ===

The hard disk drive is 6GB as stated above, however a larger HDD can be used but the game offets are hardcoded at 0x200000, 0x59200000, 0xB2200000, 0x10B200000. These coincide with the "slots" on the NPDP Console/GDEV. Each game entry seems to be 0x59000000 bytes long (to be confirmed).

The hard disk is locked with a master password at the high security level. The password is 'N-PDP Master Passwd', and it can depend on your view if you need to byteswap it or not. Sending the ATA commands 0xF2 (UNLOCK) then a 0xF6 (DISABLE) with the correct packet data will get you the Hard Disk unlocked, then you are able to read/write the contents, and put it back in the [[NPDP Reader]] to have it lock again with the master password.

The games (not in between areas) are XOR'd with a 32bit key which is seeded by 0xDEADBEEF + the response from either 0x12 or NPDP-ID command sent to the card - need to confirm this part. After applying the XOR to get the decypted content, you need to byteswap the dump to get it into proper format.

MXB012355

2024-07-24T07:56:08Z

Lumina33: /* D-Terminal cable */ bolded section heading

{{Infobox
|name = Infobox/doc
|bodystyle =
|title =
|titlestyle =

|image = [[File:MX_IC.png|200px|alt=DAC]]
|imagestyle =
|caption = MXB012355 MXB012455
|captionstyle =
|headerstyle = background:#ccf;
|labelstyle = background:#ddf;
|datastyle = background:#ddf;

|header1 = Macronix Digital Analog Converter
|label2 = Video Signal Input
|data2 = Y′CBCR
|label3 = Video Signal Output
|data3 = Y′PBPR RBGHV
|label4 = Video Resolution Output
|data4 = 480i/60Hz 576i/50Hz 480p/60Hz 576p/50Hz
}}
'''MXB012355 CMPV-DOL''' and '''MXB012455 CMPV-DOL''' are Digital-to-Analog Converter (DAC) IC's manufactured by Macronix specifically for use with the [[Nintendo Gamecube]]. 
They are used to convert the Gamecube's Y′CBCR digital video signal to Y′PBPR analog signal officially supporting video resolutions up to 480 / 576 interlaced and 480 progressive. These IC's can also be reconfigured to support RBGHV VGA output, and with the use of homebrew, such as [[Swiss]], capable of supporting up to 576 progressive video resolution.

These DAC's are included in the Official Gamecube Component Video and D-Terminal cable for use with Gamecube model DOL-001.

== Component Video cable ==
The '''Component Video Cable''' provides video quality superior to that of other connections, including the RF modulator, composite video cable and s-video cable. It enables the use of progressive scan in supported games (or Forced progressive video output with [[Swiss]]. However, the analog cable was still required in conjunction for audio output.

The cable was available for purchase exclusively in Nintendo's online store, and the cables were eventually discontinued by Nintendo due to what Nintendo claimed was a lack of consumer interest. This cable is only compatible with DOL-001 models of the GameCube, as Nintendo chose to omit the Digital AV port in subsequent models of the console.

== D-Terminal cable ==
The '''D-Terminal Video Cable''' is identical to the Component Video Cable with the exception of its physical output connection.

==Diagrams==

{| border="3" style="margin-left: 3em;"
|-
! scope="col" width = "100" | PINOUT
! scope="col" | [[File:MXB012355.png]]
|}

===PartsList===

{| border="3" style="margin-left: 3em;"
|-
! colspan=2 width = "200" | CAPACITORS
! colspan=2 width = "200" | RESISTORS
! colspan=2 width = "200" | FILTERS
|-
! scope="col" width = "100" | C1
! scope="col" width = "100" | 230 nF
! scope="col" width = "100" | R1
! scope="col" width = "100" | 75 ohm
! scope="col" width = "100" | FIL1
! scope="col" width = "100" | 80 ohm
|-
! scope="col" | C2
! scope="col" | 230 nF
! scope="col" | R2
! scope="col" | 75 ohm
! scope="col" | FIL2
! scope="col" | 80 ohm
|-
! scope="col" | C3
! scope="col" | 1 uF
! scope="col" | R3
! scope="col" | 75 ohm
! scope="col" | FIL3
! scope="col" | 80 ohm
|-
! scope="col" | C4
! scope="col" | 230 nF
! scope="col" | R4
! scope="col" | 115 ohm
|-
! scope="col" | C5
! scope="col" | 220 uF
! scope="col" | R5
! scope="col" | 14K ohm
|-
! scope="col" | C6
! scope="col" | 220 uF
! scope="col" | R6
! scope="col" | 23K ohm
|-
! scope="col" | C7
! scope="col" | 220 uF
|}

==12v Circuit and D-Terminal Connector==
12v power circuit is only utilized and required for Japanese D-terminal connection...
TV's which utilize a D-terminal connection require a data line voltage which will switch the displays video mode between interlaced / progressive.

The MX chip uses 12v power and associated board circuitry to reduce delivered data line voltage to 0v or 5v to the "black" pad.
The "black" pad is the D-terminal connection for the data line.
0 V = 59.94i / 60i
5 V = 59.94p / 60p

PIN 20 performs internal switching to control delivery of data line voltage:
1. GC powered off...PIN 20 = ~9K ohm
2. bootup and "progressive mode YES NO" message displayed (interlaced)...PIN20 = ~80K ohm = 0v
3. once "YES" is selected, the chip will output progressive scan video and provide signal to D-Terminal...PIN20 = open = 5v

==VGA Mod==
The MX chip is capable of switching between Component and VGA video output.

When Pin 12 is connected to GND (unmodified) the MX chip is in Component mode (YPBPR video output). To convert the MX chip for VGA output, simply lift Pin 12 from the GND pad and connect a 10K resistor between Pin 12 and 3.3v. PIN 21 and 22 are used for VGA vertical and horizontal sync.

VGA PINOUT
1 R
2 G
3 B
4 -
5 -
6 GND
7 GND
8 GND
9 -
10 GND
11 GND
12 -
13 H-Sync
14 V-Sync
15 -

==Selecting Progressive Mode==
Progressive video mode can only be displayed on supported software titles'''*'''. To manually call the progressive mode selection prompt, hold the "B" button at boot up and the selection prompt will appear.

'''*''' Not all titles support progressive video mode output. These titles can be "Forced" to output a progressive mode display with [[Swiss]].

[[Category:Hardware_Hacks]]

MXB012355

2024-07-24T07:55:49Z

Lumina33: /* Component Video cable */ bolded section heading

{{Infobox
|name = Infobox/doc
|bodystyle =
|title =
|titlestyle =

|image = [[File:MX_IC.png|200px|alt=DAC]]
|imagestyle =
|caption = MXB012355 MXB012455
|captionstyle =
|headerstyle = background:#ccf;
|labelstyle = background:#ddf;
|datastyle = background:#ddf;

|header1 = Macronix Digital Analog Converter
|label2 = Video Signal Input
|data2 = Y′CBCR
|label3 = Video Signal Output
|data3 = Y′PBPR RBGHV
|label4 = Video Resolution Output
|data4 = 480i/60Hz 576i/50Hz 480p/60Hz 576p/50Hz
}}
'''MXB012355 CMPV-DOL''' and '''MXB012455 CMPV-DOL''' are Digital-to-Analog Converter (DAC) IC's manufactured by Macronix specifically for use with the [[Nintendo Gamecube]]. 
They are used to convert the Gamecube's Y′CBCR digital video signal to Y′PBPR analog signal officially supporting video resolutions up to 480 / 576 interlaced and 480 progressive. These IC's can also be reconfigured to support RBGHV VGA output, and with the use of homebrew, such as [[Swiss]], capable of supporting up to 576 progressive video resolution.

These DAC's are included in the Official Gamecube Component Video and D-Terminal cable for use with Gamecube model DOL-001.

== Component Video cable ==
The '''Component Video Cable''' provides video quality superior to that of other connections, including the RF modulator, composite video cable and s-video cable. It enables the use of progressive scan in supported games (or Forced progressive video output with [[Swiss]]. However, the analog cable was still required in conjunction for audio output.

The cable was available for purchase exclusively in Nintendo's online store, and the cables were eventually discontinued by Nintendo due to what Nintendo claimed was a lack of consumer interest. This cable is only compatible with DOL-001 models of the GameCube, as Nintendo chose to omit the Digital AV port in subsequent models of the console.

== D-Terminal cable ==
The D-Terminal Video Cable is identical to the Component Video Cable with the exception of its physical output connection.

==Diagrams==

{| border="3" style="margin-left: 3em;"
|-
! scope="col" width = "100" | PINOUT
! scope="col" | [[File:MXB012355.png]]
|}

===PartsList===

{| border="3" style="margin-left: 3em;"
|-
! colspan=2 width = "200" | CAPACITORS
! colspan=2 width = "200" | RESISTORS
! colspan=2 width = "200" | FILTERS
|-
! scope="col" width = "100" | C1
! scope="col" width = "100" | 230 nF
! scope="col" width = "100" | R1
! scope="col" width = "100" | 75 ohm
! scope="col" width = "100" | FIL1
! scope="col" width = "100" | 80 ohm
|-
! scope="col" | C2
! scope="col" | 230 nF
! scope="col" | R2
! scope="col" | 75 ohm
! scope="col" | FIL2
! scope="col" | 80 ohm
|-
! scope="col" | C3
! scope="col" | 1 uF
! scope="col" | R3
! scope="col" | 75 ohm
! scope="col" | FIL3
! scope="col" | 80 ohm
|-
! scope="col" | C4
! scope="col" | 230 nF
! scope="col" | R4
! scope="col" | 115 ohm
|-
! scope="col" | C5
! scope="col" | 220 uF
! scope="col" | R5
! scope="col" | 14K ohm
|-
! scope="col" | C6
! scope="col" | 220 uF
! scope="col" | R6
! scope="col" | 23K ohm
|-
! scope="col" | C7
! scope="col" | 220 uF
|}

==12v Circuit and D-Terminal Connector==
12v power circuit is only utilized and required for Japanese D-terminal connection...
TV's which utilize a D-terminal connection require a data line voltage which will switch the displays video mode between interlaced / progressive.

The MX chip uses 12v power and associated board circuitry to reduce delivered data line voltage to 0v or 5v to the "black" pad.
The "black" pad is the D-terminal connection for the data line.
0 V = 59.94i / 60i
5 V = 59.94p / 60p

PIN 20 performs internal switching to control delivery of data line voltage:
1. GC powered off...PIN 20 = ~9K ohm
2. bootup and "progressive mode YES NO" message displayed (interlaced)...PIN20 = ~80K ohm = 0v
3. once "YES" is selected, the chip will output progressive scan video and provide signal to D-Terminal...PIN20 = open = 5v

==VGA Mod==
The MX chip is capable of switching between Component and VGA video output.

When Pin 12 is connected to GND (unmodified) the MX chip is in Component mode (YPBPR video output). To convert the MX chip for VGA output, simply lift Pin 12 from the GND pad and connect a 10K resistor between Pin 12 and 3.3v. PIN 21 and 22 are used for VGA vertical and horizontal sync.

VGA PINOUT
1 R
2 G
3 B
4 -
5 -
6 GND
7 GND
8 GND
9 -
10 GND
11 GND
12 -
13 H-Sync
14 V-Sync
15 -

==Selecting Progressive Mode==
Progressive video mode can only be displayed on supported software titles'''*'''. To manually call the progressive mode selection prompt, hold the "B" button at boot up and the selection prompt will appear.

'''*''' Not all titles support progressive video mode output. These titles can be "Forced" to output a progressive mode display with [[Swiss]].

[[Category:Hardware_Hacks]]

MXB012355

2024-07-24T07:55:03Z

Lumina33: linkify GC

{{Infobox
|name = Infobox/doc
|bodystyle =
|title =
|titlestyle =

|image = [[File:MX_IC.png|200px|alt=DAC]]
|imagestyle =
|caption = MXB012355 MXB012455
|captionstyle =
|headerstyle = background:#ccf;
|labelstyle = background:#ddf;
|datastyle = background:#ddf;

|header1 = Macronix Digital Analog Converter
|label2 = Video Signal Input
|data2 = Y′CBCR
|label3 = Video Signal Output
|data3 = Y′PBPR RBGHV
|label4 = Video Resolution Output
|data4 = 480i/60Hz 576i/50Hz 480p/60Hz 576p/50Hz
}}
'''MXB012355 CMPV-DOL''' and '''MXB012455 CMPV-DOL''' are Digital-to-Analog Converter (DAC) IC's manufactured by Macronix specifically for use with the [[Nintendo Gamecube]]. 
They are used to convert the Gamecube's Y′CBCR digital video signal to Y′PBPR analog signal officially supporting video resolutions up to 480 / 576 interlaced and 480 progressive. These IC's can also be reconfigured to support RBGHV VGA output, and with the use of homebrew, such as [[Swiss]], capable of supporting up to 576 progressive video resolution.

These DAC's are included in the Official Gamecube Component Video and D-Terminal cable for use with Gamecube model DOL-001.

== Component Video cable ==
The Component Video Cable provides video quality superior to that of other connections, including the RF modulator, composite video cable and s-video cable. It enables the use of progressive scan in supported games (or Forced progressive video output with [[Swiss]]. However, the analog cable was still required in conjunction for audio output.

The cable was available for purchase exclusively in Nintendo's online store, and the cables were eventually discontinued by Nintendo due to what Nintendo claimed was a lack of consumer interest. This cable is only compatible with DOL-001 models of the GameCube, as Nintendo chose to omit the Digital AV port in subsequent models of the console.

== D-Terminal cable ==
The D-Terminal Video Cable is identical to the Component Video Cable with the exception of its physical output connection.

==Diagrams==

{| border="3" style="margin-left: 3em;"
|-
! scope="col" width = "100" | PINOUT
! scope="col" | [[File:MXB012355.png]]
|}

===PartsList===

{| border="3" style="margin-left: 3em;"
|-
! colspan=2 width = "200" | CAPACITORS
! colspan=2 width = "200" | RESISTORS
! colspan=2 width = "200" | FILTERS
|-
! scope="col" width = "100" | C1
! scope="col" width = "100" | 230 nF
! scope="col" width = "100" | R1
! scope="col" width = "100" | 75 ohm
! scope="col" width = "100" | FIL1
! scope="col" width = "100" | 80 ohm
|-
! scope="col" | C2
! scope="col" | 230 nF
! scope="col" | R2
! scope="col" | 75 ohm
! scope="col" | FIL2
! scope="col" | 80 ohm
|-
! scope="col" | C3
! scope="col" | 1 uF
! scope="col" | R3
! scope="col" | 75 ohm
! scope="col" | FIL3
! scope="col" | 80 ohm
|-
! scope="col" | C4
! scope="col" | 230 nF
! scope="col" | R4
! scope="col" | 115 ohm
|-
! scope="col" | C5
! scope="col" | 220 uF
! scope="col" | R5
! scope="col" | 14K ohm
|-
! scope="col" | C6
! scope="col" | 220 uF
! scope="col" | R6
! scope="col" | 23K ohm
|-
! scope="col" | C7
! scope="col" | 220 uF
|}

==12v Circuit and D-Terminal Connector==
12v power circuit is only utilized and required for Japanese D-terminal connection...
TV's which utilize a D-terminal connection require a data line voltage which will switch the displays video mode between interlaced / progressive.

The MX chip uses 12v power and associated board circuitry to reduce delivered data line voltage to 0v or 5v to the "black" pad.
The "black" pad is the D-terminal connection for the data line.
0 V = 59.94i / 60i
5 V = 59.94p / 60p

PIN 20 performs internal switching to control delivery of data line voltage:
1. GC powered off...PIN 20 = ~9K ohm
2. bootup and "progressive mode YES NO" message displayed (interlaced)...PIN20 = ~80K ohm = 0v
3. once "YES" is selected, the chip will output progressive scan video and provide signal to D-Terminal...PIN20 = open = 5v

==VGA Mod==
The MX chip is capable of switching between Component and VGA video output.

When Pin 12 is connected to GND (unmodified) the MX chip is in Component mode (YPBPR video output). To convert the MX chip for VGA output, simply lift Pin 12 from the GND pad and connect a 10K resistor between Pin 12 and 3.3v. PIN 21 and 22 are used for VGA vertical and horizontal sync.

VGA PINOUT
1 R
2 G
3 B
4 -
5 -
6 GND
7 GND
8 GND
9 -
10 GND
11 GND
12 -
13 H-Sync
14 V-Sync
15 -

==Selecting Progressive Mode==
Progressive video mode can only be displayed on supported software titles'''*'''. To manually call the progressive mode selection prompt, hold the "B" button at boot up and the selection prompt will appear.

'''*''' Not all titles support progressive video mode output. These titles can be "Forced" to output a progressive mode display with [[Swiss]].

[[Category:Hardware_Hacks]]

NeoGeo CD Redux

2024-07-24T07:51:45Z

Lumina33: linkify GC

{{Infobox/homebrew
| title = NeoGeo CD Redux
| image = [[File:NedCDRedux.png]]
| type = Emulator
| author = Softdev, megalomaniac
| version = 0.1.52A.3 (unofficial)
| licence =
| website = https://www.gc-forever.com/forums/viewtopic.php?f=13&t=1246
| download =
| source =
}}

'''NeoGeo CD''' Redux, a NeoGeo CD/Z emulator for the [[Nintendo GameCube]] console.

==Features==
* WKF support (load roms from FAT formatted SD card in WKF SLOT only)
* IDE-EXI support
* Automatic TV mode detection
* Safemode Menu display (Hold L TRIGGER during bootup to activate)
* Supports both SD(SDHC) and DVD loading

== How to run it? ==
=== Emulator ===
# Download one of the last releases of emulator (A2 or A3).
# Place emulator's DOL into your FAT32 SD card.
# Run it thru Swiss and SDGecko.
=== Games ===
# Download NeoGeo CD BIOS and games (include ISO and MP3s).
# Place it into your SD:
#* BIOS Path: sd:\neocd\bios\NeoCD.bin (BIN name must be same!)
#* Game Path: sd:\neocd\roms\NameOfYourGame (you must unpack your ISO here!)
#* Audio Path: sd:\neocd\roms\NameOfYourGame\MP3 (rename audio files to Track01.mp3, Track02.mp3 and so on.)
# Run Emulator and then run games.
# Enjoy!

== Controls ==
=== In Game ===

{| class="wikitable" style="left;text-align:center;"
|-
| [[File:GCNController.png|50px]] || Action
|-
| [[File:GC_D-Pad.png|35px]] or [[File:GameCubeControlStick.png|35px]] || Neogeo DPad
|-
| [[File:GCNAButton.png|25px]] || A
|-
| [[File:GCNBButton.png|25px]] || B
|-
| [[File:GCNXButton.png|25px]] || C
|-
| [[File:GCNYButton.png|35px]] || D
|-
| [[File:GCNLButton.png|40px]] || Emulator Menu
|-
| [[File:GCNZButton.png|45px]] || Pause
|-
|}

=== In Menu ===

{| class="wikitable" style="left;text-align:center;"
|-
| [[File:GCNController.png|50px]] || Action
|-
| [[File:GC_D-Pad.png|35px]] or [[File:GameCubeControlStick.png|35px]] || Navigate the menu
|-
| [[File:GCNAButton.png|25px]] || Enter Directory/Confirm
|-
| [[File:GCNBButton.png|25px]] || Parent Directory
|-
| [[File:GCNXButton.png|25px]] || Launch Game
|-
| [[File:GCNZButton.png|45px]] || Emulator Menu
|-
|}
[[Category:Homebrew_Software]]

Freeloader

2024-07-24T07:51:17Z

Lumina33: linkify GC

[[File:Freeloader_ntsc.jpg|right|thumb|150px]]

'''Freeloader''' is a bootdisc based solution developed by [https://www.datel.co.uk/ Datel] to circumvent regional lockout on the [[Gamecube]]. It allows unmodified Gamecubes to play '''original''' out-of-region ([[Playing_Imports|import]]) titles. Datel sold different versions of Freeloader compatible for use with NTSC (USA, JPN) and PAL (EUR) Gamecubes.

[[File:Freeloader_pal.jpg|left|thumb|150px]]
== Features ==
* Launch and play imported GameCube games from any region.
* No need to modify your console - keeps your warranty intact.
* Add loads of new titles to your GameCube collection, including games never released in your region.
* Play ANY region of games ANY GameCube.
* Fast and easy to use.
* Compatible with the [[WikiScene:GameCube#Panasonic_Q|Panasonic Q]].
* Not 100% compatible with the Japanese version of ''F-Zero GX'' and ''Paper Mario 2''.
* Does not allow use of DVD±R for [[Create_a_bootable_homebrew_disc|homebrew]] or [[Backing_Up_Discs|backups]].

'''Important:''' When playing a Japanese game, the memory card will be re-formatted to Japanese settings, overwriting any existing US or European settings and any game saves stored on the card. Recommend keeping a separate card for use with Japanese games only.

CubeSX

2024-07-24T07:38:15Z

Lumina33: linkify GC

{{Infobox/homebrew
| title = CubeSX
| image = [[File:WiiSXicon.png]]
| type = Emulator
| author = emu_kidid, sepp256, tehpola
| version = Beta 4.1
| licence = [http://www.gnu.org/licenses/gpl-2.0.txt GNU GPL v2]
| download = https://github.com/emukidid/pcsxgc/releases
| website = https://github.com/emukidid/pcsxgc
| source = https://github.com/emukidid/pcsxgc
}}

PSX emulator for the [[Nintendo Gamecube]] & Wii based on various PCSX code bases.

== Features ==
* Emulation via Dynamic Recompilation & Interpreter
* Software Rendered Graphics with GX scaling
* SPU and XA Stereo Audio
* Input via Gamecube Controller
* Input Emulation for DualShock Controllers (Both Standard & Analog Modes)
* Vibration Feedback
* Configurable input combinations
* DVD/SDGecko/Samba ISO Loading
* Memory Cards
* Save States
* Progressive/Widescreen Resolution

[[Category:Homebrew_Software]]

Talk:Hardware Acronyms

2024-07-24T07:27:22Z

Lumina33: created page

The linked original document names the emu creator "or9" but this page says "org" - which is correct? --Lumina33 7/24/2024

Hardware Acronyms

2024-07-24T07:25:02Z

Lumina33: DDH=Dolphin Development Hardware

== Gamecube hardware acronyms for CubeDocumented project ==

Documented by Andrei Shestakov (org). Version 1.1. (22 Jan 2006)
(original document hosted here: http://dolwin.emulation64.com/docs/acronyms.txt)

------------------------------------------------------------------------------

=== AA ===
Antialiasing. Rendering method, that makes polygon edges seem less sharpen,
combining colors of nearby pixels.

=== AD16 ===
Mysterious EXI device.

=== AI ===
Audio Interface. Hardware responsible for DMA playback of PCM buffer and
DVD ADPCM streaming sound. AI hardware cannot mix sound channels or set
channel volume for PCM DMA playback. These operations and more advanced
sound effects are produced by DSP.

=== [[Apploader]] ===
Small program on DVD to load main DOL executable.

=== AR, ARAM ===
Auxiliary (Audio) Memory. 16 MB of slow (comapred to RAM) DRAM.
Used for raw DSP sound data and as temporary space for textures.
ARAM has DMA communication channel with main memory (RAM). Development
boards has "ARAM Expansion" (additional 4, 16 or 32 MBs).

=== BAT ===
Block Address Translation, PPC MMU translation mechanism. There are DBAT
and IBAT special-purpose registers for data and instruction address
translation respectively.

=== BBA ===
Broad-Band Adapter, GC's 10BaseT Ethernet Adapter.

=== BS ===
Bootstrap Stage (from analogy with UNIX). Very first code, executed after
GC hard reset.

=== BS2 ===
Bootstrap Stage 2. Same as IPL.

=== CR ===
PPC Condition Register, stores result of integer comare operation, for
conditional branch decision.

=== CRT ===
C Run Time. C/C++ program environment (libraries and startup calls).

=== DDH ===
Dolphin Development Hardware

=== DOL ===
Gamecube application (custom executable file format).

=== Dolphin ===
Early development work name of Gamecube.

=== Dolphin OS ===
Gamecube OS. Single user, single process, multithreaded. Linked together
with any GC application ("hard-linked"), as library.

=== DSP ===
Digital Signal Processor. Used to produce advanced sound on GC.
DSP is integrated with GP in Flipper chip and has its own ROM.
Developed by Macronix.

=== DI, DVD ===
DVD hardware interface. GC DVD is actually microcontroller, based on MN-102
CPU with proprietary firmware ROM. DVD is protected by non-standard barcodes
and data encryption, which is decrypted on-the-fly by DVD controller. GC DVD
cannot be read on usual PC hardware. Whole GC DVD stuff is developed by
Matsushita.

=== EFB ===
Embedded Framebuffer. 2MB of fast 1T-SRAM memory located inside Flipper.
Used by GP's pixel engine to draw pixels. Later copied into XFB, for final
TV-output.

=== EXI ===
Expansion Interface. Gamecube peripherial devices bus, sort of USB
architecture. Developed by Macronix. Devices drived by EXI: memory cards,
broad-band adapter, real-time clock, bootrom, SRAM.

=== FIFO ===
First-In-First-Out buffer to send GP commands and create GP command lists.

=== Flipper ===
Gamecube Northbridge+Peripheral Hardware+Graphics Processor+Audio DSP.

=== FPR ===
Floating Point Register. Gekko has 32 64-bit FPRs, named f0-f31.

=== FPSCR ===
Floating Point Status and Control Register.

=== JTAG ===
Hardware debug interface to CPU. You can connect some wires to CPU pins,
to overwhelm it. Gekko has full support of IEEE 1149-1a-1993 JTAG standard.

=== GC, GCN, NGC ===
Nintendo Gamecube.

=== GCM ===
Gamecube Master Data (official term). GC DVD Image files.

=== Gekko ===
Gamecube CPU, PowerPC 750-derivative processor with FPU extensions, called
"Paired Single".

=== GP, GX ===
Graphics Processor, the major part of Flipper chip. GP is fixed point
state-machine. Developed by ArtX team.

=== GPR ===
General Purpose Register. Gekko has 32 32-bit GPRs, named r0-r31. r1 often
used as stack pointer (sp).

=== GX ===
Software library, developed by Nintendo and ArtX, to drive GP hardware.
Has many crossways with OpenGL (but more advanced).

=== HW2 ===
Common name of GC hardware. Number state for revision ("2" is production
board).

=== IPL ===
Initial Program Loader. Graphics shell, used to load game from DVD.

=== MC ===
Memory Card, EXI device.

=== MI ===
Flipper memory interface, plays role of "Nothbridge".

=== MMU ===
PPC Memory Management Unit. Translates virtual address to physical.
MMU has two translation mechanisms: block address translation and page table
translation. Address translation for data access and instruction fetch is
processed separately in DMMU and IMMU.

=== MSR ===
Machine State Register. CPU status and control register.

=== MX ===
Macronix Ltd. chips index. GC has many hardware parts, developed
by Macronix, like DSP, EXI and bootrom chip.

=== PC ===
Program Counter. PowerPC architecture does not define such term, but
everyone is using it anyway, instead "CIA" (Current Instruction Address).

=== PCM ===
Pulse Code Modulation, method commonly used in digital sound hardware.
PCM sound parameters are: playback rate, bits per sample, sample format.
GC AI can playback 32000/48000 Hz, 16-bit big-endian stereo samples via
DMA.

=== PI ===
Peripheral Interface. Set of hardware registers to control interrupts and
hardware reset. There also "PI FIFO": hardware-driven FIFO buffer in RAM.

=== PM ===
PowerPC Performance Monitor. Set of PPC special purpose registers used for
speed profiling of applications.

=== PPC ===
IBM PowerPC Architecture.

=== PTE ===
Page Table Entry. Page table record, used to translate virtual address to
physical.

=== RAM ===
Main memory. GC has 24 MB of fast 1T-SRAM. Development boards has RAM
extended up to 48 MB. Developed by MoSys.

=== ROM ===
Read-only memory. GC has following ROMs: 2 MB encrypted bootrom, 128 KB
DVD firmware, 4 KB DSP DROM, 8 KB DSP IROM.

=== RSW ===
"Reset Switch", same as reset button. Seems early development GC models
were equipped by switch, instead programmable reset button.

=== RTC ===
Real-time clock. EXI device, counting seconds since 00:00 AM 2000.

=== SDK ===
Software Development Kit. Full set of compilers, libraries and documentation
for development on specified platform. Gamecube SDK contain development tools,
like sound and texture convertors, and set of libraries for OS and hardware.
Compiler is provided by Metrowerk's CodeWarrior. There also huge development
board and paper documentation.

=== SI ===
Serial Interface. Hardware responsible for communication with serial devices,
such as GC controller and keyboard via serial I/O buffer.

=== SPR ===
Special-purpose register. Set of registers, dedicated to operating system.
Gekko has about 60 SPRs.

=== SR ===
Segment Registers, used by MMU for virtual address translation.

=== SRAM ===
Small amount of battery backuped memory for OS misc settings.

=== TLB ===
PPC MMU Translation Lookaside Buffer, used to keep recently used page
address translations. Gekko has 128 two-way set associative TLB for each
MMU (DMMU and IMMU).

=== VI ===
Video Interface. Hardware responsible for TV-out of framebuffer (XFB),
and generating VBlank interrupt (actually can be configured to interrupt
CPU at any beam location). Has support for light-gun, antialiasing of XFB
by tap-filters and progressive video mode (480p).

=== WBUF ===
Gekko Write Gather Buffer. Small cache for burst memory transactions.
Used together with graphics FIFO to send GP commands.

=== XF ===
Transform Processor

=== XFB ===
External Framebuffer, located in main memory. Used for final TV-out by VI.

[[Category:CubeDocumented]]
[[Category:Technical Info]]
[[Category:Reverse Engineering]]

SDLoad

2024-07-23T13:35:59Z

Lumina33: fix run on sentence

'''SDLoad''' is an older way of loading homebrew onto the [[Nintendo Gamecube]]. It was originally released in 2005 by Costis, and can be downloaded [http://gc-forever.com/forums/viewtopic.php?f=4&t=401 here].

This method of loading homebrew has mainly been superseded by the use of save-game exploits and mod-chips. However, it is still a functional way of enabling homebrew on a gamecube and unlike save game exploits does not initially require a Nintendo Wii or a previously homebrew enabled game cube to load a save-game exploit onto a memory card. Thus this guide can be followed by anybody who has only a gamecube, SD-card adapter with SD-card and a [https://www.datel.co.uk/ Datel] [[Action Replay]] to get homebrew running on their gamecube.

This guide requires the user to have some basic windows knowledge such as how to launch an administrative command prompt as well as format an SD-Card in the FAT16 filesystem and how to change directories (folders) in the command prompt, how to do this is not covered here but there are many guides already on the internet about how to do both.

== Requirements==

===Hardware===
* Nintendo Gamecube -> Any version / any region should work.
* Datel [[Action Replay]] (version 1.14 or below) -> Newer versions of action replay lack the user-code entry screen, if you cannot input codes your action replay disc is too new. The Japanese version of the Action Replay uses a different set of codes to the US / Europe version of the disc so be careful when you are choosing the codes on the code-input screen, the Japanese Pro Action Replay (Karat) disc is in Japanese so unless you have this disc (unlikely) then the standard code should work regardless of console region.
* PC with SD CARD Reader.
** Note: It is a common misconception that the bundled memory card is required for the action replay to work, this is not true, if your disc didn't come with a memory card simply insert any memory card that has some free space into slot 2 before booting the action replay disc and it will automatically create a code database file on the memory card.
* SD-Card adapter and SD-card -> The genuine SD-card adapter is long discontinued and commands high prices, you can buy pre-made adapaters like the Wiikey SD Gecko for a few dollars or make your own if you are handy with a soldering iron, there are diagrams online if you wish to try and build one.
* SD-Card: The card itself needs to be a NON SDHC card (i.e 2gb or less) and formatted as a FAT16 file system.
** Smaller SD Cards (sub 64mb) might format as FAT12, you can ensure a FAT16 format on such a card by using the command "format x: /FS: FAT /A:512" from a command prompt (where X: represents the drive letter of your SD card).

===Software===

Microsoft Windows -> Windows 2000 and later are supported.

sdload.zip -> There are two versions of the software, the original version works with Windows 2000 & XP, the later version which works with newer versions of Windows such as Vista / 7 / 8 / 10. Make sure you download the version appropriate for your system.

==Installation==

===Step 1 [Setting up the SD Card - Windows Vista / 7 / 8 / 10]===

This section is for users of Windows Vista / 7 / 8 / 10, if you are running an older OS such as XP or Windows 2000 skip to the Windows XP section.

1. Make sure your PC can access your SD-Card and that it has been freshly formatted as a FAT16 filesystem.

2. Download and extract the sdload.zip (Windows 10 supported version) to a folder on your computer. i.e "c:\sdload"

3. Copy the 2 files sdloader.bin and sdipdata.cfg to the root of your SD card (don't put them in a folder). You can also copy any other DOL (gamecube executable) files you wish to run from your SD Card as this time too, such as SWISS, CleanRip, GCOS, GCMM etc.

3. Open an administrator command prompt and navigate to the directory (folder) where you extracted sdload to, i.e "cd c:\sdload"

4. Run [[SDPatch|sdpatch]] without any parameters, i.e "sdpatch", the program will take a few seconds and report a list of connected drives to your computer. i.e.

Caption DeviceID Model Partitions Size
TOSHIBA THNSN9240GESG \\.\PHYSICALDRIVE0 TOSHIBA THNSN9240GESG 2 240054796800
Generic SDC SD Card \\.\PHYSICALDRIVE1 Generic SDC SD Card 1 8225280

Depending on if you are using a USB card reader or a built in card reader the device might show up as a generic USB device, if you are unsure unplug all external usb drives and memory sticks from the computer.

5. In the example above we can see the SD card is reported to the system as physical drive 1, depending on your system this could be 2 or 3 etc, be sure you are choosing the correct drive and run sdpatch but specify the number you wish to patch, i.e sdpatch 1

* The software will NOT let you pick drive 0 as this is usually the first installed hard disk but depending on your system and number of hard disks and how the machine is set up to boot it is possible to break your PC by patching the wrong drive if it is set up to boot in some weird way so pay extra care, you can always remove the SD card and run sdpatch again and see which drive disappears from the list to make extra sure.

The program will run and if all went OK it will report that your SD Card is now patched, before removing it from the system double check in file explorer that you are still able to see the files you copied earlier

6. Put the SD-Card into the SD-Card adapter and install it into slot 1, make sure you have a memory card installed in slot 2 and boot up the gamecube and begin the sdload code entry sequence.

===Step 1 [Setting up the SD Card - Windows XP / 2000]===

This section is for users of Windows XP & 2000, if you are running an newer OS such as Windows 7 or 10 then please follow the section above.

1. Make sure your PC can access your SD-Card and that it has been freshly formatted as a FAT16 filesystem.

2. Download and extract the sdload.zip (original windows XP version) to a folder on your computer. i.e "c:\sdload"

3. Copy the 2 files sdloader.bin and sdipdata.cfg to the root of your SD card (don't put them in a folder). You can also copy any other DOL (gamecube executable) files you wish to run from your SD Card as this time too, such as SWISS, CleanRip, GCOS, GCMM etc. Make a note of what drive your SD card is too, i.e E:

3. Open an administrator command prompt and navigate to the directory (folder) where you extracted sdload to, i.e "cd c:\sdload"

4. Run sdpatch x: where x: represents your SD-Card i.e: sdpatch E:

5. The program will run and if all went OK it will report that your SD Card is now patched, before removing it from the system double check in file explorer that you are still able to see the files you copied earlier.

* The software will NOT let you pick a non removable drive but depending on your system setup it might be possible to somehow patch an incorrect drive and stop your PC from booting up so take extra care when writing in the letter of your SD Card.

The program will run and if all went OK it will report that your SD Card is now patched, before removing it from the system double check in file explorer that you are still able to see the files you copied earlier

6. Put the SD-Card into the SD-Card adapter and install it into slot 1, make sure you have a memory card installed in slot 2 and boot up the gamecube and begin the sdload code entry sequence.

===Step 2 [Action Replay Code Entry]===

Providing you have patched your SD Card and copied the appropriate files to it the last step is to create a custom code in the Action Replay to boot up SD Loader, this is a long code and will take around 15 minutes to enter, fortunately it only has to be done once so take your time and verify that all codes have been typed correctly.

1. Select "Action Replay Codes"
2. Select the USA flag (This applies regardless of PAL / NTSC gamecube).
3. Select "Add New Game", call it SDLOAD (use all capital lettters) and push the done key.
4. Enter (m) as the code name (use a small m and use the CAPS button to find the brackets) and push the done key.
5. Enter the following 3 codes, pushing done after each code, once you have entered the final code just push done for a second time and you should get an "updating action replay hardware" message while the codes are saved.

(m)
1: 7YPR-RKZZ-MH6W5
2: D26A-PE4J-1XX2W
3: ZJHY-B1ZH-6P00G

6. You should now see SDLOAD and Add New Code (your (m) should be visible in green too). Select add new code and this time call the code SDLOAD (all capitals) and like before input the following code, this code is 29 lines so double check before pushing done.

(SDLOAD)
1: AF4H-JPF5-H1B5J
2: MVAB-7TQE-ABZPB
3: V2CK-QQ1A-Y6P72
4: M5N6-CMMH-9EURT
5: 0JFM-3A6C-VZ6VK
6: KYV8-0JGV-0GR1N
7: 2EGU-HVKF-NDMCN
8: 7AH0-J9JZ-HHGNJ
9: 4MHU-G8XT-ZRYCJ
10: 9474-KF41-8KG34
11: QMEV-G90N-A8RV0
12: KD4G-5QHV-74D46
13: V97K-652Q-Y4TEY
14: 6M4W-9GPT-E99NG
15: QPFY-DJAF-E01FV
16: 2Z6E-P2WY-24WV4
17: 6NHW-G3NH-HP31Y
18: A2KF-MCKN-D645J
19: K5V8-EF9W-7GFQC
20: XTU3-269T-VH5NE
21: H9GP-C4PP-6FGF9
22: HF77-R45C-ZXPDV
23: 22Y3-D98C-50AJM
24: WTWZ-EC88-U5ZTV
25: 36G1-UGDG-J2G84
26: DUMT-15KR-DXJ8K
27: JV55-6VF5-2Z02T
28: D4R8-MVJ5-QGR21
29: 1G3C-APD7-1CUVD

7: Select the code SDLOAD and press A to enable it (the code should get a checkbox) and press B to return to the main menu. Some versions of the Action Replay are buggy and disable newly entered codes after a reboot so it is a good idea to browse to the options menu, select update hardware then reboot the system and verify that your SDLOAD code is enabled. To do this after a reboot pick Action Replay Codes, SDLOAD should already be selected, select it with A and make sure the SDLOAD code has a check-mark in it. Press B twice to go back to the main menu and press Start Game, open and close the lid (leaving the action replay disc is fine.) and if all went well after a few seconds you should see the SDLoad screen where you can pick any DOL you wish to run.

===Step 3 [Post Installation & Troubleshooting]===

Congratulations, if all went well you should be looking at the SDLoad screen and can launch any DOL of your choice. If you have a spare memory card you can use a tool like GCMM to clone your memory card with the Action Replay SDload code on it to another memory card in case of corruption or deletion, this will save you having to input the code again should it get erased. I like to verify that my cloned memory card works by testing it with the Action Replay, some copy tools will copy the Action Replay file across ok but the Action Replay won't recognize the file, you will know if it copied OK as SDLOAD will be the default selected game.

If you didn't get to see the SDload screen then verify the steps above, is your SD Card 2gb or under and non HC? is it formatted as FAT16 and patched with the patch utility? Have you copied the sdloader.bin and the .cfg files to it in the proper place?

If you made your own adapter check the wiring and connections, if you are using a bought adapter some of them are of low quality so try verifying the SD Card is making good contact and the adapter is making good contact with the gamecube memory card slot.

==[Note for users of the Japanese Pro Action Replay]==

This code is only for those using the Karat branded Pro Action Replay sold in Japan. (it is unlikely but you never know) I'm not sure if this is a datel knock off or sold under licence but it looks very similar apart from all the menus being in Japanese, if your Action Replay is NOT in Japanese then don't use this code or else it won't work. If your Action Replay is the Japanese version then when you come to the code entry sequence use the following codes instead of those above.

(m)
1: Q1NP-P0FY-7P4NA
2: D26A-PE4J-1XX2W
3: ZJHY-B1ZH-6P00G

SDLOAD
1: 9N5B-081B-HF6E3
2: MVAB-7TQE-ABZPB
3: V2CK-QQ1A-Y6P72
4: M5N6-CMMH-9EURT
5: 0JFM-3A6C-VZ6VK
6: KYV8-0JGV-0GR1N
7: 2EGU-HVKF-NDMCN
8: 7AH0-J9JZ-HHGNJ
9: 4MHU-G8XT-ZRYCJ
10: 9474-KF41-8KG34
11: QMEV-G90N-A8RV0
12: KD4G-5QHV-74D46
13: V97K-652Q-Y4TEY
14: 6M4W-9GPT-E99NG
15: QPFY-DJAF-E01FV
16: 2Z6E-P2WY-24WV4
17: 6NHW-G3NH-HP31Y
18: A2KF-MCKN-D645J
19: K5V8-EF9W-7GFQC
20: XTU3-269T-VH5NE
21: H9GP-C4PP-6FGF9
22: HF77-R45C-ZXPDV
23: 22Y3-D98C-50AJM
24: WTWZ-EC88-U5ZTV
25: 36G1-UGDG-J2G84
26: DUMT-15KR-DXJ8K
27: JV55-6VF5-2Z02T
28: D4R8-MVJ5-QGR21
29: 1G3C-APD7-1CUVD

DuoQ

2024-07-23T13:34:04Z

Lumina33: /* Overview */ linkify GC

{{Infobox/modchip
| image = [[File:duoq.jpg|200px|alt=DuoQ Modchip]]
| gen = drivechip
}}

==Overview==
The '''DuoQ''' is a drivechip for the [[Nintendo Gamecube]]. It's identical to a XenoGC 1.0 modchip (as it is most likely a clone under a different name).

==Features==
* Jumperless solution for Pal, US and Jap machines.
* LED Indicator lights.
* Low power design.
* Simple 6 wire installation points.
* Supports Multi games & AR
* Compatible with GQ originals & imports
* Compatible with backups.

==Settings==
(Assuming that this behaves the same as the XenoGC 1.0)
===General Info===
You can adjust a few settings by holding various buttons on controller 1 while booting a game - this means from just before and during the black screen as the boot up menu goes away and the game starts up. The settings will be in effect per boot and not change behaviour permanently.

===[L button] Disable audiofix===
If you modified your backup images to work with bioses that didn't support streaming audio correctly, you can disable the native fix.

===[R button] Disable DREfix===
Turns off the native read adjustment/retries. Can be useful if you want to scan a disc for read errors. The chip will not try to prevent any errors and use the default read settings

===[X/Y button] Force NTSC/PAL display mode===
Will force the selected region's display mode regardless of the actual game region. This will work for some games, for others it won't.

===[START button] Version display===
On a version 1.0 XenoGC it shows some basic version info (Chip, GC and drive) but on this chip it appears to be missing - in order to use a cheaper IC or to avoid looking like a clone?

{| border="3" align="center"
|-
! colspan="2" style="background:lightblue;font-size:10pt" width="800"| DuoQ
|-
! scope="row" width="200" | Developers
| Team Omega
|-
! scope="row" | CPU
| Unknown
|-
! scope="row" | Modchip Type
| [[Drivechip]]
|-
! scope="row" | Features
| [[Gamecube BIOS]]
|-
! scope="row" | Installation
| 9 wires (3 optional)
|-
|}

[[Category:Modchips]]

USBGecko

2024-07-23T13:31:57Z

Lumina33: /* Reception */ its not possessive

{{Infobox
|name = Infobox/doc
|bodystyle =
|title = USB Gecko
|titlestyle =

|image = [[File:USBGecko.jpg|200px|alt=USB Gecko]]
|imagestyle =
|caption = USB Gecko in original packaging
|captionstyle =
|headerstyle = background:#ccf;
|labelstyle = background:#ddf;
|datastyle = background:#ddf;

|header1 = Specification
|header2 = Flash Size
|label3 = USB Gecko
|data3 = 512Kb (4MBit)
|label4 = USB Gecko SE
|data4 = N/A
}}

== General ==
The '''USB Gecko''' was originally released as a "Developers Tool" aimed at homebrew developers and GC/Wii enthusiasts. It was originally released in early 2007 but was only produced in limited numbers. It is basically a device that uses the EXI bus to communicate bi-directionally from GC/Wii to a PC. It can plug in to either memory card port of a GC/Wii, but the software of course must be written to support both ports. The original version also featured 512Kb of internal Flashable memory which developers could store useful data in (such as code to reboot/reload to from their homebrew applications).

[[File:USBGeckoSE.jpg|thumb|USB Gecko SE in its official packaging]]
[[File:USBGeckos.jpg|thumb|USBGecko beta, Original, SE]]
In late 2010 - early 2011, a cheaper, even more limited edition version was produced dubbed "USB Gecko SE". It featured the same features as its predecessor however the flash memory was removed since not many homebrew applications made use of it. A status LED was added to the USB Gecko SE which was user controllable.

== Reception ==
Although it was predominantly referred to as a developers tool, the USB Gecko perhaps received its biggest sales from users who wanted to debug/hack commercial games for cheating/exploit purposes - the cheats community (wiiRD/Ocarina).

Many developers consider it a "must have" as it is very useful for debugging/stepping through code in libOGC / GDB.

== Downloads (PCB/VHDL/GeckoOS) ==
After production stopped for the USB Gecko SE, the product was made open source with all files being available for download.

Official Googlecode [http://code.google.com/p/geckodownloads/ Project Page] for Gecko Downloads

Gamecube tools and Gecko Downloads mirror @ [http://www.gc-forever.com/forums/viewtopic.php?f=4&t=98 GC-Forever]

== PCB Differences ==
=== Pre-release Version ===
[[File:USBGeckoBetaTop.jpg|200px|USBGecko beta PCB top]]
[[File:USBGeckoBetaBottom.jpg|200px|USBGecko beta PCB bottom]]
=== Original Version ===
[[File:USBGeckoTop.jpg|200px|USBGecko PCB top]]
[[File:USBGeckoBottom.jpg|200px|USBGecko PCB bottom]]
=== SE Version ===
[[File:USBGeckoSETop.jpg|200px|USBGecko SE PCB top]]
[[File:USBGeckoSEBottom.jpg|200px|USBGecko SE PCB bottom]]

[[Category:MiscHardware]]

USBGecko

2024-07-23T13:30:41Z

Lumina33: /* General */ bolded title

{{Infobox
|name = Infobox/doc
|bodystyle =
|title = USB Gecko
|titlestyle =

|image = [[File:USBGecko.jpg|200px|alt=USB Gecko]]
|imagestyle =
|caption = USB Gecko in original packaging
|captionstyle =
|headerstyle = background:#ccf;
|labelstyle = background:#ddf;
|datastyle = background:#ddf;

|header1 = Specification
|header2 = Flash Size
|label3 = USB Gecko
|data3 = 512Kb (4MBit)
|label4 = USB Gecko SE
|data4 = N/A
}}

== General ==
The '''USB Gecko''' was originally released as a "Developers Tool" aimed at homebrew developers and GC/Wii enthusiasts. It was originally released in early 2007 but was only produced in limited numbers. It is basically a device that uses the EXI bus to communicate bi-directionally from GC/Wii to a PC. It can plug in to either memory card port of a GC/Wii, but the software of course must be written to support both ports. The original version also featured 512Kb of internal Flashable memory which developers could store useful data in (such as code to reboot/reload to from their homebrew applications).

[[File:USBGeckoSE.jpg|thumb|USB Gecko SE in its official packaging]]
[[File:USBGeckos.jpg|thumb|USBGecko beta, Original, SE]]
In late 2010 - early 2011, a cheaper, even more limited edition version was produced dubbed "USB Gecko SE". It featured the same features as its predecessor however the flash memory was removed since not many homebrew applications made use of it. A status LED was added to the USB Gecko SE which was user controllable.

== Reception ==
Although it was predominantly referred to as a developers tool, the USB Gecko perhaps received it's biggest sales from users who wanted to debug/hack commercial games for cheating/exploit purposes - the cheats community (wiiRD/Ocarina).

Many developers consider it a "must have" as it is very useful for debugging/stepping through code in libOGC / GDB.

== Downloads (PCB/VHDL/GeckoOS) ==
After production stopped for the USB Gecko SE, the product was made open source with all files being available for download.

Official Googlecode [http://code.google.com/p/geckodownloads/ Project Page] for Gecko Downloads

Gamecube tools and Gecko Downloads mirror @ [http://www.gc-forever.com/forums/viewtopic.php?f=4&t=98 GC-Forever]

== PCB Differences ==
=== Pre-release Version ===
[[File:USBGeckoBetaTop.jpg|200px|USBGecko beta PCB top]]
[[File:USBGeckoBetaBottom.jpg|200px|USBGecko beta PCB bottom]]
=== Original Version ===
[[File:USBGeckoTop.jpg|200px|USBGecko PCB top]]
[[File:USBGeckoBottom.jpg|200px|USBGecko PCB bottom]]
=== SE Version ===
[[File:USBGeckoSETop.jpg|200px|USBGecko SE PCB top]]
[[File:USBGeckoSEBottom.jpg|200px|USBGecko SE PCB bottom]]

[[Category:MiscHardware]]

Playing Backups

2024-07-23T13:28:59Z

Lumina33: bolded title

If you can [[Booting Homebrew|boot homebrew]], that should provide enough as a base to be able to play '''backups''' of your legally owned games. Make sure you [[Backing Up Discs|back them up properly]] first.

==Mediums to play backups from==
Backups can be played from a large variety of mediums. These are listed below in order of best to worst performance and stability based on my personal opinion.

{| border="3" align="center"
|-
! colspan="1" style="background:lightblue;font-size:10pt" width="100"| Medium
! colspan="1" style="background:lightblue;font-size:10pt" width="300"| Performance
! colspan="1" style="background:lightblue;font-size:10pt" width="300"| Stability
! colspan="1" style="background:lightblue;font-size:10pt" width="50"| [[Audio_Streaming|Audio Streaming]]
! colspan="1" style="background:lightblue;font-size:10pt" width="300"| Requires hardware beyond softmod?
! colspan="1" style="background:lightblue;font-size:10pt" width="300"| Which homebrew enables this?
|-
! scope="row" width="150" | DVD-R
| Just like the real thing
| Depends on laser and media quality but generally good
| Yes
| No
| [[Swiss]], [[GCoS]], [[GCOM]], [[XenoGC]]
|-
! scope="row" | SD/HC/XC Card via [[Wiikey Fusion]] or [[Wii Optical Drive Emulator|WODE]]
| Perfect
| Perfect, super fast load times
| No
| [[Wiikey Fusion]] or [[Wii Optical Drive Emulator|WODE]]
| [[Swiss]]
|-
! scope="row" | USB Hard Disk Drive via [[Wii Optical Drive Emulator|WODE]]
| Perfect
| Perfect, super fast load times
| No
| [[Wii Optical Drive Emulator|WODE]]
| [[Swiss]]
|-
! scope="row" | SD/HC/XC Card via [[SDGecko]]
| Stutters on high load areas
| Generally very stable on games that are supported
| Yes
| [[SDGecko]] (make your own too)
| [[Swiss]]
|-
! scope="row" | IDE Hard Disk via [[Ide-exi]]
| Stutters on high load areas
| Generally very stable on games that are supported
| Yes
| [[Ide-exi]]
| [[Swiss]]
|-
! scope="row" | Ethernet
| Stutters on high load areas
| Generally stable, can freeze randomly on poor LAN card
| No
| [[Broadband Adapter]], NetGear FA311A recommendedby loaders
| S3-loader, Animal Crossing Loader
|-
! scope="row" | [[USBGecko]]
| Very slow and stutters
| Generally pretty stable if a game doesn't mind very slow loading times
| No
| [[USBGecko]]
| [[Swiss]]
|-
|}

[[Category:Howto]]

Talk:Cubeboot

2024-07-23T08:34:52Z

Lumina33: created page

The first sentence on this page feels like it could be made much shorter. --Lumina33 7/23/2024

Cubeboot

2024-07-23T08:32:30Z

Lumina33: linkify GC

{{Infobox/homebrew
| title = Cubeboot
| image = [[File:Cubeboot-custom-logo.png|center|thumb|235px]]
| type = Utility / IPL Replacement
| author = Offbroadway, 9ary, PlatypusWithCheese
| version = v0.1.4
| licence = [http://www.gnu.org/licenses/gpl-2.0.txt GNU GPL v2]
| website = https://flippydrive.com/
| download = https://github.com/OffBroadway/cubeboot/releases
| source = https://github.com/OffBroadway/cubeboot
}}

This project provides a program called '''Cubeboot''' which is able to play the [[GameCube]] boot animation. This is useful for some modchips like PicoBoot which skip the boot sequence. This project allows you to restore and customize the boot animation with custom colors and logos.

==Usage==
* [https://github.com/OffBroadway/cubeboot?tab=readme-ov-file#usage Cubeboot usage]

==Compatibility==

==Download==
* Binaries available [https://github.com/OffBroadway/cubeboot/releases here]
* Source via [https://github.com/OffBroadway/cubeboot/ github]

==Features==
Team OffBroadway is working with the [[Swiss]] team to import more features into Cubeboot. Stay tuned for more!

===General===
* Restore boot animation
* Loading an alternative IPL from an SD Card
* Support all NTSC and PAL IPL revisions
* Support booting SDGecko A/B and SD2SP2
* Flashable firmware image for picoboot
* Settings loaded from an SD Card
* Custom GameCube animation colors
* Random color each boot using RTC
* Custom Nintendo logo text replacement
* Force Progressive video modes

==Known Issues==
* Official issue tracker [https://github.com/OffBroadway/cubeboot/issues here]

[[Category:Homebrew_Software]]

GC-Linux with rootFS on SD

2024-07-23T08:25:53Z

Lumina33: linkify GC

=Introduction=
First of all I want to thank the people who made all this possible:

The guys from GC-Linux: http://www.gc-linux.org

Simon "Scorpei" van de Berg for his great tutorial how to build an SD-card adapter for the cube: http://ngc.scorpei.com/GUIDE-SD_adapter.html

The linuxwiki: http://linuxwiki.de

The creators of MFE: http://www.gc-linux.org/wiki/Mfe-distro

=The aim=
The aim of this Project is to create a custom Linux Kernel, which runs on a modified [[GameCube]] and has the root file system on an SD-card which is plugged into the memory-card slot via an [[SDGecko]].
After the system boots form the SD-card, it should start a custom program which allows the user to start programs using the GameCube-pad.

=Why?=
Normally the GC-Linux kernel will try to load the root file system from a NFS attached storage over the BBA.

However this isn't very practical because you need a broadband adapter for your GameCube, and you will always have to run an NFS-Share on your PC or a dedicated Server.
What I want is a stand-alone Linux on my GameCube! So why not create one by myself?

=Roadmap=
*Create & boot a Kernel with his root file system on an SD-Card [Done!]
*Create an auto executing script (init/linuxrc?) [Done!]
*Write an GameCube-pad controlled program [ToDo…]
*Enjoy your Linux-Cube!

=What you will need=
*Nintendo Gamecube
*Method to load homebrew
*An SD-Card (max. 2GB atm)
*[[SDGecko]] (See [5] or Buy)

==For Compiling it==
*Little knowledge about Linux Kernel
*A running Linux Distribution
*A running gc-linux tool chain + patched kernel source (2.6.32)
**See http://www.gc-linux.org/wiki/Building_a_GameCube_Linux_Kernel
**Clone my git for the Kernel: https://github.com/Nold360/GC-Linux-Kernel-2.6.32
**You may just want to use my config files:
cp .config linux-2.6.32/.config
cp gamecube.dts linux-2.6.32/arch/powerpc/boot/dts/gamecube.dts

=What should happen?=
After the GameCube boots, you will start the kernel.dol from the 1st partition of your SD-Card (fat formatted). The kernel will boot and mount the 2nd partition as his root (ext2/3 Formatted). Then will the Kernel look for his init-script and execute it.
In our Case we use the /bin/init script to configure the rest of the hardware (swap, mounting, etc.) and then start our script/program.

==The boot parameter==
The boot parameters were the first thing I edited. It’s defined in the
“arch/powerpc/boot/dts/gamecube.dts”-file. I edited it as follows:

chosen {
bootargs = "root=/dev/gcnsda2 rw video=gcn-vifb:tv=auto";
};

The “root=” parameter tells the kernel that his root is on “/dev/gcnsda2” that means the SD-Card (sd) that is plugged into the GameCube’s (gcn) MemoryCard-Slot1 (a) on Partition 2 (2) [Because the fist is used so SD-Load to execute the kernel.dol]
“rootwait” tells him to wait for his root file system until it’s ready.
The video parameter tells him which video device to use, and how.
In our case he uses the GameCube framebuffer (gcn-vifb), on a tv.
With the “auto” parameter, he will look for himself which mode to use. (NTFS, PAL50/60Hz…)

==Creating a Root file system==
After I could see that my kernel wants to use my SD-Card, I needed a root file system. Basically you don’t need really much, it’s just the normal root-tree (/dev /bin /etc /mnt /usr…) But because I’m a pretty lazy person, I just used a mix of the ramdisk and the file system of the MFE-Distribution and it worked pretty well. I just used my own /linuxrc and /bin/init-scripts. Also you need to add the SD-Card-Devicenodes to the /dev directory.
Please do not use the description from the gc-linux wiki [1]. There they were called “/dev/sdcarda” and “/dev/sdcardb” but they are called “/dev/gcnsda” and “/dev/gcnsdb”.

So we will add some nodes (as root):
mknod dev/gcnsda b 61 0
mknod dev/gcnsda1 b 61 1
mknod dev/gcnsda2 b 61 2
mknod dev/gcnsda3 b 61 3

mknod dev/gcnsdb b 61 8
mknod dev/gcnsdb1 b 61 9
mknod dev/gcnsdb2 b 61 10
mknod dev/gcnsdb3 b 61 11

We will also need one for Audio-RAM
mknod dev/aram b 37 0

I also added an 3rd SD-card partition, if we maybe want to use them later.

Last we add an mount path for the 1st SD-Card partition at /mnt/sdcarda, so we can mount it for later use.
# mkdir mnt/sdcarda

After that we need to create an fstab (/etc/fstab) to mount the cube’s Audio RAM as swap. 
Also we will add proc, root and our first SD-Card (vfat) Partition [Optional].
===/etc/fstab===
/dev/aram swap swap pri=32767 0 0
/dev/gcnsda2 / ext3 defaults,errors=remount-ro 0 0
/dev/gcnsda1 /mnt/gcnsda1 vfat defaults 0 0
proc /proc proc defaults 0 0

==The Init-Script==
So, the kernel boots, the filesystem looks great, what to do next?
We need to give our Kernel a init-script. As we didn’t gave the kernel the “init=/…” parameter, he will try to start the default script “/bin/init”.

A very important thing is that init is not allowed to die! So it has to run all the time.

But what has our system now to do?
We need:
*Format Audio-RAM as swap (mkswap)
*Mount fstab
*Activate swap
*Start our programs we need (mplayer, GUI, whatever)
*Keep init alive!

So let’s do that!
===/bin/init===
#!/bin/ash
mkswap /dev/aram
mount –a
swapon –a

#Now comes our script or whatever you want to execute
/linuxrc

#And keep init alive
while [ 1 –eq 1 ]; do
sleep 1
done

==Preparing the SD-Card==
First of all, we need to prepare our SD-Card partitions. We need a first partition formatted with fat (vfat) and a second partition for the root file system (ext2/3). 
How big they are depends on your SD-Card and for what additional use you want to use it. 
We need about 10MB For the kernel.dol plus the SDLOADER.BIN and about 20mb for the basic root file system. Since I want to extend the rootfs and maybe want to use other homebrew and kernel.dol’s I formatted it as follows (1GB SD):
*300MB vfat
*700MB ext2/3

I choose ext3 because I was first using ext2, but I had problems with destroyed libraries. So I switched to ext3 because it’s journaling. 
If you are ready to go, copy the file system onto the ext2/3 partition, and the GcImage.dol on the vfat partition.

===Preparing SD-Card with fdisk===
Partitioning with fdisk is pretty easy, i will do an example of how to do it using a 1GB SD-Card. Of course can you choose your partition sizes as you want.
Notice that the device path WILL be another on your system!
# fdisk /dev/mmcblk0 #Change to your device-path
> o #Create empty DOS Patition Table
> n #Create new Partition
> p #Primary
> [Enter] #At first sector
> +300M #with 300MB size, change to whatever you want for your "Homebrew"-Partition

That was our first partition that is going to be out vfat-homebrew partition, now comes the rootfs partition
> n #Create new Partition
> p #Primary
> [Enter] #At first useable sector (behind our vfat-partition)
> [Enter] #With maximum of size (Here: 700MB)
> w #Write everything to device
> q #Quit fdisk

Now we have our Partitions. But they need a filesystem. In this example we use mkfs for this task:
# mkfs.vfat /dev/mmcblk0p1 #Watch your path!
# mkfs.ext3 /dev/mmcblk0p2 #Same here!

Now you are ready to go. Copy GcImage.dol to the 1st Partition and the rootfs to the second.

=So what’s next?=
The next part is to include the software we need. This isn’t very problematic because we can use every binary which is compiled for a PowerPC! So what I did is that I downloaded my binaries and libraries from the Debian package-Service [3]. And used the libSDL and the mplayer binary from the mfe-distribution, since they were included in the filesystem. I just added the libraries for divx and mp3.

If you have an Broadband-Adapter in your Cube, you could even install apt-get and just download the packages directly on your cube! 
Another possibility for creating a big but good root file system would be the way from the GC-Linux wiki [4].

=Need Help? Got Ideas? Want to Help?=
Join the GC-Forever Community! :) [0]

=Links=
[0] http://nold.freeunix.net/devnull/index.php?show=./Stuff/Consoles/Gamecube/GameCube%20Linux 
[0] http://gc-forever.com 
[1] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Creating_the_SD.2FMMC_card_device_nodes 
[2] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Create_the_device_node_for_the_audio_RAM_driver 
[3] http://packages.debian.org 
[4] http://www.gc-linux.org/wiki/Creating_a_Root_Filesystem 
[5] http://ngc.scorpei.com/GUIDE-SD_adapter.html 

[[Category:Software]]

Hardware Acronyms

2024-07-23T07:48:24Z

Lumina33: XF=Transform Processor

== Gamecube hardware acronyms for CubeDocumented project ==

Documented by Andrei Shestakov (org). Version 1.1. (22 Jan 2006)
(original document hosted here: http://dolwin.emulation64.com/docs/acronyms.txt)

------------------------------------------------------------------------------

=== AA ===
Antialiasing. Rendering method, that makes polygon edges seem less sharpen,
combining colors of nearby pixels.

=== AD16 ===
Mysterious EXI device.

=== AI ===
Audio Interface. Hardware responsible for DMA playback of PCM buffer and
DVD ADPCM streaming sound. AI hardware cannot mix sound channels or set
channel volume for PCM DMA playback. These operations and more advanced
sound effects are produced by DSP.

=== [[Apploader]] ===
Small program on DVD to load main DOL executable.

=== AR, ARAM ===
Auxiliary (Audio) Memory. 16 MB of slow (comapred to RAM) DRAM.
Used for raw DSP sound data and as temporary space for textures.
ARAM has DMA communication channel with main memory (RAM). Development
boards has "ARAM Expansion" (additional 4, 16 or 32 MBs).

=== BAT ===
Block Address Translation, PPC MMU translation mechanism. There are DBAT
and IBAT special-purpose registers for data and instruction address
translation respectively.

=== BBA ===
Broad-Band Adapter, GC's 10BaseT Ethernet Adapter.

=== BS ===
Bootstrap Stage (from analogy with UNIX). Very first code, executed after
GC hard reset.

=== BS2 ===
Bootstrap Stage 2. Same as IPL.

=== CR ===
PPC Condition Register, stores result of integer comare operation, for
conditional branch decision.

=== CRT ===
C Run Time. C/C++ program environment (libraries and startup calls).

=== DOL ===
Gamecube application (custom executable file format).

=== Dolphin ===
Early development work name of Gamecube.

=== Dolphin OS ===
Gamecube OS. Single user, single process, multithreaded. Linked together
with any GC application ("hard-linked"), as library.

=== DSP ===
Digital Signal Processor. Used to produce advanced sound on GC.
DSP is integrated with GP in Flipper chip and has its own ROM.
Developed by Macronix.

=== DI, DVD ===
DVD hardware interface. GC DVD is actually microcontroller, based on MN-102
CPU with proprietary firmware ROM. DVD is protected by non-standard barcodes
and data encryption, which is decrypted on-the-fly by DVD controller. GC DVD
cannot be read on usual PC hardware. Whole GC DVD stuff is developed by
Matsushita.

=== EFB ===
Embedded Framebuffer. 2MB of fast 1T-SRAM memory located inside Flipper.
Used by GP's pixel engine to draw pixels. Later copied into XFB, for final
TV-output.

=== EXI ===
Expansion Interface. Gamecube peripherial devices bus, sort of USB
architecture. Developed by Macronix. Devices drived by EXI: memory cards,
broad-band adapter, real-time clock, bootrom, SRAM.

=== FIFO ===
First-In-First-Out buffer to send GP commands and create GP command lists.

=== Flipper ===
Gamecube Northbridge+Peripheral Hardware+Graphics Processor+Audio DSP.

=== FPR ===
Floating Point Register. Gekko has 32 64-bit FPRs, named f0-f31.

=== FPSCR ===
Floating Point Status and Control Register.

=== JTAG ===
Hardware debug interface to CPU. You can connect some wires to CPU pins,
to overwhelm it. Gekko has full support of IEEE 1149-1a-1993 JTAG standard.

=== GC, GCN, NGC ===
Nintendo Gamecube.

=== GCM ===
Gamecube Master Data (official term). GC DVD Image files.

=== Gekko ===
Gamecube CPU, PowerPC 750-derivative processor with FPU extensions, called
"Paired Single".

=== GP, GX ===
Graphics Processor, the major part of Flipper chip. GP is fixed point
state-machine. Developed by ArtX team.

=== GPR ===
General Purpose Register. Gekko has 32 32-bit GPRs, named r0-r31. r1 often
used as stack pointer (sp).

=== GX ===
Software library, developed by Nintendo and ArtX, to drive GP hardware.
Has many crossways with OpenGL (but more advanced).

=== HW2 ===
Common name of GC hardware. Number state for revision ("2" is production
board).

=== IPL ===
Initial Program Loader. Graphics shell, used to load game from DVD.

=== MC ===
Memory Card, EXI device.

=== MI ===
Flipper memory interface, plays role of "Nothbridge".

=== MMU ===
PPC Memory Management Unit. Translates virtual address to physical.
MMU has two translation mechanisms: block address translation and page table
translation. Address translation for data access and instruction fetch is
processed separately in DMMU and IMMU.

=== MSR ===
Machine State Register. CPU status and control register.

=== MX ===
Macronix Ltd. chips index. GC has many hardware parts, developed
by Macronix, like DSP, EXI and bootrom chip.

=== PC ===
Program Counter. PowerPC architecture does not define such term, but
everyone is using it anyway, instead "CIA" (Current Instruction Address).

=== PCM ===
Pulse Code Modulation, method commonly used in digital sound hardware.
PCM sound parameters are: playback rate, bits per sample, sample format.
GC AI can playback 32000/48000 Hz, 16-bit big-endian stereo samples via
DMA.

=== PI ===
Peripheral Interface. Set of hardware registers to control interrupts and
hardware reset. There also "PI FIFO": hardware-driven FIFO buffer in RAM.

=== PM ===
PowerPC Performance Monitor. Set of PPC special purpose registers used for
speed profiling of applications.

=== PPC ===
IBM PowerPC Architecture.

=== PTE ===
Page Table Entry. Page table record, used to translate virtual address to
physical.

=== RAM ===
Main memory. GC has 24 MB of fast 1T-SRAM. Development boards has RAM
extended up to 48 MB. Developed by MoSys.

=== ROM ===
Read-only memory. GC has following ROMs: 2 MB encrypted bootrom, 128 KB
DVD firmware, 4 KB DSP DROM, 8 KB DSP IROM.

=== RSW ===
"Reset Switch", same as reset button. Seems early development GC models
were equipped by switch, instead programmable reset button.

=== RTC ===
Real-time clock. EXI device, counting seconds since 00:00 AM 2000.

=== SDK ===
Software Development Kit. Full set of compilers, libraries and documentation
for development on specified platform. Gamecube SDK contain development tools,
like sound and texture convertors, and set of libraries for OS and hardware.
Compiler is provided by Metrowerk's CodeWarrior. There also huge development
board and paper documentation.

=== SI ===
Serial Interface. Hardware responsible for communication with serial devices,
such as GC controller and keyboard via serial I/O buffer.

=== SPR ===
Special-purpose register. Set of registers, dedicated to operating system.
Gekko has about 60 SPRs.

=== SR ===
Segment Registers, used by MMU for virtual address translation.

=== SRAM ===
Small amount of battery backuped memory for OS misc settings.

=== TLB ===
PPC MMU Translation Lookaside Buffer, used to keep recently used page
address translations. Gekko has 128 two-way set associative TLB for each
MMU (DMMU and IMMU).

=== VI ===
Video Interface. Hardware responsible for TV-out of framebuffer (XFB),
and generating VBlank interrupt (actually can be configured to interrupt
CPU at any beam location). Has support for light-gun, antialiasing of XFB
by tap-filters and progressive video mode (480p).

=== WBUF ===
Gekko Write Gather Buffer. Small cache for burst memory transactions.
Used together with graphics FIFO to send GP commands.

=== XF ===
Transform Processor

=== XFB ===
External Framebuffer, located in main memory. Used for final TV-out by VI.

[[Category:CubeDocumented]]
[[Category:Technical Info]]
[[Category:Reverse Engineering]]

GCLoader

2024-07-23T07:28:12Z

Lumina33: /* General information */ linkify GC

{{Infobox/modchip
| image = [[File:gcloader.png|200px|alt=GCLoader]]
| gen = drivereplace
| cpu = Spartan 6
| flash = 64Mbit onboard flash
| extstorage = SD Slot
| minstorage = 4GB SDHC
| maxstorage = 2TB SDXC
}}

== General information ==
'''GC Loader''' is [[GameCube]] DVD drive replacement that allows you boot homebrew and your existing library of games on DOL-001 and DOL-101 models. No longer do you need to worry about when your laser will burn out on your DVD drive. The GC Loader is a full replacement and acts exactly* like an original DVD drive but uses memory cards for its media.

*Some titles will load noticeably faster compared to the original DVD drive. GC Loader also has full audio streaming support.

Available for purchase from a US source [https://www.black-dog.tech/gc-loader-pnp-1.html here] and from a EU source [https://gc-loader.com/product/gc-loader-pnp-hw2/ here]

== Features ==
* DOL-001 and DOL-101 support
* Minimum SDHC 4GB to maximum SDXC 2TB (theoretical) supported SD cards
* Update via DOL file found on [https://github.com/danielkraak/GC-Loader/releases/ GitHub]
* Easily launch homebrew and your existing library of games.
* Installation is fast and simple (does require basic soldering skills)
* Full Audio Streaming Support.
* Swiss can read from it and launch games
* Faster loading times compared to original DVD drive.
* Firmware is updatable and a simple procedure

== Firmware ==
Firmware updates can be found [https://github.com/danielkraak/GC-Loader here].

{| border="3" align="center"
|-
! colspan="3" style="background:lightblue;font-size:10pt" width="1250"| GCLoader firmware
|-
! scope="row" style="background:lightgrey;font-size:10pt" width="200"| Version
! scope="row" style="background:lightgrey;font-size:10pt" width="800"| Release Notes
|-
! scope="row" width="200" | 0.9.0 beta
|
* Initial Release
|-
! scope="row" | 0.10.0 beta
|
* No SD card inserted boots to dashboard
|-
! scope="row" | 1.0.0 beta
|
* Fragmentation and multi disc fix.
|-
! scope="row" | 1.0.1
|
* Fixed some stability issues.
* Decreased FPGA boot time.
|}

== API ==

API is documented [https://github.com/danielkraak/GC-Loader/blob/master/API.md here].

== Notes ==
{| border="3" align="center"
|-
! colspan="2" style="background:lightblue;font-size:10pt" width="800"| GCLoader
|-
! scope="row" width="200" | Developers
| meneerbeer
|-
! scope="row" | CPU
| Xilinx Spartan 6 LX XC6SLX9 (HW1), Efinix Trion T20F256 + Espressif ESP32-WROOM-32E (HW2)
|-
! scope="row" | Modchip Type
| [[Drive Replacement Chip]]
|-
! scope="row" | Features
| [[Gamecube BIOS]]
|-
! scope="row" | Installation
| Flex cable or connector from existing drive
|-
|}

[[Category:Modchips]]

Modchip

2024-07-23T07:23:04Z

Lumina33: linkify GC

A '''modchip''' is any piece of hardware that must be physically installed into the [[GameCube]] to work. Modchips are generally used to assist in loading homebrew and backups.

== Generations of modchips ==
Modchips come in 3 main generations:
* [[IPL Replacement]]
* [[Drivechip]]
* [[Drive Replacement Chip]]

SDLoad

2024-07-23T07:22:42Z

Lumina33: linkify GC

'''SDLoad''' is an older way of loading homebrew onto the [[Nintendo Gamecube]], it was originally released in 2005 by Costis, and can be downloaded [http://gc-forever.com/forums/viewtopic.php?f=4&t=401 here].

This method of loading homebrew has mainly been superseded by the use of save-game exploits and mod-chips. However, it is still a functional way of enabling homebrew on a gamecube and unlike save game exploits does not initially require a Nintendo Wii or a previously homebrew enabled game cube to load a save-game exploit onto a memory card. Thus this guide can be followed by anybody who has only a gamecube, SD-card adapter with SD-card and a [https://www.datel.co.uk/ Datel] [[Action Replay]] to get homebrew running on their gamecube.

This guide requires the user to have some basic windows knowledge such as how to launch an administrative command prompt as well as format an SD-Card in the FAT16 filesystem and how to change directories (folders) in the command prompt, how to do this is not covered here but there are many guides already on the internet about how to do both.

== Requirements==

===Hardware===
* Nintendo Gamecube -> Any version / any region should work.
* Datel [[Action Replay]] (version 1.14 or below) -> Newer versions of action replay lack the user-code entry screen, if you cannot input codes your action replay disc is too new. The Japanese version of the Action Replay uses a different set of codes to the US / Europe version of the disc so be careful when you are choosing the codes on the code-input screen, the Japanese Pro Action Replay (Karat) disc is in Japanese so unless you have this disc (unlikely) then the standard code should work regardless of console region.
* PC with SD CARD Reader.
** Note: It is a common misconception that the bundled memory card is required for the action replay to work, this is not true, if your disc didn't come with a memory card simply insert any memory card that has some free space into slot 2 before booting the action replay disc and it will automatically create a code database file on the memory card.
* SD-Card adapter and SD-card -> The genuine SD-card adapter is long discontinued and commands high prices, you can buy pre-made adapaters like the Wiikey SD Gecko for a few dollars or make your own if you are handy with a soldering iron, there are diagrams online if you wish to try and build one.
* SD-Card: The card itself needs to be a NON SDHC card (i.e 2gb or less) and formatted as a FAT16 file system.
** Smaller SD Cards (sub 64mb) might format as FAT12, you can ensure a FAT16 format on such a card by using the command "format x: /FS: FAT /A:512" from a command prompt (where X: represents the drive letter of your SD card).

===Software===

Microsoft Windows -> Windows 2000 and later are supported.

sdload.zip -> There are two versions of the software, the original version works with Windows 2000 & XP, the later version which works with newer versions of Windows such as Vista / 7 / 8 / 10. Make sure you download the version appropriate for your system.

==Installation==

===Step 1 [Setting up the SD Card - Windows Vista / 7 / 8 / 10]===

This section is for users of Windows Vista / 7 / 8 / 10, if you are running an older OS such as XP or Windows 2000 skip to the Windows XP section.

1. Make sure your PC can access your SD-Card and that it has been freshly formatted as a FAT16 filesystem.

2. Download and extract the sdload.zip (Windows 10 supported version) to a folder on your computer. i.e "c:\sdload"

3. Copy the 2 files sdloader.bin and sdipdata.cfg to the root of your SD card (don't put them in a folder). You can also copy any other DOL (gamecube executable) files you wish to run from your SD Card as this time too, such as SWISS, CleanRip, GCOS, GCMM etc.

3. Open an administrator command prompt and navigate to the directory (folder) where you extracted sdload to, i.e "cd c:\sdload"

4. Run [[SDPatch|sdpatch]] without any parameters, i.e "sdpatch", the program will take a few seconds and report a list of connected drives to your computer. i.e.

Caption DeviceID Model Partitions Size
TOSHIBA THNSN9240GESG \\.\PHYSICALDRIVE0 TOSHIBA THNSN9240GESG 2 240054796800
Generic SDC SD Card \\.\PHYSICALDRIVE1 Generic SDC SD Card 1 8225280

Depending on if you are using a USB card reader or a built in card reader the device might show up as a generic USB device, if you are unsure unplug all external usb drives and memory sticks from the computer.

5. In the example above we can see the SD card is reported to the system as physical drive 1, depending on your system this could be 2 or 3 etc, be sure you are choosing the correct drive and run sdpatch but specify the number you wish to patch, i.e sdpatch 1

* The software will NOT let you pick drive 0 as this is usually the first installed hard disk but depending on your system and number of hard disks and how the machine is set up to boot it is possible to break your PC by patching the wrong drive if it is set up to boot in some weird way so pay extra care, you can always remove the SD card and run sdpatch again and see which drive disappears from the list to make extra sure.

The program will run and if all went OK it will report that your SD Card is now patched, before removing it from the system double check in file explorer that you are still able to see the files you copied earlier

6. Put the SD-Card into the SD-Card adapter and install it into slot 1, make sure you have a memory card installed in slot 2 and boot up the gamecube and begin the sdload code entry sequence.

===Step 1 [Setting up the SD Card - Windows XP / 2000]===

This section is for users of Windows XP & 2000, if you are running an newer OS such as Windows 7 or 10 then please follow the section above.

1. Make sure your PC can access your SD-Card and that it has been freshly formatted as a FAT16 filesystem.

2. Download and extract the sdload.zip (original windows XP version) to a folder on your computer. i.e "c:\sdload"

3. Copy the 2 files sdloader.bin and sdipdata.cfg to the root of your SD card (don't put them in a folder). You can also copy any other DOL (gamecube executable) files you wish to run from your SD Card as this time too, such as SWISS, CleanRip, GCOS, GCMM etc. Make a note of what drive your SD card is too, i.e E:

3. Open an administrator command prompt and navigate to the directory (folder) where you extracted sdload to, i.e "cd c:\sdload"

4. Run sdpatch x: where x: represents your SD-Card i.e: sdpatch E:

5. The program will run and if all went OK it will report that your SD Card is now patched, before removing it from the system double check in file explorer that you are still able to see the files you copied earlier.

* The software will NOT let you pick a non removable drive but depending on your system setup it might be possible to somehow patch an incorrect drive and stop your PC from booting up so take extra care when writing in the letter of your SD Card.

The program will run and if all went OK it will report that your SD Card is now patched, before removing it from the system double check in file explorer that you are still able to see the files you copied earlier

6. Put the SD-Card into the SD-Card adapter and install it into slot 1, make sure you have a memory card installed in slot 2 and boot up the gamecube and begin the sdload code entry sequence.

===Step 2 [Action Replay Code Entry]===

Providing you have patched your SD Card and copied the appropriate files to it the last step is to create a custom code in the Action Replay to boot up SD Loader, this is a long code and will take around 15 minutes to enter, fortunately it only has to be done once so take your time and verify that all codes have been typed correctly.

1. Select "Action Replay Codes"
2. Select the USA flag (This applies regardless of PAL / NTSC gamecube).
3. Select "Add New Game", call it SDLOAD (use all capital lettters) and push the done key.
4. Enter (m) as the code name (use a small m and use the CAPS button to find the brackets) and push the done key.
5. Enter the following 3 codes, pushing done after each code, once you have entered the final code just push done for a second time and you should get an "updating action replay hardware" message while the codes are saved.

(m)
1: 7YPR-RKZZ-MH6W5
2: D26A-PE4J-1XX2W
3: ZJHY-B1ZH-6P00G

6. You should now see SDLOAD and Add New Code (your (m) should be visible in green too). Select add new code and this time call the code SDLOAD (all capitals) and like before input the following code, this code is 29 lines so double check before pushing done.

(SDLOAD)
1: AF4H-JPF5-H1B5J
2: MVAB-7TQE-ABZPB
3: V2CK-QQ1A-Y6P72
4: M5N6-CMMH-9EURT
5: 0JFM-3A6C-VZ6VK
6: KYV8-0JGV-0GR1N
7: 2EGU-HVKF-NDMCN
8: 7AH0-J9JZ-HHGNJ
9: 4MHU-G8XT-ZRYCJ
10: 9474-KF41-8KG34
11: QMEV-G90N-A8RV0
12: KD4G-5QHV-74D46
13: V97K-652Q-Y4TEY
14: 6M4W-9GPT-E99NG
15: QPFY-DJAF-E01FV
16: 2Z6E-P2WY-24WV4
17: 6NHW-G3NH-HP31Y
18: A2KF-MCKN-D645J
19: K5V8-EF9W-7GFQC
20: XTU3-269T-VH5NE
21: H9GP-C4PP-6FGF9
22: HF77-R45C-ZXPDV
23: 22Y3-D98C-50AJM
24: WTWZ-EC88-U5ZTV
25: 36G1-UGDG-J2G84
26: DUMT-15KR-DXJ8K
27: JV55-6VF5-2Z02T
28: D4R8-MVJ5-QGR21
29: 1G3C-APD7-1CUVD

7: Select the code SDLOAD and press A to enable it (the code should get a checkbox) and press B to return to the main menu. Some versions of the Action Replay are buggy and disable newly entered codes after a reboot so it is a good idea to browse to the options menu, select update hardware then reboot the system and verify that your SDLOAD code is enabled. To do this after a reboot pick Action Replay Codes, SDLOAD should already be selected, select it with A and make sure the SDLOAD code has a check-mark in it. Press B twice to go back to the main menu and press Start Game, open and close the lid (leaving the action replay disc is fine.) and if all went well after a few seconds you should see the SDLoad screen where you can pick any DOL you wish to run.

===Step 3 [Post Installation & Troubleshooting]===

Congratulations, if all went well you should be looking at the SDLoad screen and can launch any DOL of your choice. If you have a spare memory card you can use a tool like GCMM to clone your memory card with the Action Replay SDload code on it to another memory card in case of corruption or deletion, this will save you having to input the code again should it get erased. I like to verify that my cloned memory card works by testing it with the Action Replay, some copy tools will copy the Action Replay file across ok but the Action Replay won't recognize the file, you will know if it copied OK as SDLOAD will be the default selected game.

If you didn't get to see the SDload screen then verify the steps above, is your SD Card 2gb or under and non HC? is it formatted as FAT16 and patched with the patch utility? Have you copied the sdloader.bin and the .cfg files to it in the proper place?

If you made your own adapter check the wiring and connections, if you are using a bought adapter some of them are of low quality so try verifying the SD Card is making good contact and the adapter is making good contact with the gamecube memory card slot.

==[Note for users of the Japanese Pro Action Replay]==

This code is only for those using the Karat branded Pro Action Replay sold in Japan. (it is unlikely but you never know) I'm not sure if this is a datel knock off or sold under licence but it looks very similar apart from all the menus being in Japanese, if your Action Replay is NOT in Japanese then don't use this code or else it won't work. If your Action Replay is the Japanese version then when you come to the code entry sequence use the following codes instead of those above.

(m)
1: Q1NP-P0FY-7P4NA
2: D26A-PE4J-1XX2W
3: ZJHY-B1ZH-6P00G

SDLOAD
1: 9N5B-081B-HF6E3
2: MVAB-7TQE-ABZPB
3: V2CK-QQ1A-Y6P72
4: M5N6-CMMH-9EURT
5: 0JFM-3A6C-VZ6VK
6: KYV8-0JGV-0GR1N
7: 2EGU-HVKF-NDMCN
8: 7AH0-J9JZ-HHGNJ
9: 4MHU-G8XT-ZRYCJ
10: 9474-KF41-8KG34
11: QMEV-G90N-A8RV0
12: KD4G-5QHV-74D46
13: V97K-652Q-Y4TEY
14: 6M4W-9GPT-E99NG
15: QPFY-DJAF-E01FV
16: 2Z6E-P2WY-24WV4
17: 6NHW-G3NH-HP31Y
18: A2KF-MCKN-D645J
19: K5V8-EF9W-7GFQC
20: XTU3-269T-VH5NE
21: H9GP-C4PP-6FGF9
22: HF77-R45C-ZXPDV
23: 22Y3-D98C-50AJM
24: WTWZ-EC88-U5ZTV
25: 36G1-UGDG-J2G84
26: DUMT-15KR-DXJ8K
27: JV55-6VF5-2Z02T
28: D4R8-MVJ5-QGR21
29: 1G3C-APD7-1CUVD

FlippyDrive

2024-07-23T07:22:05Z

Lumina33: /* General information */ capitalize & link gamecube

{{Infobox/modchip
| image = [[File:Flippydrive.jpg|200px|alt=FlippyDrive]]
| gen = drivereplace
| Microprocessor = rp2040, esp32
| flash = 16MB onboard flash
| extstorage = MicroSD Slot
| minstorage = 2GB SDHC
| maxstorage = 2TB SDXC
}}

== General information ==
The '''Flippydrive''' is an optical disc drive emulator for the [[Gamecube]] that installs without any soldering, can be used with or without a disk drive, and fits neatly inside the cube itself with no case modifications preserving the appearance of the system.

Loads disk images via:

* uSD card (1TB+ supported)
* Experimental Wi-Fi loading
* 16MB internal flash
* Ethernet (future add-on module)

Other major features include:

* No-solder install
* Use with or without OEM drive
* 2.8x-10x faster than all EXI devices (SD2SP2, BBA, any memory card/SP1/SP2 device, etc.) in non-WiFi mode
* Real drive interface, no software hacks required
* One-button disk passthrough
* OTA software updates
* Rescue USB port for brick recovery
* No disk drives are scrapped to make this mod
* Compatible with Cubeboot menu patcher

== Purchase and Installation ==
Pre-Order Notification Signup is currently available worldwide on the [https://flippydrive.com/ project homepage]
Installation video [https://www.youtube.com/watch?v=YPq48Wm8y-U here]

== Firmware ==
Firmware updates can be found [https://github.com/OffBroadway/flippydrive here].

{| border="3" align="center"
|-
! colspan="3" style="background:lightblue;font-size:10pt" width="1250"| FlippyDrive Firmware
|-
! scope="row" style="background:lightgrey;font-size:10pt" width="200"| Version
! scope="row" style="background:lightgrey;font-size:10pt" width="800"| Release Notes
|-
! scope="row" | 1.0.0
|
* Initial release
|}

== Notes ==
{| border="3" align="center"
|-
! colspan="2" style="background:lightblue;font-size:10pt" width="800"| FlippyDrive
|-
! scope="row" width="200" | Developers
| [https://github.com/OffBroadway Team OffBroadway]
|-
! scope="row" | CPU
| RP2040 32-bit dual ARM Cortex-M0+ (Microcontroller 1), ESP32 (Microcontroller 2)
''note: esp32 handles all file access for SD/WiFi etc while the RP2040 handles the GC communication and firmware updates''
|-
! scope="row" | Modchip Type
| [[Drive Replacement Chip]]
|-
! scope="row" | Features
| Compatibility with [[Cubeboot]] menu injection program for the [[Gamecube BIOS]]
|-
! scope="row" | Installation
| Connector from existing drive [https://www.youtube.com/watch?v=YPq48Wm8y-U tutorial]
|-
|}

[[Category:Modchips]]

[[See also:]]
[[Cubeboot]]

Hugo GX

2024-07-23T07:21:31Z

Lumina33: linkify GC

{{Infobox/homebrew
| title = Hugo GX
| image = [[File:HugoGX.png]]
| author = EkeEke
| type = Emulator
| version = 2.12 Official 2.12.1 Unofficial
| licence = [http://www.gnu.org/licenses/gpl-2.0.txt GNU GPL v2]
| website = http://code.google.com/p/hugo-gx
| download = http://code.google.com/p/hugo-gx/downloads/list
| source = http://code.google.com/p/hugo-gx/source/checkout
}}
'''Hu-Go!''' GC is a PC Engine / TurboGrafx-16 emulator ported to the [[Nintendo GameCube]]. 
Official support has ceased and the last official build was released June 2010.

In February 2013, an unofficial GameCube version was released ( version 2.13 ) which fixed previous compiling issues causing black screen / crash after loading a rom file. This release also included fixes to add SDHC support, fixed Rapid Fire buttons feature (X Y), re-enabled the "stop DVD motor" feature, and small GUI changes.

[[Category:Homebrew_Software]]

XenoGC

2024-07-23T07:21:06Z

Lumina33: /* Overview */ linkify GC

{{Infobox/modchip
| image = [[File:Xeno.jpeg|200px|alt=XenoLogo]]
| gen = drivechip
| source = http://www.gc-forever.com/forums/viewtopic.php?f=15&t=439
| forksource = https://github.com/emukidid/xenogcfork
}}

==Overview==
The '''XenoGC''' is a drivechip for the [[Nintendo Gamecube]]. It is installed directly to the optical drive's logic board and injects patch code into the drive at run time. This enables the execution of debug commands and reading of DVD+/-R/RW media. The original project name of the modchip was Qoob Lite (subsequently discovered in the source code).

==Versions==
The XenoGC is available in two variants. Version 2.0 (displayed as 1.5) includes support for multi-game discs, while Version 1.0 does not. Version 1.0 has a Green LED to indicate that the drive has been patched successfully, whereas Version 2.0 has an orange LED. As the XenoGC is now effectively an open source modchip, certain clones will defy these color conventions.

==Features==
* Direct boot of DVD+-RW media
* Compatible with all regions & all versions
* Region-free game loading
* Wireless installation
* Removal of motherboard not required
* PAL/NTSC region force
* Status LEDs
* Switchable read setting adjustment & error retry
* Switchable audiofix
* Anti-static packaging
* Extremely low cost

==Settings==
===General Info===
You can adjust a few settings by holding various buttons on controller one while booting a game. This means from just before and during the black screen as the boot menu disappears and the game launches. Settings are applied on a per-boot basis and do not permanently alter the behavior of the console.

===[L button] Disable audiofix===
If you have previously modified your backup images to work with a BIOS that did not have proper support for audio streaming, this setting will disable that modification.

===[R button] Disable DREfix===
Disables the native read adjustment and retries. This may be useful if you wish to scan a disc for read errors. The XenoGC will not attempt to correct any errors and will use the default read settings.

===[X/Y button] Force NTSC/PAL display mode===
This will force the selected region's display mode regardless of the actual game region. Some games are not compatible with this setting.

===[START button] Version display===
* On a Version 1.0 XenoGC, this displays basic version information (modchip, console and drive).
* On a Version 2.0 XenoGC, this displays the XenoShell in PAL50 (bug?) and is only useful for running multi-game discs (not multi-disc games).

===Status LEDs===
The XenoGC features two status LEDs to indicate correct function. The red LED is active when the drive resets and the modchip is doing its job. Once the drive has been patched successfully, the green (orange on XenoGC2.0 and certain clones) LED will illuminate. If only the red LED illuminates, check your installation. It should be noted however that some XenoGC clones may only have red LEDs to indicate functionality, if this is the case check to see how many times the LED blinks on and off. If the LED blinks twice, pauses, and stays on afterwards than the installation and patching was successful.

==Troubleshooting Installation==
The XenoGC doesn't offer much in terms of diagnostics, however there are a number of ways to determine how well it is working. Ideally, you should see a red LED illuminate on the XenoGC when the console turns on and then a green (Version 1.0) or orange (Version 2.0) LED when the drive has been patched successfully. If none of the LEDs on the XenoGC illuminate, then check your solder joints and consider removing it in favor of a wired installation instead.

The following steps should be performed after the XenoGC has been installed and performed in order. If the first step fails, so will those which follow.
# Start the console with an original disc in the drive and the lid closed, don't press anything, if it works, great, the laser isn't dead. Alternatively try [[Laser_Tuning|tuning the laser]] and trying this step again.
# Hold the Start button down in controller 1, start the console with an original disc in the drive and hold start until the game is supposed to load. If the game doesn't load and a menu (v2+) or credits screen (v1) loads up the XenoGC is working properly. Alternatively try to run a disc for another region if you have no controller.
# Start the console with a copy of the [https://github.com/emukidid/swiss-gc/releases/latest Swiss ISO] or something known to work, use Ritek G05 discs (probably near impossible to get now) or something decent with a dark dye, it seems to work better. If the disc boots then everything works, if it doesn't, tune the laser and go through Step 3 again until it does.

==Firmware Updates==
Two official versions of software exist which were only available pre-installed at time of purchase. Since the release of the source code, a XenoGC Flashing Utility has been discovered which will enable the user to upgrade and/or downgrade the XenoGC software using the appropriate flashing utility version. In order to prepare the XenoGC to allow flashing, a switch must be installed between GND and any of the letters 'X E N O' which can be found on the circuit board.

==Source Code==
In February 2011 the source code was made publicly available at [http://www.gc-forever.com/forums/viewtopic.php?f=15&t=439 GC-Forever]

==DIY XenoGC Clone==
Information on making a XenoGC Clone or to understand how to modify an actual XenoGC for flashing can be found [http://www.gc-forever.com/wiki/index.php?title=XenoGC_Clone HERE]

{| border="3" align="center"
|-
! colspan="2" style="background:lightblue;font-size:10pt" width="800"| XenoGC
|-
! scope="row" width="200" | Developers
|
|-
! scope="row" | CPU
| Atmel Atmega8L
|-
! scope="row" | Modchip Type
| [[Drivechip]]
|-
! scope="row" | Features
| [[Gamecube BIOS]]
|-
! scope="row" | Installation
| 0 wires (optional 6 wires)
|-
|}

[[Category:Modchips]]

NinjaMod

2024-07-23T07:20:28Z

Lumina33: linkify GC

{{Infobox/modchip
|image = [[File:NinjaMod.png|200px|alt=NinjaMod Modchip]]
|gen = ipl
|flash = 2Mb (16MBit)
}}

The '''NinjaMod''' is a commercially produced [[IPL Replacement]] based on open source design by tmbinc for the [[Nintendo Gamecube]].

==Controversy==
The software BIOS which the Ninjamod was sold with was a copy of GCOS version 1.4 with a different backdrop and re-labelled "NinjaShell". Controversy arose when the open sourced GCOS v1.4 code was re-labelled and made closed source and sold as the modchip BIOS since this broke the GPL conventions.

==Features==
* Direct No-Swap Boot of All Media
* Support for all regions (PAL, USA and Japan).
* 16Mbit flash memory for application storage.
* DVD +-R Compatible
* Create Backups to PC via network connection (Requires BBA adapter)
* Boot Homebrew via network connection (Requires BBA adapter)
* Supports BIOS Update via DVD or via network connection (Requires BBA adapter)
* Only 7 wires to solder
* Includes 2 different BIOS Banks ( Bank 1 = Ninja Shell, Bank 2 = User Programmable )

{| border="3" align="center"
|-
! colspan="2" style="background:lightblue;font-size:10pt" width="800"| NINJAMOD
|-
! scope="row" width="200" | Developers
| Ninja Mod Team
|-
! scope="row" | CPU
| Lattice iM4A5-128/64
|-
! scope="row" | Modchip Type
| [[IPL Replacement]]
|-
! scope="row" | Features
| [[Gamecube BIOS]]
|-
! scope="row" | Installation
| 7 wires
|-
|}

[[Category:Modchips]]

IPL Replacement

2024-07-23T07:19:22Z

Lumina33: YT video name

[[File:Iplmaskrom.jpg|right|thumb|235px|The original RTC/IPL Mask ROM IC on the Gamecube Mainboard]]

'''IPL Replacements''' were the first [[modchip]]s for the [[GameCube]]. Basically, the Mask ROM which contains the IPL could be overridden to load unsigned code from a separate flash chip on the EXI bus.

Technical details on the replacement can be found in [http://gc-forever.com/yagcd/chap2.html#sec2.8.3 YAGCD Section 2.8.3]

Many IPL Replacements also replaced the disc drive firmware by sending a "sudo password" from the Gekko, namely <code>MATSHITA DVD-GAME</code>.<ref>23C3: Console Hacking 2006. https://youtube.com/watch?v=xlSOAsLSYzE</ref> These DVD-compatibility IPL Replacements were succeeded by [[drivechip]]s.

==IPL Replacements==
Several modchips existed which were full IPL Replacements, but the [[Qoob]] and the [[Viper GC]] were the most popular.

Full list:
*tmbinc's original IPL replacement
*[[Viper GC]]
*[[Ripper 3]]
*[[Ninjamod]] (rip off of tmbinc's work running [[GCOS]])
*[[Qoob]]
*[http://www.retro-system.com/shuriken_attack.htm Shuriken Attack]
*[[HyperBoot]]
*[https://github.com/webhdx/PicoBoot PicoBoot]

== References ==
<references />

[[Category:Modchip Types]]

GameCube

2024-07-23T07:16:35Z

Lumina33: created page

#redirect [[Nintendo GameCube]]

IPL Replacement

2024-07-23T07:16:25Z

Lumina33: linkify GC

[[File:Iplmaskrom.jpg|right|thumb|235px|The original RTC/IPL Mask ROM IC on the Gamecube Mainboard]]

'''IPL Replacements''' were the first [[modchip]]s for the [[GameCube]]. Basically, the Mask ROM which contains the IPL could be overridden to load unsigned code from a separate flash chip on the EXI bus.

Technical details on the replacement can be found in [http://gc-forever.com/yagcd/chap2.html#sec2.8.3 YAGCD Section 2.8.3]

Many IPL Replacements also replaced the disc drive firmware by sending a "sudo password" from the Gekko, namely <code>MATSHITA DVD-GAME</code>.<ref>https://youtube.com/watch?v=xlSOAsLSYzE</ref> These DVD-compatibility IPL Replacements were succeeded by [[drivechip]]s.

==IPL Replacements==
Several modchips existed which were full IPL Replacements, but the [[Qoob]] and the [[Viper GC]] were the most popular.

Full list:
*tmbinc's original IPL replacement
*[[Viper GC]]
*[[Ripper 3]]
*[[Ninjamod]] (rip off of tmbinc's work running [[GCOS]])
*[[Qoob]]
*[http://www.retro-system.com/shuriken_attack.htm Shuriken Attack]
*[[HyperBoot]]
*[https://github.com/webhdx/PicoBoot PicoBoot]

== References ==
<references />

[[Category:Modchip Types]]

Gamecube

2024-07-23T07:14:22Z

Lumina33: created page

#redirect [[Nintendo GameCube]]

Playing Imports

2024-07-23T07:14:06Z

Lumina33: linkify GC

The [[Gamecube]] utilized a regional lockout protection which was governed by the IPL ROM ([[WikiScene:GameCube#GameCube_Original_BIOS_.28IPL.29_Version_Information|Gamecube "BIOS"]]) to prevent the console from playing out-of-region titles('''imports'''). 

Since the hardware is mostly 100% identical across all regions (apart from NTSC/PAL hardware differences for video output), several universal methods exist which can bypass the lockout protection. These methods include:
* [[Region Switch]] - NTSC-U '''&''' NTSC-J only hardware mod to allow NTSC-U models to play Japanese titles, or vice versa.
* [[Freeloader]] - Bootdisc based solution for original titles without modifying the Gamecube.
* [[:Category:Modchips|Modchip]] - Hardware based solution installed to the Gamecube.
* Homebrew - Particularly [[Swiss]], this will allow imports from all regions to be played.

----

{| border="3" align="center"
|-
! colspan="1" style="background:lightblue;font-size:10pt" width="200"| Gamecube Regions
! colspan="1" style="background:lightblue;font-size:10pt" width="300"| Region Lock Bypass Methods
|-
| style="text-align: center;" | '''NTSC-U''' ( USA )
| style="text-align: center;" | [[Region Switch]] for NTSC-J [[Freeloader]] [[:Category:Modchips|Modchip]] Homebrew
|-
| style="text-align: center;" | '''NTSC-J''' ( Japan )
| style="text-align: center;" | [[Region Switch]] for NTSC-U [[Freeloader]] [[:Category:Modchips|Modchip]] Homebrew
|-
| style="text-align: center;" | '''PAL''' ( Europe & Australia )
| style="text-align: center;" | [[Freeloader]] [[:Category:Modchips|Modchip]] Homebrew
|-
|}
[[Category:Howto]]
[[Category:Modchips]]

GC-Linux with rootFS on SD

2024-07-23T07:07:51Z

Lumina33: /* For Compiling it */ ws

=Introduction=
First of all I want to thank the people who made all this possible:

The guys from GC-Linux: http://www.gc-linux.org

Simon "Scorpei" van de Berg for his great tutorial how to build an SD-card adapter for the cube: http://ngc.scorpei.com/GUIDE-SD_adapter.html

The linuxwiki: http://linuxwiki.de

The creators of MFE: http://www.gc-linux.org/wiki/Mfe-distro

=The aim=
The aim of this Project is to create a custom Linux Kernel, which runs on a modified GameCube and has the root file system on an SD-card which is plugged into the memory-card slot via an [[SDGecko]].
After the system boots form the SD-card, it should start a custom program which allows the user to start programs using the GameCube-pad.

=Why?=
Normally the GC-Linux kernel will try to load the root file system from a NFS attached storage over the BBA.

However this isn't very practical because you need a broadband adapter for your GameCube, and you will always have to run an NFS-Share on your PC or a dedicated Server.
What I want is a stand-alone Linux on my GameCube! So why not create one by myself?

=Roadmap=
*Create & boot a Kernel with his root file system on an SD-Card [Done!]
*Create an auto executing script (init/linuxrc?) [Done!]
*Write an GameCube-pad controlled program [ToDo…]
*Enjoy your Linux-Cube!

=What you will need=
*Nintendo Gamecube
*Method to load homebrew
*An SD-Card (max. 2GB atm)
*[[SDGecko]] (See [5] or Buy)

==For Compiling it==
*Little knowledge about Linux Kernel
*A running Linux Distribution
*A running gc-linux tool chain + patched kernel source (2.6.32)
**See http://www.gc-linux.org/wiki/Building_a_GameCube_Linux_Kernel
**Clone my git for the Kernel: https://github.com/Nold360/GC-Linux-Kernel-2.6.32
**You may just want to use my config files:
cp .config linux-2.6.32/.config
cp gamecube.dts linux-2.6.32/arch/powerpc/boot/dts/gamecube.dts

=What should happen?=
After the GameCube boots, you will start the kernel.dol from the 1st partition of your SD-Card (fat formatted). The kernel will boot and mount the 2nd partition as his root (ext2/3 Formatted). Then will the Kernel look for his init-script and execute it.
In our Case we use the /bin/init script to configure the rest of the hardware (swap, mounting, etc.) and then start our script/program.

==The boot parameter==
The boot parameters were the first thing I edited. It’s defined in the
“arch/powerpc/boot/dts/gamecube.dts”-file. I edited it as follows:

chosen {
bootargs = "root=/dev/gcnsda2 rw video=gcn-vifb:tv=auto";
};

The “root=” parameter tells the kernel that his root is on “/dev/gcnsda2” that means the SD-Card (sd) that is plugged into the GameCube’s (gcn) MemoryCard-Slot1 (a) on Partition 2 (2) [Because the fist is used so SD-Load to execute the kernel.dol]
“rootwait” tells him to wait for his root file system until it’s ready.
The video parameter tells him which video device to use, and how.
In our case he uses the GameCube framebuffer (gcn-vifb), on a tv.
With the “auto” parameter, he will look for himself which mode to use. (NTFS, PAL50/60Hz…)

==Creating a Root file system==
After I could see that my kernel wants to use my SD-Card, I needed a root file system. Basically you don’t need really much, it’s just the normal root-tree (/dev /bin /etc /mnt /usr…) But because I’m a pretty lazy person, I just used a mix of the ramdisk and the file system of the MFE-Distribution and it worked pretty well. I just used my own /linuxrc and /bin/init-scripts. Also you need to add the SD-Card-Devicenodes to the /dev directory.
Please do not use the description from the gc-linux wiki [1]. There they were called “/dev/sdcarda” and “/dev/sdcardb” but they are called “/dev/gcnsda” and “/dev/gcnsdb”.

So we will add some nodes (as root):
mknod dev/gcnsda b 61 0
mknod dev/gcnsda1 b 61 1
mknod dev/gcnsda2 b 61 2
mknod dev/gcnsda3 b 61 3

mknod dev/gcnsdb b 61 8
mknod dev/gcnsdb1 b 61 9
mknod dev/gcnsdb2 b 61 10
mknod dev/gcnsdb3 b 61 11

We will also need one for Audio-RAM
mknod dev/aram b 37 0

I also added an 3rd SD-card partition, if we maybe want to use them later.

Last we add an mount path for the 1st SD-Card partition at /mnt/sdcarda, so we can mount it for later use.
# mkdir mnt/sdcarda

After that we need to create an fstab (/etc/fstab) to mount the cube’s Audio RAM as swap. 
Also we will add proc, root and our first SD-Card (vfat) Partition [Optional].
===/etc/fstab===
/dev/aram swap swap pri=32767 0 0
/dev/gcnsda2 / ext3 defaults,errors=remount-ro 0 0
/dev/gcnsda1 /mnt/gcnsda1 vfat defaults 0 0
proc /proc proc defaults 0 0

==The Init-Script==
So, the kernel boots, the filesystem looks great, what to do next?
We need to give our Kernel a init-script. As we didn’t gave the kernel the “init=/…” parameter, he will try to start the default script “/bin/init”.

A very important thing is that init is not allowed to die! So it has to run all the time.

But what has our system now to do?
We need:
*Format Audio-RAM as swap (mkswap)
*Mount fstab
*Activate swap
*Start our programs we need (mplayer, GUI, whatever)
*Keep init alive!

So let’s do that!
===/bin/init===
#!/bin/ash
mkswap /dev/aram
mount –a
swapon –a

#Now comes our script or whatever you want to execute
/linuxrc

#And keep init alive
while [ 1 –eq 1 ]; do
sleep 1
done

==Preparing the SD-Card==
First of all, we need to prepare our SD-Card partitions. We need a first partition formatted with fat (vfat) and a second partition for the root file system (ext2/3). 
How big they are depends on your SD-Card and for what additional use you want to use it. 
We need about 10MB For the kernel.dol plus the SDLOADER.BIN and about 20mb for the basic root file system. Since I want to extend the rootfs and maybe want to use other homebrew and kernel.dol’s I formatted it as follows (1GB SD):
*300MB vfat
*700MB ext2/3

I choose ext3 because I was first using ext2, but I had problems with destroyed libraries. So I switched to ext3 because it’s journaling. 
If you are ready to go, copy the file system onto the ext2/3 partition, and the GcImage.dol on the vfat partition.

===Preparing SD-Card with fdisk===
Partitioning with fdisk is pretty easy, i will do an example of how to do it using a 1GB SD-Card. Of course can you choose your partition sizes as you want.
Notice that the device path WILL be another on your system!
# fdisk /dev/mmcblk0 #Change to your device-path
> o #Create empty DOS Patition Table
> n #Create new Partition
> p #Primary
> [Enter] #At first sector
> +300M #with 300MB size, change to whatever you want for your "Homebrew"-Partition

That was our first partition that is going to be out vfat-homebrew partition, now comes the rootfs partition
> n #Create new Partition
> p #Primary
> [Enter] #At first useable sector (behind our vfat-partition)
> [Enter] #With maximum of size (Here: 700MB)
> w #Write everything to device
> q #Quit fdisk

Now we have our Partitions. But they need a filesystem. In this example we use mkfs for this task:
# mkfs.vfat /dev/mmcblk0p1 #Watch your path!
# mkfs.ext3 /dev/mmcblk0p2 #Same here!

Now you are ready to go. Copy GcImage.dol to the 1st Partition and the rootfs to the second.

=So what’s next?=
The next part is to include the software we need. This isn’t very problematic because we can use every binary which is compiled for a PowerPC! So what I did is that I downloaded my binaries and libraries from the Debian package-Service [3]. And used the libSDL and the mplayer binary from the mfe-distribution, since they were included in the filesystem. I just added the libraries for divx and mp3.

If you have an Broadband-Adapter in your Cube, you could even install apt-get and just download the packages directly on your cube! 
Another possibility for creating a big but good root file system would be the way from the GC-Linux wiki [4].

=Need Help? Got Ideas? Want to Help?=
Join the GC-Forever Community! :) [0]

=Links=
[0] http://nold.freeunix.net/devnull/index.php?show=./Stuff/Consoles/Gamecube/GameCube%20Linux 
[0] http://gc-forever.com 
[1] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Creating_the_SD.2FMMC_card_device_nodes 
[2] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Create_the_device_node_for_the_audio_RAM_driver 
[3] http://packages.debian.org 
[4] http://www.gc-linux.org/wiki/Creating_a_Root_Filesystem 
[5] http://ngc.scorpei.com/GUIDE-SD_adapter.html 

[[Category:Software]]

GC-Linux with rootFS on SD

2024-07-23T07:07:29Z

Lumina33: /* Introduction */ ws

=Introduction=
First of all I want to thank the people who made all this possible:

The guys from GC-Linux: http://www.gc-linux.org

Simon "Scorpei" van de Berg for his great tutorial how to build an SD-card adapter for the cube: http://ngc.scorpei.com/GUIDE-SD_adapter.html

The linuxwiki: http://linuxwiki.de

The creators of MFE: http://www.gc-linux.org/wiki/Mfe-distro

=The aim=
The aim of this Project is to create a custom Linux Kernel, which runs on a modified GameCube and has the root file system on an SD-card which is plugged into the memory-card slot via an [[SDGecko]].
After the system boots form the SD-card, it should start a custom program which allows the user to start programs using the GameCube-pad.

=Why?=
Normally the GC-Linux kernel will try to load the root file system from a NFS attached storage over the BBA.

However this isn't very practical because you need a broadband adapter for your GameCube, and you will always have to run an NFS-Share on your PC or a dedicated Server.
What I want is a stand-alone Linux on my GameCube! So why not create one by myself?

=Roadmap=
*Create & boot a Kernel with his root file system on an SD-Card [Done!]
*Create an auto executing script (init/linuxrc?) [Done!]
*Write an GameCube-pad controlled program [ToDo…]
*Enjoy your Linux-Cube!

=What you will need=
*Nintendo Gamecube
*Method to load homebrew
*An SD-Card (max. 2GB atm)
*[[SDGecko]] (See [5] or Buy)

==For Compiling it==
*Little knowledge about Linux Kernel
*A running Linux Distribution
*A running gc-linux tool chain + patched kernel source (2.6.32)
**See http://www.gc-linux.org/wiki/Building_a_GameCube_Linux_Kernel
**Clone my git for the Kernel: https://github.com/Nold360/GC-Linux-Kernel-2.6.32
**You may just want to use my config files:
cp .config linux-2.6.32/.config
cp gamecube.dts linux-2.6.32/arch/powerpc/boot/dts/gamecube.dts

=What should happen?=
After the GameCube boots, you will start the kernel.dol from the 1st partition of your SD-Card (fat formatted). The kernel will boot and mount the 2nd partition as his root (ext2/3 Formatted). Then will the Kernel look for his init-script and execute it.
In our Case we use the /bin/init script to configure the rest of the hardware (swap, mounting, etc.) and then start our script/program.

==The boot parameter==
The boot parameters were the first thing I edited. It’s defined in the
“arch/powerpc/boot/dts/gamecube.dts”-file. I edited it as follows:

chosen {
bootargs = "root=/dev/gcnsda2 rw video=gcn-vifb:tv=auto";
};

The “root=” parameter tells the kernel that his root is on “/dev/gcnsda2” that means the SD-Card (sd) that is plugged into the GameCube’s (gcn) MemoryCard-Slot1 (a) on Partition 2 (2) [Because the fist is used so SD-Load to execute the kernel.dol]
“rootwait” tells him to wait for his root file system until it’s ready.
The video parameter tells him which video device to use, and how.
In our case he uses the GameCube framebuffer (gcn-vifb), on a tv.
With the “auto” parameter, he will look for himself which mode to use. (NTFS, PAL50/60Hz…)

==Creating a Root file system==
After I could see that my kernel wants to use my SD-Card, I needed a root file system. Basically you don’t need really much, it’s just the normal root-tree (/dev /bin /etc /mnt /usr…) But because I’m a pretty lazy person, I just used a mix of the ramdisk and the file system of the MFE-Distribution and it worked pretty well. I just used my own /linuxrc and /bin/init-scripts. Also you need to add the SD-Card-Devicenodes to the /dev directory.
Please do not use the description from the gc-linux wiki [1]. There they were called “/dev/sdcarda” and “/dev/sdcardb” but they are called “/dev/gcnsda” and “/dev/gcnsdb”.

So we will add some nodes (as root):
mknod dev/gcnsda b 61 0
mknod dev/gcnsda1 b 61 1
mknod dev/gcnsda2 b 61 2
mknod dev/gcnsda3 b 61 3

mknod dev/gcnsdb b 61 8
mknod dev/gcnsdb1 b 61 9
mknod dev/gcnsdb2 b 61 10
mknod dev/gcnsdb3 b 61 11

We will also need one for Audio-RAM
mknod dev/aram b 37 0

I also added an 3rd SD-card partition, if we maybe want to use them later.

Last we add an mount path for the 1st SD-Card partition at /mnt/sdcarda, so we can mount it for later use.
# mkdir mnt/sdcarda

After that we need to create an fstab (/etc/fstab) to mount the cube’s Audio RAM as swap. 
Also we will add proc, root and our first SD-Card (vfat) Partition [Optional].
===/etc/fstab===
/dev/aram swap swap pri=32767 0 0
/dev/gcnsda2 / ext3 defaults,errors=remount-ro 0 0
/dev/gcnsda1 /mnt/gcnsda1 vfat defaults 0 0
proc /proc proc defaults 0 0

==The Init-Script==
So, the kernel boots, the filesystem looks great, what to do next?
We need to give our Kernel a init-script. As we didn’t gave the kernel the “init=/…” parameter, he will try to start the default script “/bin/init”.

A very important thing is that init is not allowed to die! So it has to run all the time.

But what has our system now to do?
We need:
*Format Audio-RAM as swap (mkswap)
*Mount fstab
*Activate swap
*Start our programs we need (mplayer, GUI, whatever)
*Keep init alive!

So let’s do that!
===/bin/init===
#!/bin/ash
mkswap /dev/aram
mount –a
swapon –a

#Now comes our script or whatever you want to execute
/linuxrc

#And keep init alive
while [ 1 –eq 1 ]; do
sleep 1
done

==Preparing the SD-Card==
First of all, we need to prepare our SD-Card partitions. We need a first partition formatted with fat (vfat) and a second partition for the root file system (ext2/3). 
How big they are depends on your SD-Card and for what additional use you want to use it. 
We need about 10MB For the kernel.dol plus the SDLOADER.BIN and about 20mb for the basic root file system. Since I want to extend the rootfs and maybe want to use other homebrew and kernel.dol’s I formatted it as follows (1GB SD):
*300MB vfat
*700MB ext2/3

I choose ext3 because I was first using ext2, but I had problems with destroyed libraries. So I switched to ext3 because it’s journaling. 
If you are ready to go, copy the file system onto the ext2/3 partition, and the GcImage.dol on the vfat partition.

===Preparing SD-Card with fdisk===
Partitioning with fdisk is pretty easy, i will do an example of how to do it using a 1GB SD-Card. Of course can you choose your partition sizes as you want.
Notice that the device path WILL be another on your system!
# fdisk /dev/mmcblk0 #Change to your device-path
> o #Create empty DOS Patition Table
> n #Create new Partition
> p #Primary
> [Enter] #At first sector
> +300M #with 300MB size, change to whatever you want for your "Homebrew"-Partition

That was our first partition that is going to be out vfat-homebrew partition, now comes the rootfs partition
> n #Create new Partition
> p #Primary
> [Enter] #At first useable sector (behind our vfat-partition)
> [Enter] #With maximum of size (Here: 700MB)
> w #Write everything to device
> q #Quit fdisk

Now we have our Partitions. But they need a filesystem. In this example we use mkfs for this task:
# mkfs.vfat /dev/mmcblk0p1 #Watch your path!
# mkfs.ext3 /dev/mmcblk0p2 #Same here!

Now you are ready to go. Copy GcImage.dol to the 1st Partition and the rootfs to the second.

=So what’s next?=
The next part is to include the software we need. This isn’t very problematic because we can use every binary which is compiled for a PowerPC! So what I did is that I downloaded my binaries and libraries from the Debian package-Service [3]. And used the libSDL and the mplayer binary from the mfe-distribution, since they were included in the filesystem. I just added the libraries for divx and mp3.

If you have an Broadband-Adapter in your Cube, you could even install apt-get and just download the packages directly on your cube! 
Another possibility for creating a big but good root file system would be the way from the GC-Linux wiki [4].

=Need Help? Got Ideas? Want to Help?=
Join the GC-Forever Community! :) [0]

=Links=
[0] http://nold.freeunix.net/devnull/index.php?show=./Stuff/Consoles/Gamecube/GameCube%20Linux 
[0] http://gc-forever.com 
[1] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Creating_the_SD.2FMMC_card_device_nodes 
[2] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Create_the_device_node_for_the_audio_RAM_driver 
[3] http://packages.debian.org 
[4] http://www.gc-linux.org/wiki/Creating_a_Root_Filesystem 
[5] http://ngc.scorpei.com/GUIDE-SD_adapter.html 

[[Category:Software]]

GC-Linux with rootFS on SD

2024-07-23T07:06:46Z

Lumina33: /* So what’s next? */ ws

=Introduction=
First of all I want to thank the people who made all this possible:

The guys from GC-Linux: http://www.gc-linux.org

Simon "Scorpei" van de Berg for his great tutorial how to build an SD-card adapter for the cube: http://ngc.scorpei.com/GUIDE-SD_adapter.html

The linuxwiki: http://linuxwiki.de

The creators of MFE: http://www.gc-linux.org/wiki/Mfe-distro

=The aim=
The aim of this Project is to create a custom Linux Kernel, which runs on a modified GameCube and has the root file system on an SD-card which is plugged into the memory-card slot via an [[SDGecko]].
After the system boots form the SD-card, it should start a custom program which allows the user to start programs using the GameCube-pad.

=Why?=
Normally the GC-Linux kernel will try to load the root file system from a NFS attached storage over the BBA.

However this isn't very practical because you need a broadband adapter for your GameCube, and you will always have to run an NFS-Share on your PC or a dedicated Server.
What I want is a stand-alone Linux on my GameCube! So why not create one by myself?

=Roadmap=
*Create & boot a Kernel with his root file system on an SD-Card [Done!]
*Create an auto executing script (init/linuxrc?) [Done!]
*Write an GameCube-pad controlled program [ToDo…]
*Enjoy your Linux-Cube!

=What you will need=
*Nintendo Gamecube
*Method to load homebrew
*An SD-Card (max. 2GB atm)
*[[SDGecko]] (See [5] or Buy)

==For Compiling it==
*Little knowledge about Linux Kernel
*A running Linux Distribution
*A running gc-linux tool chain + patched kernel source (2.6.32)
**See http://www.gc-linux.org/wiki/Building_a_GameCube_Linux_Kernel
**Clone my git for the Kernel: https://github.com/Nold360/GC-Linux-Kernel-2.6.32
**You may just want to use my config files:
cp .config linux-2.6.32/.config
cp gamecube.dts linux-2.6.32/arch/powerpc/boot/dts/gamecube.dts

=What should happen?=
After the GameCube boots, you will start the kernel.dol from the 1st partition of your SD-Card (fat formatted). The kernel will boot and mount the 2nd partition as his root (ext2/3 Formatted). Then will the Kernel look for his init-script and execute it.
In our Case we use the /bin/init script to configure the rest of the hardware (swap, mounting, etc.) and then start our script/program.

==The boot parameter==
The boot parameters were the first thing I edited. It’s defined in the
“arch/powerpc/boot/dts/gamecube.dts”-file. I edited it as follows:

chosen {
bootargs = "root=/dev/gcnsda2 rw video=gcn-vifb:tv=auto";
};

The “root=” parameter tells the kernel that his root is on “/dev/gcnsda2” that means the SD-Card (sd) that is plugged into the GameCube’s (gcn) MemoryCard-Slot1 (a) on Partition 2 (2) [Because the fist is used so SD-Load to execute the kernel.dol]
“rootwait” tells him to wait for his root file system until it’s ready.
The video parameter tells him which video device to use, and how.
In our case he uses the GameCube framebuffer (gcn-vifb), on a tv.
With the “auto” parameter, he will look for himself which mode to use. (NTFS, PAL50/60Hz…)

==Creating a Root file system==
After I could see that my kernel wants to use my SD-Card, I needed a root file system. Basically you don’t need really much, it’s just the normal root-tree (/dev /bin /etc /mnt /usr…) But because I’m a pretty lazy person, I just used a mix of the ramdisk and the file system of the MFE-Distribution and it worked pretty well. I just used my own /linuxrc and /bin/init-scripts. Also you need to add the SD-Card-Devicenodes to the /dev directory.
Please do not use the description from the gc-linux wiki [1]. There they were called “/dev/sdcarda” and “/dev/sdcardb” but they are called “/dev/gcnsda” and “/dev/gcnsdb”.

So we will add some nodes (as root):
mknod dev/gcnsda b 61 0
mknod dev/gcnsda1 b 61 1
mknod dev/gcnsda2 b 61 2
mknod dev/gcnsda3 b 61 3

mknod dev/gcnsdb b 61 8
mknod dev/gcnsdb1 b 61 9
mknod dev/gcnsdb2 b 61 10
mknod dev/gcnsdb3 b 61 11

We will also need one for Audio-RAM
mknod dev/aram b 37 0

I also added an 3rd SD-card partition, if we maybe want to use them later.

Last we add an mount path for the 1st SD-Card partition at /mnt/sdcarda, so we can mount it for later use.
# mkdir mnt/sdcarda

After that we need to create an fstab (/etc/fstab) to mount the cube’s Audio RAM as swap. 
Also we will add proc, root and our first SD-Card (vfat) Partition [Optional].
===/etc/fstab===
/dev/aram swap swap pri=32767 0 0
/dev/gcnsda2 / ext3 defaults,errors=remount-ro 0 0
/dev/gcnsda1 /mnt/gcnsda1 vfat defaults 0 0
proc /proc proc defaults 0 0

==The Init-Script==
So, the kernel boots, the filesystem looks great, what to do next?
We need to give our Kernel a init-script. As we didn’t gave the kernel the “init=/…” parameter, he will try to start the default script “/bin/init”.

A very important thing is that init is not allowed to die! So it has to run all the time.

But what has our system now to do?
We need:
*Format Audio-RAM as swap (mkswap)
*Mount fstab
*Activate swap
*Start our programs we need (mplayer, GUI, whatever)
*Keep init alive!

So let’s do that!
===/bin/init===
#!/bin/ash
mkswap /dev/aram
mount –a
swapon –a

#Now comes our script or whatever you want to execute
/linuxrc

#And keep init alive
while [ 1 –eq 1 ]; do
sleep 1
done

==Preparing the SD-Card==
First of all, we need to prepare our SD-Card partitions. We need a first partition formatted with fat (vfat) and a second partition for the root file system (ext2/3). 
How big they are depends on your SD-Card and for what additional use you want to use it. 
We need about 10MB For the kernel.dol plus the SDLOADER.BIN and about 20mb for the basic root file system. Since I want to extend the rootfs and maybe want to use other homebrew and kernel.dol’s I formatted it as follows (1GB SD):
*300MB vfat
*700MB ext2/3

I choose ext3 because I was first using ext2, but I had problems with destroyed libraries. So I switched to ext3 because it’s journaling. 
If you are ready to go, copy the file system onto the ext2/3 partition, and the GcImage.dol on the vfat partition.

===Preparing SD-Card with fdisk===
Partitioning with fdisk is pretty easy, i will do an example of how to do it using a 1GB SD-Card. Of course can you choose your partition sizes as you want.
Notice that the device path WILL be another on your system!
# fdisk /dev/mmcblk0 #Change to your device-path
> o #Create empty DOS Patition Table
> n #Create new Partition
> p #Primary
> [Enter] #At first sector
> +300M #with 300MB size, change to whatever you want for your "Homebrew"-Partition

That was our first partition that is going to be out vfat-homebrew partition, now comes the rootfs partition
> n #Create new Partition
> p #Primary
> [Enter] #At first useable sector (behind our vfat-partition)
> [Enter] #With maximum of size (Here: 700MB)
> w #Write everything to device
> q #Quit fdisk

Now we have our Partitions. But they need a filesystem. In this example we use mkfs for this task:
# mkfs.vfat /dev/mmcblk0p1 #Watch your path!
# mkfs.ext3 /dev/mmcblk0p2 #Same here!

Now you are ready to go. Copy GcImage.dol to the 1st Partition and the rootfs to the second.

=So what’s next?=
The next part is to include the software we need. This isn’t very problematic because we can use every binary which is compiled for a PowerPC! So what I did is that I downloaded my binaries and libraries from the Debian package-Service [3]. And used the libSDL and the mplayer binary from the mfe-distribution, since they were included in the filesystem. I just added the libraries for divx and mp3.

If you have an Broadband-Adapter in your Cube, you could even install apt-get and just download the packages directly on your cube! 
Another possibility for creating a big but good root file system would be the way from the GC-Linux wiki [4].

=Need Help? Got Ideas? Want to Help?=
Join the GC-Forever Community! :) [0]

=Links=
[0] http://nold.freeunix.net/devnull/index.php?show=./Stuff/Consoles/Gamecube/GameCube%20Linux 
[0] http://gc-forever.com 
[1] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Creating_the_SD.2FMMC_card_device_nodes 
[2] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Create_the_device_node_for_the_audio_RAM_driver 
[3] http://packages.debian.org 
[4] http://www.gc-linux.org/wiki/Creating_a_Root_Filesystem 
[5] http://ngc.scorpei.com/GUIDE-SD_adapter.html 

[[Category:Software]]

GC-Linux with rootFS on SD

2024-07-23T07:06:28Z

Lumina33: /* The boot parameter */ whitespace

=Introduction=
First of all I want to thank the people who made all this possible:

The guys from GC-Linux: http://www.gc-linux.org

Simon "Scorpei" van de Berg for his great tutorial how to build an SD-card adapter for the cube: http://ngc.scorpei.com/GUIDE-SD_adapter.html

The linuxwiki: http://linuxwiki.de

The creators of MFE: http://www.gc-linux.org/wiki/Mfe-distro

=The aim=
The aim of this Project is to create a custom Linux Kernel, which runs on a modified GameCube and has the root file system on an SD-card which is plugged into the memory-card slot via an [[SDGecko]].
After the system boots form the SD-card, it should start a custom program which allows the user to start programs using the GameCube-pad.

=Why?=
Normally the GC-Linux kernel will try to load the root file system from a NFS attached storage over the BBA.

However this isn't very practical because you need a broadband adapter for your GameCube, and you will always have to run an NFS-Share on your PC or a dedicated Server.
What I want is a stand-alone Linux on my GameCube! So why not create one by myself?

=Roadmap=
*Create & boot a Kernel with his root file system on an SD-Card [Done!]
*Create an auto executing script (init/linuxrc?) [Done!]
*Write an GameCube-pad controlled program [ToDo…]
*Enjoy your Linux-Cube!

=What you will need=
*Nintendo Gamecube
*Method to load homebrew
*An SD-Card (max. 2GB atm)
*[[SDGecko]] (See [5] or Buy)

==For Compiling it==
*Little knowledge about Linux Kernel
*A running Linux Distribution
*A running gc-linux tool chain + patched kernel source (2.6.32)
**See http://www.gc-linux.org/wiki/Building_a_GameCube_Linux_Kernel
**Clone my git for the Kernel: https://github.com/Nold360/GC-Linux-Kernel-2.6.32
**You may just want to use my config files:
cp .config linux-2.6.32/.config
cp gamecube.dts linux-2.6.32/arch/powerpc/boot/dts/gamecube.dts

=What should happen?=
After the GameCube boots, you will start the kernel.dol from the 1st partition of your SD-Card (fat formatted). The kernel will boot and mount the 2nd partition as his root (ext2/3 Formatted). Then will the Kernel look for his init-script and execute it.
In our Case we use the /bin/init script to configure the rest of the hardware (swap, mounting, etc.) and then start our script/program.

==The boot parameter==
The boot parameters were the first thing I edited. It’s defined in the
“arch/powerpc/boot/dts/gamecube.dts”-file. I edited it as follows:

chosen {
bootargs = "root=/dev/gcnsda2 rw video=gcn-vifb:tv=auto";
};

The “root=” parameter tells the kernel that his root is on “/dev/gcnsda2” that means the SD-Card (sd) that is plugged into the GameCube’s (gcn) MemoryCard-Slot1 (a) on Partition 2 (2) [Because the fist is used so SD-Load to execute the kernel.dol]
“rootwait” tells him to wait for his root file system until it’s ready.
The video parameter tells him which video device to use, and how.
In our case he uses the GameCube framebuffer (gcn-vifb), on a tv.
With the “auto” parameter, he will look for himself which mode to use. (NTFS, PAL50/60Hz…)

==Creating a Root file system==
After I could see that my kernel wants to use my SD-Card, I needed a root file system. Basically you don’t need really much, it’s just the normal root-tree (/dev /bin /etc /mnt /usr…) But because I’m a pretty lazy person, I just used a mix of the ramdisk and the file system of the MFE-Distribution and it worked pretty well. I just used my own /linuxrc and /bin/init-scripts. Also you need to add the SD-Card-Devicenodes to the /dev directory.
Please do not use the description from the gc-linux wiki [1]. There they were called “/dev/sdcarda” and “/dev/sdcardb” but they are called “/dev/gcnsda” and “/dev/gcnsdb”.

So we will add some nodes (as root):
mknod dev/gcnsda b 61 0
mknod dev/gcnsda1 b 61 1
mknod dev/gcnsda2 b 61 2
mknod dev/gcnsda3 b 61 3

mknod dev/gcnsdb b 61 8
mknod dev/gcnsdb1 b 61 9
mknod dev/gcnsdb2 b 61 10
mknod dev/gcnsdb3 b 61 11

We will also need one for Audio-RAM
mknod dev/aram b 37 0

I also added an 3rd SD-card partition, if we maybe want to use them later.

Last we add an mount path for the 1st SD-Card partition at /mnt/sdcarda, so we can mount it for later use.
# mkdir mnt/sdcarda

After that we need to create an fstab (/etc/fstab) to mount the cube’s Audio RAM as swap. 
Also we will add proc, root and our first SD-Card (vfat) Partition [Optional].
===/etc/fstab===
/dev/aram swap swap pri=32767 0 0
/dev/gcnsda2 / ext3 defaults,errors=remount-ro 0 0
/dev/gcnsda1 /mnt/gcnsda1 vfat defaults 0 0
proc /proc proc defaults 0 0

==The Init-Script==
So, the kernel boots, the filesystem looks great, what to do next?
We need to give our Kernel a init-script. As we didn’t gave the kernel the “init=/…” parameter, he will try to start the default script “/bin/init”.

A very important thing is that init is not allowed to die! So it has to run all the time.

But what has our system now to do?
We need:
*Format Audio-RAM as swap (mkswap)
*Mount fstab
*Activate swap
*Start our programs we need (mplayer, GUI, whatever)
*Keep init alive!

So let’s do that!
===/bin/init===
#!/bin/ash
mkswap /dev/aram
mount –a
swapon –a

#Now comes our script or whatever you want to execute
/linuxrc

#And keep init alive
while [ 1 –eq 1 ]; do
sleep 1
done

==Preparing the SD-Card==
First of all, we need to prepare our SD-Card partitions. We need a first partition formatted with fat (vfat) and a second partition for the root file system (ext2/3). 
How big they are depends on your SD-Card and for what additional use you want to use it. 
We need about 10MB For the kernel.dol plus the SDLOADER.BIN and about 20mb for the basic root file system. Since I want to extend the rootfs and maybe want to use other homebrew and kernel.dol’s I formatted it as follows (1GB SD):
*300MB vfat
*700MB ext2/3

I choose ext3 because I was first using ext2, but I had problems with destroyed libraries. So I switched to ext3 because it’s journaling. 
If you are ready to go, copy the file system onto the ext2/3 partition, and the GcImage.dol on the vfat partition.

===Preparing SD-Card with fdisk===
Partitioning with fdisk is pretty easy, i will do an example of how to do it using a 1GB SD-Card. Of course can you choose your partition sizes as you want.
Notice that the device path WILL be another on your system!
# fdisk /dev/mmcblk0 #Change to your device-path
> o #Create empty DOS Patition Table
> n #Create new Partition
> p #Primary
> [Enter] #At first sector
> +300M #with 300MB size, change to whatever you want for your "Homebrew"-Partition

That was our first partition that is going to be out vfat-homebrew partition, now comes the rootfs partition
> n #Create new Partition
> p #Primary
> [Enter] #At first useable sector (behind our vfat-partition)
> [Enter] #With maximum of size (Here: 700MB)
> w #Write everything to device
> q #Quit fdisk

Now we have our Partitions. But they need a filesystem. In this example we use mkfs for this task:
# mkfs.vfat /dev/mmcblk0p1 #Watch your path!
# mkfs.ext3 /dev/mmcblk0p2 #Same here!

Now you are ready to go. Copy GcImage.dol to the 1st Partition and the rootfs to the second.

=So what’s next?=
The next part is to include the software we need. This isn’t very problematic because we can use every binary which is compiled for a PowerPC! So what I did is that I downloaded my binaries and libraries from the Debian package-Service [3]. And used the libSDL and the mplayer binary from the mfe-distribution, since they were included in the filesystem. I just added the libraries for divx and mp3.

If you have an Broadband-Adapter in your Cube, you could even install apt-get and just download the packages directly on your cube! 
Another possibility for creating a big but good root file system would be the way from the GC-Linux wiki [4].

=Need Help? Got Ideas? Want to Help?=
Join the GC-Forever Community! :) [0]

=Links=
[0] http://nold.freeunix.net/devnull/index.php?show=./Stuff/Consoles/Gamecube/GameCube%20Linux 
[0] http://gc-forever.com 
[1] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Creating_the_SD.2FMMC_card_device_nodes 
[2] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Create_the_device_node_for_the_audio_RAM_driver 
[3] http://packages.debian.org 
[4] http://www.gc-linux.org/wiki/Creating_a_Root_Filesystem 
[5] http://ngc.scorpei.com/GUIDE-SD_adapter.html 

[[Category:Software]]

GC-Linux with rootFS on SD

2024-07-23T07:06:05Z

Lumina33: /* Roadmap */ whitespace

=Introduction=
First of all I want to thank the people who made all this possible:

The guys from GC-Linux: http://www.gc-linux.org

Simon "Scorpei" van de Berg for his great tutorial how to build an SD-card adapter for the cube: http://ngc.scorpei.com/GUIDE-SD_adapter.html

The linuxwiki: http://linuxwiki.de

The creators of MFE: http://www.gc-linux.org/wiki/Mfe-distro

=The aim=
The aim of this Project is to create a custom Linux Kernel, which runs on a modified GameCube and has the root file system on an SD-card which is plugged into the memory-card slot via an [[SDGecko]].
After the system boots form the SD-card, it should start a custom program which allows the user to start programs using the GameCube-pad.

=Why?=
Normally the GC-Linux kernel will try to load the root file system from a NFS attached storage over the BBA.

However this isn't very practical because you need a broadband adapter for your GameCube, and you will always have to run an NFS-Share on your PC or a dedicated Server.
What I want is a stand-alone Linux on my GameCube! So why not create one by myself?

=Roadmap=
*Create & boot a Kernel with his root file system on an SD-Card [Done!]
*Create an auto executing script (init/linuxrc?) [Done!]
*Write an GameCube-pad controlled program [ToDo…]
*Enjoy your Linux-Cube!

=What you will need=
*Nintendo Gamecube
*Method to load homebrew
*An SD-Card (max. 2GB atm)
*[[SDGecko]] (See [5] or Buy)

==For Compiling it==
*Little knowledge about Linux Kernel
*A running Linux Distribution
*A running gc-linux tool chain + patched kernel source (2.6.32)
**See http://www.gc-linux.org/wiki/Building_a_GameCube_Linux_Kernel
**Clone my git for the Kernel: https://github.com/Nold360/GC-Linux-Kernel-2.6.32
**You may just want to use my config files:
cp .config linux-2.6.32/.config
cp gamecube.dts linux-2.6.32/arch/powerpc/boot/dts/gamecube.dts

=What should happen?=
After the GameCube boots, you will start the kernel.dol from the 1st partition of your SD-Card (fat formatted). The kernel will boot and mount the 2nd partition as his root (ext2/3 Formatted). Then will the Kernel look for his init-script and execute it.
In our Case we use the /bin/init script to configure the rest of the hardware (swap, mounting, etc.) and then start our script/program.

==The boot parameter==
The boot parameters were the first thing I edited. It’s defined in the
“arch/powerpc/boot/dts/gamecube.dts”-file. I edited it as follows:

chosen {
bootargs = "root=/dev/gcnsda2 rw video=gcn-vifb:tv=auto";
};

The “root=” parameter tells the kernel that his root is on “/dev/gcnsda2” that means the SD-Card (sd) that is plugged into the GameCube’s (gcn) MemoryCard-Slot1 (a) on Partition 2 (2) [Because the fist is used so SD-Load to execute the kernel.dol]
“rootwait” tells him to wait for his root file system until it’s ready.
The video parameter tells him which video device to use, and how.
In our case he uses the GameCube framebuffer (gcn-vifb), on a tv.
With the “auto” parameter, he will look for himself which mode to use. (NTFS, PAL50/60Hz…)

==Creating a Root file system==
After I could see that my kernel wants to use my SD-Card, I needed a root file system. Basically you don’t need really much, it’s just the normal root-tree (/dev /bin /etc /mnt /usr…) But because I’m a pretty lazy person, I just used a mix of the ramdisk and the file system of the MFE-Distribution and it worked pretty well. I just used my own /linuxrc and /bin/init-scripts. Also you need to add the SD-Card-Devicenodes to the /dev directory.
Please do not use the description from the gc-linux wiki [1]. There they were called “/dev/sdcarda” and “/dev/sdcardb” but they are called “/dev/gcnsda” and “/dev/gcnsdb”.

So we will add some nodes (as root):
mknod dev/gcnsda b 61 0
mknod dev/gcnsda1 b 61 1
mknod dev/gcnsda2 b 61 2
mknod dev/gcnsda3 b 61 3

mknod dev/gcnsdb b 61 8
mknod dev/gcnsdb1 b 61 9
mknod dev/gcnsdb2 b 61 10
mknod dev/gcnsdb3 b 61 11

We will also need one for Audio-RAM
mknod dev/aram b 37 0

I also added an 3rd SD-card partition, if we maybe want to use them later.

Last we add an mount path for the 1st SD-Card partition at /mnt/sdcarda, so we can mount it for later use.
# mkdir mnt/sdcarda

After that we need to create an fstab (/etc/fstab) to mount the cube’s Audio RAM as swap. 
Also we will add proc, root and our first SD-Card (vfat) Partition [Optional].
===/etc/fstab===
/dev/aram swap swap pri=32767 0 0
/dev/gcnsda2 / ext3 defaults,errors=remount-ro 0 0
/dev/gcnsda1 /mnt/gcnsda1 vfat defaults 0 0
proc /proc proc defaults 0 0

==The Init-Script==
So, the kernel boots, the filesystem looks great, what to do next?
We need to give our Kernel a init-script. As we didn’t gave the kernel the “init=/…” parameter, he will try to start the default script “/bin/init”.

A very important thing is that init is not allowed to die! So it has to run all the time.

But what has our system now to do?
We need:
*Format Audio-RAM as swap (mkswap)
*Mount fstab
*Activate swap
*Start our programs we need (mplayer, GUI, whatever)
*Keep init alive!

So let’s do that!
===/bin/init===
#!/bin/ash
mkswap /dev/aram
mount –a
swapon –a

#Now comes our script or whatever you want to execute
/linuxrc

#And keep init alive
while [ 1 –eq 1 ]; do
sleep 1
done

==Preparing the SD-Card==
First of all, we need to prepare our SD-Card partitions. We need a first partition formatted with fat (vfat) and a second partition for the root file system (ext2/3). 
How big they are depends on your SD-Card and for what additional use you want to use it. 
We need about 10MB For the kernel.dol plus the SDLOADER.BIN and about 20mb for the basic root file system. Since I want to extend the rootfs and maybe want to use other homebrew and kernel.dol’s I formatted it as follows (1GB SD):
*300MB vfat
*700MB ext2/3

I choose ext3 because I was first using ext2, but I had problems with destroyed libraries. So I switched to ext3 because it’s journaling. 
If you are ready to go, copy the file system onto the ext2/3 partition, and the GcImage.dol on the vfat partition.

===Preparing SD-Card with fdisk===
Partitioning with fdisk is pretty easy, i will do an example of how to do it using a 1GB SD-Card. Of course can you choose your partition sizes as you want.
Notice that the device path WILL be another on your system!
# fdisk /dev/mmcblk0 #Change to your device-path
> o #Create empty DOS Patition Table
> n #Create new Partition
> p #Primary
> [Enter] #At first sector
> +300M #with 300MB size, change to whatever you want for your "Homebrew"-Partition

That was our first partition that is going to be out vfat-homebrew partition, now comes the rootfs partition
> n #Create new Partition
> p #Primary
> [Enter] #At first useable sector (behind our vfat-partition)
> [Enter] #With maximum of size (Here: 700MB)
> w #Write everything to device
> q #Quit fdisk

Now we have our Partitions. But they need a filesystem. In this example we use mkfs for this task:
# mkfs.vfat /dev/mmcblk0p1 #Watch your path!
# mkfs.ext3 /dev/mmcblk0p2 #Same here!

Now you are ready to go. Copy GcImage.dol to the 1st Partition and the rootfs to the second.

=So what’s next?=
The next part is to include the software we need. This isn’t very problematic because we can use every binary which is compiled for a PowerPC! So what I did is that I downloaded my binaries and libraries from the Debian package-Service [3]. And used the libSDL and the mplayer binary from the mfe-distribution, since they were included in the filesystem. I just added the libraries for divx and mp3.

If you have an Broadband-Adapter in your Cube, you could even install apt-get and just download the packages directly on your cube! 
Another possibility for creating a big but good root file system would be the way from the GC-Linux wiki [4].

=Need Help? Got Ideas? Want to Help?=
Join the GC-Forever Community! :) [0]

=Links=
[0] http://nold.freeunix.net/devnull/index.php?show=./Stuff/Consoles/Gamecube/GameCube%20Linux 
[0] http://gc-forever.com 
[1] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Creating_the_SD.2FMMC_card_device_nodes 
[2] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Create_the_device_node_for_the_audio_RAM_driver 
[3] http://packages.debian.org 
[4] http://www.gc-linux.org/wiki/Creating_a_Root_Filesystem 
[5] http://ngc.scorpei.com/GUIDE-SD_adapter.html 

[[Category:Software]]

GC-Linux with rootFS on SD

2024-07-23T07:05:52Z

Lumina33: /* Why? */ whitespace

=Introduction=
First of all I want to thank the people who made all this possible:

The guys from GC-Linux: http://www.gc-linux.org

Simon "Scorpei" van de Berg for his great tutorial how to build an SD-card adapter for the cube: http://ngc.scorpei.com/GUIDE-SD_adapter.html

The linuxwiki: http://linuxwiki.de

The creators of MFE: http://www.gc-linux.org/wiki/Mfe-distro

=The aim=
The aim of this Project is to create a custom Linux Kernel, which runs on a modified GameCube and has the root file system on an SD-card which is plugged into the memory-card slot via an [[SDGecko]].
After the system boots form the SD-card, it should start a custom program which allows the user to start programs using the GameCube-pad.

=Why?=
Normally the GC-Linux kernel will try to load the root file system from a NFS attached storage over the BBA.

However this isn't very practical because you need a broadband adapter for your GameCube, and you will always have to run an NFS-Share on your PC or a dedicated Server.
What I want is a stand-alone Linux on my GameCube! So why not create one by myself?

=Roadmap=
*Create & boot a Kernel with his root file system on an SD-Card [Done!]
*Create an auto executing script (init/linuxrc?) [Done!]
*Write an GameCube-pad controlled program [ToDo…]
*Enjoy your Linux-Cube!

=What you will need=
*Nintendo Gamecube
*Method to load homebrew
*An SD-Card (max. 2GB atm)
*[[SDGecko]] (See [5] or Buy)

==For Compiling it==
*Little knowledge about Linux Kernel
*A running Linux Distribution
*A running gc-linux tool chain + patched kernel source (2.6.32)
**See http://www.gc-linux.org/wiki/Building_a_GameCube_Linux_Kernel
**Clone my git for the Kernel: https://github.com/Nold360/GC-Linux-Kernel-2.6.32
**You may just want to use my config files:
cp .config linux-2.6.32/.config
cp gamecube.dts linux-2.6.32/arch/powerpc/boot/dts/gamecube.dts

=What should happen?=
After the GameCube boots, you will start the kernel.dol from the 1st partition of your SD-Card (fat formatted). The kernel will boot and mount the 2nd partition as his root (ext2/3 Formatted). Then will the Kernel look for his init-script and execute it.
In our Case we use the /bin/init script to configure the rest of the hardware (swap, mounting, etc.) and then start our script/program.

==The boot parameter==
The boot parameters were the first thing I edited. It’s defined in the
“arch/powerpc/boot/dts/gamecube.dts”-file. I edited it as follows:

chosen {
bootargs = "root=/dev/gcnsda2 rw video=gcn-vifb:tv=auto";
};

The “root=” parameter tells the kernel that his root is on “/dev/gcnsda2” that means the SD-Card (sd) that is plugged into the GameCube’s (gcn) MemoryCard-Slot1 (a) on Partition 2 (2) [Because the fist is used so SD-Load to execute the kernel.dol]
“rootwait” tells him to wait for his root file system until it’s ready.
The video parameter tells him which video device to use, and how.
In our case he uses the GameCube framebuffer (gcn-vifb), on a tv.
With the “auto” parameter, he will look for himself which mode to use. (NTFS, PAL50/60Hz…)

==Creating a Root file system==
After I could see that my kernel wants to use my SD-Card, I needed a root file system. Basically you don’t need really much, it’s just the normal root-tree (/dev /bin /etc /mnt /usr…) But because I’m a pretty lazy person, I just used a mix of the ramdisk and the file system of the MFE-Distribution and it worked pretty well. I just used my own /linuxrc and /bin/init-scripts. Also you need to add the SD-Card-Devicenodes to the /dev directory.
Please do not use the description from the gc-linux wiki [1]. There they were called “/dev/sdcarda” and “/dev/sdcardb” but they are called “/dev/gcnsda” and “/dev/gcnsdb”.

So we will add some nodes (as root):
mknod dev/gcnsda b 61 0
mknod dev/gcnsda1 b 61 1
mknod dev/gcnsda2 b 61 2
mknod dev/gcnsda3 b 61 3

mknod dev/gcnsdb b 61 8
mknod dev/gcnsdb1 b 61 9
mknod dev/gcnsdb2 b 61 10
mknod dev/gcnsdb3 b 61 11

We will also need one for Audio-RAM
mknod dev/aram b 37 0

I also added an 3rd SD-card partition, if we maybe want to use them later.

Last we add an mount path for the 1st SD-Card partition at /mnt/sdcarda, so we can mount it for later use.
# mkdir mnt/sdcarda

After that we need to create an fstab (/etc/fstab) to mount the cube’s Audio RAM as swap. 
Also we will add proc, root and our first SD-Card (vfat) Partition [Optional].
===/etc/fstab===
/dev/aram swap swap pri=32767 0 0
/dev/gcnsda2 / ext3 defaults,errors=remount-ro 0 0
/dev/gcnsda1 /mnt/gcnsda1 vfat defaults 0 0
proc /proc proc defaults 0 0

==The Init-Script==
So, the kernel boots, the filesystem looks great, what to do next?
We need to give our Kernel a init-script. As we didn’t gave the kernel the “init=/…” parameter, he will try to start the default script “/bin/init”.

A very important thing is that init is not allowed to die! So it has to run all the time.

But what has our system now to do?
We need:
*Format Audio-RAM as swap (mkswap)
*Mount fstab
*Activate swap
*Start our programs we need (mplayer, GUI, whatever)
*Keep init alive!

So let’s do that!
===/bin/init===
#!/bin/ash
mkswap /dev/aram
mount –a
swapon –a

#Now comes our script or whatever you want to execute
/linuxrc

#And keep init alive
while [ 1 –eq 1 ]; do
sleep 1
done

==Preparing the SD-Card==
First of all, we need to prepare our SD-Card partitions. We need a first partition formatted with fat (vfat) and a second partition for the root file system (ext2/3). 
How big they are depends on your SD-Card and for what additional use you want to use it. 
We need about 10MB For the kernel.dol plus the SDLOADER.BIN and about 20mb for the basic root file system. Since I want to extend the rootfs and maybe want to use other homebrew and kernel.dol’s I formatted it as follows (1GB SD):
*300MB vfat
*700MB ext2/3

I choose ext3 because I was first using ext2, but I had problems with destroyed libraries. So I switched to ext3 because it’s journaling. 
If you are ready to go, copy the file system onto the ext2/3 partition, and the GcImage.dol on the vfat partition.

===Preparing SD-Card with fdisk===
Partitioning with fdisk is pretty easy, i will do an example of how to do it using a 1GB SD-Card. Of course can you choose your partition sizes as you want.
Notice that the device path WILL be another on your system!
# fdisk /dev/mmcblk0 #Change to your device-path
> o #Create empty DOS Patition Table
> n #Create new Partition
> p #Primary
> [Enter] #At first sector
> +300M #with 300MB size, change to whatever you want for your "Homebrew"-Partition

That was our first partition that is going to be out vfat-homebrew partition, now comes the rootfs partition
> n #Create new Partition
> p #Primary
> [Enter] #At first useable sector (behind our vfat-partition)
> [Enter] #With maximum of size (Here: 700MB)
> w #Write everything to device
> q #Quit fdisk

Now we have our Partitions. But they need a filesystem. In this example we use mkfs for this task:
# mkfs.vfat /dev/mmcblk0p1 #Watch your path!
# mkfs.ext3 /dev/mmcblk0p2 #Same here!

Now you are ready to go. Copy GcImage.dol to the 1st Partition and the rootfs to the second.

=So what’s next?=
The next part is to include the software we need. This isn’t very problematic because we can use every binary which is compiled for a PowerPC! So what I did is that I downloaded my binaries and libraries from the Debian package-Service [3]. And used the libSDL and the mplayer binary from the mfe-distribution, since they were included in the filesystem. I just added the libraries for divx and mp3.

If you have an Broadband-Adapter in your Cube, you could even install apt-get and just download the packages directly on your cube! 
Another possibility for creating a big but good root file system would be the way from the GC-Linux wiki [4].

=Need Help? Got Ideas? Want to Help?=
Join the GC-Forever Community! :) [0]

=Links=
[0] http://nold.freeunix.net/devnull/index.php?show=./Stuff/Consoles/Gamecube/GameCube%20Linux 
[0] http://gc-forever.com 
[1] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Creating_the_SD.2FMMC_card_device_nodes 
[2] http://www.gc-linux.org/wiki/Memory_and_Filesystems#Create_the_device_node_for_the_audio_RAM_driver 
[3] http://packages.debian.org 
[4] http://www.gc-linux.org/wiki/Creating_a_Root_Filesystem 
[5] http://ngc.scorpei.com/GUIDE-SD_adapter.html 

[[Category:Software]]

Playing Imports

2024-07-23T07:04:35Z

Lumina33: bolded title

The Gamecube utilized a regional lockout protection which was governed by the IPL ROM ([[WikiScene:GameCube#GameCube_Original_BIOS_.28IPL.29_Version_Information|Gamecube "BIOS"]]) to prevent the console from playing out-of-region titles('''imports'''). 

Since the hardware is mostly 100% identical across all regions (apart from NTSC/PAL hardware differences for video output), several universal methods exist which can bypass the lockout protection. These methods include:
* [[Region Switch]] - NTSC-U '''&''' NTSC-J only hardware mod to allow NTSC-U models to play Japanese titles, or vice versa.
* [[Freeloader]] - Bootdisc based solution for original titles without modifying the Gamecube.
* [[:Category:Modchips|Modchip]] - Hardware based solution installed to the Gamecube.
* Homebrew - Particularly [[Swiss]], this will allow imports from all regions to be played.

----

{| border="3" align="center"
|-
! colspan="1" style="background:lightblue;font-size:10pt" width="200"| Gamecube Regions
! colspan="1" style="background:lightblue;font-size:10pt" width="300"| Region Lock Bypass Methods
|-
| style="text-align: center;" | '''NTSC-U''' ( USA )
| style="text-align: center;" | [[Region Switch]] for NTSC-J [[Freeloader]] [[:Category:Modchips|Modchip]] Homebrew
|-
| style="text-align: center;" | '''NTSC-J''' ( Japan )
| style="text-align: center;" | [[Region Switch]] for NTSC-U [[Freeloader]] [[:Category:Modchips|Modchip]] Homebrew
|-
| style="text-align: center;" | '''PAL''' ( Europe & Australia )
| style="text-align: center;" | [[Freeloader]] [[:Category:Modchips|Modchip]] Homebrew
|-
|}
[[Category:Howto]]
[[Category:Modchips]]

Freeloader

2024-07-23T07:03:56Z

Lumina33: linkify Datel

[[File:Freeloader_ntsc.jpg|right|thumb|150px]]

'''Freeloader''' is a bootdisc based solution developed by [https://www.datel.co.uk/ Datel] to circumvent regional lockout on the Gamecube. It allows unmodified Gamecubes to play '''original''' out-of-region ([[Playing_Imports|import]]) titles. Datel sold different versions of Freeloader compatible for use with NTSC (USA, JPN) and PAL (EUR) Gamecubes.

[[File:Freeloader_pal.jpg|left|thumb|150px]]
== Features ==
* Launch and play imported GameCube games from any region.
* No need to modify your console - keeps your warranty intact.
* Add loads of new titles to your GameCube collection, including games never released in your region.
* Play ANY region of games ANY GameCube.
* Fast and easy to use.
* Compatible with the [[WikiScene:GameCube#Panasonic_Q|Panasonic Q]].
* Not 100% compatible with the Japanese version of ''F-Zero GX'' and ''Paper Mario 2''.
* Does not allow use of DVD±R for [[Create_a_bootable_homebrew_disc|homebrew]] or [[Backing_Up_Discs|backups]].

'''Important:''' When playing a Japanese game, the memory card will be re-formatted to Japanese settings, overwriting any existing US or European settings and any game saves stored on the card. Recommend keeping a separate card for use with Japanese games only.