I don't fully understand what it's doing, but I think I found the data for that specific instruction.
Search for the hex 40 53 42 30.
In the disc image it's found at 0x21b4fb71. Not sure how that is useful to know.
Tried to save as a binary but I couldn't get it to work. Set address to 0x00 and size ot 0x2000000. Most I can get is a size of 0x200000. I could make 10 binary dumps and then search through all of them, maybe? Unless you know of a Windows tool that lets you search through specified binary files or directories for specific bytes?
Saved a disassembly of battle ram from 0x00 to 0x2000000 but it looks like it's too much for Notepad2 to search through. I'll try find (windows 7 user here).
C:\stuff\>find /n "30425340" battle_disassembly.lst
C:\stuff\>find /n "40534230" battle_disassembly.lst
C:\stuff\>find /n "40 53 42 30" battle_disassembly.lst
C:\stuff\>find /n "30 42 53 40" battle_disassembly.lst
Using a write breakpoint, I discovered that it was loading values from the scratch pad. Then I used a write breakpoint on the scratch pad and found various routines, but I needed to narrow it down. I set the breakpoint condition so it would only trigger when the register holding value to write had the exact value of the instruction. I looked at the memory address it had loaded from when building up the value.
I don't know how much changing those bytes will affect though. I think I saw the very next or nearby instructions coming from very far apart memory addresses.
Edit: Here's an example of one of the routines.
00070b28: 92a50000 lbu r5,0x0000(r21)
00070b2c: 26d6ffff addiu r22,r22,0xffff
00070b30: 12c000fa beq r22,r0,0x00070f1c
00070b34: 26b50001 addiu r21,r21,0x0001
00070b38: 00121c00 sll r3,r18,0x10
00070b3c: 00031c03 sra r3,r3,0x10
00070b40: 000310c0 sll r2,r3,0x03
00070b44: 00451004 sllv r2,r5,r2
00070b48: 146f0017 bne r3,r15,0x00070ba8
00070b4c: 02629825 or r19,r19,r2
00070b50: ae130000 sw r19,0x0000(r16)
00070b54: 26100004 addiu r16,r16,0x0004
I'm really not sure what I'm looking at.
I loaded all saves from a memory card, and when that didn't work I started a new game.
Thanks to Pyriel of gamehacking.org, for pointing out that the gameshark code only writes to a single byte (the conditional code checks two bytes if they match, and if they do then it executes the next code which overwrites 0x40 with 0x00 at 0x1a665c).
So the routine is originally this:
andi r2,r2 0x4000
and it becomes this:
andi r2,r2 0x0000
I checked endianness by comparing something I know: ability data, in SCUS_942.30 and in RAM.
SCUS_942.30 : 9ee0 : 30 00 01 c0 80 14 00
RAM : 296e0 : 30 00 01 c0 80 14 00
So whatever I see in RAM is exactly the same as anything I'll see in a game file.
Now checking disassembly.
RAM : 1a665c : 00 40 42 30
Disassembly : 1a665c : 30 42 40 00
So anything I see in disassembly is in reverse order, byte by byte, from what I see in memory or in a file.
With this in mind, I'm looking for:
00 00 00 00
00 40 42 30
2d 00 40 14
00 00 00 00
Again, the only hit I get on this entire string is at 0x88531f5 in a *.bin disc image.
Trying agin. Setting 0x88531f5 from 0x40 to 0x00.
Can't take a screencap for some damn reason in Windows 7. Nonetheless this seems like it should be it.
Still doesn't work.
Decided to replace all occurences of 0x00404230 with 0x00004230, and then use data corruption methods to find the exact location when something actually changes in RAM. Only 29 hit in the entire disc image, replacing them all now.
Nothing seems buggy.
Doesn't work, still displays 0x40 at 0x1a665d.
I located the file in which the routine is found. It is /MOUT/BATTLE.OUT, at 0x2665d. The exact same routine (even the routines as far up and down as I can scroll in about 4 seconds, maybe a few dozen lines - they are EXACTLY the same in RAM and in BATTLE.OUT) yet when I edit BATTLE.OUT nothing happens. Could this be because I'm loading saves from a memory card?
I patched /MOUT/BATTLE.OUT. Imported the file into sf_testing.bin. Checked 0x88531f5 in sf_testing.bin. The change from 0x40 to 0x00 is listed there too and the hex above and below that location are identical to BATTLE.OUT. Loading it in pSX and starting a new game, we'll see what happens.
Still doesn't show up as changed in RAM.
There is no reason why this shouldn't work, and I'm ****ed if I know. I'll move on to another code that is within the range of SCUS_942.30 where it's loaded in RAM (I know this because I know where a few data tables from SCUS_942.30 are found in RAM) and unless someone has an explanation for this. If I encounter the same problems there then I don't know what I'll do, but at least I'll know it isn't something I'm doing wrong.