(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
 Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album 		05-07-24 03:19 PM
0 users currently in ROM Hacking.
Acmlm's Board - I3 Archive - ROM Hacking - Disassembling a ROM:Help New poll | |
Add to favorites | Next newer thread | Next older thread
User Post
interdpth

Mole
MZM rapist


 





Since: 11-18-05

Last post: 6287 days
Last view: 6287 days
Posted on 06-30-06 02:31 PM Link | Quote
Ok, well i'm disassembling MZM, and well I have no clue how to tell when it creates a variable in memory and that stuff. I know it usually has them in the 0x3000000 area of memory but I need to know how many lines it takes to create them and access them and what the code looks like and how it knows when it's accessing an array or structure this way.
Kyoufu Kawa
Intends to keep Rom Hacking in one piece until the end








Since: 11-18-05
From: Catgirl Central Station

Last post: 6287 days
Last view: 6287 days
Posted on 06-30-06 02:42 PM Link | Quote
Unless there's a lot of malloc use, variables don't need to be "created" in memory.

The compiler uses the whole "int i" thing to keep track of what kind of variables you use. The intermediate ASM code doesn't include any predeclaration. In fact, the closest I've seen is "GunAmmo EQU (some location)".

In fact, statements regarding variables load the value at the location previously assigned to GunAmmo into a CPU register, does the math, and puts it back.

For example:
uint8 GunAmmo = 9;
...
GunAmmo--;

...could become
LDA $03000005
DEC
STA $03000005

...after the startup routine presets 0x3000005 to 9. The "uint8" declaration tells the compiler that GunAmmo is an unsigned byte, so byte commands are spawned where available.

Note: just my theory based on my own observations.
Edit: the commands you seek are LDA/STA and their brethren.

(edited by Kyoufu Kawa on 06-30-06 01:43 PM)
labmaster

Red Paragoomba


 





Since: 11-18-05
From: Away for exams, back mid-December.

Last post: 6363 days
Last view: 6293 days
Posted on 06-30-06 08:20 PM Link | Quote
Local variables are usually stored on the stack, or aren't put into memory at all. For example, a function from a game that I'm currently doing some work on:


08065eb8 b5f0 push {r4-r7,lr}
08065eba 4657 mov r7, r10
08065ebc 464e mov r6, r9
08065ebe 4645 mov r5, r8
08065ec0 b4e0 push {r5-r7}
08065ec2 b084 add sp, -#0x10
08065ec4 0400 lsl r0, r0, #0x10
08065ec6 0c05 lsr r5, r0, #0x10
08065ec8 0609 lsl r1, r1, #0x18
08065eca 0e0c lsr r4, r1, #0x18
08065ecc 9200 str r2, [sp, #0x0]
08065ece 9301 str r3, [sp, #0x4]


08065ec2 makes room on the stack for the variables, the next 4 instructions performs some unrelated masking, then the last two str's put 2 of the functions arguments into memory. These can later be accessed by instructions like

08065f18 9902 ldr r1, [sp, #0x4]

Alternatively, local variables could just be stored in registers - sometimes you'll see them moved to r8-r12 to get them out of the way when they aren't needed.

Everything else is either in EWRAM or IWRAM (0x02000000 and 0x03000000) - there aren't any hard and fast rules on what a game will use, though as you get more experience you'll see that things tend to be done certain ways (in my experience, player stats and level data have almost always been in EWRAM).

In terms of how games access this data - sometimes the pointers will be hardcoded into the game, other times pointers to pointers will be hardcoded in, sometimes pointers to pointers to pointers will be in, sometimes a base pointer will be kept in a register like r12. For a really pain-in-the-ass example of how a game accesses player data, see Pokémon Emerald

You'll have to look out for ldrx/strx instructions - if you step through code it will usually become apparent when a game is looping through an array. As for structs, sometimes they'll use immediate-indexed ldrx's, other times they might use a ldmia instruction, which pulls several sequential words and chucks them into a set of registers in one swoop.

The last thing I'd have to say, is don't rely on disassembly ('deadlisting') to find out what you need. Things can often make a lot more sense when you take the 'live' approach and manually step through code in a debug, or dump a trace.
Kyoufu Kawa
Intends to keep Rom Hacking in one piece until the end








Since: 11-18-05
From: Catgirl Central Station

Last post: 6287 days
Last view: 6287 days
Posted on 07-01-06 05:33 AM Link | Quote
Originally posted by labmaster

For a really pain-in-the-ass example of how a game accesses player data, see Pokémon Emerald
It's not that bad...
Add to favorites | Next newer thread | Next older thread
Acmlm's Board - I3 Archive - ROM Hacking - Disassembling a ROM:Help |


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.048 seconds; used 365.84 kB (max 437.13 kB)