Operating instructions

Symbol Table Sorter/Printer
for the AIM Assembler
Some information about the AIM Assembler, a program
to print the Symbol Table . sorted alphabetically or
numerically, and some other useful stuff.
Mel Evans
ERIM,
P.O.
Box 8618
Ann Arbor, MI 48107
)
When the
first
Rockwell AIM showed
up at the local computer store,
mouths
started watering. For a KIM user, to
see
an
AIM is
to
want one. It is hard to resist
that fine keyboard and display,
the
clever
little
printer, and sockets for
Monitor, RAM, Assembler, and BASIC; or
for 2716 EPROM with your own
stuff
on
it. I've been running KIM with a Memory
Plus board (8K
RAM,
8K EPROM, 2716
programmer, and a 6522 VIA), mounted
with
power supply and I/O board in an at-
tache case for portable use. This rig
hasaccumulated a half-dozen 2716's full
of
KIM software, and I intend
to
continue
working on KIM applications. Since AtM
provides the same VIA, I bought one
with
the
justification
that it would help me
develop more and better KIM software. If
you write it and debug it on AIM, and
move it over
to
KIM, you're done, right?
Well, yes. After a
bit
of
learning about
conversion from one memory map
to
another, it really does work
that
way.
The mnemonic insert mode
("I"
com-
mand) is a joy to use. There are no more
op-code lookups and branch calcula-
tions
and there are fewer typos. And the
disassembler
("K"
command) lets you
check your work faster and more ac-
curately. But for clean, patch-free object
code, the assembler is the best
of
all.
Six-character variable names! No line-
number hassle! Six-character labels,
such
as
"JMP
NEXT,"
or
"BEQ
OUTCHR."
Af1d
for easy transfer
of
ob-
ject
code from AIM
to
KIM,
it's
the
assembler
that
really does it. It makes
the
writing
of
relocatable code almost
automatic.
January, 1980
The AIM assembler lacks one feature;
there is no command for printing the
symbol table
after
an
assembly. So here
is a
little
program that
fits
on Page Zero
and does
just
that. After assembling any
program, load
this
one and start at
10.
It
prints two
listings
of the assembly sym-
bol table; one sorted alphabetically by
symbol name, and the other sorted
numerically by symbol address. The first
list is helpful when going through the
assembly listing. The second is even
more helpful when reading the
output
of
the disassembler; it lets you know right
away that the cryptic "JSR E9BC," for
example, is a jump
to
subroutine
OUTALL.
The source (assembly-language) ver-
sion
of
the sort/print program is shown
in Figure
1.
The assembly listing, with
absolute addresses, is shown in Figure
2.
A disassembler listing is not shown;
if
you
can't
assemble this one, you
don't
need it!
The sorting algorithm is plain brute-
force; it is desigbed
to
conserve memory
space, not sorting time. But even so, it
takes much less time to sort a list than it
does
to
print it. The only tricky feature
of
the program is
in
its allocation
of
zero-
page memory; in loading,
it
carefully
avoids wiping out the six bytes that
remember sxmbol-table size and loca-
tion, because it will need them
to
know
where
to
work when you hit
"Go."
Figure 3 shows, as
an
example, the
use
of
the assembled program on
its
MICRO
--
The 6502 Journal
own symbol table. Notice
that
you
don't
have
to
find and enter the location and
size
of
the symbol table; the program
finds these from the zero-page bytes
that it conserved while loading.
One note
of
caution in case you
don't
read the following section. When you
assemble this source program,
don't
direct the object code to memory. Direct
it to tape. Then load it and
start
at
10.
AIMĀ·la-KIM Software Conversion
The following assumes that you have
more space in AIM
RAM
than you will
need for KIM memory.
It works well with
a 4K AIM, and even better with
8K.
The idea is to use AIM for both
assembly and running
of
the program
during the debug phase. In the process
of
editing source, assembling, and runn-
ing (and re-editing, re-assembling,
re-
running, re-editing, etc., etc.), much time
can
be
saved by not having
to
load
source from tape, dump object to tape,
and reload object from tape for the next
run. (If you have disc, this may
be
less
of
a problem. I wouldn't know.) So, build
your source with the editor (the very
good editor), assemble from memory,
and direct object to memory - to any
available memory,
n01
necessarily where
it will go in KIM. It will
be
easy to move
later if you follow one rule:
don't
use fix-
ed
addresses
except where
really
necessary.
Look at Figure 1 again. Observe
that
the only fixed addresses used are those
20:43