ROM hacking/disassembling

[Lazarus]

I don't get it. How do I disassemble an .smc file?

I tried using xkas, but it seems to want an .asm file as input (wouldn't that be the output?).

Couldn't find relevant documentation in either the xkas README or on romhacking.net or wherever. I have some experience programming in assembly, but it has been a few years and I've partially forgotten the details. Maybe I suck, but help me anyway, pretty please.

[creaothceann]

RHDN has a disassembler.

See also:
http://www.zophar.net/utilities/nesdev.html
http://www.programmersheaven.com/downlo ... nload.aspx
http://board.zsnes.com/phpBB2/viewtopic.php?p=33033

[byuu]

xkas is an assembler, not a disassembler. The only disassembler I wrote was spcdas, which is only for the SPC700.

And the correct answer to 65c816 dissassembly is that you can't. Some people may point you to things like TRaCER, but that's really a no-go. The 65c816 has variable-length instructions, which can be toggled through dynamic code. There's no way to statically disassemble the code 100% perfectly in every case.

Using something like TRaCER will result in parts of the code being disassembled incorrectly. Your best bet is to use trace logs on the parts of the game you want to disassemble. Doing this to the whole game is not feasible.

[Lazarus]

xkas is an assembler, not a disassembler.

Sorry. Yeah, after posting, the feeling of being way off grew on me.

Your best bet is to use trace logs on the parts of the game you want to disassemble.

To produce these logs, do I need a non-standard/debugger version of bsnes or zsnes?

I have no expectation of being able to disassemble an entire game (lol), but I hope to be able to understand a little how the data is organized within a ROM. By looking both at traces and recognizable elements in a hexdump such as text, tiles and such, I guess. Or at least to find out how (un)doable such an endeavor is.

[grinvader]

Remember that a lot of games got these (text and graphics) compressed...

Everything's just MACHINE CODE <insert macro here> or data, ultimately. However there aren't any real "standard layouts". Code and data can be anywhere, and there aren't any way to differentiate them from the outside (although running data would probably end up crashing somewhere). Besides, what looks like data from the outside can be a SPC program waiting to be loaded, or something.

[whicker]

well. I suppose to get you started, on a higher level, the data could be seen to be organized by pages. At then end of a page, the data is usually padded with FF's. It helps to use a headerless image so the addresses are easier to calculate from the offset.

Unless the developers were cramped, a page usually is going to be all code, or all data. Or split at some even location. Generally level data is going to be all in one big block one after the other. You can find out if an area is executable code by looking for the returns or jump instructions. Watch out for jump tables (a table of addresses for what would be a CASE statement in a higher language) interspersed randomly in-between subroutines.

graphics data is going to be all compressed. There's not going to be much visible at first glance from a hex editor.

Starfox, however, does have a reduced ASCII-compliant character set. You can actually use Upper-case letters in the dialog, even though the game never uses them, because they look kind of funny by extending down instead of up.

Hope this little bit helps.