I know DahrkDaiz did tons of work on SMB3, and Jigglysaint did tons of work on LoZ.  However I don't think either of them made a proper disassembly.  LoZ would be especially tricky to make a disassembly for because it has relocatable code.

Anyway, disassemblies are hard to come by.  Especially commented ones.  You can use a basic 6502 disassembler and run your ROM through it and produce a somewhat readable diassembly of any ROM, but there won't be comments and it won't be re-assembleable.  It's still a good idea for extensive hacks, IMO.  Much easier to comment a disassembly as you go and make notes of where common routines are than it is to re-decipher things over and over and analyze all that machine code.

Sorry I can't be of more help on this one.


** note while I use a real game and real scenario, this is a totally fictional example where I fabricated all code/addresses/everything. **

It usually all starts with finding where the data you're interested in is stored in RAM.  Say you want to find out how much life Link loses when he gets hit by a Zora fireball.  The relevent information you'd look for here is Link's life.  So you'd open up the RAM viewer and try to find which area in RAM hold's Link's current life.

There are a few ways you can find this.  One is to try to figure out what value Link's life would be represented as.  If you have 3 hearts you could try looking for $03 -- but it'd probably be $06 (because of half-hearts) or possibly even $0C or $18 (because of quarter/eighth hearts -- which can happen when you have the blue/red rings).  Anyway search RAM for those values and change them to see if Link's life changes in the game.

Another way is to look at RAM, get hit by something, then look at RAM again to see what changed (probably lots of stuff, but narrow it down until you find it).

Once you know where life is, you can watch it by setting a write breakpoint on that address.  When the write breakpoint trips, it means the game is writing a new value to Link's life, which indicates he's either gaining or losing life.  You can use this in conjuction with the trace logger to see the code that happens just before this new value gets written.

So the steps here are:

1)  Savestate a bit before you're about to get hit by target object (in this case zora's fireball)
2)  Set write breakpoint on whatever address represents Link's life
3)  Open up the trace logger and start logging (note this will make the emu crawl, so try to hold off on this until you're just about to get hit)
4)  Get hit by fireball
5)  watch debugger snap
6)  Examine tracelogger to see how the game is changing the life
7)  Use that to determine where it's getting the fireball damage from

I recommend step 1 there in case you slip up and don't get the tracelogger fired up in time, or if you need to repeat the process again (perhaps the first breakpoint was a false lead -- like the game writes to the life a few times).  Anyway if you need to repeat you can simply load the state rather than having to reprep everything and start over.

Life changes would be a subtraction deal.  So the code at the end of the trace logger would probably look something like this:


In this example code, you'd be interested in the value at $00 since that represents the damage.  But to find out how the game got that damage you'd have to scroll up in the tracelogger even more.  If you're lucky you'll come across something concrete... like:


In which case you know the fireball damage is coming from address $8123 (which is ROM) -- and from there you can determine the file offset.  More likely, though, you'll find a generic "DealLinkDamage" routine where the damage comes from another variable:


So now you'd need to find how the number got to $6100+X.  You might be able to just scroll up in the tracelog -- but you might even have to set a new breakpoint to find out.

But anyway that's tracing.  Just keep going back and looking to see how the number got there.  Eventually the number has to originate in ROM, so just keep tracing back until you find out where it comes from.

Thanks for the reply, Disch.  I played some of the other hacks for SMB3 and the hacking pros here make it seem so easy to change some of the simpler aspects of games.  But at least now I have an example to go off of and can start doing these changes myself.  It's a starting point at least.  I really appreciate this.

By the way, just for the record, there were three primary reasons that I wanted help with this for my SMB3 hack: to change the amount of points before the N-Spade shows up (it's usually 80,000 points), change the 200 second time limit preset option to 50, and to change the amount of damage certain attacks do to certain enemies.  I didn't have any luck before, but hopefully I can change these things now.  Wish me luck!

P.S.: I tried to get in contact with DahrkDaiz, but I didn't have any luck.  Maybe he didn't get the email or maybe he's been busy doing other stuff (I think he was working on another SMB3 editor).  Do you know by chance if he is still around and hacking?