Re: Apple II+ compatible disassembler

[dempson@atlantis.actrix.gen.nz (David Empson)]

In article <Pine.PMDF.3.91.960418085912.1614922315A-100000@ewu.edu>,
Ian K. Erickson <ierickson@ewu.edu> wrote:
> What diassemblers would work on a II+?

No commercial ones that I know of.

There is a simple disassembler built into the monitor of every Apple
II.  It just displays 20 instructions starting at a specified address
(or the address following the last disassembly).

This isn't sufficient to do what I would regard as a proper
disassembly, with the ability to define code and data areas, generation
of labels, etc. unless you do everything by hand.

The output format is not able to be fed into an assembler unless you
do some editing.

> What about HyperC?

HyperC is a C compiler.  It includes an assembler, but I doubt it has
a disassembler.  I don't know if it works on the II+.

> Or is there a magic "Two-Liner" to disassemble an entire binary file, set the
> output to the printer and print the whole thing off?

Yes, that is possible.  It would be necessary to control it from a
BASIC program, feeding commands to the monitor to get it to do
disassemblies as required.  You would probably need to have several
goes at it to get a reasonable disassembly, by examining the listing
each time and working out which parts are data and which parts are code.

The sequence would go something like this:

Get the size of the binary file, in bytes.  Estimate the number of
instructions by dividing by about 2 (the average number of bytes per
instruction).  The result should be roughly the number of lines needed
to disassemble.  Divide this number by 20 to get the number of
disassembly commands required.  (You might need to do another attempt
asking for more lines if the program has a lot of one byte
instructions, or you might end up with far too much data if it has
lots of three byte instructions.)

The BASIC program needs to load the binary file (you could do this by
hand, as long as BASIC's variables are prevented from overwriting it),
then start outputting to a text file, and poke in commands for the
monitor.

Digging in some old magazines (Open Apple, February 1985), I have
managed to find the following piece of code.  This is a subroutine for
Applesoft BASIC, originally written by S.H. Lam (in a letter to
Call-A.P.P.L.E.) which allows a BASIC program to execute monitor
commands.  Note: this doesn't work on a IIgs without some changes, but
should on all other machines.

500 C$ = C$ + " N D9C6G": REM space required before and after N
510 FOR I = 1 TO LEN(C$)
512 : POKE 511 + I,ASC(MID$(C$,I,1)) + 128
514 NEXT
520 POKE 72,0: CALL -144
530 RETURN


To use this routine, you simply set C$ to the monitor command you want
to execute, then GOSUB 500.  For example:

100 C$ = "FF59L": GOSUB 500
110 END
[insert above subroutine here]

When this program is run, it will give a disassembly of the first 20
lines of the monitor code, starting at the "cold" entry (the normal
entry point is FF69, or -151 in decimal).

You can disassemble more lines with a single command by repeating the
"L" as required.

100 C$="E000LLLLL": GOSUB 500

This will disassemble 100 lines starting at location E000 (Applesoft
BASIC cold entry point).

Note: you probably cannot avoid putting the address at the start of
each line.  For example, if you wanted to do fifty or so "L" commands,
and spread it over several Applesoft lines, you would have to
explicitly enter the address at the start of each subsequent line.

If you write the program cleanly, you could gradually modify it for the
program being disassembled, to correctly disassemble all code areas,
and use the monitor "." command to dump data areas in a more compact
form.  You would probably want some support code to do hex address
calculations and string conversion.
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand