Wow, this is a super useful hint, thanks!
I wasn't even too far off with my theory about the ANDs haha
Yes, I would like to fix it using the binary hacking tools... taking advantage of the decomps to seek the addresses is OK with me.
It's not only about fixing the issue, but also understanding what exactly went wrong in the ROM - just changing a line in a decomp and compiling again hasn't the same effect for me ^^
OK, so I am not super deep into C/C++, but the symbols are just the translation between the names (variables, functions, etc.) and the offsets, right?
The function this particular problem is in, is called "atkEF_handleballthrow".
Big question is which symbol file I have to use... I am using the english european Ruby Revision 1 ... should be
this, right?
If correct, this tells me the following:
0802b5b8 g 000003a8 atkEF_handleballthrow
I have no clue what the columns are exactly, since there is no header, but I guess the first one is the address and the third is the length in bytes (probably?).
The second column always changes between "g" and "l"... probably a declaration if it is a local or global function I would assume.
So, given that I didn't get it wrong, this should mean that the code in the ROM (whose address offset is 0x08000000 per se) starts at 0x02b5b8 inside the ROM and is 0x3a8 (= 936 dec) bytes long - wouldn't seem to be completely off the table.
Now, how do I look at the code behind that?
What exactly is behind this address... ASM instructions or THUMB instructions... how do I know?
XSE doesn't show anything with that offset at all - am I off with my detective work?
Kind regards