GCN What about a Raspberry Pi as a modern modchip?

[Archerite]

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.

 

[niuus]

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 paragraph alone would make it totally worth it!

 

[Archerite]

That paragraph alone would make it totally worth it!

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.

 

[ghjfdtg]

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.

 

[niuus]

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.

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

 

[Archerite]

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

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.

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.

 

[Deleted User]

i'd support it, it'd give a use to my model 2B+ if it happens lol, that is if there was a solderless option which should be possible considering the pi has actual pins on it

 

[niuus]

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.

Really interesting read. I'm kinda hyped for the possibilities

 

[ghjfdtg]

@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.

Good luck with this project. I will have an eye on it.

 

[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).

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.

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.

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!

Good luck with this project. I will have an eye on it.

Thanks, I am glad to see there is enough interest and skepticism to get a discussion going.

Note to self: Write shorter replies!

 

[Archerite]

I am glad I am not the only one crazy enough to see the Raspberry's potential! I have found this article
where a guy used a Raspberry Pi Zero W on the Nintendo Switch as a storage bridge to his NAS!

The switch sees a normal USB storage device which the rpi 'emulates' and redirects the requests over iSCSI (a low level network storage protocol) to his Synology NAS. And it's fast enough to play actual switch games through it.

This shows my crazy idea might not be that crazy after all

 

[Archerite]

While I was testing the latest version of my homebrew game on the GameCube and was reminded how frustrating it was to launch homebrew using the SD MediaLauncher! That also reminded me that I had already received some required components to continue on the idea for a modern modchip but never really got around to even test them. I had already selected a chip from the STM32 family of micro controllers that should allow the GameCube to have Ethernet and USB host features. I know this means the "modchip" will not be using a Raspberry Pi anymore and thus this might not be the best thread to continue talking about it in the future. I just wanted to let those interested in an option like this that in a few weeks I am going to start on making this work and see how far it will succeed.

Here is a picture of some of the boards that I am going to use for this project:


The blue board on the left has a STM32F407VET6 microcontroller that can run at 168Mhz has 1MB of flash and 192KB of SRAM and includes a lot of cool hardware features like:
- 10/100 Ethernet MAC with dedicated DMA (Should be capable of 100Mbit's with another expansion module like the black board)
- USB 2.0 full-speed device/host/OTG controller with on-chip PHY (sounds really cool but limited to 12Mbit's)
- USB 2.0 high-speed device/host/OTG controller with dedicated DMA (high speed 480Mbit's but requires expansion module like the green board)
- SDIO interface (for an SD card or other devices)
- Up to 3 SPI ports which can reach speeds of 43Mbit/s (MemoryCard slots and the EXI bus to which the BroadBandAdapter connects are basically SPI)
- Up to 4 USARTS with a max speed of 10Mbit/s (fancy name for serial ports like RS232 but at a different voltage)
- Up to 3 I2C interfaces (slow two wire communication like used by the Nunchunck and classic controllers for the Wii)

The green board uses an USB3300 high speed USB physical interface that connects to a special ULPI bus on the STM32F407VET6 that in theory allows for really fast USB transfers. This expansion board costs about 10 euro which is nearly the same as the blue STM32 board but because it should allow a much higher USB speed I think it would be worth it. And finally the black board which has a LAN8720 Ethernet controller to connect to the RMII bus and gives 10/100Mbit/s Ethernet and costs less than 2 euro per board!!! Meaning this would be a total of just about 25 euro and supports a TON of features and possibilities.

I do not know yet if it would be possible to make the STM32 act like a real BroadBandAdapter so it could be used with official games like MarioKart Double Dash...or if that would be worth the effort anyway. The idea I have is that with this hardware and a low-level device driver other higher level libraries like libogc would be able to see an Ethernet device and two USB ports to use for whatever they have support for. Whatever comes out of this that might be useful I will shared as opensource using a license that makes it possible to maybe be included into libogc eventually (wishfully thinking ahead )

 

[Archerite]

I figured it would be easier to test anything for 'my new modchip' when I have an existing one working to learn from. And since I had already prepared a gamecube for that with wires sticking out on the side I thought it was finally time to test them!

I have looked into making a XenoGC clone with an 'arduino board' but I thought why not just see if that raspberry pie project I linked to before actually works! So after preparing an SD card and following the instructions it did not work. Rechecking the wires and it all looked ok...after the third time I noticed I swapped two pins....oops.
Luckily nothing seemed to be damaged since after that I could get into the XenoShell 'menu', although the version included with xenopie is old and does not support booting from memorycard. It did launch!

Eventually I got a disc burned correctly for the gamecube to read it but it required a serious tweak of the laser potentiometer. I started from 200ohms and anything above 120ohms prevent the disc from working. So now I can boot into swiss MUCH faster but I am afraid the laser value is so low it might burn out. This was a cheap GameCube I bought especially for testing this, and I have two other working ones as backups (in addition to 6 wii's....don't ask why ). So if it ends up burning out it won't be the end of the world, but still....

Is this value normal for the drive to read burned discs? from what I found 150ohms is the most common 'safe value' to use but then it won't read the disc.

 

[Mazamin]

That would be really interesting, and I hope it will enable hdmi output in some way, including widescreen hack et cetera

 

[KleinesSinchen]

Nice.

Eventually I got a disc burned correctly for the gamecube to read it but it required a serious tweak of the laser potentiometer. I started from 200ohms and anything above 120ohms prevent the disc from working. So now I can boot into swiss MUCH faster but I am afraid the laser value is so low it might burn out. This was a cheap GameCube I bought especially for testing this, and I have two other working ones as backups (in addition to 6 wii's....don't ask why ). So if it ends up burning out it won't be the end of the world, but still....

Is this value normal for the drive to read burned discs? from what I found 150ohms is the most common 'safe value' to use but then it won't read the disc.

If read somewhere (don't know the source anymore) that it depends on the actual drive and on wear and tear. Some GC read backups with higher resistance, some need a fairly low. I have two cubes. One of them will not read backups. Period. Lowering the resistance had no effect whatsoever. Pressed discs run fine for hours without any error but I think the laser is on it's last leg and will fail soon.
The other GC has the potentiometer set to about 230Ω or 250Ω and reads the backups quite fine.

Set Swiss to turn off the drive automatically. For the homebrew testing you do not need constant reading backups. Should not be much stress for the laser.

(in addition to 6 wii's....don't ask why ).

It's a good idea to get some Wiis now. They are so cheap at the moment. When I see a cheap Wii on the flea market… I can't resist.

===
Still: A full replacement for the optical drive would be the best.
Memory card ports/EXI are slow. Don't know about the network adapter, but that thing is expensive (at least in Germany).

 

[Archerite]

Nice.

If read somewhere (don't know the source anymore) that it depends on the actual drive and on wear and tear. Some GC read backups with higher resistance, some need a fairly low. I have two cubes. One of them will not read backups. Period. Lowering the resistance had no effect whatsoever. Pressed discs run fine for hours without any error but I think the laser is on it's last leg and will fail soon.
The other GC has the potentiometer set to about 230Ω or 250Ω and reads the backups quite fine.

Set Swiss to turn off the drive automatically. For the homebrew testing you do not need constant reading backups. Should not be much stress for the laser.


It's a good idea to get some Wiis now. They are so cheap at the moment. When I see a cheap Wii on the flea market… I can't resist.

===
Still: A full replacement for the optical drive would be the best.
Memory card ports/EXI are slow. Don't know about the network adapter, but that thing is expensive (at least in Germany).

I also read about each drive being different but not at such a low value. I am glad you say it might not be much of a problem. And it's true that I only need it for a short time to boot swiss and run homebrew tests. I think that motor off option is already enabled but good idea to make sure of it to save the laser a bit. As much as I do like that GameCube intro...it's getting annoying seeing it 5 times a minute while testing a failed boot.

It's indeed very hard to resist getting a Wii with the low prices they go for these days. Last one I bought for my nephew cost only 14 euro without any wires! Just because it had a lot of scratches on it which are noticeable on black wii's, at least that's what the description said. Need to do more testing on it but it did power on at least

I agree that a full drive replacement is the best and most future proof solution. At some point the drives will fail or the original discs get bitrot and be unusable! This counts for all disc based systems and it surprises me that they actually still work after almost 15 years!! Happy about it of course but from day one I have hated CD's and DVD's since they get damaged so easily.
The broadband adapter is expensive everywhere because it's useless and rare. I have no idea how much I paid for it 10 years ago but not more than 80 euro I think. It connect's to the EXI bus so it's limited to the same speeds as memorycards and SD Gecko. But it does have some options to use DMA for faster transfers and I plan on doing some bandwidth and throughput measuring on all ports available on the cube (and also the wii actually). Really curious about the results of those tests but I keep getting distracted by other things to get on with it...

 

[Deleted User]

We could probably go a little cheaper and use an Arduino, as I know that there's an Arduino PSX modchip out there. So that's likely a possibility.

 

[Archerite]

We could probably go a little cheaper and use an Arduino, as I know that there's an Arduino PSX modchip out there. So that's likely a possibility.

If you want cheap just go with a regular XenoGC which is almost an Arduino already. It just uses a low power version with more limited memory capacities and no Arduino bootloader, but it can be done. The reason for a more powerful chip is to not just mod it to read backup disks but get the added features listed in previous posts.

 

[Deleted User]

If you want cheap just go with a regular XenoGC which is almost an Arduino already. It just uses a low power version with more limited memory capacities and no Arduino bootloader, but it can be done. The reason for a more powerful chip is to not just mod it to read backup disks but get the added features listed in previous posts.

That's fair enough, I've just finished reading the other posts. My bad for jumping into a conversation without reading everything.

Yeah, this looks like something that would definetely be a good thing, especially if USB loading ends up being a thing. You got my vote!

 

[Alexander1970]

What do you think about an Raspberry PI AS an Gamecube

https://www.instructables.com/id/Retropie-Gamecube-Case-Project/

Sadly only for Emulations.