SSBM DOL that accepts Gecko codes

[Dan Salvato]

It's been on the back of my mind for a while that all this tedious DOL modding business is so unnecessary if we just inject the Gecko codehandler into the DOL. So that's what I did.

SSBM Gecko DOL (for SSBM v1.02)

All you have to do is prepare a Gecko .gct and inject it into location 0x3f7124.

Note: This overwrites the Melee debug menu! You cannot use the debug menu with this mod.

A .gct file always begins with:

00D0C0DE00D0C0DE

And ends with:

F0000000

Simply dumping raw codes into the DOL won't work, you need to make sure that your injection begins and ends with the above. There are plenty of tools/guides on preparing .gct files, which follow this format already.

This works with all Gecko codes, including ASM codes. There is no longer a need to calculate branches and find offsets, etc. Also, Gecko codes that are not ASM in the first place simply work natively now. There are no additional steps.

Enjoy. I will answer questions.

 

[Doq]

Do you mean .gct for gecko code filenames?

 

[oksas]

so does this mean that converting from Gecko codes into DOL will be obsolete from here on out? is this something that could be included in future 20xx builds? I guess you mention that it overwrites the debug menu though, so I would assume it wouldn't necessarily be that universal...

 

[Dan Salvato]

Do you mean .gct for gecko code filenames?

Yes, sorry. Too much work on TE has gotten me accustomed to the .gci extension.

 

[Doq]

TE4dayz

What would happen if you did attempt to use the Debug Menu? i.e. would it crash or just be garbage text?

 

[Dan Salvato]

TE4dayz

What would happen if you did attempt to use the Debug Menu? i.e. would it crash or just be garbage text?

It would crash. It's still possible to build a custom debug menu for more advanced mods, because you can reposition the address of the menu. But, the default debug menu is not usable.

 

[MagicScrumpy]

You're a god, Dan.

 

[DRGN]

This is pretty cool.

What is the ideal solution between Gecko codes or DOL mods though, if both are just as easy to implement? It would seem to me to be DOL mods, for code execution efficiency (not to mention you would then have more free space for codes and/or be able to include the debug menu).

One thing I've wondered is whether all Gecko codes can even be turned into DOL mods at all though. Aren't there Gecko specific commands that are a combination of ASM codes, which can't directly be converted (meaning you can only translate them with the Gecko codehandler)? If so, what commands are these?

 

[Cyjorg]

This is pretty cool.

What is the ideal solution between Gecko codes or DOL mods though, if both are just as easy to implement? It would seem to me to be DOL mods, for code execution efficiency (not to mention you would then have more free space for codes and/or be able to include the debug menu).

One thing I've wondered is whether all Gecko codes can even be turned into DOL mods at all though. Aren't there Gecko specific commands that are a combination of ASM codes, which can't directly be converted (meaning you can only translate them with the Gecko codehandler)? If so, what commands are these?

http://geckocodes.org/index.php?arsenal=1

Gecko codes are ideal and easier to write.

 

[xDvLHD]

You Mean if we Dumped the Debug Menu And Replace It with Raw Gecko Codes Made Much easier then making custom sub menu's and lot easier for extended working on some release's >> Gecko codes is RAW Type but how to inject them in the DOL while using HxD Or any other hex system ?
sorry for my English its my second Language

 

[Tater]

So first off, I want to say this is an awesome mod. Great job on it

Unfortunately, I'm having an issue with it... It seems that once a certain number of lines of code are added, the game doesn't handle them properly and crashes on startup as a result.

Any combination of two codes from the list below will work fine, but once I add a third code, the game no longer works.

Spoiler

custom SSS color(blue) (1.2) [Shamrock]

Spoiler

C225A3C0 0000000C
3E000000 621000FF
3E20804D 623176DB
8A310000 1E310003
3A400000 5613063F
7E738A14 2C1300FF
40810008 3A6000FF
5610002F 7E109B78
5610C03F 3A520001
2C120003 41A0FFD8
3E2080CA 62313570
92110000 92110004
C001001C 00000000

Yellow Color Overlay During IASA Frames(1.02) [Achilles]

Spoiler

C2071960 00000007
98032218 98030504
3C00437F 900304B8
900304BC 900304C4
38000000 900304C0
900304C8 900304CC
900304D0 900304D4
60000000 00000000

Stock Dependent Revival Platform Colors (1.02) [Achilles]

Spoiler

C20D5008 0000001C
7C7E1B78 3FE08016
63FFB094 7FE803A6
4E800021 2C030001
408200C0 3C60801A
60634340 7C6803A6
3C608047 60639D30
88630000 4E800021
2C030001 4182009C
7FC3F378 3E608045
626FBF12 8A0F0002
2C100004 40820084
3E00804D 821064FC
626F310E 8BE3006C
1DDF0E90 7DEE78AE
2C0F0001 41820040
2C0F0003 41820020
2C0F0002 41820024
3E20BAB0 6231FFFF
3E408000 625280FF
48000024 3E2000FF
3E400059 48000018
3E20FF99 3E409F5F
4800000C 3E20FF00
3E409000 623100FF
625200FF 92300AC4
92500AF0 92300B90
92300CE0 92300D18
7FC3F378 00000000

Random Hitbox Elements - Modified Attack Specific(1.02) [Achilles]

Spoiler

C20715B0 0000000B
807E0030 2C030011
40820044 7C0F0378
38600010 3C808038
60840580 7C8903A6
4E800421 2C030004
41A2FFE8 2C030007
41A2FFE0 2C030008
41A2FFD8 2C03000B
41A2FFD0 907E0030
7DE07B78 28000009
60000000 00000000

Custom Cursor Snap After Selecting Name Tag(1.02) [Achilles]

Spoiler

C2263DB0 00000004
981F001A 3C80804A
60840BC0 1C1C0004
7C84002E 3C00C1A8
90040010 00000000

As you can see, the codes are fairly diverse in what they alter and until I add a third code they work fine, so I don't think it's a case of codes interfering with one another. I've tried using both Ocarina Cheat Code Manager and the .GCT compiler at http://geckocodes.org/index.php?gct= and both produce the same result.

I'm using HxD to inject the contents of my .GCT file, if that's something significant.

I'm running Melee on dolphin with cheats disabled so there's no chance of other codes interfering.

I feel like I'm probably missing something simple, but I have no idea what it could be. Is anyone else having an issue like this?

 

[DRGN]

It's late, so I'll be brief, but I seem to be getting similar behavior.

Running Dolphin 4.0 (master branch)

I can include some small codes that work fine, such as 'Unlock all 293 Trophies', 'Disable Initial Bricks on Green Greens', 'Disabled FD Transitions', but when I try longer codes, Dolphin just crashes (closes) as I load the game. With some more testing I could probably find the max number of bytes that works.

Also, a few times I've gotten the error, "BackPatch: Currently only supporting reads. Attempted to write to 82007a01.", followed by "Backpatch write - not through EAX". I'm not exactly sure how to reproduce it yet though. But I know one time I got it just by trying to run "D-Pad Down at Vs. Mode CSS Loads Rumble Select Screen" with nothing else. (Any ideas what this could mean @ Dan Salvato ?)

I have very few other mods on this test copy. Just these static overwrites: 'unlock all characters, stages, & random stage select', 'players can choose the same costume color for the same character', 'every character can walljump'.

I don't even really know for sure if these problems are related to this method of Gecko code implementation or something else, since I haven't done a lot of work with Gecko codes.

 

[tatatat0]

Would there be any way to use this with 20xx??

 

[tatatat0]

Also I followed your instructions, put
00D0C0DE00D0C0DE before and
F0000000 after my codes, and injected it into the specified offset. Now I am just getting a nice black screen with 0 frames.

 

[Tater]

Also I followed your instructions, put
00D0C0DE00D0C0DE before and
F0000000 after my codes, and injected it into the specified offset. Now I am just getting a nice black screen with 0 frames.

There's a little inconsistency I noticed with the format of .GCT files and the format that this DOL needs; Normally, a .GCT file starts with 00 D0 C0 DE 00 D0 C0 DE and then just lists one Gecko code after another until there are no more codes, and then ends the file with F0 00 00 00 00 00 00 00.

However, injecting codes that way doesn't work properly for some reason; What does work is putting 00 D0 C0 DE 00 D0 C0 DE before each new code added.

The code below is an example of the exact format I'm talking about.

Spoiler

Yellow color overlay for IASA frames[achilles]

Spoiler

C2071960 00000007
98032218 98030504
3C00437F 900304B8
900304BC 900304C4
38000000 900304C0
900304C8 900304CC
900304D0 900304D4
60000000 00000000

Stock dependent revival platform colors[achilles]

Spoiler

C20D5008 0000001C
7C7E1B78 3FE08016
63FFB094 7FE803A6
4E800021 2C030001
408200C0 3C60801A
60634340 7C6803A6
3C608047 60639D30
88630000 4E800021
2C030001 4182009C
7FC3F378 3E608045
626FBF12 8A0F0002
2C100004 40820084
3E00804D 821064FC
626F310E 8BE3006C
1DDF0E90 7DEE78AE
2C0F0001 41820040
2C0F0003 41820020
2C0F0002 41820024
3E20BAB0 6231FFFF
3E408000 625280FF
48000024 3E2000FF
3E400059 48000018
3E20FF99 3E409F5F
4800000C 3E20FF00
3E409000 623100FF
625200FF 92300AC4
92500AF0 92300B90
92300CE0 92300D18
7FC3F378 00000000

Full code to inject:

Spoiler

00 D0 C0 DE 00 D0 C0 DE C2 07 19 60 00 00 00 07 98 03 22 18 98 03 05 04 3C 00 43 7F 90 03 04 B8 90 03 04 BC 90 03 04 C4 38 00 00 00 90 03 04 C0 90 03 04 C8 90 03 04 CC 90 03 04 D0 90 03 04 D4 60 00 00 00 00 00 00 00 00 D0 C0 DE C2 0D 50 08 00 00 00 1C 7C 7E 1B 78 3F E0 80 16 63 FF B0 94 7F E8 03 A6 4E 80 00 21 2C 03 00 01 40 82 00 C0 3C 60 80 1A 60 63 43 40 7C 68 03 A6 3C 60 80 47 60 63 9D 30 88 63 00 00 4E 80 00 21 2C 03 00 01 41 82 00 9C 7F C3 F3 78 3E 60 80 45 62 6F BF 12 8A 0F 00 02 2C 10 00 04 40 82 00 84 3E 00 80 4D 82 10 64 FC 62 6F 31 0E 8B E3 00 6C 1D DF 0E 90 7D EE 78 AE 2C 0F 00 01 41 82 00 40 2C 0F 00 03 41 82 00 20 2C 0F 00 02 41 82 00 24 3E 20 BA B0 62 31 FF FF 3E 40 80 00 62 52 80 FF 48 00 00 24 3E 20 00 FF 3E 40 00 59 48 00 00 18 3E 20 FF 99 3E 40 9F 5F 48 00 00 0C 3E 20 FF 00 3E 40 90 00 62 31 00 FF 62 52 00 FF 92 30 0A C4 92 50 0A F0 92 30 0B 90 92 30 0C E0 92 30 0D 18 7F C3 F3 78 00 00 00 00 F0 00 00 00 00 00 00 00

Remember, there should only be ONE entry of F0 00 00 00 00 00 00 00, because that tells Gecko to stop looking for more codes(To my understanding, anyways. I could be wrong.)

I've been fiddling with all of this for a while(I've got a dol patcher set up in Crazy Hand, and it works with this gecko code format but only within the limits discussed above) and this method has worked best for me.

 

[DRGN]

There's a little inconsistency I noticed with the format of .GCT files and the format that this DOL needs; Normally, a .GCT file starts with 00 D0 C0 DE 00 D0 C0 DE and then just lists one Gecko code after another until there are no more codes, and then ends the file with F0 00 00 00 00 00 00 00.

However, injecting codes that way doesn't work properly for some reason; What does work is putting 00 D0 C0 DE 00 D0 C0 DE before each new code added.

The code below is an example of the exact format I'm talking about.

Spoiler

Yellow color overlay for IASA frames[achilles]

Spoiler

C2071960 00000007
98032218 98030504
3C00437F 900304B8
900304BC 900304C4
38000000 900304C0
900304C8 900304CC
900304D0 900304D4
60000000 00000000

Stock dependent revival platform colors[achilles]

Spoiler

C20D5008 0000001C
7C7E1B78 3FE08016
63FFB094 7FE803A6
4E800021 2C030001
408200C0 3C60801A
60634340 7C6803A6
3C608047 60639D30
88630000 4E800021
2C030001 4182009C
7FC3F378 3E608045
626FBF12 8A0F0002
2C100004 40820084
3E00804D 821064FC
626F310E 8BE3006C
1DDF0E90 7DEE78AE
2C0F0001 41820040
2C0F0003 41820020
2C0F0002 41820024
3E20BAB0 6231FFFF
3E408000 625280FF
48000024 3E2000FF
3E400059 48000018
3E20FF99 3E409F5F
4800000C 3E20FF00
3E409000 623100FF
625200FF 92300AC4
92500AF0 92300B90
92300CE0 92300D18
7FC3F378 00000000

Full code to inject:

Spoiler

00 D0 C0 DE 00 D0 C0 DE C2 07 19 60 00 00 00 07 98 03 22 18 98 03 05 04 3C 00 43 7F 90 03 04 B8 90 03 04 BC 90 03 04 C4 38 00 00 00 90 03 04 C0 90 03 04 C8 90 03 04 CC 90 03 04 D0 90 03 04 D4 60 00 00 00 00 00 00 00 00 D0 C0 DE C2 0D 50 08 00 00 00 1C 7C 7E 1B 78 3F E0 80 16 63 FF B0 94 7F E8 03 A6 4E 80 00 21 2C 03 00 01 40 82 00 C0 3C 60 80 1A 60 63 43 40 7C 68 03 A6 3C 60 80 47 60 63 9D 30 88 63 00 00 4E 80 00 21 2C 03 00 01 41 82 00 9C 7F C3 F3 78 3E 60 80 45 62 6F BF 12 8A 0F 00 02 2C 10 00 04 40 82 00 84 3E 00 80 4D 82 10 64 FC 62 6F 31 0E 8B E3 00 6C 1D DF 0E 90 7D EE 78 AE 2C 0F 00 01 41 82 00 40 2C 0F 00 03 41 82 00 20 2C 0F 00 02 41 82 00 24 3E 20 BA B0 62 31 FF FF 3E 40 80 00 62 52 80 FF 48 00 00 24 3E 20 00 FF 3E 40 00 59 48 00 00 18 3E 20 FF 99 3E 40 9F 5F 48 00 00 0C 3E 20 FF 00 3E 40 90 00 62 31 00 FF 62 52 00 FF 92 30 0A C4 92 50 0A F0 92 30 0B 90 92 30 0C E0 92 30 0D 18 7F C3 F3 78 00 00 00 00 F0 00 00 00 00 00 00 00

Remember, there should only be ONE entry of F0 00 00 00 00 00 00 00, because that tells Gecko to stop looking for more codes(To my understanding, anyways. I could be wrong.)

I've been fiddling with all of this for a while(I've got a dol patcher set up in Crazy Hand, and it works with this gecko code format but only within the limits discussed above) and this method has worked best for me.

I found that discrepancy with FF 00 00 00 00 00 00 00 too by generating a .gct from geckocodes.org, but I hadn't gotten to testing it yet. I was hoping that would be it.

So with your method, are you able to load as many codes/lines as you want (within the limits of the amount of space for the Debug region, anyway)?

Also I followed your instructions, put
00D0C0DE00D0C0DE before and
F0000000 after my codes, and injected it into the specified offset. Now I am just getting a nice black screen with 0 frames.

Did you paste overwrite, or insert (increasing the length of the file)? What code(s) did you try?

 

[Tater]

I found that discrepancy with FF 00 00 00 00 00 00 00 too by generating a .gct from geckocodes.org, but I hadn't gotten to testing it yet. I was hoping that would be it.

So with your method, are you able to load as many codes/lines as you want (within the limits of the amount of space for the Debug region, anyway)?

I can load a maximum of two medium-sized codes and one small code; I'd say that's about.... 50 lines? I'm not sure what the limits of the debug region are though.

 

[DRGN]

The debug region is 0x3AFC bytes long (close to 1900 lines). So that's not the issue. :/

 

[SinsOfApathy]

I diff'd this DOL to pull out the codehandler. It's @ 0x407950 in the DOL for anyone interested. It's just the codehandleronly from GeckoOS along with a pointer to the instruction at 80367D00 instead of a BLR (Didn't convert that to DOL) which branches to 8040A950.

@ Dan Salvato
Used Random Hitbox Elements followed by Custom SSS Code from above.
45 lines of code in and I crashed with an invalid assert from instruction 3E2080CA (from the SSS code) @ 803FA1DC.

The line "ori r7, 31, cheatdata@l" is pointing to 80001808, because r7 is used for lwzx r9, r7,r9 on several lines of CT2, this will cause crashes in Dolphin if cheats aren't enabled, because Dolphin writes STUBHAXX there.
See the comment at:
https://github.com/dolphin-emu/dolp...50b734853/Source/Core/Core/Boot/Boot.cpp#L445

I believe that's the bug causing issues with the folks testing everything on Dolphin.

Also, Dolphin writes FF000000 00000000 to the end of its codelist. Maybe there's the problem with codes have issues past a few? That region of memory just has garbage 00000008 written into it. So, that needs to be overwritten probably.

Lastly, you have duplicate code past 8040B214 (Starts @ 0x408208 in the DOL). It's the _load_NM function and everything following. Seems unintentional and a waste of free space.

 

[DRGN]

The line "ori r7, 31, cheatdata@l" is pointing to 80001808, because r7 is used for lwzx r9, r7,r9 on several lines of CT2, this will cause crashes in Dolphin if cheats aren't enabled, because Dolphin writes STUBHAXX there.
See the comment at:
https://github.com/dolphin-emu/dolp...50b734853/Source/Core/Core/Boot/Boot.cpp#L445

I believe that's the bug causing issues with the folks testing everything on Dolphin.

Where is this ori line you're mentioning here? I tried converting it to hex so I could search for it, but couldn't convert it. What is this for? And most importantly, what's the best way you would recommend fixing this part?

After the above, I'll experiment with using FF000000 00000000 for the codelist end, and removing the duplicate code from the codehandler.

 

[SinsOfApathy]

Where is this ori line you're mentioning here? I tried converting it to hex so I could search for it, but couldn't convert it. What is this for? And most importantly, what's the best way you would recommend fixing this part?

After the above, I'll experiment with using FF000000 00000000 for the codelist end, and removing the duplicate code from the codehandler.

In the Dolphin, the instruction will appear as "ori r7, r31, 1808". In the DOL @ 4079B4, "63 E7 18 08" I believe.

As for fixing it, if you removed the duplicate code at @ 408208 and below, I believe you'd have enough space. Otherwise, you could point it to 8000180C, and that'd avoid the STUBHAXX lines. (Note: I haven't tested that. It'd work in theory.)

Alternatively, you can move the codehandler to a less useful region, then move your codelist to the old spot.



This did give me the idea though to inject my codehandler at the region you've been using @ Dan Salvato and completely bypass a loader, so thanks for that.

 

[DRGN]

I removed the duplicate code from the codehandler, used FF000000 00000000 to end the codelist, and tried with and without changing "63 E7 18 08" to "63 E7 18 0C". But I'm getting this error each time:

"BackPatch: Currently only supporting reads.

Attempted to write to 82004000."

When you click OK, it then says, "Backpatch write - not through EAX"

(Cheats are enabled in my Dolphin.)

I tried placing a breakpoint on 82004000, but it didn't trigger. Edit: Just realized this build of Dolphin doesn't work with write breakpoints.

Here is the modified Gecko DOL I'm testing if you want to look at it yourself, with these mods added for testing: 'D-Pad Down at CSS loads Rumble Select Screen', 'Stage Striking', '"RANDOM" is Selected by Default on the SSS', 'Disable Great Fox's Guns on Corneria', and 'Hot Mr. Saturn Potato'.

As for fixing it, if you removed the duplicate code at @ 408208 and below, I believe you'd have enough space.

I'm not sure what you meant by this. Enough space for what? Afaik, even with the duplicate code, the entire codehandler is within what is considered to be free space (as defined by achilles, and apparently containing text likely used for debugging the game).

 

[Dan Salvato]

I thought codelists ended with F0000000 00000000, not FF000000 00000000

 

[DRGN]

I thought codelists ended with F0000000 00000000, not FF000000 00000000

I found FF000000 00000000 when generating a .gct from geckocodes.org. I tried both anyway, both with and without changing "63 E7 18 08" to "63 E7 18 0C", but I still get the same error. So after those 4 combination attempts, it seems there's still some other underlying problem.

 

[SinsOfApathy]

I removed the duplicate code from the codehandler, used FF000000 00000000 to end the codelist, and tried with and without changing "63 E7 18 08" to "63 E7 18 0C". But I'm getting this error each time:

"BackPatch: Currently only supporting reads.

Attempted to write to 82004000."

When you click OK, it then says, "Backpatch write - not through EAX"

(Cheats are enabled in my Dolphin.)

I tried placing a breakpoint on 82004000, but it didn't trigger. Edit: Just realized this build of Dolphin doesn't work with write breakpoints.

Here is the modified Gecko DOL I'm testing if you want to look at it yourself, with these mods added for testing: 'D-Pad Down at CSS loads Rumble Select Screen', 'Stage Striking', '"RANDOM" is Selected by Default on the SSS', 'Disable Great Fox's Guns on Corneria', and 'Hot Mr. Saturn Potato'.

I can't even get to your BackPatch issue. I just get constant invalid read/writes in Dolphin at the loop that occurs at 8040af1c. "Invalid read from 0x3f3f3f3f", "Invalid write to 0x6b4f3f40", "Invalid read from 0x3f3f3f40", "Invalid write to 0x6b4f3f41". The last byte just keeps incrementing. Try removing codes one by one and adding simpler codes. I have a feeling it's one code in particular.

The offending code is this, in particular it's caught in the copy loop.

Spoiler

_op56:           

    bne-    cr7,_readcodes        #lf code execution set to false skip code

    rlwinm    r9,r3,24,0,31        #r9=r3 ror 8 (NM8AYYYY, NM8CYYYY)
    mr    r14,r12            #r14=(ba/po)
    bl    _load_NM

    beq-    cr4,+12
    add    r17,r17,r4        #lf sub code type==0 then source+=XXXXXXXX
    b    +8
    add    r9,r9,r4        #lf sub code type==1 then destination+=XXXXXXXX

    rlwinm.    r4,r3,24,16,31        #Extracts YYYY, compares it with 0
    li    r5,0

_copy_loop:
    beq     _readcodes        #Loop until all bytes have been copied.
    lbzx     r10,r5,r17
    stbx     r10,r5,r9
    addi    r5,r5,1
    cmpw    r5,r4
    b     _copy_loop

Edit: I've been stepping through the instructions and "load_NM" causes it to load the "3f3f3f3f" into r17. I have a feeling that this is related to some Dolphin workaround causing it, if this has been tested to run on actual hardware. I can't think of any other reason why this would be an issue.

There's an explicit hack for making Project M work with Dolphin since the icache isn't properly invalidated, so I don't even know at this point.

I'm not sure what you meant by this. Enough space for what? Afaik, even with the duplicate code, the entire codehandler is within what is considered to be free space (as defined by achilles, and apparently containing text likely used for debugging the game).

There's supposed to be 39*4 free space before the codelist to serve as a memory storage region. That's 39 rows of 4 bytes, I believe.

I thought codelists ended with F0000000 00000000, not FF000000 00000000

Gecko OS says "#End code handler = F0000000 00000000".

Dolphin says:
https://github.com/dolphin-emu/dolp...50b734853/Source/Core/Core/GeckoCode.cpp#L140

Without opening Dolphin's codehandler.bin and comparing it, which I'm unable to do at the moment, I can't really say for certain.

 

[Achilles1515]

Made with Ocarina Cheat Code Manager a long time ago.

 

[SinsOfApathy]

View attachment 68913

Made with Ocarina Cheat Code Manager a long time ago.

Yeah, in reality, looking at Gecko, it literally just checks if the MSB is F. Unless Dolphin's codehandler.bin was coded to be different, which I doubt, then it'd be the same.

If it isn't, someone should probably post a PR over at Dolphin just to make it functionally equivalent with the actual software.

Edit: I'm a bit overwhelmed atm between my semester starting (8am - 5pm of classes) and work. If someone wants to debug it, I think your best bet may be to start with r4. I have a weird feeling though that it's possibly got to do with any Gecko code that's change inputs (like the D-Pad Down), because I did move the list around from 1808 to a few other locations.

 

[SinsOfApathy]

So I looked into what I think cause is. By not writing

gameid:
.long 0,0

to 80001800, Dolphin won't invalidate the instruction cache. Dolphin expects that .text region to be there, which is handled by "-Ttext,0x80001800 " in the .bin compilation process.

Dolphin has an explicit check for 0xD01F1BB2, which it writes and manually invalidates the icache with for its own codehandler. However, Project M doesn't do that, and the icache is improperly invalidated. As a result, Dolphin has a hacky workaround seen here:
https://github.com/dolphin-emu/dolp...4cbe8db/Source/Core/Core/HLE/HLE_Misc.cpp#L57

I haven't tested it, since I personally just replace Dolphin's codehandler.bin with my own (which required its own workaround), but I believe you may be able to write 0xD01F1BB3 to 80001800 and force Dolphin to invalidate the icache, thus working around the issues. It may repeatedly invalidate the icache though, so you may want to conditionally apply that value to 80001800. No dice. Still getting the incrementing garbage values.

 

[DRGN]

I can't even get to your BackPatch issue. I just get constant invalid read/writes in Dolphin at the loop that occurs at 8040af1c. "Invalid read from 0x3f3f3f3f", "Invalid write to 0x6b4f3f40", "Invalid read from 0x3f3f3f40", "Invalid write to 0x6b4f3f41". The last byte just keeps incrementing. Try removing codes one by one and adding simpler codes. I have a feeling it's one code in particular.

The offending code is this, in particular it's caught in the copy loop.

Spoiler

_op56:         

    bne-    cr7,_readcodes        #lf code execution set to false skip code

    rlwinm    r9,r3,24,0,31        #r9=r3 ror 8 (NM8AYYYY, NM8CYYYY)
    mr    r14,r12            #r14=(ba/po)
    bl    _load_NM

    beq-    cr4,+12
    add    r17,r17,r4        #lf sub code type==0 then source+=XXXXXXXX
    b    +8
    add    r9,r9,r4        #lf sub code type==1 then destination+=XXXXXXXX

    rlwinm.    r4,r3,24,16,31        #Extracts YYYY, compares it with 0
    li    r5,0

_copy_loop:
    beq     _readcodes        #Loop until all bytes have been copied.
    lbzx     r10,r5,r17
    stbx     r10,r5,r9
    addi    r5,r5,1
    cmpw    r5,r4
    b     _copy_loop

I did some testing, and it seems like 02 and 04 based codes work, but C2 based codes fail. Almost all C2 codes are also larger than the 04s, so I tried a really short C2 code too (only 48 bytes) to make sure it wasn't a size issue instead, but it still didn't work. So maybe the codelist isn't where the codehandler thinks it is, and code execution is getting lost in the branches? I dunno. I don't know how the codehandler injects these.

Edit: I've been stepping through the instructions and "load_NM" causes it to load the "3f3f3f3f" into r17. I have a feeling that this is related to some Dolphin workaround causing it, if this has been tested to run on actual hardware. I can't think of any other reason why this would be an issue.

There's an explicit hack for making Project M work with Dolphin since the icache isn't properly invalidated, so I don't even know at this point.

Just tested and it doesn't work on console either.

There's supposed to be 39*4 free space before the codelist to serve as a memory storage region. That's 39 rows of 4 bytes, I believe.

Is the codelist relocated in RAM independently of the DOL's relocation? If not, then that sounds like a problem, because 0x3F7124 (0x3F4124 in RAM), where the codelist starts, is directly at the start of the 'debug menu free space' region. I don't know how important the code right before this is, but it's not designated as free space for custom code (and these areas aren't separated when the DOL moves into RAM, going all the way back to 0x3B6840 (or 0x3B9840 in RAM) btw). I assume that this isn't an oversight though, which is part of why I'm wondering about the codelist being moved.

 

[SinsOfApathy]

I did some testing, and it seems like 02 and 04 based codes work, but C2 based codes fail. Almost all C2 codes are also larger than the 04s, so I tried a really short C2 code too (only 48 bytes) to make sure it wasn't a size issue instead, but it still didn't work. So maybe the codelist isn't where the codehandler thinks it is, and code execution is getting lost in the branches? I dunno. I don't know how the codehandler injects these.

The codehandler just replaces the C2 address with a branch into its codelist AFAIK. Like I said, using your DOL, I saw a completely different issue with garbage being written, probably from an address near the codehandler, and crashing Dolphin.

Just tested and it doesn't work on console either.

What loader are you using? C2 codes with "D-Pad down" etc. won't work with Nintendont. It emulates SI and EXI registers, which causes a whole host of other issues.

]Is the codelist relocated in RAM independently of the DOL's relocation? If not, then that sounds like a problem, because 0x3F7124 (0x3F4124 in RAM), where the codelist starts, is directly at the start of the 'debug menu free space' region. I don't know how important the code right before this is, but it's not designated as free space for custom code (and these areas aren't separated when the DOL moves into RAM, going all the way back to 0x3B6840 (or 0x3B9840 in RAM) btw). I assume that this isn't an oversight though, which is part of why I'm wondering about the codelist being moved.

That's what I've been wondering and meaning to debug. I do think I set all those addresses to 00000000 though and still received that garbage "3f3f3f3f" value.

 

[DRGN]

The codehandler just replaces the C2 address with a branch into its codelist AFAIK. Like I said, using your DOL, I saw a completely different issue with garbage being written, probably from an address near the codehandler, and crashing Dolphin.

That's what I was thinking concerning the branching, so I was wondering if maybe it was miscalculating branches due to it being incorrect on where the codelist is stored. Which I figure might be possible if there was another variable that's not properly hard-coded into the codehandler (if it was off, the 04 codes might still work as long as they're still read, but the C2s of course would break). There's a codeListStart variable in the codehandler somewhere, and I think a codeListEnd, but I'm not sure where. I'll see if I can figure that out later.

What loader are you using? C2 codes with "D-Pad down" etc. won't work with Nintendont. It emulates SI and EXI registers, which causes a whole host of other issues.

DIOS MIOS Lite (2.10)

I didn't test as much as I did in Dolphin, but from what I did, the same scenarios that worked/didn't work in Dolphin worked/didn't work on hardware.

That's what I've been wondering and meaning to debug. I do think I set all those addresses to 00000000 though and still received that garbage "3f3f3f3f" value.

Perhaps that garbage is a result of something that's now missing from that region, instead. (Or rather not because it's missing, but because it's overwritten by the Gecko coding to prepare that space?)

 

[flieskiller]

DRGN I've seen from your Melee Code Manager thread that you didn't fix the problem when basing on this gecko handler. I've used that same gecko handler, but with some modifications for it to work, because I had the same problems. It makes the code working for 04 and C2 codes, but I'm unsure for other things. Here are the list of changes I made (address based on the .dol of the post of Dan)

80407fc0 39ef0007 -> 60000000
80407fc4 55ef0038 -> 60000000

These two made sometimes a line too much in the code, resulting of the handler going "out of bounds", making is miss the next C2 and going crazy and crashing.

 

[SinsOfApathy]

DRGN I've seen from your Melee Code Manager thread that you didn't fix the problem when basing on this gecko handler. I've used that same gecko handler, but with some modifications for it to work, because I had the same problems. It makes the code working for 04 and C2 codes, but I'm unsure for other things. Here are the list of changes I made (address based on the .dol of the post of Dan)

80407fc0 39ef0007 -> 60000000
80407fc4 55ef0038 -> 60000000

These two made sometimes a line too much in the code, resulting of the handler going "out of bounds", making is miss the next C2 and going crazy and crashing.

Pinging Dan Salvato this would fix your 20XXTE .raw files, I think.