Points of Required Attention™
Please chime in on a proposed restructuring of the ROM hacking sections.
Views: 88,441,623
Main | FAQ | Uploader | IRC chat | Radio | Memberlist | Active users | Latest posts | Calendar | Stats | Online users | Search 04-20-24 11:29 AM
Guest: Register | Login

0 users currently in ROM Hacking | 2 guests | 1 bot

Main - ROM Hacking - 65816 Tracing Tutorial?! New thread | New reply


FloBo
Posted on 08-12-07 11:36 AM Link | Quote | ID: 61964

Newcomer
Level: 6

Posts: 3/4
EXP: 627
Next: 280

Since: 06-26-07
From: Germany

Last post: 6095 days
Last view: 6067 days
Hi there.

As this has always been some kind of myth to me, I just wanted to know if anyone of you guys knows some descent 65816 tracing tutorial, showing how to trace data (like tilemaps, etc.) using geigers snes9x debugger...

I mean, I know that you have to somehow figure out, where your data might be (using corruption or something similar), then trace the according address using the debugger... thus, you can find out where the data is loaded from/stored to and what compression it uses... you just have to identify some of the most important asm-routines, right?

So... having read a whole lot about snes-hardware-internals and 55816 asm and having all that theoretical how-to knowledge explained above, I'd just like to see, how it is done in reality...

So is there some tutorial existing or any volunteer wanting to help me out on this one? Thanks in advance

____________________
check my fabulous website Digisalt online

Sukasa
Posted on 08-12-07 11:40 AM Link | Quote | ID: 61965


Red Birdo
Level: 92

Posts: 409/2112
EXP: 7685703
Next: 71234

Since: 02-19-07

Last post: 4442 days
Last view: 3213 days
well, mostly when your'e looking for data you need to find how it's stored. if you're looking for something like level tilemaps, it's not as bad. try corrupting sections of RAM, possibly by using a lot of PAR codes or by using ZSNES savestates, altering the RAM in them, and repeating until you find bytes then when changed affect what you're trying to find out, such as corrupting collision data in the game.

then, once you've found the RAM location, you might use a SNES9X debugger breakpoint to look for writes to the start of that RAM section, and then finally 'step out', then place an execution breakpoint on the bytes just before the command you're currently at. reset, and you'll have found the routine that handles data you're interested in.

of course, you'd need to expand on that greatly and find other ways of locating data, but this is one example.

FloBo
Posted on 08-12-07 12:40 PM Link | Quote | ID: 61969

Newcomer
Level: 6

Posts: 4/4
EXP: 627
Next: 280

Since: 06-26-07
From: Germany

Last post: 6095 days
Last view: 6067 days
Posted by Sukasa
...to look for writes to the start of that RAM section, and then finally 'step out', then place an execution breakpoint on the bytes just before the command you're currently at. reset, and you'll have found the routine that handles data you're interested in.

of course, you'd need to expand on that greatly and find other ways of locating data, but this is one example.



What exactly do you mean by the start of the RAM section? the start of the rom bank? And just for my understanding: when I 'step out', I get to the point, where the routine started, that actually messed around with the offset I set my first breakpoint to, right?

Alright then... having the knowledge of where my tileset is stored in rom (compressed) and where it finally is loaded to ram, I should be able to figure out the compression routine using just what you said. take a read-breakpoint, push step out, take an execute breakpoint and push next op as often as needed to figure out what the compression algorithm does, right?

____________________
check my fabulous website Digisalt online

Main - ROM Hacking - 65816 Tracing Tutorial?! New thread | New reply

Acmlmboard 2.1+4δ (2023-01-15)
© 2005-2023 Acmlm, blackhole89, Xkeeper et al.

Page rendered in 0.019 seconds. (339KB of memory used)
MySQL - queries: 47, rows: 70/70, time: 0.015 seconds.