I would like to do some Homebrew development on my TDEV Gamecube. I want to be able to debug with a source code debugger and not have to burn disks. With the official tools this is done with a boot disk that allows the gamecube to connect over a network to a virtual drive. From what I am able to gather I could just use the gcube emulator and not use the hardware at all (with the limits of the emulation). I am looking for some feedback from people who use the devkitPPC tools and the emulator/hardware as to the limits of both the emulator and the hardware. If you have something to say please don't just say what to do, add a why so I can evaluate the information on my own. I will appreciate any information that can help me make a more informed decision.
Thanks in advance.
My ultimate goal is to set up my 40 TDEV units in an environment where then can be used to build and test gamecube code without concern for proprietary restrictions. I DO NOT WANT to be able to play any commercial games in this environment (which is why I have TDEV units). I already own the units so I can't go out and buy more "modified" gamecubes because of money and the ability to play commercial games.
Homebrew Dev on Game Cube TDEV hardware
-
- Posts: 11
- Joined: Mon Nov 12, 2007 10:47 pm
- Location: Winter Springs Florida, USA
Re: Homebrew Dev on Game Cube TDEV hardware
Hi,
Well i think you're on the wrong way..
Devkits architecture slightly differs from retail versions, moreover homebrew SDK is *not* supporting hw dev units *only* retail units.
I don't know precisely the tidbits but outdated/unsupported official tools from N. were generating incompatible elf binaries/gcm(s)
( i don't really know if it's only code signing related or worse)
Anyhow, i think that the only way to keep your 40 TDEV out of the trash bin of history is to search (but dunno where or even it exists) for a h****ed version of the official SDK (which has expiration licence or equ) .. Then, you'll be able to use the hw debuger and toolz..
But... you'll still be stuck with incompatible binaries for retails! so no one will be able to execute your stuff and N gcube submissions are closed for years. ^^
So, as a conclusion you should have to maintain a second compile path for the devkitro SDK to release proper binaries for retail.
As far as i know, you can mod retail consoles to enable hw debugging if it is your main concern.
Finally, you can also being a better hardcore coder and only use an emulator/simulator for development and then test your generated gcm master on retail.
You can check my little page for some infos: [EDIT: hacky reference removed]
good code and good luck.
Well i think you're on the wrong way..
Devkits architecture slightly differs from retail versions, moreover homebrew SDK is *not* supporting hw dev units *only* retail units.
I don't know precisely the tidbits but outdated/unsupported official tools from N. were generating incompatible elf binaries/gcm(s)
( i don't really know if it's only code signing related or worse)
Anyhow, i think that the only way to keep your 40 TDEV out of the trash bin of history is to search (but dunno where or even it exists) for a h****ed version of the official SDK (which has expiration licence or equ) .. Then, you'll be able to use the hw debuger and toolz..
But... you'll still be stuck with incompatible binaries for retails! so no one will be able to execute your stuff and N gcube submissions are closed for years. ^^
So, as a conclusion you should have to maintain a second compile path for the devkitro SDK to release proper binaries for retail.
As far as i know, you can mod retail consoles to enable hw debugging if it is your main concern.
Finally, you can also being a better hardcore coder and only use an emulator/simulator for development and then test your generated gcm master on retail.
You can check my little page for some infos: [EDIT: hacky reference removed]
good code and good luck.
Who is online
Users browsing this forum: Ahrefs [Bot] and 2 guests