[FinS]

I think I like the trace as you play idea the best.  You could modify a debugger that already does most of the work to just output the opcodes to a file and sort them relative to the program counter.  You could have willing participants volunteer to all use this special debugger while they play with instructions to try to explore all parts of the game.  Then they can send you the files to be united. The file would probably take up around 20 MB just in opcodes so the process used to write to it would have to be fairly well written code.

If you wanted to add tables data, raw data and compressed data it may be necessary to put it in afterwards.

[RyanfaeScotland]

It would certainly eliminate the problems mentioned previously. Multiple players of the same rom would be needed to do it in a timely fashion, my first thought was to have several people taking turns so say a team of 3 doing a couple of hours playing each but I think you might be onto a better way to cover as much possibilities as possible. Ultimately it would be up to those making the disassembly to decide.

Yea the data would need added in afterward but it shouldn't be hard since the system could log areas of the rom that weren't touched.

The command you guys are on about is also possible in the 68K. I reckon the above would solve this but I still think there is a way of doing it in an automated fashion. You's have more experience in this than me so can probably tell me, if we are following the program through a command at a time, trying each branch one way then the other, wouldn't that result in us setting values such as x above only to ones that are possible in game? Although I guess it would still lead to garbage if the programmer has used a branch that is only ever meant to go 1 way.

[Ryusui]

Admittedly, while you couldn't hope for a complete dissasembly, you could probably produce a reasonably complete disassembly and fill in the gaps by hand.

But you'd need to make sure the gaps are adequately marked.

[Nightcrawler]

The command you guys are on about is also possible in the 68K. I reckon the above would solve this but I still think there is a way of doing it in an automated fashion. You's have more experience in this than me so can probably tell me, if we are following the program through a command at a time, trying each branch one way then the other, wouldn't that result in us setting values such as x above only to ones that are possible in game? Although I guess it would still lead to garbage if the programmer has used a branch that is only ever meant to go 1 way.

No. How do you know what ones are 'possible in game'? What if the value of X relies on user input, RAM data, indirectly addressed ROM, or hardware state to directly calculate? Command by command doesn't yield useful results when runtime state is required to determine code paths. This is why straight diss-assembly isn't possible on the SNES. Opcode length depends on runtime state. This is along the lines of another holes in the plan. Code can be dynamically created and execute from RAM. It's not too common, but I have seen in a few times. Next, a program may choose to directly manipulate the program counter via code on some platforms. This calculation may also rely on runtime state data to calculate. There's a reason nobody has bothered to do this before. There's all kinds of holes like this.

Admittedly, while you couldn't hope for a complete dissasembly, you could probably produce a reasonably complete disassembly and fill in the gaps by hand.

But you'd need to make sure the gaps are adequately marked.

I don't even think it would be reasonably complete in a complex game. Think about a typical a SRPG or your typical RPG translation. Let's take your own Bof2 project. Was one single play through enough to capture most code branches? I think it's safe to say absolutely not, or you wouldn't have had so many bugs to work out or need so many others to play through as well. I think you underestimate how much code is executed in a single play-through. A single play through does not execute all the code in a game, not even close. I would be curious to see an actual statistic on this to state with authority, but I don't think this analysis has been done. I'd probably start there if I were seriously going to do a project like this. Determine it's real feasibility and usefulness.

[KingMike]

It won't be in BoF2 because it has branching paths (namely, it's impossible to get all TownShip residents in a single playthrough).
So of course some code/data for the un-selected residents will not be accessed.

[FinS]

Multiple players of the same rom would be needed to do it in a timely fashion, my first thought was to have several people taking turns so say a team of 3 doing a couple of hours playing each but I think you might be onto a better way to cover as much possibilities as possible.

I think a timely fashion would be hard to manage. I think more of a leisurely pace would be in order.  Instead of everyone trying real hard to examine the code they would just be playing the game. And after a month or so...., oh hey here's the assembly code file.  Eventually you would get to a point where you would probably start pinpointing areas that haven't been covered and you could ask some players to work from save states to keep going over the same section.  You could have a website set up to make the debugger/disassembler available and let everyone know what areas of what games need to be played with it.

Yea the data would need added in afterward but it shouldn't be hard since the system could log areas of the rom that weren't touched.

It would be very important to insert all the data afterwards because there will be control codes in it that the game will need to run properly which would be hard to pick out from the rest of the data.

[Nightcrawler]

It won't be in BoF2 because it has branching paths (namely, it's impossible to get all TownShip residents in a single playthrough).
So of course some code/data for the un-selected residents will not be accessed.

Yeah, that's more of what I was getting at. A play through, or even many play throughs may not be all that useful. Also, what's the end goal here? You already have to do it individually game by game with countless hours invested. Even then, it would be very hard to get it to 100% with any kind of reliability. Then after all that, what do you really have that you didn't already have? I don't think anybody is ever going to realistically do do this. You can talk about it all day on a theoretical level for fun (if that's what we're doing), but who's really going to do this?

I'll go back to making my 5 second trace log dumps of relevant code now, which is less time consuming than a single response to this post!

[RyanfaeScotland]

Haha well I guess there will always be non-believers. Don't worry though, when I get this uber auto debugger working I won't hold any grudges against those who doubted.

KingMike, those situations shouldn't be a problem as the system would effectively go through all situations possible. I'm not sure about BoF2 by Shining Force 2 has a point where you have to select between 4 characters so at this point the system would select the first one and record the way it branched and continue on then at a later point it would return and make the other choice and so on and so on.

FinS, yeah I think you're right with the way of using it and you're definitely right with the need to reinsert the data. This of course assumes we can't get an automated version working instead.

Well Nightcrawler I guess after making it I would just print it out and hang on my wall cause it would be pretty cool to have a full disassembly of a game hanging on my wall Other people might find better uses for it but that would be up to them. Have any interesting things been done with any of the full disassemblies out there? (I know this wouldn't produce fully commented, ordered or anything near those ones)

[FinS]

I get your point, Nightcawler, that there is probably some code that just couldn't possibly be logged no matter how much you play through it, and I'm  sure you would know with your amount of experience. I just don't think it would be that big of an issue since it could be added back in as unknown data anyway.

The best question I think is what would be the goal and what purpose would it serve. One thing I can think of is that once the code is dissected from the data then the data should be more easy to identify.

Another thing might be to have the game fully ready to assemble in entirety so you could hack the assembly code instead of the binary. I'm not really sure if that would make hacking it any easier  though.

[frantik]

my disassembler DISASM6 allows you to use Code/Data log files (generated by FCEU*).. using incomplete CDL files it successfully disassembled excitebike and marks each region appropriately.  the output can be immediately recompiled with ASM6

http://www.romhacking.net/forum/index.php?topic=12177.0

[DaMarsMan]

I have full disassembly of Glory of Heracles 3 and Dragon Quest 3. Just though I'd drop that off here so it is possible depending on how you code the disassembler to differentiate and process along different paths. But if you are asking simple questions then you are starting off with the wrong idea. Do something simple. Replace a small block of code and you'll have a better understanding of how the whole thing works. Also, code a small demo in assembly and you should be able to understand what you are doing better.