GCN What about a Raspberry Pi as a modern modchip?

[Deleted User]

What do you think about an Raspberry PI AS an Gamecube

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

Sadly only for Emulations.

Last I remember trying RetroPie, it didn't have GC support, or ran like ass.

 

[Archerite]

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

When in ultimate dreaming mode....the Flipper GPU renders the image into a framebuffer and if we can use the disc drive interface at high speeds to transfer the image to the STM32 and then move it over USB 2.0 to the Raspberry Pi and then using it's Videocore GPU as a texture...it might be possible. Maybe. In other more sensible words: NOT going to happen anytime soon

If you really want to get HDMI directly from the GameCube look up GCVideo as prices for that are dropping. It was $150 when it came out and I have already seen version for around $80.

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!

No problem, I was just making sure you got the intentions I have for this project which might need another thread later since I am not going to be using a Raspberry Pi anymore. It does seem to get a lot of attention this way though...

Like I have said before I am just going to experiment and see where it leads, thanks for your vote!

What do you think about an Raspberry PI AS an Gamecube

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

Sadly only for Emulations.

Last I remember trying RetroPie, it didn't have GC support, or ran like ass.

I have the dolphin emulator running on my Note 9 and it's working but sometimes even that is struggling to keep up. At least I can play games now which was impossible at 0.5FPS which I had on my Note 4 before that. My point being that even the Raspberry Pi 3 B+ is not as powerful as a Samsung Note 4, so unless they specifically work on optimizations for the Raspberry Pi (unlikely) don't count on it ever having GameCube emulation.

That little cube Nintendo made is a powerhouse that is not easy to emulate! Just look at the article about the Ubershaders in dolphin if you don't believe me. And there is a similar one about the audio part.

I wonder if that converted Retropie gamecube might have just needed a new powerboard or a fuse or something.....still a cool project to put a Pie into a kids-proof casing though! If you would go through all that trouble it would be even cooler to mod a Wii into the gamecube case and having all it's extra features. More than enough tutorials and guides for portable Wii's to look what can be cut off and how to connect your wires. Some day I might do that myself actually...the WiiCube or Cubii...hahaha

 

[Slaminger]

I've seen pi and tinkerboards joined together and sharing workload to give the boards more overall power. I can't think of a reason this can't be done on the GameCube also. Homebrew and things of that nature can be stored and executed on the rpi, using it's more powerful processor and RAM, and then the necessary data of said operation transmitted to the GC. Dolphin emu exists on rpi but runs like trash. But that doesn't mean the back end won't work if you are simply playing with data and there is no graphical pi output, it's possible it can handle GameCube data. I've used dolphin on PC to test exploits before using on my console. A game exploit will break you out of the GC into your loader..just modify it to communicate with the rpi instead of boot the SD reader of gb player, and that can be the gui on the GC.

--------------------- MERGED ---------------------------

Id have dolphin on the Asus tinkerTinke if they didn't drop 32 bit support. I'm the Retropie on the tinkerboard head software developer and project owner .

 

[Archerite]

Just a little update on my experiments with the XenoPie....I have been cleaning up the wiring and installed dupont connectors so it's less fragile while moving stuff around. Like I said the XenoPie was only meant to test if it would work at all and I will migrate all of it to a STM32 microcontroller later. I have noticed that the drive patch code is not just run at boot but several times after that on each access or reset of the DVD drive. This makes me thing an ALL-IN-ONE controller might not be such a smart idea as it might miss one of the reset events while finishing another task. To replace the XenoPie/XenoGC I was thinking of using the $2 "Bluepill" board which has a smaller STM32 but still has more memory and speed than an Arduino/Atmega chip, and ofcourse A LOT less than a Raspberry Pi but as said before this is a waste of a Pi anyway. What I do like about the XenoPie is that it's super easy and fast to build a new "firmware" and place it on the SD card.

I have tried to use the XenoShell from the XenoGC-fork which should be capable of launching a GCI packed DOL from memorycard. Unfortunately swiss is larger than the 512Kb limit I found inside the sourcecode of the XenoShell. While I have not got swiss to boot yet without a custom disk in the drive I was able to re-compile XenoShell and Xenopie with an extra message that no DOL has been found. Only tested on dolphin to see if it works and not on real hardware yet sicne I was searching for smaller DOL's to convert into GCI and launch those instead. I am also curious if I could force XenoShell (or another payload) to launch without a button combo but I guess that would interfere with the drive patching stuff.

I've seen pi and tinkerboards joined together and sharing workload to give the boards more overall power. I can't think of a reason this can't be done on the GameCube also. Homebrew and things of that nature can be stored and executed on the rpi, using it's more powerful processor and RAM, and then the necessary data of said operation transmitted to the GC. Dolphin emu exists on rpi but runs like trash. But that doesn't mean the back end won't work if you are simply playing with data and there is no graphical pi output, it's possible it can handle GameCube data. I've used dolphin on PC to test exploits before using on my console. A game exploit will break you out of the GC into your loader..just modify it to communicate with the rpi instead of boot the SD reader of gb player, and that can be the gui on the GC.

--------------------- MERGED ---------------------------

Id have dolphin on the Asus tinkerTinke if they didn't drop 32 bit support. I'm the Retropie on the tinkerboard head software developer and project owner .

I am not exactly sure what you are trying to say here. Sure the Raspberry Pi has a very powerfull ARM CPU and a lot of RAM to do really awesome things which would be cool if those became accessible on the GameCube. I am just not sure that with the available connections there is enough bandwidth to transfer a lot of data really fast as would be needed for using the HDMI output. This is why I said "maybe possible but not going to happen any time soon" and not that it's impossible.
What would be the point of having the Dolphin backend running on the raspberry pi and then send some "data" back to the GameCube?? And what does a game exploit have to do with any of this? Like I said...I have no idea what your point is actually.

 

[Slaminger]

Just a little update on my experiments with the XenoPie....I have been cleaning up the wiring and installed dupont connectors so it's less fragile while moving stuff around. Like I said the XenoPie was only meant to test if it would work at all and I will migrate all of it to a STM32 microcontroller later. I have noticed that the drive patch code is not just run at boot but several times after that on each access or reset of the DVD drive. This makes me thing an ALL-IN-ONE controller might not be such a smart idea as it might miss one of the reset events while finishing another task. To replace the XenoPie/XenoGC I was thinking of using the $2 "Bluepill" board which has a smaller STM32 but still has more memory and speed than an Arduino/Atmega chip, and ofcourse A LOT less than a Raspberry Pi but as said before this is a waste of a Pi anyway. What I do like about the XenoPie is that it's super easy and fast to build a new "firmware" and place it on the SD card.

I have tried to use the XenoShell from the XenoGC-fork which should be capable of launching a GCI packed DOL from memorycard. Unfortunately swiss is larger than the 512Kb limit I found inside the sourcecode of the XenoShell. While I have not got swiss to boot yet without a custom disk in the drive I was able to re-compile XenoShell and Xenopie with an extra message that no DOL has been found. Only tested on dolphin to see if it works and not on real hardware yet sicne I was searching for smaller DOL's to convert into GCI and launch those instead. I am also curious if I could force XenoShell (or another payload) to launch without a button combo but I guess that would interfere with the drive patching stuff.


I am not exactly sure what you are trying to say here. Sure the Raspberry Pi has a very powerfull ARM CPU and a lot of RAM to do really awesome things which would be cool if those became accessible on the GameCube. I am just not sure that with the available connections there is enough bandwidth to transfer a lot of data really fast as would be needed for using the HDMI output. This is why I said "maybe possible but not going to happen any time soon" and not that it's impossible.
What would be the point of having the Dolphin backend running on the raspberry pi and then send some "data" back to the GameCube?? And what does a game exploit have to do with any of this? Like I said...I have no idea what your point is actually.

I was basically saying you could use the rpi for the HDMI and boot process, acts as mod chip, allowing burned games and isos, the SD card could store said isos, and when you load a GC iso the pi would transmit the data to the gamecube, sort of like how one can play ps2 games over a network via smb, only it's connected directly to the GC instead of network. The reference to the game and memory card exploit was that it will allow you to break out of the normal gameplay and run an exploit, which would be needed to boot the app that would communicate between pi and gc.