Hello,

I am looking for recommendations on good disassemblers for the 65C02
CPU. I would like to find some that run on the PC (DOS or Windows)
so I can recreate the source code for some old program ROM's. Most
of the ROM's are 2K-8K in size. If you know of any tools that will
help please let me know.

Regards,

Robert

I have found that disassembing a ROM is not as easy as it may seem. The most obvious problem is distinguishing code from data tables. Another is that I encountered with some Apple ][ code was masking of one or two byte instructions with a three byte one. You may waste a byte but it sure makes it harder to disassemble.

I have written an simple disassembler for DOS that reads an input file and send the disassembly to another file. It starts at the top and goes straight down.

Output looks like this:
8000 OPC OPERAND ; HH HH HH

where the 8000 is a label, OPC is the opcode or ".db" for data.
After the comment ";", is up to three bytes from the input file that make up the instruction (helpful in adjusting for data tables). If it encounters an invalid opcode, it assumes its one byte of data and saves it as such.

I have also written additional code to remove the label if its not ever addressed in the operands, but it still needs a little work.

Even with a system like this, you must still read through it line by line to fix the broken links.

Let me know if your interested in using either of these tools.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I've written a 65C02 disassembler in Turbo Pascal. It is a personal tool, not a commercial product, and it helps to have Turbo Pascal 7 for the multiple text windows (one for the program, one for the disassembly script, and one for the disassembler output). E-mail me for the program (binary and code).

Paul R. Santa-Maria
Monroe, Michigan USA

My disassembler follows the code. It tracks the destination address of all jumps, JSRs, and branches. I do have to give it one valid code address. With 6502 ROMs I use the three vectors at the top of memory (RESET, IRQ, NMI). After the first pass, I look at the output for jump tables and add those addresses to the disassembly script. It doesn't take many iterations to complete the process.

My disassembler can still be fooled. For example, code that decrypts itself before running then encrypts itself after running will not be handled properly. My disassembler does stop disassembling when it reaches an illegal opcode or a BRK; it then goes back to the address list for more code to disassemble.

Paul R. Santa-Maria
Monroe, Michigan USA

I like your method of starting from a know point (Reset vector) and building a table of starting addresses based on branch & jump instructions encountered. Sounds as if your program is much more advanced than mine. I just wanted to offer something up. Thanks for your input!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Paul,

I would love to try a copy of your disassembler. One that follows
the code can make it a lot easier to correctly re-create the code.
I have used disassemblers like that for Z-80 based systems with
excellent results. That one would also let me enter extra hooks into
code areas that it would scan through as well.

The ROM's I need to disassemble are 2K to 8K in size and I have some
information on the memory map of the system. Once I finish the
disassembly it will be much easier to do repairs on it.

Thanks!

Robert

rdoerr@home.com

http://www.robotworkshop.com