Location of ba/po in MEM1?

Started by daijoda, December 08, 2011, 10:30:42 PM

Previous topic - Next topic

daijoda

Just wondering if the ba and the po have their own fixed locations in memory like the grN's. If a fixed address always holds the po, then I suppose I could do direct reads/writes on it? Thanks.

dcx2

You can do direct reads/writes on the ba/po using the existing code types.  42, 44, 4A, and 4C code types.

They do not exist at a memory address.  Rather, they exist in registers while the code handler is executing.

The code handler is executed once per frame (not always true, depends on the hook).  Before it begins parsing the code list, it sets two registers to 80000000.  These registers can vary depending on what version of the code handler you're using.  They can be accessed inside C0 codes.

Keep in mind that C2 codes do not execute in the context of the code handler.  Rather, they execute in the context of the game (that is why we have access to game pointers in a C2 code).  Do not attempt to read the ba and po registers from a C2 code, it will fail.

In recent code handlers, r6 will have the ba and r16 will have the po.  This post has more details.  Again, these regs will change depending on the version of the code handler, so this is not really the most reliable technique.  http://wiird.l0nk.org/forum/index.php/topic,5622.msg55892.html#msg55892

daijoda

Thanks for the information. I guess I just can't have access to both the po and the game pointer at the same time... lol

dcx2

Correct.  The po simply does not exist during the game's execution.  It only exists while the code handler is executing.

Why do you want to use the po during the game's execution?  What are you trying to do?

daijoda

I was hoping I could dump a pointer from a register while in a C2 code to the po, then load the pointer's value into grN and do float add and float multiply using existing grN codetypes, as floating point operations in a C2 code seem complicated to me... what I ended up doing was dumping that pointer to grN, and using [grN] codetypes to do the calculations, but I don't think that's nearly as elegant as the po itself.