Post
by Nemesis » Tue Apr 02, 2019 4:48 am
Thanks for your suggestions and feedback. I'm glad you're finding the current features useful. There is certainly a lot that could be done to the output from active disassembly to make the generated code more useful. One of the challenges though is keeping things generic and platform independent. I've got a lot of plans around arcade hardware I'd like to support for example, a fair few of which also use an M68000 processor. The current implementation of the M68000 core is platform independent, and so is the active disassembly feature and subsequent analysis. This means those features will work correctly without any changes on, for example, the three M68000 processors on a Sega Y-board running G-LOC, just as well as they will in the Mega Drive. What this means is that nothing in the base analysis process can depend on system specific knowledge. I do plan to add support to "trace through" banking hardware and the like so that bankswitching doesn't interfere with active disassembly, but nuances like recognizing system-specific register banks and binary headers would need to stay out of the cores themselves.
As you suggest, a post-processing step is a potential solution to the obvious desire to do additional system-specific cleanup to a generated disassembly, without baking that logic into areas of the code that should remain platform independent. To be honest, I always imagined a lot of that work being farmed out to other tools written by other people. There's currently an option to generate an IDC script for example, to use in IDA Pro. I imagined you might import the initial disassembly with that script, then run one or more system-specific cleanup scripts (IE, "CleanMegaDriveDisassembly.idc"), which performs the kind of tasks you've mentioned, like labelling the header fields, known hardware registers and address regions, and possibly scattering in comments or better naming elements of the disassembly. Even with the direct asm output though, nowadays I'd think some well written python scripts might be the solution. Do you think that kind of approach is viable here? Even if you needed to feed that kind of script the original ROM, plus the asm output, plus the "text output" that contains the raw analysis outcomes, that should be enough for an independent python script to implement the kind of features you've described. It's possible "standard" scripts could be added to the actual Exodus release and shipped with it, but generally I'd consider this add-on functionality that other people would create and distribute.
I guess that leads to the question, would you like to try your hand at cutting some code that could do this? It's possible I could add in some kind of "one-click" support for running user-defined external post-process steps on the disassembly output, but I'd like to see one or two of them appear publicly first, so I could get a feel for what input they'd need and how they'd operate in practice.