Library> ASM662 Destinations: Home | Library | Change Log | Index
Search | Go

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:

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


October 8, 2003

asm662 version 1.2 for Win32 has been released. This code is in the same experimental stage mentioned below -- extra commandline arguments are addresses not to consider as tables.


I'm working towards a perfectly relocatable disassembly of various ROMs, starting with P30, and to that end the disassembler code in CVS is in an experimental stage. You can supply additional commandline arguments which are addresses it should not consider as a pointer to ROM tables. i.e.:

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.

Revision: r1.1 - 19 Feb 2004 - 23:01 GMT - guest { Edit | Attach | History | More }
Copyright © 2002-present by the contributing authors. All material on this collaboration platform is the property of the
contributing authors, and is covered by the Non-Commercial Share-Alike License unless explicitly stated otherwise.
Ideas, requests, problems regarding the PGMFI TWiki? E-Mail the WikiAdmin
Site Designed By: Digital Fusion   Need a website? - Powered by