65816 Disassembler

M

MathOnNapkins

New member
Now don't get your hopes up, disassemblers were never meant to fully decompose a rom with the push of a button. Tracers can do that to an extent, but they don't encapsulate routines like C would. What I'm working on is meant to be a clear and superior alternative to console apps written for the same purpose - it's intended to take a routine in the file and encapsulate it.

EDIT: for those of you who like pictures:
mydisasm.jpg


exampleoutput.jpg


It currently already works quite well, with the following features:

-Linear Tracing (right now it just goes from top to bottom)

-Autogenerates english labels with a variety of preset names, "ALPHA", ..., "MAGUS", etc...

-has a number of failsafes including
1. will alert you if it detects a BRK or COP instruction. These instructions are quite rare, and about 100% of the time signal an error on your part in choosing boundaries for disassembly or initial settings.

2. does an analysis of branch destinations, and will determine if they are misaligned (that's very bad). That means one of your branches goes to something that has determined to not be an opcode.

3. saves you time by determining if there are branch destinations to the end of the region you are trying to disassemble. (examples of this will be in the help file, whenever I get around to making it, with pictures).

-selectable initial 16-bit accumulator or X/Y registers.

-support for 512 byte headers

With all the above options it is already better than any existing disassembler I have seen, including the one in Geiger's Debugger. And there's probably other diagnostic messages I cant' remember atm.

Here's a list of features I'm currently working on adding and improving, straight out of my .cpp file:

List of things to add:


1. Save user preferences, possibly add the ability to hide the application, and other Gui niceties.
-probably want to use a file to store settings.

2. -Warning on unconditional Program Counter changes without following branch
-Option to include "Alternate Entry Point" labels
-Generally I have decided not to accept the notion of routines
with internal data, though some of my manually typed disassembly may
allow this, I no longer do it

*complete* 3. Conversion from Linear to Dynamic Tracing - outpuf buffer and many other things will have to be
revamped

4. Calculation of in rom addresses for JSR, JSL, and branch operations with no internal labels.
-Note, LoRom, HiRom, and FastRom should be specified as needed

5. Streamline spacing of operations to save time in various things.

6. Jump table generation - with conversion to Rom addresses
-Absolute Linear
-Long Linear
-Absolute Indexed
-Long Indexed

7. Possibly generate (i.e. rip from the rom) data tables with specified types of spacing

8. Handle RTF API to generate colorized text

9. Reconfigure the maskbits array and create new ones to store branch destination and source information.
-incorporate data concerning register width at each particular opcode.

10. *optional* add support for PHP and PLP and stack balancing diagnostics. not sure if I need that and it would probably get pretty complicated with more hairy routines.


Ok, so I'm looking for suggestions and input, as well as some Beta Testers.
 
> EDIT: for those of you who like pictures:

If you add code to check the filesize and read the intenal ROM info you can eliminate two of those checkboxes.
 
I told you on IRC and I'll tell you here . . . This is already more accurate than the disassembler I had been using before (the one that confused LDA (stack relative) with CPX for some strange reason.

Only thing I'd change at the moment (and you probably already have)... At the end of the disassemble, the checkboxes should be set back to the values that the user had set for them.
 
D-BOY: certainly a good suggestion, and I have been considering it, though I think generally people disassemble one game at a time. So they ought to know what type of memory mapping it is or else they ain't got no business disassembling it. However, it would be convenient. However, in the case that my program makes a mistake, I would still probably keep the checkbox so users have control over that if they desire.

The filesize I already know. But I don't want to make assumptions. Especially since some roms that have been hack (such as those edited by Hyrule Magic) are of weird and variable sizes. Therefore, making a determination as to whether it is headered seems difficult in the general case. I try to provide as many options as possible.

Jathys: I fixed it so it does what you were referring to. (resetting M and X bits after disassembly.)

If anyone has info about detecting hi-rom versus lo-rom I'm all ears. I once read a few docs on it but they didn't seem to explain it well enough to where I felt safe implementing it in code.
 
Okay, I found a doc that explained it a little better than what i had previously read. I will attempt to add the auto detect hi-rom/lo-rom feature, but I will leave in the option to choose if it backfires. That also solved the header detection issue, but again I like giving people options.
 
> The filesize I already know. But I don't want to make
> assumptions. Especially since some roms that have been hack
> (such as those edited by Hyrule Magic) are of weird and
> variable sizes.

If Hyrule Magic is not bothering to pad out ROMs to the nearest valid size and thusly produces SNES incompatible images, fuck it.
 
Do you have a option to disassemble a single bank if you dont want to disassemble the entire rom? hi rom or low rom. And to set the origin as well if you desire.
 
> Do you have a option to disassemble a single bank if you
> dont want to disassemble the entire rom? hi rom or low rom.
> And to set the origin as well if you desire.

You don't disasemble the entire rom . . . You do set the bounds for which the disassemble is limited to.
 
I have minor beefs with the syntax in your pics:

'//' for comments and not ';'?
';' after every instruction?

I guess that's to make it more C-like or something... I dunno just seems strange to me.

But the biggie is your inconsitency with '$'. Looks like you put it on every digit except immediate mode -- even though immediate mode still uses hex ("LDA #CF" when you obviously mean "LDA #$CF") When there's alphabetic chars in the number it's obvious, but that makes the lines like "LDA #10" real ambiguous. Do you mean ten or sixteen? When I first looked at it I assumed ten, but now that I saw that you just drop the $ in immediate mode I'm thinking sixteen.
 
While you raise a valid point, Disch, I am not forcing anyone to use my syntax. The output in the picture was produced using "MathOnNapkins' Settings". See that big toggle button? ;)

Normal Settings give standard output more or less. When I release, if there are any issuesyou can make me aware at that time. Normal Settings have no ";" after ever instruction. And The // becomes ;. The immediate mode instructions use #$ rather than the # I prefer. (Who uses Decimal anyways ;p)
 
> You don't disasemble the entire rom . . . You do set the
> bounds for which the disassembly is limited to.
>

Right. Let me just state that this is designed to handle one routine at a time. It was never intended to disassemble large portions with the click of a button. Hence, most of the analytical tools being built into it help you determine if you have chosen correct bounds for a routine. You could disassemble from the beginning to the very end if you wanted, but depending on the size of your rom that might require a large amount of RAM (for a 1MB rom, that'd be about 8MB of RAM. For a 4MB ROM about 32MB, and I'd be slinging you a crapload of error messages while this was happening. If you wanted to do that you'd be better off with a traditional disassembler. Of course, there is a linear override feature now which would help out
 
You must log in or register to reply here.
Back
Top Bottom