Memory Copy Crashes Game

[Anarion]

Hi. So I'm quite stumped as to why this happens the moment I apply the code.

Lets just say this is the code overall.

48000000 80123456
DE000000 92009300
5A011005 00000050 (gr5=180)
90010000 00000000
E0000000 80008000 -code sets gr0 to address in pointer+1D0
48000000 80987654
DE000000 92009300
58010000 00000008
DE000000 92009300
5A010000 0000001C (freezes with&without this line if i'd add 1c to 4e)
9A001003 0000004E
E0000000 80008000 -code is supposed to copy 16 bytes from address in gr0 to address in pointers+6A


Its the memory copy that is causing the freeze as it happens the moment I apply that pointer code. And I don't know why. It looks ok to me. Or am I missing something here? :-\ I'd appreciate any input. Also, whom may I speak to to get a username change, if possible and willing to do so? I want to have my geckocodes name :s thanks!

[Arudo]

Can't you change your username in your own profile? If not, PM me.

[Anarion]

i didn't know i could. *facepalm*

thanks :)

[dcx2]

You got the 9 but forgot the F.  You actually kindof blended two code types together, which made me wonder what the code handler would do.  Turns out it does what you think it would do.

[spoiler=code handler source]
#copy1        (5) : 8AYYYYNM XXXXXXXX = copy YYYY bytes from [rN] to ([rM]+)XXXXXXXX
#copy2        (6) : 8CYYYYNM XXXXXXXX = copy YYYY bytes from ([rN]+)XXXXXX to [rM]

_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==5 then source+=XXXXXXXX
   b   +8
   add   r9,r9,r4      #lf sub code type==6 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


_load_NM:            # note M = K in the code type doc
# r17 will contain N, r9 will contain M
   cmpwi   cr5,r10,4      #compare code type and 4(rn Operations) in cr5

   rlwinm    r17,r9,6,26,29      #Extracts N*4
   cmpwi    r17,0x3C
   lwzx   r17,r7,r17      #Loads rN value in r17
   bne    +8
   mr   r17,r14         #lf N==0xF then source address=(ba/po)(+XXXXXXXX, CT6)

   beq   cr5,+8
   lhz   r17,0(r17)      #...and lf CT4 then N = 16 bits at [XXXXXX+base address]

   rlwinm    r9,r9,10,26,29      #Extracts M*4
   cmpwi    r9,0x3C
   lwzx   r9,r7,r9      #Loads rM value in r9
   bne    +8
   mr   r9,r14         #lf M==0xF then dest address=(ba/po)(+XXXXXXXX, CT5)

   beq   cr5,+8
   lhz   r9,0(r9)      #...and lf CT4 then M = 16 bits at [XXXXXX+base address]


   blr



[/spoiler]

8AYYYYNK XXXXXXXX
copy YYYY bytes from [grN] to [grK]+XXXXXXXX, grK can't be F.

9AYYYYNF XXXXXXXX
copy YYYY bytes from [grN] to po+XXXXXXXX

The reason your code crashes is because you are actually copying from [gr0] to [gr3]+0x4E.  In your case, you are using K=0x3 but you actually wanted to use K=0xF.  My assumption is that some garbage in gr3 was not a valid address (I would bet 99% chance it was 0), which caused a DSI exception to be generated when it tried to write to an invalid address, and the game appeared to "crash".

I would be surprised if Gecko.NET could not catch the exception generated by the crash; just switch to BP tab and click Step Into to catch the exception.  This would cause a crash in the code handler, so Gecko.NET will ask if you want to reset the code handler.  You should say no, because you would need to fix the code, and *then* restart the code handler.

Note that it's possible to catch some exceptions with WiiRDGUI, and DSI exceptions are one of them.  The trick is that you must set at least one breakpoint.  When you do this, WiiRDGUI will automatically patch a few exception handlers down around 80000300 etc.  Then, if a crash happens, the code handler will catch it, and you can go to WiiRDGUI's BP tab and click "Get BP Data" or "Step" and it will catch the exception.  If you fix the problem with the crash, e.g. realize your code is throwing null pointer exceptions and fix it, you can actually reset the instruction pointer back to the beginning of the code handler (just after the stack frame is stored) and un-crash the game.

[Anarion]

Wow. That fixed my code. Thank you very much for the explanation!  :) Its quite amazing to me the difference that bit of code makes depending on the gr used.

[Bully@Wiiplaza]

Some of these codetypes are seriously way to confusingly explained.
It´s so bad, you need to have coded or analyzed the code handler to know what you need to use and what crashes.
Assembly is easier overall. Codetypes should simplify but often achieve the opposite.

Don´t just say: "Do it better then" because firstly I don´t know the usage of all of them (because of their lack of description) and secondly I can´t edit the page. Also it´ll take very long to explain everything in detail the way people need it.

Also we need good examples on ALL codetypes. There isn´t even one for 04. :smileyface:

Many people complain there are no proper explanations on the codetypes, especially newbies.
I don´t blame them, it´s true...

[γRB]

True, I was kinda disappointed aswell..

[dcx2]

It can be difficult to understand, but AFAIK the codetype doc has no technical mistakes, except for possibly the Else thing (I vaguely recall kenobi saying that Else codes act funny).

If you would like to write some examples, I'm sure James would modify the codetype doc to include your examples.  In fact I'm sure some people have written exemplary codes that demonstrate how to use different code types.

I often find myself delving into the code handler source to make sure it is doing exactly what I think it's doing.  For instance, even though the code type doc says "grK can't be F", a reading of the code handler source implies that neither grN or grK can be F.  In both cases, grF will cause ba/po to be loaded into N and/or K(M in the code handler).  It wouldn't cause a crash, but it wouldn't do anything useful.  I don't view this as really a technical error in the code type doc, but it should perhaps be more explicit.

Also, nothing beats actually trying to write the code and making it work.  You can read the code handler source all day but in the end it might not be doing what you think it's doing.  Sometimes, "just try it and see what happens" is the best approach.

[James0x57]

If you would like to write some examples, I'm sure James would modify the codetype doc to include your examples.  In fact I'm sure some people have written exemplary codes that demonstrate how to use different code types.

Definitely would add more examples if people made some. Post 'em in an appropriately named thread and shoot me a PM to be sure I see it.

[Bully@Wiiplaza]

Give me some time and I´ll get started with some perfect examples. :P