Super Smash Brothers Brawl [RSBP01]

Started by hetoan2, November 13, 2008, 08:31:54 PM

Previous topic - Next topic

Deathwolf

lolz

Deathwolf

hmm now I think it's possible to port this code...
lolz

Manaboy

#542
Hello, can any one port this code for me please.

WiFi Damage Ratio  Modifier (FMK)
4A000000 90FDDB60
10000069 000000xx
E0000000 80008000
xx=floating point number

Also any idea if the gigerbowser or warioman wifi was ever ported to pal?

And lastly was the 7man brawl have ever finished?

thanks

Deathwolf

btw all wifi codes for brawl are region free
it works on pal/ntsc-u/ntsc-j
lolz

Thewill

Quote from: Manaboy on March 08, 2010, 05:36:17 PM
Hello, can any one port this code for me please.

WiFi Damage Ratio  Modifier (FMK)
4A000000 90FDDB60
10000069 000000xx
E0000000 80008000
xx=floating point number

Also any idea if the gigerbowser or warioman wifi was ever ported to pal?

And lastly was the 7man brawl have ever finished?

thanks
No I don't think 7man brawl is finished ask igglyboo.
I ask that myself sometimes.

Deathwolf

he won't give out his code.
and phantom wings also...
lolz

Manaboy

In the 10000 hours I played online there was one player that loaded 6 player slots at the bottom of the screen then it DCed

Deathwolf  are you sure all Wifi codes are region free?

I may get grilled for asking this, but do you know where I can get other Wifi enabled SSBB codes? I have got them for MKwii but none of my friends play that game, and SSBB is starting to get boring, I am only asking for codes that works on friend mode only, ones that don’t Dc, all my friends don’t have homebrew so a code that don’t require them to have it as well would be good.

Email me if you have to

thanks

Deathwolf

yes they are region free! ALL wifi codes
lolz

GaryCXJk

Let me dissect it for you, or at least the parts I understand.

File Patch Code v3.5.1: [Phantom Wings] - Update #3

E0000000 80008000
225664EC 00000000
0401BFE0 4858BE20
065A7E00 00000070
38A00067 38810020
3CE0805A 60E37C18
4BE52531 38A0007F
3883FFE8 38610020
4BE52521 38A00068
60E47C18 38610020
9421FF80 BC410008
38610088 4BA74DB9
7C7C1B78 2C030000
4082000C 38210080
4800001C B8410008
38210080 4BE524E5
38610008 4BA742E1
7C7C1B78 4BA741E8
040223E0 48585BC0
065A7FA0 00000020
77239000 2C030000
4182000C 7FDDC850
3BDEFFE0 93DB0008
4BA7A42C 00000000
0401CD0C 4858B1F4
065A7F00 00000038
2C030000 4182000C
4BA7DD51 4BA74E04
80780008 2C030000
41820014 8118000C
7C634214 7C7B1850
48000008 8078000C
4BA74DE0 00000000
043EE9D8 48000014
043EEBD4 48000014
043D8B9C 48000018
043E9B4C 38600000
043E9D38 38600000
043D8C80 60000000
80000000 80406920
80000001 805A7C00
8A001001 00000000
045A7C10 2F525342
045A7C14 452F7066

This part loads the textures.


80000001 805A7B00
8A001001 00000000
065A7B10 0000000F
2F525342 452F7066
2F736F75 6E642F00
041C6CE0 483E0D20
065A7A00 00000028
9421FF80 BC410008
3C60805A 60637B1F
4BE52931 B8410008
38210080 4BE52995
4BC1F2C4 00000000
065A7900 00000078
9421FF80 7C0802A6
9001000C BC810010
9421FF00 7C872378
54B2BA7E 7CD33378
38800000 9081000C
90810010 90610014
90810018 3880FFFF
9081001C 38610020
90610008 7CE43B78
38A00080 4BE529F5
38610008 4BA752A1
60000000 80210000
B8810010 8001000C
7C0803A6 80210000
4E800020 00000000
043E399C 481C3F04
065A78A0 00000010
80BC0020 7CA59214
3A400000 4BE3C0F4
043DBAEC 481CBDE4
065A78D0 00000018
800302A4 2C130000
41820008 7E609B78
3A600000 4BE3420C
041CDF7C 483D9884
065A7800 00000098
818C0014 9421FF80
BC410008 3D009034
61089D94 7C034000
4082003C 7C882378
3C60804D 60630000
3C80805A 60847B00
7CC53378 38C04200
80E40080 2C070000
40820014 60000000
480000B9 2C030000
41820010 B8410008
80210000 4BC26724
70A501FF 3868FFFF
3C80804C 6084FFFF
7C842A14 38A04001
38A5FFFF 8C040001
9C030001 2C050000
4082FFF0 B8410008
80210000 4BC2670C
141CCF90 483DA770
065A7700 00000048
9421FF80 BC410008
7FE3FB78 3C80805A
60847B00 38A00000
38C04000 480001E5
90640080 807F0008
907A0014 907A005C
907A0074 B8410008
80210000 807F0000
4BC25854 00000000
E0000000 80008000

This part loads the music. The above two parts were the parts we were talking about, so yes, they were the file patch codes we were talking about. If you don't understand the following parts, I suggest reading up the documentary on it altogether, seeing as reading actually is required to actually be able to port codes.

Now, let's get back on the first part of the code.

E0000000 80008000

Obviously, it does a full terminate of any previously loaded code, and resets both base address and pointer.


225664EC 00000000

This will determine if a certain address, specifically, 805664EC, has the 32-bit value (4 bytes) of 00000000. If it doesn't, it executes the rest of the code.


0401BFE0 4858BE20

This will place a 32-bit value of 4858BE20 at the adress 8001BFE0. What it actually does is insert a piece of assembly code, in this case it will branch off to the address that lies 5815840 bytes right off the current position (executing the part of code that lies there, 5815840 == 0x58BE20). In this case, it will start executing at 805A7E00.


065A7E00 00000070
38A00067 38810020
3CE0805A 60E37C18
4BE52531 38A0007F
3883FFE8 38610020
4BE52521 38A00068
60E47C18 38610020
9421FF80 BC410008
38610088 4BA74DB9
7C7C1B78 2C030000
4082000C 38210080
4800001C B8410008
38210080 4BE524E5
38610008 4BA742E1
7C7C1B78 4BA741E8

This again is a code insert, but this time, it writes to the position 805A7E00, the address we previously got, and which is 11436 bytes right from one of the hex values DEADBABE. Take note of this when porting, seeing as this position was obviously taken to make sure you have enough unused parts in the Wii memory. Also, here it writes 112 bytes. You can read up all specifics on why this is. The following bit of code will continue this trend.


040223E0 48585BC0

065A7FA0 00000020
77239000 2C030000
4182000C 7FDDC850
3BDEFFE0 93DB0008
4BA7A42C 00000000

0401CD0C 4858B1F4

065A7F00 00000038
2C030000 4182000C
4BA7DD51 4BA74E04
80780008 2C030000
41820014 8118000C
7C634214 7C7B1850
48000008 8078000C
4BA74DE0 00000000



043EE9D8 48000014
043EEBD4 48000014
043D8B9C 48000018
043E9B4C 38600000
043E9D38 38600000
043D8C80 60000000

Now, what these bits of code inserts at the positions specified I don't really know for sure. What I do know is that for the first three codes it inserts a bit of assembly which makes sure it skips execution of a certain part of code.


80000000 80406920
80000001 805A7C00
8A001001 00000000

Here it first loads the value 80406920 into gecko register 0, and 805A7C00 into gecko register 1. Both are addresses, where the first points to a string signifying the SD card directory where things like snapshots and replays are stored, and the second points to another bit of empty space. Finally, it will copy 16 bytes from the value at gecko register 0 (80406920) to the position defined in gecko register 1 (805A7C00), basically making a copy of the string /private/wii/app.


045A7C10 2F525342
045A7C14 452F7066

This bit now adds the /RSBE/pf part after the /private/wii/app part that got copied.

Next up, the second part of the code, which handles the music. The previous part is required for the second code to work. Also, in order to not make the first part of the code crash so hard when testing, I suggest putting a terminate code at the end of the previous code. Do however remove the same terminate code when adding the music part of the code. I do think it is best to first focus on the first part of the code, the texture handling, which is probably required to make the music part work at all.


80000001 805A7B00
8A001001 00000000
065A7B10 0000000F
2F525342 452F7066
2F736F75 6E642F00

Assuming you still remember what happened back in the previous code, it will set gecko register 1 to 805A7B00, after which it will copy again 16 bytes from gr0 to gr1. Now it will write 15 bytes right after the copied part, which will result in the string /RSBE/sound/brstm/ to be written.


041C6CE0 483E0D20

065A7A00 00000028
9421FF80 BC410008
3C60805A 60637B1F
4BE52931 B8410008
38210080 4BE52995
4BC1F2C4 00000000

065A7900 00000078
9421FF80 7C0802A6
9001000C BC810010
9421FF00 7C872378
54B2BA7E 7CD33378
38800000 9081000C
90810010 90610014
90810018 3880FFFF
9081001C 38610020
90610008 7CE43B78
38A00080 4BE529F5
38610008 4BA752A1
60000000 80210000
B8810010 8001000C
7C0803A6 80210000
4E800020 00000000

043E399C 481C3F04

065A78A0 00000010
80BC0020 7CA59214
3A400000 4BE3C0F4

043DBAEC 481CBDE4

065A78D0 00000018
800302A4 2C130000
41820008 7E609B78
3A600000 4BE3420C

041CDF7C 483D9884

065A7800 00000098
818C0014 9421FF80
BC410008 3D009034
61089D94 7C034000
4082003C 7C882378
3C60804D 60630000
3C80805A 60847B00
7CC53378 38C04200
80E40080 2C070000
40820014 60000000
480000B9 2C030000
41820010 B8410008
80210000 4BC26724
70A501FF 3868FFFF
3C80804C 6084FFFF
7C842A14 38A04001
38A5FFFF 8C040001
9C030001 2C050000
4082FFF0 B8410008
80210000 4BC2670C



141CCF90 483DA770

Why this part of code is using the pointer instead of base address is beyond me, but it pretty much does the same, it writes 483DA770 to 801CCF90 in this case, seeing as we have neither moved the pointer nor the base address.


065A7700 00000048
9421FF80 BC410008
7FE3FB78 3C80805A
60847B00 38A00000
38C04000 480001E5
90640080 807F0008
907A0014 907A005C
907A0074 B8410008
80210000 807F0000
4BC25854 00000000



E0000000 80008000

And now a terminate is being placed, ending the code.

Chaos_Absolute

I couldn't find a Brawl request thread so I thought I would ask here.

Is there a code to disable Zelda's down B move so that she doesn't transform? :\

GaryCXJk

Okay, now it's time to look step by step what each address and bit of code originally does, while I'll also try to port it. Some will be disassembled using WiiRd, while others will be done using the ASM <> WiiRd Converter.

We first look at the first code added, which is a terminate code type, meaning, we could just leave it at that.

E0000000 80008000

The following code is an if 32-bit not, which basically checks whether the following four bytes are not equal to the bytes on that position. This one's tricky, but after investigating, you'll find that this address is 11084 bytes away from the string /dev/sdio/slotw, meaning that in PAL, this position has to be 0x805683EC.

E0000000 80008000

225683EC 00000000


Next, we go with the first found address that gets replaced, which is at 0x8001BFE0. Now, by taking the memory dump of the NTSC-U version, going to that address and comparing it to the PAL memory dump, we find that at 0x8001C3A8 there is a similar piece. Putting a breakpoint there will result in a pause when loading new stuff, so we know we're right. Now let's take a look at the assembly here.

8001C3A8:  40800020 bge- 0x8001c3c8

The description of bge says "Branch if greater than or equal to", meaning, the code will branch off to the address given, in this case, branch off to 0x8001C3C8, which is 0x20 bytes further. For porting, it really doesn't matter what it compares from. What does matter is what it's replaced with, which is 4858BE20, which equals to:

b 0x58BE20

When placed in NTSC-U at 0x8001BFE0, disassembling with Wiird would look like this:

8001BFE0:  4858BE20 b 0x805a7e00

This is a regular branch, which means no matter what, it will always branch off to this location. Now, as you noticed, the address it branches off to corresponds to the address used in the next code. That means we have to adjust the assembly code to our own location. After searching, we find that 0x805A9C00 corresponds to this address, being 11436 bytes removed from the nearest DEADBABE occurrence. This means that we will have to adjust the assembly accordingly. That means that the code it would be replaced with would need to be 4858D858, resulting in:

8001C3A8:  4858D858 b 0x805a9c00

This also means that the address in the next code should be adjusted accordingly, meaning that the old address has to be replaced by this new address, 0x805A9C00.

E0000000 80008000
225683EC 00000000

0401C3A8 4858D858
065A9C00 00000070


Now, as we have seen earlier, it will insert 112 bytes of assembly code. When inserting this code at the original address, the following assembly would have been gotten.

li r5,103
addi r4,r1,32
lis r7,-32678
ori r3,r7,31768
bl 0xFFE52530
li r5,127
subi r4,r3,24
addi r3,r1,32
bl 0xFFE52520
li r5,104
ori r4,r7,31768
addi r3,r1,32
stwu r1,-128(r1)
stmw r2,8(r1)
addi r3,r1,136
bl 0xFFA74DB8
mr r28,r3
cmpwi r3,0
bne- 0x0C
addi r1,r1,128
b 0x1C
lmw r2,8(r1)
addi r1,r1,128
bl 0xFFE524E4
addi r3,r1,8
bl 0xFFA742E0
mr r28,r3
b 0xFFA741E8


Now, let's start from the beginning.

805A7E00:  38A00067 li r5,103
805A7E04:  38810020 addi r4,r1,32
805A7E08:  3CE0805A lis r7,-32678
805A7E0C:  60E37C18 ori r3,r7,31768


This is what it does:

  • Sets r5 to 103 (0x67);
  • Adds 32 (0x20) to r1 and stores this in r4;
  • Sets r7 to -32678 (0x805A) shifted;
  • Performs a bitwise OR on r7 with 31768 (0x7C18) and stores it in r3.
In PAL, after performing a breakpoint, on 0x8001C3A8, the address where we branched off, I found that r1 had the value 805C05A8, which was 32 bytes away from the string specifying a certain file that got loaded, hence the value stored on r4.

Now for those unfamiliar with bitshifting, shifting is nothing more than adding data to the beginning of an object. For example, with arrays, if can have the following array:

cat, mouse, dog

We could then shift it with, for example, bird, making the array like this:

bird, cat, mouse, dog

In an unrelated note, unshifting just means taking away the first element, mostly storing this element in a temporary object for immediate use.

Bitshifting just means adding zeroes to the beginning of a bitvalue, meaning, to the right side. For example, bitshifting the value 2 (which is 10 in bits) by six bits will result in the bitvalue 10000000, or 128.

In the case of this assembly code, it will always be shifted by 16 bits. This will also result in just adding four zeroes to the beginning of a hexadecimal value, since 16 bits of zeroes is the same as two zeroes of bytes, and one byte with the value zero is two zeroes in hexadecimal value. So, in this case, 0x805A would become 0x805A0000.

Bitwise OR is also simple. Let's take the two values 10 and 3 (1010 and 11). If you perform a bitwise OR, you check for each bit if either of the two bits at the same position are one. In this case:


1010 (10)
0011 (3)
----
1011 (11)


Seeing as we already bitshifted r7 and the value to perform this operation is only two bytes long, all zeroes at the beginning will just be replaced by this new value of 0x805A7C18, which is almost 512 bytes away from the beginning of the execution of the original code. We could therefore change the last assembly code to 60E39A18, seeing as the new location would also have to be similarly empty, being 0x805A9A18.

E0000000 80008000
225683EC 00000000
0401C3A8 4858D858
065A9C00 00000070

38A00067 38810020
3CE0805A 60E39A18


805A7E10:  4BE52531 bl 0x803fa340

This will branch off to the address 0x803FA340. When searching for a similar string of code in the PAL version, we then come to 0x803FD148. After that, we reconstruct the assembly code at the position we will insert our PAL code:

805A9C10:  4BE53539 bl 0x803fd148

This results in the following code so far:

E0000000 80008000
225683EC 00000000
0401C3A8 4858D858
065A9C00 00000070
38A00067 38810020
3CE0805A 60E39A18

4BE53539 ________


[spoiler]
As a side project, let's see what the assembly of that address means.

803FD148:  3884FFFF subi r4,r4,1
803FD14C:  38C3FFFF subi r6,r3,1
803FD150:  38A50001 addi r5,r5,1
803FD154:  4800002C b 0x803fd180


First it substracts one from the value in r4 and stores it back in r4. If we go back at 0x805C05C8, the value previously stored in r4, which was the name and location of the file currently being loaded, we'll notice that, when we go back one byte, the value there is 0x80. We can notice from here that the name and location of the file and all zeroes coming after it will total up to 128 (0x80) bytes.

Next, r6 becomes r3 minus 1. As we all remember, 0x805A9A18 was the value stored there. Seeing as this will be later used, we'll forget about it for now.

In the following, we can now see that r5 will be hightened by 1. The old value was 103 (0x67), so the new value would be 104 (0x68).

Finally, a branch to 803FD180. Let's take a look there.

803FD180:  34A5FFFF subic. r5,r5,1
803FD184:  4082FFD4 bne+ 0x803fd158


For the first, I'm not sure of the exact mechanic, but basically it acts like subi, meaning that r5 will be its original value of 103 (0x67) yet again. In fact, I really don't know what bne+ does either aside from branching off to 0x803FD158 if a certain condition set is not equal, so let's take a look there:

803FD158:  8C040001 lbzu r0,1(r4)
803FD15C:  2C000000 cmpwi r0,0
803FD160:  9C060001 stbu r0,1(r6)
803FD164:  4082001C bne- 0x803fd180


First, r4, which is at the moment 805C05C7, will be changed, in this case by adding one, making it 805C05C8. Then, the value at the location of r4 will be taken. In this case, it would most likely be 2F, which is the slash of the file path. This value will be stored in the lower eight bits of r0, and the rest would be zeroed out. To say it simple, it will only store this byte value.

Next, it will compare r0 with 0, whether it will be greater than, smaller than or equal to r0 and sets the condition state accordingly. In this case, r0 isn't equal to 0. In fact, until the string is done, it will always set the condition state to greater than, which probably also equates to not equal.

Now it will add 1 to r6 (which was the value of 805A9A17), and the lower eight bits of r0 will be stored at that address (0x805A9A18). This address will now also be stored at r6. Finally, it will branch off to 0x803FD180 again if the current condition state is not equal.

So, now that you know this, you will find that the code basically writes the path of the current file. But let's continue.

803FD168:  38000000 li r0,0
803FD16C:  48000008 b 0x803fd174


r0 will be set to 0, and the code will now branch off to 0x803FD174.

803FD170:  9C060001 stbu r0,1(r6)
803FD174:  34A5FFFF subic. r5,r5,1
803FD178:  4082FFF8 bne+ 0x803fd170


What happens here isn't clear to me, but apparently it will continue until r5 is zero. Until that time, it will write zeroes after the file path string, in order to avoid confusion.

803FD17C:  4E800020 blr


What this does has to be explained by an earlier code. You see, there were two instances of regular branches we found, the one that was initialized by just b, and one that was innitialized by bl. The latter is used in conjunction with this codetype, which basically branches off back to the last bl set, or rather, after the last bl has been set. It continues from here.
[/spoiler]

Let's continue from here.

805A7E14:  38A0007F li r5,127
805A7E18:  3883FFE8 subi r4,r3,24
805A7E1C:  38610020 addi r3,r1,32


First, r5 becomes 127 (0x7F). Then, r4 becomes the value of r3 minus 24. r3 is now the place where the file path stands. To give you a heads on what will happen with this string, at 805A9A00, the rest of the file path will be placed here, so that's where r4 will be pointing to after 24 will be substracted from the value of r3.

Finally, 32 will be added to the value of r1 (which was 805C05A8) and stored into r3. If you look back, 0x805C05C8 was the location where the original file path string was, which was located 32 bytes from 805C05A8.

E0000000 80008000
225683EC 00000000
0401C3A8 4858D858
065A9C00 00000070
38A00067 38810020
3CE0805A 60E39A18

4BE53539 38A0007F
3883FFE8 38610020


Next up:

805A7E20:  4BE52521 bl 0x803fa340


As we all know, this should again point to 0x803FD148.

805A9C20:  4BE53529 bl 0x803fd148

E0000000 80008000
225683EC 00000000
0401C3A8 4858D858
065A9C00 00000070
38A00067 38810020
3CE0805A 60E39A18
4BE53539 38A0007F
3883FFE8 38610020

4BE53529 ________


[spoiler]
Now, what would happen here exactly? As you know by now, the code will copy one string to another position, in this case, it will copy the previously copied string with the 24 bytes before it back to the old position.
[/spoiler]

805A7E24:  38A00068 li r5,104


Another pretty short one. This one will set r5 to 104 (0x68).

E0000000 80008000
225683EC 00000000
0401C3A8 4858D858
065A9C00 00000070
38A00067 38810020
3CE0805A 60E39A18
4BE53539 38A0007F
3883FFE8 38610020

4BE53529 38A00068


805A7E28:  60E47C18 ori r4,r7,31768


This will set r4 to the bitwise OR value of r7 with 31768 (0x7C18). Seeing as we have seen that r7 points to the empty space designated for the new file path, we have to adjust this one as well.

805A9C28:  60E49A18 ori r4,r7,39448


E0000000 80008000
225683EC 00000000
0401C3A8 4858D858
065A9C00 00000070
38A00067 38810020
3CE0805A 60E39A18
4BE53539 38A0007F
3883FFE8 38610020
4BE53529 38A00068

60E49A18 ________



805A7E2C:  38610020 addi r3,r1,32
805A7E30:  9421FF80 stwu r1,-128(r1)
805A7E34:  BC410008 stmw r2,8(r1)
805A7E38:  38610088 addi r3,r1,136


First, 32 gets added to r1 and stored back to r3. I don't have to remind you that it's the location of the (original) file string. Then, the 32 bit value of r1, which is 805C05A8, is stored 128 bytes before the address stored in r1, which is 0x805C0528. This address is then stored in r1, so r1 becomes 805C0528.

Now what should happen next I don't know. Apperently it doesn't seem to do anything, or at least not in PAL.

Anyway, next, 136 (0x88) gets added to r1 (805C0528), and gets stored in r3, becoming 805C05B0.

E0000000 80008000
225683EC 00000000
0401C3A8 4858D858
065A9C00 00000070
38A00067 38810020
3CE0805A 60E39A18
4BE53539 38A0007F
3883FFE8 38610020
4BE53529 38A00068

60E49A18 38610020
9421FF80 BC410008
38610088 ________


805A7E3C:  4BA74DB9 bl 0x8001cbf4


A branch to 0x8001CBF4. The location should actually be to 0x8001CE7C.

805A9C3C:  4BA73241 bl 0x8001ce7c


E0000000 80008000
225683EC 00000000
0401C3A8 4858D858
065A9C00 00000070
38A00067 38810020
3CE0805A 60E39A18
4BE53539 38A0007F
3883FFE8 38610020
4BE53529 38A00068
60E49A18 38610020
9421FF80 BC410008

38610088 4BA73241


[spoiler]
Again, let's see what this branch does.

8001CE7C:  9421FF30 stwu r1,-208(r1)
8001CE80:  7C0802A6 mflr r0
8001CE84:  900100D4 stw r0,212(r1)
8001CE88:  396100D0 addi r11,r1,208
8001CE8C:  483D7291 bl 0x803f411c


At this point, r1 is 805C0528, so the following instruction places this value 208 bytes before r1, after which r1 takes this value (805C0458).

So, remember that we got sent here by a bl right? Seeing as down the code we get another bl, the old bl value would get overwritten, therefore we would not be able to return. That's why the next instruction will store the address of the last bl to r0. Now, and I guess as a safekeeping, this value gets stored 212 bytes after the address stored in r1. Then 208 gets added to r1 and stored in r11, making it 805C0528. Then, a branch off to 0x803F411C.

I'm not sure what this code does, but I don't think I'll take the time to find out.
[/spoiler]

Anyway, the rest of the code you can figure out yourself.


805A9C40:  7C7C1B78 mr r28,r3
805A9C44:  2C030000 cmpwi r3,0
805A9C48:  4082000C bne- 0x805a7e54
805A9C4C:  38210080 addi r1,r1,128
805A9C50:  4800001C b 0x805a7e6c
805A9C54:  B8410008 lmw r2,8(r1)
805A9C58:  38210080 addi r1,r1,128
805A9C5C:  4BE534ED bl 0x803fa340
805A9C60:  38610008 addi r3,r1,8
805A9C64:  4BA728A9 bl 0x8001c144
805A9C68:  7C7C1B78 mr r28,r3
805A9C6C:  4BA727B0 b 0x8001c054


E0000000 80008000
225683EC 00000000
0401C3A8 4858D858
065A9C00 00000070
38A00067 38810020
3CE0805A 60E39A18
4BE53539 38A0007F
3883FFE8 38610020
4BE53529 38A00068
60E49A18 38610020
9421FF80 BC410008
38610088 4BA73241

7C7C1B78 2C030000
4082000C 38210080
4800001C B8410008
38210080 4BE534ED
38610008 4BA728A9
7C7C1B78 4BA727B0


I might continue this on a later time, but it might even be a later date.

Slayer

@GaryCXJk

Deathwolf and paprika_killer should be able to understand that. Even though I know what ASM Codes and what sort of codetypes there are, I don't understand much of it. But I'm still learning so.. yeah..

Deathwolf

#552
SPECIAL ONLINE WiFi CODES BY DEATHWOLF
******ONLY WORKS ONLINE*******

WiFi Charakter Modifier 2 NON HOST [Deathwolf]
42000000 90000000
00FDCE62 000000XX
E0000000 80008000

WiFi Charakter Modifier 3 NON HOST [Deathwolf]
42000000 90000000
00FDD07A 000000XX
E0000000 80008000

WiFi Charakter Modifier 4 NON HOST [Deathwolf]
42000000 90000000
00FDD292 000000XX
E0000000 80008000

us it with button aktivator^^

this is perfect for Basic Brawl and Team brawl.

lol have fun :D

lolz

GaryCXJk

Yeah, my brain just died. I'll have to do this on another day. I think I will need to insert my old fixed code and see what's wrong with it, why it freezes and sitch.

Deathwolf

lol I think so too...
really nice work ;)
eventualy only you can port the code.
lolz