Getting GeckoOS to Patch/Debug Itself

Started by biolizard89, December 05, 2009, 07:49:02 PM

Previous topic - Next topic

biolizard89

So I need to peek/poke a few variables before the apploader runs.  I figure the easiest way to do this (short of editing/recompiling GeckoOS, which I would prefer not to do) is to have GeckoOS boot and debug itself, so that I would run GeckoOS once (debugger not running), boot it again (so that the code handler is running on GeckoOS), send the peek/poke commands, and then have GeckoOS boot the game.  I'm using the GameCube version of GeckoOS.  Unfortunately, I have been unable to find a way to get it to boot itself with debugging.  I first tried to have GeckoOS launch the burned GeckoOS disc (I have WiiGator's GameCube Backup Launcher cMIOS installed), but I get a disc error (I conclude that the GC backup launchers don't support that).  Then I tried running the GeckoOS dol file through GeckoLoad.  GeckoOS launched, but the USB Gecko didn't respond, implying that the code handler either was not launched or wasn't able to hook GeckoOS.

So... is there any solution to this that I missed?  I'm pretty much out of ideas.  Having GeckoOS debug itself seems like a pretty simple concept; Action Replay and GCARS could do it just fine.

Thanks!

WiiPower

I think the GC stuff is complicated in general. This may be a stupid question, but did you move the entrypoint of your 2nd Gecko OS, so it won't use the same memory as the 1st one?

biolizard89

Quote from: WiiPower on December 05, 2009, 10:42:45 PM
I think the GC stuff is complicated in general. This may be a stupid question, but did you move the entrypoint of your 2nd Gecko OS, so it won't use the same memory as the 1st one?
I did not, but I think this should be a nonissue, because the code handler is all I need to be running at the same time as the 2nd GeckoOS, and the code handler sits in an otherwise unused exception vector area, which I'm fairly sure the 2nd GeckoOS doesn't touch until it boots a game.  Or am I confused?

giantpune

i think you are probably going to have to use 2 different dols to do this.  the dol is compiled with a spot it will reside in memory.  so using a dol to boot itself means that while the first instance of a dol it still trying to boot the second one, it is overwriting itself.  you should try to either compile 2 versions of geckoOS with different entrypoints or use a preloading dol.  which is what FTPii does.  it if really a dol with a dol inside it.  so it starts and then loads the real dol.