Using Geiger's build of Snes9x, we have a way to produce a recompilable disassembly for any SNES game : the method is based on the "usage map" (which is basically a code/data logger) and the "trace/trace once" features.

One would need to play through the whole game with tracing enabled, and try to trigger as many routines as possible. At the end of each session, save the usage map, and the trace log. After you've played the game extensively, merge everything.

In the process, there might be some code and data left that was never accessed, ... hopefully something like 5% of the ROM. In theory, it's not needed to recompile a working ROM (would need to be fixed manually later though)

How useful would that be though ? I don't really understand what perspectives this could create, especially as such an uncommented disassembly remains "raw" material.

A) You'd never get 100% of the code identified this way, but yes, you can store the rest as db commands.
B) The log would be virtually useless. The point of having code is so that you can change it: rewrite blocks, insert code, delete code ... any of this will throw off all of your labels, and even if you managed to create labels and tests for all branches and jumps (and magically also handle indirect jumps somehow), you'd still not be able to use this as the code you didn't find could come back to screw you.

This isn't what we need. What we really need are statistical analysis tools. Things like, take a trace log, run it through an application that finds out the call flow of instructions and builds hierarchies. Right now, you make a trace and you have what is essentially a straight list of 100,000 or so opcodes. All in the direct order of execution. But this is not at all how code works.

An analyzer could rip out function start / stop offsets, find out where they are invoked from, allow you to label the subroutines found, label all the variables you have RE'd to have more descriptive names, add comments, and allow you to come a hell of a lot closer to having actual sources to the game in question. Imagine all the work it'd save in a multi-year translation project where you end up coming across the same reused functions again and again, and forgetting what exactly they do.

For debugging, things like stack tracing could also greatly assist, at least for the majority of games that don't perform stack magic (pea + rts, pha + rts, etc).

Hm, I wouldn't say it's useless.  For example, the sonic hacking community (or some guy in it) has disassembled sonic the hedgehog to a set of recompilable source code files.  And some pretty nifty hacks have resulted from this.

I never knew that SMB1 disassembly existed, thanks for letting me know!

I took a quick look in google, and found this:

http://www.s2beta.com/forums/index.php?showforum=13

There's stickies at the top of that forum with links, I believe.

I wasn't entirely clear, that link was for the sonic the hedgehog disassembly. My bad!

IDA would be amazing to have for SNES, unfortunately, I looked pretty extensively a while ago, and nothing seems to support the 65c816. Shame.

I wrote a disassembler that does that >_>. You give it a starting point and an end point and it tries to do all of the above and more. It's meant to disassemble one routine at a time. It discards all analysis of the code after it's done. If I logged it to a database, you'd have something similar to IDA.