More robust item slot access for ACWW [EU]

Yesterday I committed myself to some debugging in order to find out how to correctly access the inventory slots in "Animal Crossing: Wild World" (European version) irrespective of resident number or WiFi play. And since I was successful, I want to share my findings with you.

First I'll explain how the game does it, so anyone who wants to implement a pure ARDS code approach without ASM has the needed information:

A. Considerations:

While playing, you have a number. Let's call it WiFi-number or WFN for short. When playing alone or hosting a WiFi game, your WFN == 0. Presumably, when you visit other towns, your WFN == 1, 2 or 3, depending on whether you were the first visitor etc.[/*:m:waq730z3]
The game has something I call a player slot allocation table or SAT for short with 4 byte-sized entries. Presumably each entry corresponds to a WiFi number.[/*:m:waq730z3]
From the SAT it retrieves what I call current player slot, or CPS. CPS 0 to 3 are for residents #1 to #4, respectively. Presumably, CPS 4 to 6 are for WiFi visitors. There is another possible slot number, 7, which is presumably used to represent "no slot allocated", "invalid", "error" or "special slot for debug purposes".[/*:m:waq730z3]
Each player slot is associated with an equally sized data area. Let's call it PDA, player data address.[/*:m:waq730z3]
Let's call the zero-based item slot number ISN.[/*:m:waq730z3]

B. That's the procedure:

It fetches an address from the pointer at 0x20CC0C8, offsets it by +0x68 and fetches the word-sized WFN from the resulting address.[/*:m:waq730z3]
If the WFN is valid, i.e. less than 4, it takes the address 0x21D3F04, offsets it by +0x10 (thus, the SAT is at 0x21D3F14) and indexes it by the WFN. Then it reads the byte-sized CPS from the resulting location.[/*:m:waq730z3]
Otherwise the WFN is invalid and it simply sets CPS = 7.[/*:m:waq730z3]
If the CPS is less than 4, it takes 0x21DAA04 as base. Then it multiplies the CPS by 0x228C and uses the result as displacement for the base, yielding the PDA.[/*:m:waq730z3]
Otherwise the CPS is greater than or equal to 4, in which case it takes 0x21D3FB8 as base. Then it subtracts 4 from the CPS and multiplies that by 0x228C. The base is displaced by the result, yielding the PDA.[/*:m:waq730z3]
Then it adds an offset of +0x1148 to the PDA.[/*:m:waq730z3]
Last it takes the ISN times 2 (since items are halfword-sized) as offset to the PDA and adds another constant offset of +0x9DA. Now it has got the address to access the correct item slot.[/*:m:waq730z3]

C. Short formulas:

WFN = [[0x20CC0C8] + 0x68][/*:m:waq730z3]
CPS = (WFN < 4) ? [0x21D3F14 + WFN] : 7[/*:m:waq730z3]
Address = ((CPS < 4) ? 0x21DAA04 : 0x21CB588) + (CPS * 0x228C) + 0x1B22 + (ISN * 2)[/*:m:waq730z3]

So, to make a long story short, in case you don't mind a little ASM, just make a long subroutine call to the THUMB code at 0x2097858, using instructions like these, for example:

Code:

ldr r3, =0x2097859 ; the address must be incremented by one to call it as THUMB code mov lr, pc ; move the address following the bx into the link register bx r3 ; unconditionally branch to the address in r3

DO NOT FORGET to save the link register before that call if you ever want to be able to return from your ASM ;)
The THUMB routine we "borrow" from the game has standard calling conventions, i.e. it preserves all registers apart from r0-r3 and r14 (link register).
It needs a valid stack pointer and nothing else as input and returns the PDA in r0.

Thus we could use a little ASM snippet to calculate the offset and do further processing with standard ARDS codes. Here's what you need to wrap around your codes to set the offset to the first item slot (untested):

Code:

023ff090 012fff11 e0000000 00000020 e1a0c00e e59f3010 e1a0e00f e12fff13 e2800c1b e2809022 e12fff1c 02097859 <- insert your item processing codes here, 100000xx 0000yyyy would put item #yyyy into the first slot if xx == 00, for instance d3000000 00000000 023ff090 e3520003

And for those who want to port that stuff to the US or JP versions, if the routine is nearly equivalent, you might be able to find it by searching a memory dump for the byte sequence 02 48 00 68 80 6e 02 4b 18 47 c0 46.

Hopefully I haven't been too verbose, but you're free to rebuke me :)

Re: More robust item slot access for ACWW [EU]

Quote:

Originally Posted by blubberdiblub

Code:

ldr r3, =0x2097859 ; the address must be incremented by one to call it as THUMB code mov lr, pc ; move the address following the bx into the link register bx r3 ; unconditionally branch to the address in r3

i had to be honest im truly impress with this one .. kudos with you blubberdiblub .. keep up the good works .. :mrgreen:

and thanks for the documentation .. it will really help us a lot not only for the acww but for future hacking .. ;)

Re: More robust item slot access for ACWW [EU]

Quote:

Originally Posted by toenailed

and thanks for the documentation .. it will really help us a lot not only for the acww but for future hacking .. ;)

Hmm, really? It was all quite ACWW-specific, apart from the long THUMB code call maybe.

Anyways, I found a little stupidity in my untested ARDS code snippet. You can't reasonably unpatch the ARDS routines with 023ff090 e3520003 while the offset is not zero.
Thus you have to clear the offset before that.
This of course requires that you do the processing before clearing the offset.

EDIT: changed the snippet to put the offset into r9 instead of r10, according to kenobi's updated register usage information regarding v1.54 of the firmware.