Sonic CD Gems Collection Linker Disassembly Dumps

Hi Devon. Could you please explain how you went about creating your sample decompilation? I can't find good references for reading PS2 MIPS assembly. I've only had experience with reading NES 6502 assembly until now.

action() is a global function, so it appears in multiple files. So far I've figured out the first instructions do general housekeeping to update the stack and return addresses.

The first actual instruction seems to be:

Code (Text):

1. lui          a0,hi(actwk+257)

According to a reference, lui means "To load a constant into the upper half of a word.". So here the high part of actwk is loaded into the high part of a0 (function argument register)? What does +257 mean, here?

Can you please get me started? Thanks!

 

Not familiar with PS2 MIPS, but in most assembly languages, that would be the offset to move to after loading the constant address actwk. Think of Actwk like an array, with Actwk being the base offset of the array. It's saying the constant to load is the 257th element of the array in Actwk.

Looking further at the code, it seems Actwk is a structure containing many values byte packed into chunks. So that is the offset of some smaller value, ie xposi or yposi or something else in Actwk.

 

I've found the actual action function using the referenced memory address. I'm stuck on the following instructions:

Code (Text):

1. lui          s0,hi(actwk+256)
2. addiu        s0,s0,lo(actwk+13696)

I've determined that the struct type that actwk points to is 74 bytes, which is a strange size. +256 would mean the fourth element, member cddat. Then +13696 would mean the start of struct number 185, which doesn't make sense as the array of actwk structs has 128 elements.

I must be doing something wrong. No idea how that translates to:

Code (Text):

1. pActwk = actwk;

EDIT: Looking back at the symbol table, actwk's size is 8704. Divided by 128, that'd mean that each struct is 68 bytes. When I recalculate, I count 66 bytes. There must be two bytes of padding.

EDIT2: Yup, there were two padding bytes:

Code (Text):

1.  
2. struct anon0
3. {
4.   unsigned char actno;      // 1
5.   unsigned char actflg;     // 1
6.   unsigned short sproffset; // 2
7.   _anon3** patbase;         // 4
8.   _anon5 xposi;             // 4
9.   _anon5 yposi;             // 4
10.   _anon9 xspeed;            // 2
11.   _anon9 yspeed;            // 2
12.   _anon9 mspeed;            // 2
13.   unsigned char sprhsize;   // 1
14.   unsigned char sprvsize;   // 1
15.   unsigned char sprhs;      // 1
16.   unsigned char sprpri;     // 1
17.   unsigned char patno;      // 1
18.   (padding byte)
19.   _anon9 mstno;             // 2
20.   unsigned char patcnt;     // 1
21.   unsigned char pattim;     // 1
22.   unsigned char pattimm;    // 1
23.   unsigned char colino;     // 1
24.   unsigned char colicnt;    // 1
25.   unsigned char cddat;      // 1
26.   unsigned char cdsts;      // 1
27.   unsigned char r_no0;      // 1
28.   unsigned char r_no1;      // 1
29.   (padding byte)
30.   _anon9 direc;             // 2
31.   _anon9 userflag;          // 2
32.   unsigned char dummy[2];   // 2
33.   unsigned char actfree[22];// 22
34. };

Finally, my decompilation of the action function:

Code (Text):

1. void action()
2. {
3.    _anon0* pActwk = actwk;
4.    for (int i = 0; i < 128; ++i) {
5.     if (pActwk->actno != 0) {
6.       act_tbl[(pActwk->actno - 1) << 2](pActwk);
7.     }
8.     ++pActwk;
9.   }
10. }

 

I've made lots of progress the past week, reading the disassembly assisted by Ghidra. I've decompiled almost all the code that's meant to go in the action.c file. There's just one function left, but it uses an undefined global variable called @113 and an existing stack variable that's probably set by the calling function. The calling function is not part of action.c, so I'm moving on to other files until I have more data.

For some reason Ghidra is bugged regarding global variables. It seems to have multiplied the addresses by 2, which not only makes it point to incorrect addresses, but also makes them fall outside of the memory range. This makes it impossible to name or assign types to them. I have no idea of how to resolve this.

 

I want to ask: how did you all manage to get the DWARF v1 data properly interpreted by Ghidra? From what I've seen, Ghidra only natively supports DWARF versions 2 and above, and while an extension exists to handle this sort of thing, but to my knowledge, it does not work on newer versions of Ghidra (or at the very least, I cannot recompile it with current tools as described here).

 

I entered the type data manually into Ghidra.