Ultimate 8085 Disassembler

So it has come up a couple of times that there is commercial abandonware binary code that really needs to be adapted from the 100/102 to one of the other Kyocera laptop variants. To do this, disassembly needs to become simple, painless and accurate. Another important use case for a good disassembler is porting code to Ron Wiesen's "run-in-place" load file format, which solves the double-ram-penalty problem of running .CO files on the Model T.

We have several disassemblers floating around... all use an algorithm known as "linear sweep." The logic is to run from beginning to end of a binary file attempting to disassemble every byte as though it were an instruction. If you think about it for a moment, this is a crappy algorithm. CO files commonly have variable allotments and strings mixed into the code. Attempting to disassemble these produces garbage. The 8085 has no holes in the instruction set, so heuristics about mis-disassembled portions of the code are limited to recognizing a some unlikely increase in apparent occurrence of underutilized instructions during disassembly.

A considerably better algorithm is to follow all entry points recursively through all jumps and calls. We'll call this the "call graph traversal" method. This pretty much guarantees that you only disassemble executable code.

Caveats: certain types of code that modify return addresses on the callstack, or computed gotos will defeat this approach. RST 4, and RST 7 are special on the Model T ROM since they don't return to the next instruction but instead to 1 byte further on. PCHL is the heart of typical computed gotos on the 8085. At least it's easy to see.

Code which modifies the stack or modifies jump/call target immediate bytes at runtime are hopeless cases. At the very least, hints from the user will be required here.

For the "last mile" cases it might be useful to leverage VirtualT. VirtualT actually runs the binaries... one could imagine getting a trace from VirtualT of the actual instruction and data locations. Maybe someone could hack this in there. While I'm wishing, it would also be nice to have a command line version of VirtualT... the Model 100 screen would be redirected to the command prompt... simple command line options would allow loading and running a given .BA, .DO or .CO file, and sending the program output or generated file(s) to stdout.

I have a prototype working... so far I have been playing with RAM100.CO, the Rampack driver. It is working fine on the code. There are a few embedded null-terminated strings which I would like to identify in an automated way. The current problem is that the only indication in the code that there are strings is that each address is loaded into HL and then the print string routine at 0x11A2 is called.

My current thought is to simulate all instructions from each basic block that end in a jump to a known routine in the BASIC ROM. If the ROM routine expects a parameter reference provided as a register value or on the stack, I suspect that in most cases the register parameter is loaded with an immediate value. In the case of jumps or calls to 0x11A2, the 2 bytes following the instruction are the address of a ZString. Then in the disassembled code I can use the pseudo-instruction for a ZString instead of defaulting to a long list of constant (undisassembled) bytes.