C0 CT gives DSI Exception

[Nutmeg]

I am trying to launch a game, Mario Strikers Charged, through gecko OS (of course) 1.9.3.1.  I am trying to apply this code.

C0000000 00000006
3E20806E 62310BA8
82310000 3DC08000
7C117000 40810014
39E00008 91F1024C
39E00001 91F10250
4E800020 00000000

ASM:
lis r17, 0x806E
ori r17, r17, 0x0BA8
lwz r17, 0(r17)
lis r14, 0x8000
cmpw r17, r14
ble- 0x14
li r15, 8
stw r15, 0x24C(r17)
li r15, 1
stw r15, 0x250(r17)
blr


The code should work exactly like a direct RAM fill.  (It does use a pointer, which is held in r17.)  I know I could do this with a pointer, but I want to become more familiar with the C0 CT, and I don't have a lot of games to hack... In other words.  I'm trying this for the learning experience. :p)

The Problem:  When Gecko OS lanches the game, codes are applied and everything goes as expected.  However, right before the games launches, a black screen appears that says "DSI Exception has occurred."  Then it shows a lot of confusing stuff.  Some of it holds the code I am trying to activate (see above) and (I assume) the other stuff are gecko registers and the code handler.  I would like to be able to apply my C0 code.

Any suggestions would be great!

[dcx2]

You should never use r14-r31 without saving them to the stack first, unless you know for a fact that those registers are safe.

And I know for a fact that, in the context of the code handler, r15 is not safe.  Neither is r14.  r17's safety is unknown.

http://wiird.l0nk.org/forum/index.php/topic,5622.msg55892.html#msg55892

[Nutmeg]

Hmm, good to know.  :cool:  (Probably saved me from freezing later :p)

However, it seems this did not solve my DSI exception problem.  Here is what I tried:

C0000000 00000006
3D20806E 61290BA8
81290000 3D408000
7C095000 40810014
39600008 9169024C
39600001 91690250
4E800020 00000000

ASM
lis r9, 0x806E
ori r9, r9, 0x0BA8
lwz r9, 0(r9)
lis r10, 0x8000
cmpw r9, r10
ble- 0x14
li r11, 8
stw r11, 0x24C(r9)
li r11, 1
stw r11, 0x250(r9)
blr

[dcx2]

If you're freezing, the first thing you should do is make a stack frame.  In particular, C0 codes do not follow normal programming conventions.  You can't really trust any of the registers; they can change from one version to the next without notice.

I would also do another check to make sure that r9 < (0x81800000  - 0x254), otherwise you could still put a bad pointer in r9.

On a side note, since you're doing ble- to blr, you could replace the ble- with blelr-.  It will blr if it would ble.  There's no reason to do it or not do it, it's just good to know about conditional blr's.  EDIT: if you have to use a stack frame, blelr- would be a bad idea.

[Nutmeg]

So, the DSI exception is being caused because the registers I am using are not safe?  If this is the reason for the DSI exception, I can find safe registers to use rather than working with the stack, right?

[dcx2]

Maybe, maybe not.

Making a stack frame and saving the registers you want to use is one way to eliminate the problem of register safety.  At this point, it could be using a register you shouldn't, OR it could be a bad pointer, OR it could be something else...

Once you get it working with the stack first, then you can try to get away without it.  And if it fails, you know it's because of register safety, and not something else.

[Nutmeg]

Okay, I've tried a bunch of different combinations of registers.  All of them have given me DSI exceptions.  I need to create a stack frame.  How would I go about doing this?  What exactly is a stack frame? Sorry for my lack of knowledge. xD

[dcx2]

stwu r1,-80(r1)         # make space for 18 registers
stmw r14,8(r1)         # push r14-r31 onto the stack

lis r17, 0x806E
ori r17, r17, 0x0BA8
lwz r17, 0(r17)
lis r14, 0x8000
cmpw r17, r14
ble- 0x14
li r15, 8
stw r15, 0x24C(r17)
li r15, 1
stw r15, 0x250(r17)

lmw r14,8(r1)         # pop r14-r31 off the stack
addi r1,r1,80         # release the space

blr

---

btw, I would also check to make sure the pointer you load isn't >= 81800000

stwu r1,-80(r1)         # reserve memory for 18 registers
stmw r14,8(r1)         # push r14-r31 onto the stack

lis r17, 0x806E
ori r17, r17, 0x0BA8
lwz r17, 0(r17)       # load [806E0BA8] into r17

lis r14, 0x8000
cmpw r17, r14
blt- _THE_END      # if r17 < 80000000, go to the end

lis r14, 0x8180
cmpw r17,r14
bge- _THE_END    # if r17 >= 81800000, go to the end

li r15, 8
stw r15, 0x24C(r17)   # [[806E0BA8]+0x24C] = 8
li r15, 1
stw r15, 0x250(r17)   # [[806E0BA8]+0x250] = 1

_THE_END:
lmw r14,8(r1)         # pop r14-r31 off the stack
addi r1,r1,80         # release the memory

blr

[Deathwolf]

r0 safe
r1 Stack pointer
r2 Table of Contents (TOC) pointer
r3 safe
r4 not safe
r5 safe
r6 ba
r7 gr addresses
r8 code execution status
r9 safe
r10 safe
r11 safe
r12 safe
r13 not safe (reserved)
r14 safe
r15 code line address
r16 not used
r17 safe
r18 safe
r19 safe
r20 po
r21-r31 unknowen

[dcx2]

Copy and paste fail.  The registers changed.  That's why you should use a stack frame.

http://wiird.l0nk.org/forum/index.php/topic,5622.msg55892.html#msg55892

[Deathwolf]

oh... spunit posted it.

http://wiird.l0nk.org/forum/index.php/topic,1733.msg17486/topicseen.html#msg17486

[dcx2]

Look at the post above spunit's.

[Deathwolf]

nice thanks but why are r17-31 unknown?

[Deathwolf]

_THE_END:
lmw r14,8(r1)         # pop r14-r31 off the stack
addi r1,r1,80         # release the memory
blr

Btw why are you branching to THE END which is lmw? There should be the original instruction or not?

[Nutmeg]

C0 has no original instruction.

BTW, I'll try out dcx2's stack frame when I get time.