Need some experience seeking rom offsets

[Gatts]

Hello,

I am new to rom hacking but I recently had my first experience recently with Final Fantasy 12 International Zodiac Job System. I was playing the game and found it frustrating that you must set your job at the beginning and can't change it later. I wanted to change it. I first found this guide:

http://www.gamefaqs.com/ps2/459841-final-fantasy-xii/faqs/59603

Helped me a lot but this wasn't made for FF12 IZJS. So I had to figure how to change job myself. I got the hang of it. I am a software programmer in real life so looking around binary code wasn't new to me. After 2 days of comparing save states. I finally produced this guide:

http://www.gamefaqs.com/boards/939426-final-fantasy-xii-international-zodiac-job-system/68663952

I was proud of the work but somebody pointed out to me that it was completely useless since an editor existed. Gosh... well at least that gave me my first rom hacking experience.

That said, save state hacking is relatively simple since you can compare many of them with hex workshop and figure out the offsets by the changes. *However*, figuring the offsets of a rom itself seem much harder. Can't compare there. I would need some experience and some pointer to try it.

A few of my favorite games on the SNES: Seiken Densetsu 3, Final Fantasy VI, Megaman 7. I know these games have probably been mapped out. However, I want to try it out. I want to be able to find tile sprites, monster stats, levels configuration, music, etc. I have 2 questions.

1. What tools and apps should I be using?
2. Any useful tips or technique I should use?

Thanks

[FAST6191]

Though you can get lucky with simpler techniques the technique most use to properly figure out offsets (be they pointers or the actual data) is usually called tracing.

Most systems that are commonly hacked will have a tracing emulator of some description (it is a requirement really to call yourself a debugging emulator). However most of the work you see in projects around here (NES, SNES, megadrive/genesis, GB/GBC, GBA and more or less the DS) happens on systems where the data is all included in the binary (no filesystems), the cart is largely visible in memory (give or take bankswitching) and access is simple. Your PS2 work would see a DVD with a filesystem, possibly abstracted through a iso9660/UDF read protocol (if not raw disc reads, Square (Enix) is quite noted for using this for various things), not be visible in memory and more besides. This does not make it impossible but it does make it harder.

Tracing then. Naturally data will have to be read into writeable memory a lot of the time, especially for things like graphics and also because you do not want read latency getting in the way.

In the case of graphics you bust out the tile/map/model/texture viewer, see something you want to find in there and note where it is, reset/load an earlier state and set a breakpoint/watchpoint on the memory area in question.
The data you want gets written into the video memory and the debugger halts everything says "something is happening" to this area. If you are lucky it will be a nice DMA read (or similar) that has been pointed at the data. If not you might have to step through a few layers of compression or something being copied into normal memory first.
This holds more or less for a lot of assets, the sort of things you typically edit saves for are trickier. That is until you decide to step through the code and figure out -- your max HP is probably a mathematical operation using defence, constitution, character level, probably some jobs in your case.....
Alternatively for jobs then you might consider giving yourself infinite job points and using that to do lots of upgrades and watch what happens in each case.

The state of PS2 debugging is something I am not that familiar with right now (I am sticking with an ageing core2 which makes PS2 emulation pretty far from playable), in these situations I do often see good debuggers (it is not like debugging needs 30fps after all). In current dev, which has improved quite a bit as far as speed and compatibility goes, it seems to have taken something of a back seat but the older stuff looks like it was quite nice ( http://www.romhacking.net/utilities/617/ for example).
You could get crazy and try using a static disassembler (not sure what there is for the PS2 and I would probably immediately look to IDA anyway).

My usual "this is tracing" document is for the GBA and is http://www.romhacking.net/documents/361/ which is good but might be dangerous for you -- looking at the docs there are breakpoints, run to line and such things but a lot of the subtle stuff seen in emulators like FCEUX (NES) and VBA-SDL-h (GBA) is going to be lacking here.

[Gatts]

Thanks for the reply,

Yes maybe I would love to track code in FF12 for the PS2, but that seems extremely daunting. I remember reading one of the tracing FAQ on this site. The guy changed bytes to 00 until he found the first level. For FF12 we are talking about a 5 GB game. This is why I wanted to try practice on the SNES and work my way to complexity. I downloaded Geiger's SNES Debugger and Tile Layer and I am trying to see how it all work out with the 6502 Assembly. Thanks again for the tips.

[Scio]

You want to change it once, or do you want to program a switch to change whenever you want?
If it's the first, wouldn't save editing be easier? A PS2 save file is usually in the 100~500KB range.
If it's the switch, then you'll have some debugging to do.

[Gatts]

Save Hacking for PS2 is easy with the right tools, I have pretty much mastered it for Final Fantasy 12 & FF12 International Zodiac Job System. A FF12 IZJS save file is always 57864 bytes. I have done a guide on hacking the save state to change classes (read my first message). Right now I'm trying to see if I can identify anything on the ROM. If I open the .ISO winrar, I see only 5.86 MB of files for a 3.89 GB ROM. Where the heck are all the content? Where is the file system?

Otherwise, I'm practicing on snes 6502 assembly with Geiger.