News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Active Megadrive Disassembler of sorts...  (Read 1337 times)

RyanfaeScotland

  • Sr. Member
  • ****
  • Posts: 366
    • View Profile
    • My Brill Game Site
Active Megadrive Disassembler of sorts...
« on: March 07, 2016, 05:47:58 pm »
I have an idea I am playing with, it has a simple proof of concept thrown together and I plan on expanding it more as I think it will be a useful tool. Whilst I do so I thought I'd throw it to the hounds for criticism as I continue with it. Regardless of the outcome of this thread, short of someone showing me it already exists, I'll likely finish it off as it is useful for what I'm working on at the moment.

Let me provide you with an example of the results:

This is an example of my hand made notes:


And this is an example of my programs automated notes:


It may not look like much but the automated output you see here is on the fly(ish) output generated whilst playing through Toejam and Earl in Gens. The handmade notes took me several hours to make, the automated ones a few moments. Note as well that the automated output has code I haven't even looked at yet. Sure, I don't have the understanding I do of the hand annotated code which is a large part of understanding the game but once I'm done it will be much easier to learn from. That instruction at 032E looks pretty suspect as well.

How it works is pretty simple, it reads the trace file whilst it is being written to by GENS and stores each line in a hashmap keyed by address along with the full line as the value meaning it only stores each line once (re-writing the line if it is seen again). Once you quit out it sorts the contents of the map by address and then writes all the lines out to file, adding a newline when it sees a RTE or s RTS, simple.

I'm planning to expand it, the following ways are what I have in mind at the moment:
  • Output compilable code (as you can see it is currently raw lines from the trace file)
  • Switch out addresses in jump statements with labels
  • Capture and output data blocks (Currently ignored as obviously not seen in trace files)
  • Add timestamps of when code was seen (perhaps relative to start time, perhaps both)
  • Add more Megadrive specific analysis (highlight joypad reads, VRAM writes)

Anyone got any thoughts on this?

STARWIN

  • Sr. Member
  • ****
  • Posts: 452
    • View Profile
Re: Active Megadrive Disassembler of sorts...
« Reply #1 on: March 07, 2016, 06:45:24 pm »
Compilable as in asm->machine code or something else?

Could perhaps detect game loop / common code by somehow counting exec frequency and filtering out rare lines.

I would hardly call those hand made notes, more like plain disassembly (?). Utilizing trace log lines this way may be convenient. But you have to cover the code in gameplay, yes? Would a dumb disassembly over the ROM be better?

RyanfaeScotland

  • Sr. Member
  • ****
  • Posts: 366
    • View Profile
    • My Brill Game Site
Re: Active Megadrive Disassembler of sorts...
« Reply #2 on: March 07, 2016, 07:27:10 pm »
Yes, ASM to machine code, so from an editable version of the game code to a playable version. I use Easy68K for developing so it would end up in a format compatible with that (although presumably it would work in other assemblers/compilers)

That's actually one of the functions I first implemented, it started off just as a trace analysis tool which has the ability to look at a trace file and spit out how many times each line is executed (or, more accurately, how many times each line appears in the trace which looks to cap out at 64 although I haven't explored this in depth). It also has file compare so it looks at all the code that is present in one file and not in an other and outputs it, and then does it the other way round.

Again, this is just functionality I was playing around with.

Haha yeah, the hand made notes example image doesn't contain a huge amount of actual hand made notes. There is additional notes in there in the form of comments in the code but I skipped showing them as I didn't want a huge image and they aren't too relative to what I'm trying to achieve here. Although they may be down the line, wouldn't be that hard once you've identified what a certain ram address is for (say storing lives) to have the program write a comment saying increasing / decreasing lives or similar in the output.

As it stands I have a dumb disassembly and this tool has came about as a result of trying to annotate / understand that file with tracing. I'll be looking to combine trace files, dumb disassembly and the ROM file to output as useful an output as possible. For me that is currently re-assemblable code.

STARWIN

  • Sr. Member
  • ****
  • Posts: 452
    • View Profile
Re: Active Megadrive Disassembler of sorts...
« Reply #3 on: March 08, 2016, 07:15:45 am »
Technically, I suppose it might be enough to collect the executed ROM addresses and just combine that with the dumb disassembly, leaving everything else as db or however assemblers call as-is bytes. Might be able to combine that with jumps not taken but (immediately) reachable (resulting in mistakes with dead code, could note as non-executed).

As far as documentation itself goes, I think having to read asm is the slowest part then. When I made some notes (for PS1 asm) I noticed myself writing pseudocode somewhere in-between asm and C level. So basically I would store all algorithms in such a form, and leave the asm as a reference for actual hacking. I'm not quite convinced that you want to read dumb (as in asm processing level) comments, even if you could generate them without much work (labels might cover this.. variable names?).

But, that is a bit outside of scope for your discussion right now. And you are dealing with an unknown type of asm for me either way, so something could just be different.