[Coco] disassembling

[Stephen H. Fischer]

Hi,

----- Original Message ----- 
From: "Robert Gault" <robert.gault at worldnet.att.net>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Wednesday, January 14, 2004 1:52 PM
Subject: Re: [Coco] disassembling

> Roger Taylor wrote:
>
> > Is there much disassembling going on today? I've had a request or two
> > for adding a disassembler mode to Portal-9. It sounds interesting
> > enough that we could take one of the many CoCo .rom files or .bin files
> > and turn them back into source code that is ready to be reassembled.
> >
> > If I add this mode, it would work by taking a preloaded binary file and
> > then converting it into another edit window as CCASM source code. I
> > think a panel of switches should be available so the user can quickly
> > toggle some modes, change a few params, then do it again until the
> > source code is workable, cutting down on how much manual editing will be
> > required, if any.
> >
> > Any suggestions?
> >
> > ----------
> > Roger Taylor
> >
> >
> >
> >
>
> Use the CerComp Source III as a model. This disassembler has a fast mode
> which works like the EDTASM debug, but it also has a full mode which
> saves the created source to disk as an .asm file.
>
> The best thing about this program is that the user can enter addresses
> for blocks of fcb, fcc, and skip. The full mode will then take the byte
> table into account during disassembly. The byte table can be saved to
> disk so that multi-session disassemblies are possible.

There is a Intel dissembler (Sourcer) that does this automatically and does
a fine job of it.

It uses a combination of dissembler and emulator code to map the type of
blocks, code, data or messages.

It starts at the entry point disassembling the code and using the emulator
to mark parts of the program as code or data.

For example, if the current instruction is a fetch of a byte, the address of
the byte is marked as data not code.

If the current instruction is a branch, then the destination is remembered
as a additional code block start.

If the current disassembly reaches a termination point or branches to a
block known to be code then the disassembly stops for that path and the
process starts with another code block start.

This continues until all of the code block starts have been disassembled.

During this process there may be conflicting information gathered about a
block and there may be some information that is ambiguous.

For example the fetch may not be a hard coded address but a computed
address. Thus the need to do both emulating and disassembling at the same
time.

The Intel program takes up to three passes to complete the disassembly and
automatically recognizes text and numeric values also.

I believe that we have most of what is needed in some of our current
emulators, just needing to add code to follow all branches and keep track of
the memory use knowledge.

SockMaster demo's not included!

Stephen H. Fischer <sfischer1 at mindspring.com>


> The program has ascii and hex dump window to facilitate creating the
> above byte table.
>
>
> -- 
> Coco mailing list