Share This Page

Since the most popular mod chips are kind of impossible to find these days why not use a more modern replacement like a Raspberry Pi (zero)? There actually already was somebody that used a Raspberry Pi in bare metal mode to replace the XenoGC, but the powerful Raspberry Pi hardware could be used for much more!

If you would take a Pi 3 B+ for example it would have..
- 300 Mbit Ethernet
- 150 Mbit Wifi
- Bluetooth
- USB Host
- Large SD for extra storage

There is already a C++ library called "Circle" that is designed for bare metal programming of the Raspberry Pi and it has classes to use for most of the internal hardware. If the Raspberry would connect to the Gamecube with a high speed connection through EXI or the memory card slot it would make this extra hardware available and an alternative to the rare and expensive broadband adapter, SD Gecko, USB Gecko, EXI-IDE and add USB host, WiFi and Bluetooth!

I have had this crazy idea for a few months but limited time and other projects have so far prevented me fom testing any of this. I like to hear what others think about an option like this.

Since the most popular mod chips are kind of impossible to find these days why not use a more modern replacement like a Raspberry Pi (zero)? There actually already was somebody that used a Raspberry Pi in bare metal mode to replace the XenoGC, but the powerful Raspberry Pi hardware could be used for much more!

That was actually based on another project using an arduino and has some nice features. I never got around to testing it and had the idea of porting that to a more powerful STM32 board which are dirt cheap from china. Still have wires coming out of my GameCube soldered to the drive board just for this...now I will ask Santa for some extra spare time to work on this I guess.

The truth is the memory card slot is not high speed at all. It's SPI as far as i know. With luck you get 16 mbit/s out of that.

It's possible to replace a modchip with the Raspberry Pi but you are wasting quite a bit of power if the only task it does is forcing the drive (with whatever technique. No idea how the GC modchips work.) to accept burned disks.

That was actually based on another project using an arduino and has some nice features. I never got around to testing it and had the idea of porting that to a more powerful STM32 board which are dirt cheap from china. Still have wires coming out of my GameCube soldered to the drive board just for this...now I will ask Santa for some extra spare time to work on this I guess.

Click to expand...

Whenever you have the time, man! Batterycheck sure will keep you busy for a while.Thanks in advance for both projects.

Whenever you have the time, man! Batterycheck sure will keep you busy for a while.Thanks in advance for both projects.

Click to expand...

A bit late to respond here......but yeah I have been pretty busy with Batterycheck and getting the game engine running on all the platforms. But since I released the preview versions on the important platforms I could take a little break and do some hardware stuff like this. That is after all the whole reason I started wrinting homebrew in the first place.

The truth is the memory card slot is not high speed at all. It's SPI as far as i know. With luck you get 16 mbit/s out of that.

It's possible to replace a modchip with the Raspberry Pi but you are wasting quite a bit of power if the only task it does is forcing the drive (with whatever technique. No idea how the GC modchips work.) to accept burned disks.

Click to expand...

How did you get the idea that the Memory Card slot is not a high speed interface? On the YAGCD pages you can see that the Broadband Adapter is connected on the same EXI channel as Memory Card Slot A! It's true that there is also a much faster HighSpeedParallel port on the bottom which you could also just label as the GameBoy Player connection since that is the only device that has ever come out that uses it. I do have to agree with you on the maximum speed that might be possible would not be much higher than 16Mbit, but if you consider the speed of USB 1.1 or USB 2.0 Full Speed which is only 12Mbit I do not think this connection is really slow.

From what I have read about modchips and in this case the XenoGC clone made with an Arduino like chip it changes the firmware in the drive controller through the debug interface. Yeah I know it's actually an Atmel ATMEGA8 but Arduino is a better known name. This is what makes the drive accept disks from other regions and even burned disks. The clone also has a way to include a small menu DOL in the firmware that can be loaded at certain times to configure some options I think. While really awesome this method is limited by the truly low speed of the drive debug port and the small 32KB flash of the ATMEGA chip. Just replacing that with a raspberry pi is indeed a waste of the potential but it does eliminate the small storage issue with it's huge SD card.

My idea is not to replace the "drive chip mod" but to use a homebrew loader that will can acces the Raspberry Pi hardware devices through special drivers. This would give you for example: SD Card storage, USB Host, WiFi, Bluetooth, Ethernet, and if you really want to squeeze the juice out of the berry there is a huge 900MB+ RAM space that is not in use! It's true that he EXI bus is really just a very fast SPI port (compared to the XenoGC or an arduino) and I was hoping the Raspberry Pi board had the SPI slave pins exposed on the board. I know the SoC is capable of this because it is in the documentation but I read somewhere that the required pins are not exposed on all revisions. There is definitely no driver written for this mode yet, but with the datasheet that should not be that much of an issue.

I know this will not be easy and it will take a very long time to develop and test every bit of it. If you look at it from a higher level it starts with a physical link layer to transfer data between the gamecube and the raspberry pi, preferably at high speeds but if I have to use a 56k serial connection to get started I would even consider it! And I passionately HATE RS232 serial connections because they are slow and unreliable in my opinion! When the pysical layer is working you get the data layer which can send data in both directions. On top of that there would be low-level interface code that will make it possible to write drivers on the PPC side that access the Rpi peripherals as mentioned earlier. Maybe for some devices it would make more sense to do some of the transfers on the Rpi CPU because we also have the issue of an endian conversion going on between them.

Assuming that last part is going to be realized at some point it should be a matter of writing the necessary drivers that will extend libogc for example to see the rpi SD card as an "rpi:/" prefix. And since Swiss is open-source the same drivers could be made to work and compile a custom swiss that would work with that new hardware.

i know it got way to long but hope I was not to technical and you get the idea I have for this project.

A bit late to respond here......but yeah I have been pretty busy with Batterycheck and getting the game engine running on all the platforms. But since I released the preview versions on the important platforms I could take a little break and do some hardware stuff like this. That is after all the whole reason I started wrinting homebrew in the first place.

How did you get the idea that the Memory Card slot is not a high speed interface? On the YAGCD pages you can see that the Broadband Adapter is connected on the same EXI channel as Memory Card Slot A! It's true that there is also a much faster HighSpeedParallel port on the bottom which you could also just label as the GameBoy Player connection since that is the only device that has ever come out that uses it. I do have to agree with you on the maximum speed that might be possible would not be much higher than 16Mbit, but if you consider the speed of USB 1.1 or USB 2.0 Full Speed which is only 12Mbit I do not think this connection is really slow.

From what I have read about modchips and in this case the XenoGC clone made with an Arduino like chip it changes the firmware in the drive controller through the debug interface. Yeah I know it's actually an Atmel ATMEGA8 but Arduino is a better known name. This is what makes the drive accept disks from other regions and even burned disks. The clone also has a way to include a small menu DOL in the firmware that can be loaded at certain times to configure some options I think. While really awesome this method is limited by the truly low speed of the drive debug port and the small 32KB flash of the ATMEGA chip. Just replacing that with a raspberry pi is indeed a waste of the potential but it does eliminate the small storage issue with it's huge SD card.

My idea is not to replace the "drive chip mod" but to use a homebrew loader that will can acces the Raspberry Pi hardware devices through special drivers. This would give you for example: SD Card storage, USB Host, WiFi, Bluetooth, Ethernet, and if you really want to squeeze the juice out of the berry there is a huge 900MB+ RAM space that is not in use! It's true that he EXI bus is really just a very fast SPI port (compared to the XenoGC or an arduino) and I was hoping the Raspberry Pi board had the SPI slave pins exposed on the board. I know the SoC is capable of this because it is in the documentation but I read somewhere that the required pins are not exposed on all revisions. There is definitely no driver written for this mode yet, but with the datasheet that should not be that much of an issue.

I know this will not be easy and it will take a very long time to develop and test every bit of it. If you look at it from a higher level it starts with a physical link layer to transfer data between the gamecube and the raspberry pi, preferably at high speeds but if I have to use a 56k serial connection to get started I would even consider it! And I passionately HATE RS232 serial connections because they are slow and unreliable in my opinion! When the pysical layer is working you get the data layer which can send data in both directions. On top of that there would be low-level interface code that will make it possible to write drivers on the PPC side that access the Rpi peripherals as mentioned earlier. Maybe for some devices it would make more sense to do some of the transfers on the Rpi CPU because we also have the issue of an endian conversion going on between them.

Assuming that last part is going to be realized at some point it should be a matter of writing the necessary drivers that will extend libogc for example to see the rpi SD card as an "rpi:/" prefix. And since Swiss is open-source the same drivers could be made to work and compile a custom swiss that would work with that new hardware.

i know it got way to long but hope I was not to technical and you get the idea I have for this project.

@Archerite
You can't drive the GPIO pins of the Raspberry Pi fast enough for parallel. It doesn't have hardware support for parallel as far as i know. So SPI is the only option (with the Raspberry Pi alone).

So that's how it works. A Raspberry Pi may be able to do it but not sure how important timing is here. Bitbanging is relatively slow due to high latency between toggling pins which apparently has something to do with register writes going through the Video Core IV GPU first which is the slow path. I don't know the datails. The atmega microcontroller probably has lower latency toggling pins.

Problem is if you want to use multiple of them at once. If you use just Bluetooth for example it will be fine. The RAM is pretty much useless other than using it as extra storage. That's a bit of a waste unfortunately because it could be super fast but is bottlenecked by the slow connection between both devices. Maybe you should take a look into FPGAs to drive that parallel interface aswell.

You can't drive the GPIO pins of the Raspberry Pi fast enough for parallel. It doesn't have hardware support for parallel as far as i know. So SPI is the only option (with the Raspberry Pi alone).

Click to expand...

The GPIO pins are actually quite fast in bare-metal mode (see here). It is possible to make a Rpi work in USB device mode and that would be the fastest way, but useless for the GameCube which does not have a USB host interface. That leaves the SPI port as the only viable option to get any good speed.

So that's how it works. A Raspberry Pi may be able to do it but not sure how important timing is here. Bitbanging is relatively slow due to high latency between toggling pins which apparently has something to do with register writes going through the Video Core IV GPU first which is the slow path. I don't know the datails. The atmega microcontroller probably has lower latency toggling pins.
Problem is if you want to use multiple of them at once.

Click to expand...

In the link I gave above they got the pins to toggle at 22Mhz which is indeed not even close to what would be required for bitbanging a parallel port. There was also something about the ordering of the pins on the header not having a sequential number of pins.

If you use just Bluetooth for example it will be fine. The RAM is pretty much useless other than using it as extra storage. That's a bit of a waste unfortunately because it could be super fast but is bottlenecked by the slow connection between both devices. Maybe you should take a look into FPGAs to drive that parallel interface aswell.

Click to expand...

I was in a sarcastic mood when I mentioned the RAM as a "feature" and it would be pointless to use it for anything other than caching network packets or file data read from the SD card.

I have actually already been looking into other options to use a fast STM32 ARM microcontroller at 180Mhz to interface between the raspberry and the gamecube port. The one I am thinking of using even has a USB 1.1 host port, and with external components also USB 2.0 High Speed and even Ethernet at 10/100Mbit.

As a proof of concept I might just use a smaller one to connect to a free gamepad port and have it translate into USB virtual serial. Already had that planned as a simple and cheap debug option since I do not have an USB Gecko.

I do have a few CPLD's and maybe an FPGA and that would be the ideal solution, but I have never really used them. The required software and the VHDL language was so complex that I could not make it work. And as can be seen with the USB Gecko once a chip goes out of production...there is a problem!

As the Nes Online Game injector wasnt beinng updated , and lack of support for new format
I decided to take things into my hands and release Nes Online Game injector MOD
Wich give the program alot of...

Most North American Nintendo fans will be familiar with the name of Reggie Fils-Aime, the current head of Nintendo of America. It appears that his body is no longer ready, however, as 2019 will be his...