Gecko dotNET Bugs and Requests

Started by Mal1t1a, January 19, 2010, 12:08:54 AM

Previous topic - Next topic

dcx2

#465
First, you must use SD cheats to load the Extended Codes Allocator that I modified from Y.S.  The hook runs as soon as the game starts (before even the wrist-strap safety screen), so you must use SD cheats or pause start (pause start is tricky, just use SD cheats).  The allocator allocates 32kB at the bottom of the stack; some games may not like such a large stack so you may have to shrink it down a bit.  The allocator also places a pointer to the extended code list into block 0.  Once the allocator runs, it is safe to remove from the code list.

[spoiler=extended codes allocator]F6000001 80008180
54030034 48000008
D2000000 00000007
54030034 3D8000D0
618CC0DE 91830000
91830004 3980FFFF
91830008 9183000C
38630008 3D808000
906C1848 38637FF8
60000000 00000000
E0000000 80008000[/spoiler]

---

Once the SD cheat is applied, I suggest going to 80001848 and make sure there's a pointer.  If there isn't, the SD cheat failed.  If there is, then you can continue.

Next, apply the Extended Codes Activator.  This uses a 64-code type (return) to "link" from the original code list to the extended code list.  As a result of "linking" lists, anything that was leftover in the original code list after the 64-code is not executed.  If you remove the activator, the extended code list will not be executed.

[spoiler=extended codes activator]26001848 81800000
24001848 80000000
64000000 00000000
E0000000 80008000[/spoiler]

---

So you ran the allocator from SD cheats.  You ran the activator through send cheats in Gecko.NET.  Now go to the About tab and make sure Extended Codes is checked.  Now go to the GCT tab.  The code checkboxes have three states now; unchecked, checked, and red-checked.  Codes that are just checked will go in the original code list.  Codes that are red-checked will go in the extended code list.  red-checked codes can be in any order; the activator should be the last checked code, because any remaining checked codes will be ignored.

EDIT:

btw, if you have problems with zombie Gecko.NET processes (which I don't have, so I can't fix it...) try unplugging the USB cord.

Arudo

What games/code sets would require using the extender/activator?
-Crazy Hacker Hates You All (definitely)-

ノಠ益ಠ)ノ彡â"»â"â"»

Do NOT PM me about Code Requests

Pro-tip: Hit the Applaud Button

Oh? Failed to read the rules? You're already dead.

dcx2

Brawl has the File Patch code.  SMG2 has the Transformations code.  Neither of these codes can be loaded with the debugger, which makes them almost impossible to work on.

Keep in mind that the code line limit with the debugger is something like 200 or so lines.  Even if you don't have those codes, some games have a lot of codes and sometimes they're very long.

Also, Gecko.NET code handler patches take up code space.  Now that we can have 4000 lines of codes, I can start making all kinds of code handler patches.  For instance, I have plans to make a patch which can load new values into the float registers.  Another patch could get all 64-bits out of the float registers, instead of just 32-bits.  These patches will no longer compete for code space.

James0x57

Have to have a good solution for the non-hackers though....


dcx2

Who cares about cheaters?  =P  Just kidding.

I mentioned in the other topic about the code extender that we could use gpf files and a new Extended Codes Allocator that also copies the codes that were gpf'd.  We just need a suitable memory area to gpf the extended codes to.  It doesn't need to be permanent, it just needs to be unused by all games until the Allocator runs.

James0x57

Eh... I don't like the gpf idea personally.

These code handler patches you're excited about would only be optional through Gecko dotNET, right?


dcx2

What's wrong with the gpf idea?  I can make an app which creates a gct and gpf for a game.  Place them on the SD card, turn on SD patches, done.  No changes to the code handler, no changes to Gecko OS.  And it leaves USB and backup loaders in the dust because they don't support gpf.

Also, I should have been more clear, they're *debugger* patches.  From a plain old cheater's perspective, there is nothing wrong with the code handler.  The debugger needs a few patches and I can envision some extensions, none of which affect cheaters.

James0x57

@debugger patches Ahhh. I see.

@gpf:
1) /another/ file on the sd card
2) no common game enhancer apps currently support it (including accio hacks and geckocodes.org)

compression *could* be a cleaner, more epic solution if a code handled the decompression.
implementing compression to creating gct files is less of a pain in the arse than handling /another/ file.

Just IMO.


I'm not going to argue any of it- I can see reasons against compression too. (probably isn't a good-enough solution that'll fit in the footprint with the compressed codes AND allow the expanded area to be even 50% filled up after decompression.)


dcx2

1) You're already putting one file on the SD card.  No harm in putting a second.  Besides, the gct file will be the same for all games and never changes; if they want to add or change codes, all they have to do is replace the gpf file.  So technically they're still managing only one file.

2) gpf files are really easy to make, especially if they have only one patch.  That's practically identical to gct files, just with a different header.

3) I can't envision a compression solution that fits in the <1kB while leaving enough room to fit a reasonable amount of codes into the remaining space.  And the existing game enhancer apps don't support compressed gct, either, so you still need changes to them.  Adding compression is arguably more difficult than swapping "00D0C0DE00D0C0DE" with "0190000000[byte length in hex]".

Arudo

I'm getting some -severe- lag going on with ram dumping MEM90 on my system. Hopefully it's just the one game, but I hardly ever make ram dumps and even the ones I do make usually don't freeze up Gecko.Dotnet on my system.
-Crazy Hacker Hates You All (definitely)-

ノಠ益ಠ)ノ彡â"»â"â"»

Do NOT PM me about Code Requests

Pro-tip: Hit the Applaud Button

Oh? Failed to read the rules? You're already dead.

dcx2

Doing search dumps, MemView dumps, Disassembly dumps, Tools tab dumps?

The lag happens while dumping, or after dumping is over?

What game?  What do you have the top of MEM2 set to on the Tools tab?

It doesn't affect MEM1?

Arudo

Went to Tools -> Memory Dump -> DUMP90.BIN
Mem2 boundary: 93400000

Doing this for Harvest Moon Animal Parade NTSC-U

Clicked Dump -> The progress got to 99% and the process for GeckoDotNet started to hang on my PC.
The Dump was made, but was a 0 byte bin file.

The MEM1 Dump80 worked fine, I got  24mb bin file.

And during the lag/hang of GeckoDotNet, the game (which was playing it's intro scenes) started to skip/lag much like how it would if Memory Viewer's auto-update was on.
-Crazy Hacker Hates You All (definitely)-

ノಠ益ಠ)ノ彡â"»â"â"»

Do NOT PM me about Code Requests

Pro-tip: Hit the Applaud Button

Oh? Failed to read the rules? You're already dead.

dcx2

...very weird.  IOS has protected memory at the top of MEM2.  Accessing it is a big no-no (unless maybe you're using AHBPROT).  That's what the MEM2 boundary is supposed to protect against.

When doing a Tools dump, instead of using 93400000 as your end value, try 93300000 as the end value.

XeR

Would it be possible to have jokers in WGC names?
For example, if I put a F6 code in RSB_01.wgc, the code will be shown in RSBP01, RSBE01 and RSBJ01
Or even ______.wgc for codes that will work on every games (mdmwii's slowdown, or a C0 code for example)

dcx2

I think the term you're looking for is wild card.  I can look into adding that feature.  It would certainly make it easier to apply the Extended Codes Allocator.