FrankenGraphics wrote:
Note that there's no sure-proof way for a disassembler to tell data from code; it makes its best guess.
That is what code/data logs are for. You can turn this feature on in FCEUX's menu, and it will keep track of what has been executed and what has been loaded instead. Mesen can also do this. There are rare cases where something is both code and data, or some weird assembly tricks that might confuse a disassembler, but a CDL is just about as rock solid as you can get. The main problem is trying to play enough of the game that all the code gets executed or all the data gets loaded, there will be gaps, but the more info you get in the better it will get.
I've heard of diassemblers which try to recursively follow branches to figure out what code is executable, but I'm not sure how well that works in practice. They can probably give a pretty good starting guess that way. The main thing here is that the automated tools will help, but you still have to inspect the gaps and errors in it and correct them as you figure it out.
Anyhow, step 1 for me is just to turn on the CDL and play the game for a while (try to do a little bit of everything, cheating and savestating is okay here too).
SusiKette wrote:
Are there any good ways to keep track of what you have figured out?
Since I use cc65's disassembler,
da65, I would put the information into an info file for that disassembler. Frequently I'll run the disassemble and then reassemble the ROM to gain new debug info that I feed back into the debugger, i.e. all the names now show up there, which helps figure out the next information...
Also, you can process that code/data log into the disassembler info file to tell it what to leave as data. That's important too. There will be gaps in the CDL, but just disassemble everything unknown as code as first, and if it looks like garbage nonsense code it's probably data. Eventually you can sort through everything that couldn't automatically be identified.
I made a disassembly of part of StarTropics a while back. It has an example debugger info file.
https://forums.nesdev.com/viewtopic.php?f=6&t=12040SusiKette wrote:
Also, I noticed something annoying in the debugger. Sometimes when you step through the code everything is fine, but when you start scrolling through the code the debugger changes the code to something different because it disagrees with the current view on what the code should look like. Its probably because there is other data in the middle of the code and it's end doesn't line up with how the opcodes are begin written in the debugger.
Sometimes the top of the debugger window in FCEUX starts on a byte address that's in the middle of an instruction. You can scroll up up or down to get realigned.