USB Gecko source codes - Hardware and Latest Gecko OS

[dcx2]

Yeah.  It runs once, I think after the dol was loaded into memory, but before control is passed over to it.

Simple ASM patches (like nop'ing the stw) only need to be written once.  It won't work for data hacks like inf health because that needs constant writes, and it won't work for C2 codes because the C2's ASM won't be loaded into memory.  But when you're struggling to fit all your codes in, being able to load the simple ASM patches from something other than your GCT file can give you that little bit of room that you need.

[biolizard89]

I asked Mathew_Wi to update his GCT editor to include GPF support.  If he gets it working, then you can just take 04 codes from the database, drop them into his app, and it will spit out the GPF file that you can place on your SD card.  No need to mess with gameconfig.txt.

@WiiPower, does the new GeckoOS Mod with the newer code handler also support GPF's for GameCube games?  (I don't know anything about how GPF's are implemented, which is why I didn't look at that feature when I sent you the modified sourcecode.)

[WiiPower]

Gecko OS mod does only support the code handler and a very small part of the gameconfig.txt stuff. And that only for wii games.

[dcx2]

So I had this great idea.  Make an application that cuts and pastes new code handlers into the .dol of a homebrew app that's running an old code handler (e.g. Gecko OS Mod).  This idea is nice because then I can start releasing custom code handlers instead of having Gecko.NET patch them.

So I looked through Gecko OS Mod and pretty easily found the code handler binary blob.  Three copies, actually, which makes sense; codehandler, codehandlerslota, codehanderonly.

The same search on Gecko OS 1931...fails.  1932 fails as well.  I can't find the binary anywhere.  I searched both the dol and elf.  Maybe the elf is packed or something?

[WiiPower]

If your code handler is bigger, i expect some problems when your code handler is bigger than the old one. And for Gecko OS mod, it would be easy as well to just add it to the source and recompile.

[dcx2]

Yeah, there are some limitations on how much blank space is left at the end.  It seems like there's about 332 bytes of blank space at the end, and that's assuming I'm trying to patch the smallest code handler.

Recompiling isn't easy for me because I don't have devkitppc or any of that installed.  And I was hoping to make something generic so that anyone can patch any homebrew loader with any custom code handler.

[WiiPower]

Yeah, there are some limitations on how much blank space is left at the end.  It seems like there's about 332 bytes of blank space at the end, and that's assuming I'm trying to patch the smallest code handler.

Recompiling isn't easy for me because I don't have devkitppc or any of that installed.  And I was hoping to make something generic so that anyone can patch any homebrew loader with any custom code handler.

Isn't that the reserved space for variables? So if your code handler is bigger, that space if moved and then overlaps something else. Well, i'm not very good at this, so i could be wrong.

[dcx2]

The code handler sits in the reserved area of memory, 80001800 to 80003000.  However, the C array that the code handler is "stored" in (codehandler.h) is 0x10C0 bytes.  That puts the end of the code handler at 800028C0 - which is precisely where the code list begins.  The code list then consumes the remaining portion, from 800028C0 to 80003000.

The space isn't so much "moved", as it is "reduced" or "pushed back".  If I added 0x40 bytes of patches to the code handler, then I would push the start of the code list back to 80002900.  Technically I would be over-writing where variables are *supposed* to go, but it doesn't depend on the initial values and it wouldn't write to anything above 80003000.  It just means that the debugger would have fewer code lines to work with, which is already true when Gecko.NET connects.  EDIT: on second thought, this would also break SD Cheats, because the code list wouldn't be where the loader expected it to be.  This could probably be worked around with gameconfig.txt

I'll have to try manually splicing a new code handler in with a hex editor.  But none of this answers why I couldn't find the code handler in Gecko OS' dol or elf files.  Is there some sort of packing that can be done on homebrew executables?

[biolizard89]

The code handler sits in the reserved area of memory, 80001800 to 80003000.  However, the C array that the code handler is "stored" in (codehandler.h) is 0x10C0 bytes.  That puts the end of the code handler at 800028C0 - which is precisely where the code list begins.  The code list then consumes the remaining portion, from 800028C0 to 80003000.

The space isn't so much "moved", as it is "reduced" or "pushed back".  If I added 0x40 bytes of patches to the code handler, then I would push the start of the code list back to 80002900.  Technically I would be over-writing where variables are *supposed* to go, but it doesn't depend on the initial values and it wouldn't write to anything above 80003000.  It just means that the debugger would have fewer code lines to work with, which is already true when Gecko.NET connects.  EDIT: on second thought, this would also break SD Cheats, because the code list wouldn't be where the loader expected it to be.  This could probably be worked around with gameconfig.txt

I'll have to try manually splicing a new code handler in with a hex editor.  But none of this answers why I couldn't find the code handler in Gecko OS' dol or elf files.  Is there some sort of packing that can be done on homebrew executables?

There are .dol compressors in existence; one of them is at http://www.fuzziqersoftware.com/projects.php .  So yes, that could be the reason why.