ASM662 is an Oki 66201/66207/66301 assembler/disassembler which is still a work in progress. It's released under the BSD license, so you may use the code for anything you like. The best way to get the latest code is in CVS, but there are Windows executables released periodically:

http://sourceforge.net/projects/pgmfi/

It also apparently works on NEC 66911 chips used in P13/P14/P0D ECUs.

News

October 8, 2003

Notes

dasm662 p30.bin p30.asm 5e20 5e59 7133 72fa

A problem with disassembly/code analysis on the Oki 66k architecture is that the same opcode can have different meanings at runtime depending on the status flag called DD. The disassembler tracks this flag in a naïve manner which works most of the time.

It doesn't handle two code constructs properly: indirect jumps and subroutine calls.

Indirect jumps do not occur anywhere in P28, P30, P72 ROMs, but they do occur in P13 (at least). I've been mostly working with P30, though, I'm ignoring the problem for now.

Subroutine calls ''which change DD before returning'' do occur in all ROMs, however, and that causes inaccuracies in the disassembly (but it always outputs code which will re-assemble to the same sequence of bytes, so it's safe to use even if it isn't 100% correct). It is able to detect DD flag violations in some cases because certain opcodes/instructions require DD to be a certain value, and thus it issues a warning if it is not, changes it so that it is consistent, and then outputs the corrected instruction mnemonic.

To really properly handle subroutine calls, it would have to defer disassembly after a call instruction until it's worked out what the subroutine's impact on DD (and LRB and USP for that matter, but I won't get into that here) is before the RT instruction. I haven't gotten a chance to make it that smart. If I do go that far into code analysis, it starts encroaching on the realm of decompilation instead of disassembly, and many other things are possible.