Pointer With Register Help

Started by Macopride64, June 21, 2013, 02:28:06 PM

Previous topic - Next topic

Macopride64

Two things.


The following code works on Dolphin, but not on Wii. The code swaps textures on archives, and as soon as archives is loaded the game freezes on Wii. Now I thought Gecko and and the latest revision of the Dolphin were meant to use the same code handler. I also tested it with Neogamma r9 b56, same deal as gecko. I've tried changing registers but that didn't help.

[spoiler=code]Woodchives v1 [Macopride64 -NTSC-U]
48001001 80770C14
DE000000 90009340
92210001 00000BE0
94210001 00000BC4
92210001 00001ADC
94210001 00000BFC
92210001 00001A34
94210001 00001794
92210001 00001954
94210001 000017CC
92210001 00001ADC
94210001 000017E8
92210001 00001ADC
94210001 00001804
92210001 00001A34
94210001 00001820
92210001 00001A18
94210001 00001890
92210001 00001ADC
94210001 000018E4
92210001 00001ADC
94210001 00001954
92210001 00001ADC
94210001 00001A34
92210001 000018C8
94210001 00001ADC
E0000000 80008000[/spoiler]


Now what's strange is the fact that I need to use a register for my pointer code. If I don't use a register, if a texture that is being used to replace another texture gets replaced, both textures become the texture that replaced that being used to replace the other (...I know this is confusing, so open the spoiler below).

So basically:
[spoiler=]
Texture 1:


Texture 2:


Texture 3:



Texture 1 is replaced by Texture 2, Texture 2 is replaced by Texture 3, then Texture 1 becomes Texture 3. I want Texture 1 to remain replaced by Texture 2.

[/spoiler]


Why is it this doesn't happen with a pointer and register but happens with just a pointer?

dcx2

48001001 80770C14

48001 : po = [grN+XXXXXXXX]

I don't think this is what you meant to do.  On Dolphin I'll bet gr1 = 0, which is why this works (0 + X = X).  But with Gecko, I think there's some garbage in gr1 from the loader.  When this garbage gets added to your 80770C14 (? + X = ???), kaboom goes the DSI exception.

I think you wanted to use 48000000 instead.

...and, like, wouldn't this get all screwed up based on whatever was left in gr1 when it executes 94210001 00001ADC?  Unless this value was also 0.  But that stuff left over in gr1 should mess with that 48 code at the beginning, unless you somewhere else pre-loaded gr1 with the right stuff.

Macopride64

Originally, this was my code:

[spoiler]Woodchives v1 [Macopride64 -NTSC-U]
48000000 80770C14
DE000000 90009340
92210000 00000BE0
94210000 00000BC4
92210000 00001ADC
94210000 00000BFC
92210000 00001A34
94210000 00001794
92210000 00001954
94210000 000017CC
92210000 00001ADC
94210000 000017E8
92210000 00001ADC
94210000 00001804
92210000 00001A34
94210000 00001820
92210000 00001A18
94210000 00001890
92210000 00001ADC
94210000 000018E4
92210000 00001ADC
94210000 00001954
92210000 00001ADC
94210000 00001A34
92210000 000018C8
94210000 00001ADC
E0000000 80008000[/spoiler]

It works fine on both Dolphin and Wii, but the problem that I mentioned in the spoiler occurs with this code. What I want to know is, why doesn't this problem occur when a pointer has a gr?


Thanks.

dcx2

Ah, I think I see what's happening now.  That other half of your post didn't make sense at first.

The reason it works with the GR is because, as I mentioned, the GR has stale values in it.  I think those stale values make it so your code only writes to the important addresses once, and on subsequent executions it writes somewhere else, leaving the originals in tact.

I bet if you only executed your code once, you wouldn't get that retexture glitch.  You can use this hacky construct to make your code execute only once, put it at the top of your code.  The first time it runs, the A0 line sets code execution status to true, and then overwrites the A0 line with A2, which will always set the code execution to false for every subsequent run of the code handler.  This snippet also does not care what value is in gr0.

4E000000 00000000 # po = address of A0 word
A0000000 00000000 # gr0 == gr0 is always true
14000000 A2000000 # gr0 != gr0 is always false

Macopride64

Thanks for the code. However, the memory the pointer writes to isn't there until archives is loaded. And the memory resets resets every time archives is reloaded.  :(

This pretty much works like an F6 code now. All that's needed is a good activator, however I can't find a good one (other than a button activator of course).