The DOL mod topic

[Myougi]

Will that unlock Menu 2 as well as the alt musics for Adventure Mode?

Yup.
(It should at least)

 

[DRGN]

Anyone want to help me test out my DOL program?


@ Achilles1515

The dol doesn't have a header that needs to be preserved? I've noticed before that it doesn't have a file size for some reason, but I figured the first few lines of 0x10 or so were important for some other reason at least. Thanks for this though, I didn't know these areas.

Also, I almost forgot to ask: do you know how big the dol can be? Assuming it's rebuilt with GCRebuilder. If you extended the natural size of the dol, couldn't you safely add code at the end of the file?



Could it be that a large offset range of the dol is stored directly, exactly to memory as-is? If that's true, then anything within that range could have 0x3420 subtracted from it to find the equivalent DOL offset. Much simpler than searching, if true. But until that's confirmed, a search it shall be.


...correct me if I'm wrong, but the Gecko codehandler runs its entire set of codes every frame, right? Meaning they can't be "triggered" by events within the game like an injection code, and are also in that way inefficient.

Particularly the second question, about the dol size and adding code to the end.

 

[Cyjorg]

Anyone want to help me test out my DOL program?


@ Achilles1515


Particularly the second question, about the dol size and adding code to the end.

There are definitely code types that allow basic if then statements

 

[DRGN]

There are definitely code types that allow basic if then statements

I know. But if that's what the Gecko codehandler does, it's certainly more efficient to just avoid extra checks (especially per-frame checks) in the first place by using an injection code. I mean, granted, it's a tiny thing, and who knows how many tiny slivers of an FPS you'd lose, but still, less executing code is less executing code.

 

[Achilles1515]

Anyone want to help me test out my DOL program?


@ Achilles1515


Particularly the second question, about the dol size and adding code to the end.

Idk about adding code to the end of the DOL. I wanna say I tried that before I added code to the end of MnSlChr and the game ended up not booting, but I kind of forget.

The Gecko codehandler is hooked to run every frame of the game no matter what you are doing.

With a C2 gecko injection code, the custom function is only written once, but the branch into this custom function at the RAM injection point is written every frame of the game.

You can make if statements and stuff involving turning off and on 04 and C2 codes, and at that point you're just adding in more lines of code for it to run through every frame.

You're right about code efficiency. After coding Melee for the past year, I've developed the philosophy that it is a sin to have your code run more than it needs to. Except when in menus, lol. Then it kind of doesn't matter because it's not as important. But honestly...I have no idea how extra code lines per frame would be necessary to cause a noticeable slowdown. It would be a f**k ton. I guess you could *kind of* test it with a code that runs through a loop a set amount times, which you could keep increasing, but some instructions take longer for the processor to execute so idk...The fact of efficiency between DOL mods and Gecko codes still stands, but it's hard to argue against not doing the latter (for bigger projects) if it doesn't produce any noticeable difference.

 

[DRGN]

How are branches created in hex? As in an ASM injection code to branch to a custom function (non-Gecko code). And I mean without using the ASM <> WiiRd or similar tool.

@ Achilles1515 @ Cyjorg

 

[Cyjorg]

How are branches created in hex? As in an ASM injection code to branch to a custom function (non-Gecko code). And I mean without using the ASM <> WiiRd or similar tool.

@ Achilles1515 @ Cyjorg

#branch forward where X is how many bytes to go forward
48XXXXXX

#branch backward where Y is how my bytes to go backward
#note, it's a negative number so it counts backward for 0xFFFFFFFF so that
-----#branching back -0x20 is 4BFFFFE0
4BYYYYYY

Essentially, you'll branch to the custom function, let the function run, then return 0x4 from the original line. So your branch to should be

Branch to
(address of the first line in the custom function) - (original)

Branch back
(original + 0x4) - (address of the first line in the custom function + code length)

 

[DRGN]

#branch forward where X is how many bytes to go forward
48XXXXXX

#branch backward where Y is how my bytes to go backward
#note, it's a negative number so it counts backward for 0xFFFFFFFF so that
-----#branching back -0x20 is 4BFFFFE0
4BYYYYYY

Essentially, you'll branch to the custom function, let the function run, then return 0x4 from the original line.

Awwesomee. Thanks. ^_^

Is this always true regardless of where your injection site or custom functions go? I'm guessing you're going to say yes.

A while back, achilles posted:

...
In my experience, DOL equivalent code lines for a RAM address are "in the area close to" -0x3000 from the RAM address. Just a rule of thumb (for 1.02 at least). That's why I said search upwards. So if you take the RAM address and go to that in the DOL and search upwards, it should find a match *roughly* -0x3000 from the start.

Examples:
DOL offset (RAM offset)

"Random" is default selected on SSS
0x2575f0 (25AA10 in RAM)
Difference: 0x3420

Debug Menu Replaces Tournament Mode
0x22A218 (22d638 in RAM)
Difference: 0x3420

Lol...so maybe 0x3420 is a special number. I just don't know if things are always consistent.
...

So it sounds like the DOL as a whole is loaded directly to memory as-is, at 0x3420. That would mean that any offset in RAM within 0x3420 to [0x3420 + size of the dol] can be found in the game's dol file itself by simply subtracting 0x3420! If that's true, converting Gecko codes to ASM injection DOL mods would be much easier to do, requiring no searching RAM bits in the DOL for injection sites.

The 0x3420 offset might vary per game version, but the concept and implications would be the same. I'd test this myself to confirm it, but I have other dol fish to fry atm.

 

[Cyjorg]

Yeah that 0x3420 is familiar for sure.

Awwesomee. Thanks. ^_^

Is this always true regardless of where your injection site or custom functions go? I'm guessing you're going to say yes.

A while back, achilles posted:


So it sounds like the DOL as a whole is loaded directly to memory as-is, at 0x3420. That would mean that any offset in RAM within 0x3420 to [0x3420 + size of the dol] can be found in the game's dol file itself by simply subtracting 0x3420! If that's true, converting Gecko codes to ASM injection DOL mods would be much easier to do, requiring no searching RAM bits in the DOL for injection sites.

The 0x3420 offset might vary per game version, but the concept and implications would be the same. I'd test this myself to confirm it, but I have other dol fish to fry atm.

 

[Achilles1515]

Awwesomee. Thanks. ^_^

Is this always true regardless of where your injection site or custom functions go? I'm guessing you're going to say yes.

A while back, achilles posted:


So it sounds like the DOL as a whole is loaded directly to memory as-is, at 0x3420. That would mean that any offset in RAM within 0x3420 to [0x3420 + size of the dol] can be found in the game's dol file itself by simply subtracting 0x3420! If that's true, converting Gecko codes to ASM injection DOL mods would be much easier to do, requiring no searching RAM bits in the DOL for injection sites.

The 0x3420 offset might vary per game version, but the concept and implications would be the same. I'd test this myself to confirm it, but I have other dol fish to fry atm.

It's not always 0x3420.

All the free space at the beginning, the letter textures (0x426000 area I think DOL), and debug menu stuff (0x3f7500 DOL) are 0x3000 offset from RAM, just to name a few off the top of my head.

 

[shuall]

You could just get these from hex dumping it but here's a dump of the header from melee's (1.02) dol file , if it's helpful. I'm assuming the 3420 might be related to the first text section's addr? Don't really know where 3420 comes from.
Text sections hold code, data holds data, the bss is like a scratch pad for the running binary, and entry is the code entry point.

name  |      off     addr     size
text0 |      100 80003100     2420
text1 |     2520 80005940   3b0c20
data0 |   3b3140 80005520      1a0
data1 |   3b32e0 800056c0      280
data2 |   3b3560 803b6560       20
data3 |   3b3580 803b6580       20
data4 |   3b35a0 803b65a0     25c0
data5 |   3b5b60 803b8b60    77e80
data6 |   42d9e0 804d2980     2d00
data7 |   4306e0 804d6cc0     7220
bss   |          804309e0    a62c9
entry |          8000522c

A little easier on the eyes than hexedit.

 

[DRGN]

Got a simple question. I thought about posting it in the Melee Codes subforum, but I thought this still seemed like a good place for basic Q&A. (So, side question: should we move this thread to the new subforum or abandon it?)

Anyway, achilles posted a while back of a free space in the dol of, "The beginning (before 0x2900). Every area of 00's here is free." I took it as meaning 0x0 to 0x2900 is all available (even though it didn't completely make sense to me at the time, but I just thought, hey, what do I know? lol). So is that right? Seems like it's a dumb question, and that literally 0x0 to 0x2900 is most likely not right. So, could someone be more specific as to which exact areas are known to be ok for custom code? I see small sections of zeros in that range up to 0x2900, but how can we tell if there needs to be a certain amount of buffer spaces of zeros before/after necessary code?

So basically I literally want to know all exact code ranges, within which I could fill the entire thing with 0s or Fs if I wanted to and have it not impact the game.


Edit: Ok, I was starting with a simple question, but it suddenly turned more complex.

Edit2: These are the regions I've tried so far:

Range: Length:
2C5-397 D3
39C-497 FC
4E4-597 B4
5CC-697 CC

^ only briefly tested these to see if the game boots after changing these all 00 regions to FF.

about 0x3f7124 down to 0x3fac20 or so

0x407950 to 408f50

^ these last two regions given by achilles

 

[Achilles1515]

Got a simple question. I thought about posting it in the Melee Codes subforum, but I thought this still seemed like a good place for basic Q&A. (So, side question: should we move this thread to the new subforum or abandon it?)

Anyway, achilles posted a while back of a free space in the dol of, "The beginning (before 0x2900). Every area of 00's here is free." I took it as meaning 0x0 to 0x2900 is all available (even though it didn't completely make sense to me at the time, but I just thought, hey, what do I know? lol). So is that right? Seems like it's a dumb question, and that literally 0x0 to 0x2900 is most likely not right. So, could someone be more specific as to which exact areas are known to be ok for custom code? I see small sections of zeros in that range up to 0x2900, but how can we tell if there needs to be a certain amount of buffer spaces of zeros before/after necessary code?

So basically I literally want to know all exact code ranges, within which I could fill the entire thing with 0s or Fs if I wanted to and have it not impact the game.


Edit: Ok, I was starting with a simple question, but it suddenly turned more complex.

Edit2: These are the regions I've tried so far:

Range: Length:
2C5-397 D3
39C-497 FC
4E4-597 B4
5CC-697 CC

^ only briefly tested these to see if the game boots after changing these all 00 regions to FF.

about 0x3f7124 down to 0x3fac20 or so

0x407950 to 408f50

^ these last two regions given by achilles

All the zero sections are free at the beginning.

 

[DRGN]

#branch forward where X is how many bytes to go forward
48XXXXXX

#branch backward where Y is how my bytes to go backward
#note, it's a negative number so it counts backward for 0xFFFFFFFF so that
-----#branching back -0x20 is 4BFFFFE0
4BYYYYYY

Essentially, you'll branch to the custom function, let the function run, then return 0x4 from the original line. So your branch to should be

Branch to
(address of the first line in the custom function) - (original)

Branch back
(original + 0x4) - (address of the first line in the custom function + code length)

"branching back -0x20 is 4BFFFFE0" <- huh? 0xFFFFFF - 0x20 = 0xFFFFDF, and 0xFFFFFF - 20 = FFFFEB

Ok, unfortunately I might have another dumb question. I thought I understood all this at first look, but they're not working for me. And a sample I'm looking at isn't adding up. I'm looking at Dan's 'Hold A+B For a Salty Runback' (converted by Geuse):

@0x1A0D40:
981F0003 -------> 4BE603C0

@0x1520 to 0x155F:
39C00000 3DE08046
61EFB108 820F0000
5611018D 41820010
561101CF 41820008
38000002 39CE0001
2C0E0004 4080000C
39EF0008 4BFFFFD8
981F0003 4819FC08


The injection point is branching [FFFFFF - E603C0 = 0x19FC3F] bytes back. But 0x1A0D40 (the injection site) - 0x19FC3F = 0x1101, which isn't the 0x1520 where the custom code is placed. Wut? What am I missing? Is it only correct once it's in the game's RAM, not in the dol file? The branch back also doesn't add up.

 

[Achilles1515]

"branching back -0x20 is 4BFFFFE0" <- huh? 0xFFFFFF - 0x20 = 0xFFFFDF, and 0xFFFFFF - 20 = FFFFEB

Ok, unfortunately I might have another dumb question. I thought I understood all this at first look, but they're not working for me. And a sample I'm looking at isn't adding up. I'm looking at Dan's 'Hold A+B For a Salty Runback' (converted by Geuse):

@0x1A0D40:
981F0003 -------> 4BE603C0

@0x1520 to 0x155F:
39C00000 3DE08046
61EFB108 820F0000
5611018D 41820010
561101CF 41820008
38000002 39CE0001
2C0E0004 4080000C
39EF0008 4BFFFFD8
981F0003 4819FC08


The injection point is branching [FFFFFF - E603C0 = 0x19FC3F] bytes back. But 0x1A0D40 (the injection site) - 0x19FC3F = 0x1101, which isn't the 0x1520 where the custom code is placed. Wut? What am I missing? Is it only correct once it's in the game's RAM, not in the dol file? The branch back also doesn't add up.

Every branch is relative to RAM addresses not DOL addresses. It would line up if the DOL was a 1:1 copy in the RAM, but it's not (which is why I was saying their relative offsets are not always 0x3420 apart).

 

[DRGN]

Every branch is relative to RAM addresses not DOL addresses. It would line up if the DOL was a 1:1 copy in the RAM, but it's not (which is why I was saying their relative offsets are not always 0x3420 apart).

Oh. I thought you were saying that the dol was not always put into ram with a 0x3420 offset. So one time it might be at 0x2900, and another time 0x3100, yet still whole either way.

Dang. That sure throws a wrench into things. So how is it broken up?

 

[shuall]

Oh. I thought you were saying that the dol was not always put into ram with a 0x3420 offset. So one time it might be at 0x2900, and another time 0x3100, yet still whole either way.

Dang. That sure throws a wrench into things. So how is it broken up?

You could just get these from hex dumping it but here's a dump of the header from melee's (1.02) dol file , if it's helpful. I'm assuming the 3420 might be related to the first text section's addr? Don't really know where 3420 comes from.
Text sections hold code, data holds data, the bss is like a scratch pad for the running binary, and entry is the code entry point.

name  |      off     addr     size
text0 |      100 80003100     2420
text1 |     2520 80005940   3b0c20
data0 |   3b3140 80005520      1a0
data1 |   3b32e0 800056c0      280
data2 |   3b3560 803b6560       20
data3 |   3b3580 803b6580       20
data4 |   3b35a0 803b65a0     25c0
data5 |   3b5b60 803b8b60    77e80
data6 |   42d9e0 804d2980     2d00
data7 |   4306e0 804d6cc0     7220
bss   |          804309e0    a62c9
entry |          8000522c

A little easier on the eyes than hexedit.

The 0x3420 is specific to text1. text0 is helper functions, while text1 is the program most of us are interested in. All the data sections are places to store global and static variables, so not executable code.

We get 0x3420 by taking the difference between the RAM address and the dol file offset. So 0x5940-0x2520 = 0x3420 (Ignore the 8 at the beginning of the addresses).

What you're really doing when you convert dol offsets to RAM addresses is subtracting the offset into the dol to get the offset from the beginning of the section, and adding the RAM address the section is loaded. For example, a jump into code at dol offset 0x2534 would be in the text1 section. So we take 0x2534-0x2520 = 0x14 and add the addr: 0x14 + 0x5940 = 0x5954.

You shoud notice that 0x5954 is 0x2534 + 0x3420

So if we add a text section to the end of the dol, the text section's offset would have to be after the last data section, or (offset + size) 0x4306E0 + 0x7220 = 0x437900. The address would have to be loaded somewhere there is free memory (after data7 looks good) 0x804D6CC0 + 0x7220 = 0x804DDEE0.

The problem with adding text sections at the end of memory, is when the processor fetches code to run, it expects the next code will be fairly close in memory. This is called spatial locality. When you put text1 at 0x80005940 and your new text2 at 0x804DDEE0, there will be a slowdown whenever the compiler goes to fetch your special code to run it, because of a cache miss. This is fine for changes that are loaded once in a while, but if you're trying to run custom code every frame, breaking the processor's assumption of spatial locality is just asking for a cache miss and a slowdown.

EDIT: while it's asking for a cache miss, I want to note that it doesn't *necessarily* mean it will result in one, or even whether it will be a noticable slow down. Don't let my last paragraph stop you from trying it.

 

[Cyjorg]

@ DRGN
It's in hexadecimal. You subtracted in decimal.

I suck at reading. 0xFFFFFFFF is -1, not 0 (no such thing as -0).

 

[DRGN]

The 0x3420 is specific to text1. text0 is helper functions, while text1 is the program most of us are interested in. All the data sections are places to store global and static variables, so not executable code.

We get 0x3420 by taking the difference between the RAM address and the dol file offset. So 0x5940-0x2520 = 0x3420 (Ignore the 8 at the beginning of the addresses).

What you're really doing when you convert dol offsets to RAM addresses is subtracting the offset into the dol to get the offset from the beginning of the section, and adding the RAM address the section is loaded. For example, a jump into code at dol offset 0x2534 would be in the text1 section. So we take 0x2534-0x2520 = 0x14 and add the addr: 0x14 + 0x5940 = 0x5954.

You shoud notice that 0x5954 is 0x2534 + 0x3420

So if we add a text section to the end of the dol, the text section's offset would have to be after the last data section, or (offset + size) 0x4306E0 + 0x7220 = 0x437900. The address would have to be loaded somewhere there is free memory (after data7 looks good) 0x804D6CC0 + 0x7220 = 0x804DDEE0.

The problem with adding text sections at the end of memory, is when the processor fetches code to run, it expects the next code will be fairly close in memory. This is called spatial locality. When you put text1 at 0x80005940 and your new text2 at 0x804DDEE0, there will be a slowdown whenever the compiler goes to fetch your special code to run it, because of a cache miss. This is fine for changes that are loaded once in a while, but if you're trying to run custom code every frame, breaking the processor's assumption of spatial locality is just asking for a cache miss and a slowdown.

EDIT: while it's asking for a cache miss, I want to note that it doesn't *necessarily* mean it will result in one, or even whether it will be a noticable slow down. Don't let my last paragraph stop you from trying it.

Awesome. Thanks, shuall! I'm pretty anxious to start writing a function for these conversions. It's the last thing I need for my current program, and will likely be useful in the future. I'm pretty sure I understand what you're saying so far, but there are still a few things I need to know.

1) how did you get/create this table? I want to support all game versions, so I'll need one of these for the other dols too. I could probably do direct search comparisons between the dol and RAM, but I'm guessing you did it an easier way (also I'd have a bunch of questions doing it the other way anyway). Nvm, I think I figured it out. Strange that it's actually a set of 3 tables. Also I was confused at first because it looks like you actually got that table from a v1.01 DOL. Do you happen to know what any other regions of the file are?
2) Do these sections change as the game runs, like other portions of the game's code, or are they always there? If it's as simple as being static, contiguous sections as you have defined, then it looks like I already have all I need to convert pretty easily (for 1.02 anyway).

Looks like I'll also need to take note of the locations where the sections break. Can't put any functions there or else they'll be cut in half (I 'spose I could add more branches, but I'll just avoid that complexity for now).

Btw, you said that the data sections are for variables, not executable code. But does the game really access or read the space differently somehow? What I mean is, if you have a branch that goes into one of these sections, could you not put ASM instructions and have them executed just like if they were in one of the text sections, and then just branch back out again?

I was a little worried I was going to have to do RAM dump to DOL comparisons for each conversion before you posted, haha. So thanks again, this is much simpler. I'm still really new to a lot of these things, so there's a lot I still don't know. One thing I've been forgetting to ask: in Debug Dolphin's Memory tab, what's the difference between "Dump MRAM" and "Dump EXRAM"?

 

[Deleted member]

Gonna throw out a request if anyone has the spare time, patience and kindness to do this I would greatly appreciate it.

I would like a DOL made with these settings.

Modfications
C-Stick in 1P Mode
Debug Menu replaces Tournament Mode
Normal C-Stick Functionality in Develop Mode
Debug Menu Default Language
Disable Tap Jump (if possible)
Modifying Default Settings

- Stock [3]
- Friendly Fire [OFF] (default in Melee)
- Timer [OFF] (default in Melee)
- Items [OFF]​

Unrestricted Pause Camera
http://smashboards.com/threads/the-dol-mod-topic.326347/page-6#post-16833528
All Players Can Control The Debug Menu
http://smashboards.com/threads/the-dol-mod-topic.326347/page-10#post-18751015
Character Modifications
Donkey Kong - Giant Punch cannot be lost during Up+B
Samus - Charge Shot cannot be lost during Up+B
Mr. Game & Watch - N/B/U-Aerials L-Cancelable, U-Air Lag Bug Fix
Pichu Doesn't Hurt Itself (This wasn't posted in this thread, but if possible, I would like this added as well)

 

[Wooggle]

I wanted to use this code so I made a DOL mod of it and here it is:

No Rapid Jabs - All Applicable Characters(1.02) [Achilles]
@0xD36CC
480000A1 -> 60000000

 

[Cyjorg]

I feel like this thread is a waste now that the community understands how to modify machine code in the dol. This thread is the exact same as the Melee Gecko Code Guides and Discussion thread.

At least when it comes to a simple nop or blr anyway.

 

[Wooggle]

I feel like this thread is a waste now that the community understands how to modify machine code in the dol. This thread is the exact same as the Melee Gecko Code Guides and Discussion thread.

At least when it comes to a simple nop or blr anyway.

I didn't make the DOL mod above for anyone else. I did it was for myself because I actually wanted to use the code on my console.

There are two reason why I like posting DOL mods here even if most of the community knows how to do their own DOL mods
1) It helps me be organized
I have a notepad file with a list of all the modifications that I have in my start.dol, and with each modification, I have a link to the smashboards post explaining the DOL mod. This way, it is really easy for me to find out exactly what I modified in the start.dol in case I ever wanted to change something or if I wanted to edit another start.dol in the future.

2) Even though most people know how to make their own DOL mods, there are probably a few people who don't
Before I knew how to make DOL mods, I was limited to using the codes that I found in this thread. The "Melee Gecko Codes Guides and Discussion" thread was useless for me because I didn't know how to actually use the codes on my console without DOL mods. If there is anyone out there who wants to use the "disable rapid jabs" but doesn't know how to do the DOL mod themself, they now can.

 

[Sham Rock]

I feel like this thread is a waste now that the community understands how to modify machine code in the dol. This thread is the exact same as the Melee Gecko Code Guides and Discussion thread.

At least when it comes to a simple nop or blr anyway.

I apologize for creating the tutorial for dol modding, it seemed like a good idea at the time, I did not think it would come to this clusterf*** in the long run.

 

[Cyjorg]

I didn't make the DOL mod above for anyone else. I did it was for myself because I actually wanted to use the code on my console.

There are two reason why I like posting DOL mods here even if most of the community knows how to do their own DOL mods
1) It helps me be organized
I have a notepad file with a list of all the modifications that I have in my start.dol, and with each modification, I have a link to the smashboards post explaining the DOL mod. This way, it is really easy for me to find out exactly what I modified in the start.dol in case I ever wanted to change something or if I wanted to edit another start.dol in the future.

2) Even though most people know how to make their own DOL mods, there are probably a few people who don't
Before I knew how to make DOL mods, I was limited to using the codes that I found in this thread. The "Melee Gecko Codes Guides and Discussion" thread was useless for me because I didn't know how to actually use the codes on my console without DOL mods. If there is anyone out there who wants to use the "disable rapid jabs" but doesn't know how to do the DOL mod themself, they now can.

Your first point can be solved with .txt file backups on both your computer and the cloud thus making it irrelevant. In regards to your second contention, while I'd argue that posting dol mods encourages laziness in the community, most would disagree. So yes, posting the dol modifications for the new users is fine. However, we don't need a whole entire thread solely for converting Gecko Codes. The two threads should be consolidated. End of story.

I apologize for creating the tutorial for dol modding, it seemed like a good idea at the time, I did not think it would come to this clusterf*** in the long run.

The community needed it. No harm in making it.

 

[Zonak]

The post with all the codes mentions that a uair lag bug for GnW was fixed. Does anyone know what that bug is exactly?

 

[flieskiller]

The post with all the codes mentions that a uair lag bug for GnW was fixed. Does anyone know what that bug is exactly?

I'm not sure, but I think: If GnW lands during the 1st part of his uair, the animation still goes into the 2nd part of his uair instead of playing a different animation.

 

[shuall]

Awesome. Thanks, shuall! I'm pretty anxious to start writing a function for these conversions. It's the last thing I need for my current program, and will likely be useful in the future. I'm pretty sure I understand what you're saying so far, but there are still a few things I need to know.

1) how did you get/create this table? I want to support all game versions, so I'll need one of these for the other dols too. I could probably do direct search comparisons between the dol and RAM, but I'm guessing you did it an easier way (also I'd have a bunch of questions doing it the other way anyway). Nvm, I think I figured it out. Strange that it's actually a set of 3 tables. Also I was confused at first because it looks like you actually got that table from a v1.01 DOL. Do you happen to know what any other regions of the file are?
2) Do these sections change as the game runs, like other portions of the game's code, or are they always there? If it's as simple as being static, contiguous sections as you have defined, then it looks like I already have all I need to convert pretty easily (for 1.02 anyway).

Looks like I'll also need to take note of the locations where the sections break. Can't put any functions there or else they'll be cut in half (I 'spose I could add more branches, but I'll just avoid that complexity for now).

Btw, you said that the data sections are for variables, not executable code. But does the game really access or read the space differently somehow? What I mean is, if you have a branch that goes into one of these sections, could you not put ASM instructions and have them executed just like if they were in one of the text sections, and then just branch back out again?

I was a little worried I was going to have to do RAM dump to DOL comparisons for each conversion before you posted, haha. So thanks again, this is much simpler. I'm still really new to a lot of these things, so there's a lot I still don't know. One thing I've been forgetting to ask: in Debug Dolphin's Memory tab, what's the difference between "Dump MRAM" and "Dump EXRAM"?

For that table, I wrote a small addition to my dol2elf program to just dump the dol header where the information is stored.
Dol headers are described here http://hitmen.c02.at/files/yagcd/yagcd/chap14.html#sec14.2

As far as I know, there is no security measures on the gamecube for distinguishing between executable and non-executable memory, so you should be able to put code in the data sections as well.

For Dump MRAM and Dump EXRAM: I've looked over yagcd http://hitmen.c02.at/files/yagcd/yagcd/chap10.html#sec10.1 and some dolphin source, and my guess without trying it is that MRAM is RAM as you would expect whereas EXRAM is MRAM as well as any memory mapped IO devices, like ROM caches, hardware clocks, etc.

 

[SillyGoose]

EDIT: never mind, i found the guide

If anyone know of / could made DOL mods for the any of these gecko codes, it would be much appreciated

Pichu Self-Damage Disable
1Player Battlefield Background in VS

I imagine these would be quite difficult but I'll throw them out there:
FoD reflection Disable
YLink/Link Hookshot Cancel w/ Boomerang

EDIT: never mind, I found the guide. However, using the 1p battlefield background code crashes my game for some reason?

 

[Achilles1515]

The Never-Ending Search for Free Space in the DOL - Update

***********************************
* USB Screenshot function disables *
***********************************

So I found that function 8022887c controls checking for Y+Dpad Up in Develop Mode every frame.

If pressed, it loads a 1 into 0x4d6b90. Then this value of 1 gets added to the total in 0x4d6b94. From what I could tell from memory read breakpointing these addreses, this button combination is used to take screenshots with a USB device and that counter address is used to know what # to name the picture.

So...we're never going to use this. I wonder how many functions I can disable relating to this feature and how many lines that could free up!


&&&& Checking for Button Presses &&&&&&
Function 8022887c only called at one place --> 801a4f84.
(I think this 801a... function gets called every frame on every screen of the game?)

nop the branch link.

801a4f84 --> 60000000
(1a1b64 in DOL)
---> Frees up 8022887c to 80228928.


&&&& Reading the counter addresses &&&&

Memory read 804d6b90
- breaks at 802289e4 [8022892c]
   - this function is branch linked into @ 801a5070

Memory read @ 804d6b94
- breaks at [80323cf4]

nop the branch link.

801a5070 --> 60000000
(1a1c50 in DOL)

Function [8022892c]
- branch links into 802289f8
   ! Function only gets called from [8022892c]

Function [802289f8]
- branch links into 80393a5c
  ! Function only gets called from [802289f8]


Function [80393a5c]
- No: 8032ec6c
- No: 8034c408
- branch links into 8032ed8c
   ! function only gets called from [80393a5c]
- branch links into 8032ef48
   ! Function only gets called from [80393a5c]
*more
- branch links into 8032ee94
   ! function only gets called from [80393a5c] twice


Function [8032ef48]
- branch links into 8032f39c
  ! function only gets called from [8032ef48]

Function [8032f39c]
- branch links into 8032f468
  ! Function only gets called from [8032f39c]

Function [8032f468]
- branch links into 8032c848
! small function only gets called from 8032f468


Need to look into [

Now,
Function [8032f228]
- gets called by 8032ed8c, 8032ee94, 8032f468
- Disable all these, and I can disable 8032f228 as well.
- function 8032f390 gets called by this function. It's a three line function that I can disable as well. Writing 0 to -0x45c4(r13) so address may be free for a flag value as well.


Function [8032f0e4]
- gets called by 8032ed8c, 8032ee94, 8032f39c
- I'm disabling all these, so lets disable this function as well.

Function [8032dcb0]
- gets called by 8032f468, 8032f228, 8032f0e4.
- I'm disabling these so lets disable this function as well.

Function [8032c880]
- gets called by 8032f468. So disable it.

Function [8032f020]
- gets called by 8032ed8c and 8032ee94.
- I'm disabling both of those, so disable this function as well.

Function [8032ef48]
- gets called by 80393a5c. So disable it.

Functions to Disable:
RAM (DOL)
8022887c (22545c)
8022892c
802289f8
8032c848 (329428)
8032c880
8032dcb0 (32a890)
8032ed8c (32b96c)
8032ee94
8032ef48
8032f020
8032f0e4
8032f228
8032f390
8032f39c
8032f468
80393a5c (39063c)

Note: Some of these above functions branch link into the Dolphin-default-named functions:
MCCWrite
MCCRead
etc.

Do we need these functions too??

Function 8015feb4 might be related and branches to a lot of codes in adjacent areas to those from above.

FINAL DOL MODS:

0x1a1b64 --> 60000000
0x1a1c50 --> 60000000


DOL areas to zero/use for any custom codes:
0x22545c up to and including 0x225643 [0x1e8 = 122 lines]
0x329428 up to and including 0x32963f [0x218 = 134 lines]
0x32a890 up to and including 0x32a99f [0x110 = 68 lines]
0x32b96c up to and including 0x32c207 [0x89c = 551 lines]
0x39063c up to and including 0x3907f3 [0x1b8 = 110 lines]

Total: Adds 985 available lines for new code.

tldr;

FINAL DOL MODS (SSBM v1.02):

0x1a1b64 --> 60000000
0x1a1c50 --> 60000000


DOL areas to zero/use for any custom codes:
0x22545c up to and including 0x225643 [0x1e8 = 122 lines]
0x329428 up to and including 0x32963f [0x218 = 134 lines]
0x32a890 up to and including 0x32a99f [0x110 = 68 lines]
0x32b96c up to and including 0x32c207 [0x89c = 551 lines]
0x39063c up to and including 0x3907f3 [0x1b8 = 110 lines]

Total: Adds 985 available lines for new code.

Also, RAM addresses 804d6b90 & 804d6b94 are now free to use for flags or whatever you want.

@ DRGN @ Cyjorg

 

[DRGN]

Nice. I'll add these regions when I update my DOL manager. That's a good amount of extra space.

 

[Quillion]

Is it possible to make a code that allows Up-Smash out of run using the C-stick? My brother would really appreciate that.

 

[mythbust4000]

ok i looked everywhere and i cant find a stage strike doll mod i looked for hours and still no results

 

[DRGN]

ok i looked everywhere and i cant find a stage strike doll mod i looked for hours and still no results

Converted it.

 

[SinsOfApathy]

Note: Some of these above functions branch link into the Dolphin-default-named functions:
MCCWrite
MCCRead
etc.

Do we need these functions too??

Uh, yeah, they're used for the Memory Card Read/Writes and pretty much linked to by a cascade of 50+ functions, including SaveGameData.

 

[SinsOfApathy]

For Dump MRAM and Dump EXRAM: I've looked over yagcd http://hitmen.c02.at/files/yagcd/yagcd/chap10.html#sec10.1 and some dolphin source, and my guess without trying it is that MRAM is RAM as you would expect whereas EXRAM is MRAM as well as any memory mapped IO devices, like ROM caches, hardware clocks, etc.

https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/HW/Memmap.cpp#L98

Read Dolphin's source next time in the HW area. It's a lot more complete than YAGCD. EXRAM is just Wii's "extra RAM."

Edit: Ugh. Double posted by accident. Forgot I was in the same thread. And for month old posts. Necros kill me lol

 

[DRGN]

You could just get these from hex dumping it but here's a dump of the header from melee's (1.02) dol file , if it's helpful. I'm assuming the 3420 might be related to the first text section's addr? Don't really know where 3420 comes from.
Text sections hold code, data holds data, the bss is like a scratch pad for the running binary, and entry is the code entry point.

name  |      off     addr     size
text0 |      100 80003100     2420
text1 |     2520 80005940   3b0c20
data0 |   3b3140 80005520      1a0
data1 |   3b32e0 800056c0      280
data2 |   3b3560 803b6560       20
data3 |   3b3580 803b6580       20
data4 |   3b35a0 803b65a0     25c0
data5 |   3b5b60 803b8b60    77e80
data6 |   42d9e0 804d2980     2d00
data7 |   4306e0 804d6cc0     7220
bss   |          804309e0    a62c9
entry |          8000522c

A little easier on the eyes than hexedit.

I'm confused by the bss section. The header doesn't give an offset for it like the other sections, and when I go to that address in RAM, take a few values there, and search for them in the DOL, I don't get any results. Does this section really have no equivalent space in the DOL? Which would mean DOL mods for this region in memory can't be simple static overwrites in the DOL, and must instead be injection mods which modify the RAM at runtime I suppose.... And, related question, what did you mean that "the bss is like a scratch pad for the running binary"?

 

[SinsOfApathy]

And, related question, what did you mean that "the bss is like a scratch pad for the running binary"?

The .bss section holds the variables which can be allocated at compile-time rather than run-time, such as uninitialized global variables that are declared outside any function.

https://en.wikipedia.org/wiki/.bss

 

[EIREXE]

Is it possible to fix Kirby's throw release bug that allows the thrown character to be released?

 

[Doq]

Is it possible to fix Kirby's throw release bug that allows the thrown character to be released?

1. It wasn't a bug. That was 100% intentional.
2. SDR removes this, you should seek there first.