Back again!
After having done that complete reordering of the routines (so that I would need no header - in a C-program, that means, each called routines has to be defined above - which worked well, except for the two 'circles', think I wrote about it before), it is now much easier to track the behaviour of the adressregister. First I solved all stack things, then A3 felt, and now I'm in the middle to solve A5. Because that's not the first time, I know what is to be expected, but this time I do it pretty straight, non-automated, consequent and care for especially for const correctness. Having found a method to make that runnable and debugable after each editing step, the whole thing slowly gets a form.
An assembler command like:
move.b $21(A5), D0
first 'morphs' to a statement like:
DREG0.b0 = AREG5.bpeek(21);
and a short while later, when it is confirmed that it's about a party here, a pointer takes over, jumps as argument into the routine header and it looks like this:
DREG0.b0 = P->bpeek(21);
As you can imagine, all appearances of indices that are related to the party can be found much easier now. In addition, as soon as I'm through with this one, C++-typical microfunctions will replace those anonymous accesses. i.e.:
P->swlpeek(10)
will 'morph' to
P->getgfxy()
Because of C++'s protection mechanism, it will not be possible to access this word in any other way than in well-defined ones.
That way, we will reveal each one of them. I know, there aren't much indirect indices, and if so, it's mostly because of the necessary things like looping through the four party members etc.
Even those things will get their 'microcode' to enhance readability.
So the answer is: Not done yet, but is the next that will happen, and when it happens, then in one rush for all the 98 bytes.
Continuing with AREG4 and the NPC then.