... the whole game? That would indeed be a first.


Try and disassemble the db's in this code:


It could be either lda #$6b00 : nop, or lda #$00 : rtl : nop.

And this is why you can't have a generic disassembler for the SNES. Variable instruction lengths. This is why few have even tried. But if you're looking for the best overall disassembler, you might try ISDA by Louis Bontes, if you can find it. It tries a lot harder to predict changes to P, but of course no disassembler can be perfect.

Really, the only good way to do this would be to have a debugger that logged what addresses contained what opcodes. Also export a lot of symbolic information like where the code usually jumps to, sort of a profiler if you will. Follow up with a disassembly that also attempts micro-emulation of code blocks for the stuff you couldn't trigger through normal gameplay. Although it is possible to have the same code do two different things by changing P, in reality I've never seen it done, so it shouldn't be a problem. Of course, no such tools exist, so you'd have a lot of fun making something like that.

Overall, I think your goal is technically possible, but way, way more trouble than it's worth. Still, if you do decide to give it a shot, I wish you the best of luck!

While this is indeed the greatest obstacle for disassemblers trying to primarily incrementally disassemble a given contiguous block of (presumed) code (e. g., a subroutine), which is in most cases what is desired, it is not so much of (but, however, still is) a problem with disassemblers following a control flow analysis based approach, which I would recommend here, since a whole bank is certain to contain non-asm data, which the first kind of disassemblers will not be able to distinguish from code.

Of course, the success of this approach depends entirely upon the game code abstaining from certain "ugly" things, like untraceable stack manipulation, executing non-trivial modifiable code from RAM, relevant interaction with interrupts, or, as in your example, byuu, loading the status register from an address with unpredictable content. As SNES games were standardly coded directly in asm, there is no limit on the possible level of ugliness. For some of these things, depending on the level of ugliness, game-specific workarounds might enable the disassembler to handle the situation. Last but not least, the disassembler will sooner or later encounter indirect jumps/calls (there are many forms of them, not just JMP (a,x), JMP (a), or JSR (a,x), but also hand-crafted ones via stack "manipulation"), which either require external information (debugger trace), human interaction, or a very intelligent/fast theorem prover to decide upon possible jump/call targets.

In practise, though I have not looked at too many ROMs, this approach (without even further sophistication I am currently experimenting with) seems to be at least somewhat feasible, with the code of many games abstaining from the most ugliest things. I managed to completely disassemble Lufia II, for which I originally started this project: You can see some result at http://uxul.org/lufia2_E, though I would be surprised if this were of use to anybody (aside from the usage map, it is just a bunch of asm with meaningless label names).

Wondering if what I have written so far could also be useful for this game (I take it you are referring to the third game in the series), I tried and managed without much game-specific adjustments to disassemble roughly 80 kb of asm code, including most of the first bank (see http://uxul.org/heracles_usage.bmp (Warning, 1,5 mb! For much smaller PNG version see below) - white dots represent asm bytes, banks are separated by blue lines). If you are interested in this approach, let me hear, so that we can pursuit further.

Yeah, you're right. I usually create those usage images on the fly for use only by myself, and there size doesn't matter. Anyway, here's the PNG version (9,6 kb): http://uxul.org/heracles_usage.png

With the help of a ecst, we've got the whole rom recompiling. I moved bank 02 to a new region. Now I have one large chunk of code to work with. The only problem is I don't know where to set break points now. Does anyone know if there is an xkas function that can output the PC to the console? That way when I add code before or after, it'll show where I need to set the breakpoint.

Okay thanks... I feel like a noob. The xkas readme is missing a lot so I guess I assumed what I wanted wasn't there.

The one that ecst made looks like this....

 The BRK return address is +2 bytes incremented from the BRK opcode location, with the BRK only being one byte opcode. It's used as a software interrupt. For the BRK interrupt routine, the programmer can get the address from the stack, grab that one byte after the BRK opcode as an operand.