Operating instructions
;
--
...
'-
-
- .
..,..
::1
....
:;
;
-
-"
'-";"
..
lt2
*::*+1
'r'L
I M
*=*+1
'r'TAB
.;
MA
I N
PROGRAM
;
JUMP
OVER
eEl)
ac
;
; IITAB
L)ATA
,DB'I
taees.,
$060E
I
*=$00
CNTLO
*=:+<+1
'
CNTHI
*=*+1
CPC~:.:=$EA24
Figure
1:
Source Listing,
Sorter/Printer
*=:\(+1
FtDHI
*=*+1
1Y/1
*=*+1
:::
! h 1 =
~
.:-'.
:'_."'l""
.'
,
.::
: _ u -
~.
~.
r"!
direction; move blocks to $200-3FF,
dump
to
tape, load to $200-3FF
in
the
other machine, and move to wherever.
If
all you want is the block-move code,
Fig. 6 gives a disassembler
listing
and a
hex dump. It can be put anywhere, but
this version needs the
bottom
six bytes
of
zero-page for
"From",
"End",
and
"To".
What
if
you need to use Page One?
The push-down stack at the top
of
Page
One is the same in AIM
as
in KIM, so
there is no problem there. (Simply allow
a
bit
more room for the deeper-pushing
AIM monitor.) The AIM memory map
shows eleven Page One bytes (106·107,
115-11
D)
used by tape I/O, and
eight
bytes (168-16F) used by the monitor. The
tape I/O bytes can be handled like Page
Zero bytes; I.e., avoid until assembling to
tape. The eight
monitor
bytes should
probably be permanently avoided; load .
them
into
KIM by hand
after
everything
else is transferred. And
as
an
extra
precaution,
check
all
of
Page One
for
wipeouts
before running in KIM.
Please
do
not
let all these
cautions
scare you off. It really is
fast
and easy
after
a
little
practice.
Most
programs
grow
during debug, and
much
of
the
above only applies
if
your program has
grown
to
the
point
where you are
cramped
for
memory space.
Fig. 4 shows how simple
it
is when
there
is
plenty
of
room. This is a general-
purpose
"move
block"
program
that
will
go
anywhere in memory (RAM
or
ROM),
and
it
will
move any size block from
anywhere
to
anywhere. The assembly
listing
(Fig.
5)
shows
that
it
occupies
24
HEX bytes
of
memory, and uses six
bytes
of
zero-page. Before moving
it
to
KIM, change
that"
*
=$00"
to
the
start
of the six-byte block you want
it
to
use in
KIM.
Don't
bother
to
change
the
"* = $200"
starting
address;
after
you
have
it
in KIM, you can use
the
program
to move
itself
to wherever you want
to
keep it. I keep
two
copies on tape, one
that
loads
to
zero-page and one
to
the
top
of
RAM, plus one more in EPROM
With another copy in AIM,
it
can be used
for general memory
transfer
in
either
Now,
how
about
a program destined
for Page Zero, such as the sorter/printer
above? The final version (as listed
above)
must
be assembled with object-
output
to
tape, and can then
be
safely
loaded and run. But during debug, the
assemble-to-memory-and-run cycle can
still
be used by moving program and
data
to
higher memory. For example,
just
before YTAB,
change"
* = *+
1"
to "* = $200" (to move
data
to
Page
2);
and before START,
change"
*
=$10"
to
"* = $300" (to move the program
to
Page
3).
This changes some addressing
modes from zero-page
to
absolute, but
the assembler takes
it
in stride. Now
assemble
to
memory and run.
After
it
all
works, move
data
and program down
to
Page Zero, and assemble to tape.
unless you want to discover, by
trial
and
error, the undocumented portions
of
the
memory map.
It's
okay to assign zero-
page variables, but
don't
use the
assembler to initialize them
with
data.
The
data
may not survive the assembly.
So how do you
output
object to tape in
KIM format? You have your
choice
of
two
ways. The simple way is to
output
object
to tape in AIM format, load
this
back
into
AIM, and then DUMP
it
to
tape
in KIM format. This works fine,
but
it
is
slow. The faster way,
if
you have room in
AIM RAM, is to send
object
to memory
and then DUMP in KIM format. Before
you do either, read on, or you may
hit
the
second snag.
The AIM
editor
and assembler use the
top
third
(and some
of
the bottom)
of
Page Zero, and several pieces
of
Page
One are used by tape I/O and monitor.
Furthermore, you
can't
(yet)
trust
the
momory map, in the User's Manual.
Rockwell
is
diligently
fixing
the
mistakes and has already issued Revi-
sion
1,
but
it
is
still
too
new
to
be
totally
reliable. For example, look
at
the equate
list
in Fig. 1 again.
Notice
those zero-
page
addresses
for
STlO
through
NSYMHI? Does the memory map tell you
they are used by the assembler? No,
it
doesn't. STLO, STHI,
NSYMlO,
and
NSYMHI are mentioned in the
chapter
on the assembler (Section
5.2).
I found
ENlO
and ENHI by
accident!
of
the six zero-page bytes
containing
symbol-table location and size
(STlO
through NSYMHI), the four
Monitor
subroutines needed for printing
(ClR
through CRCK), the
start
of
the scratch-
pad block
(*
=
$00),
and the
start
of
the
main program
(*
=
$10).
All other ad-
dressing
is
either
relative
(*
= * +
1,
* = * +
4)
or by label (JSR
SORT,
JMP
COMPAR, BNE SWAP),
with
absolute addresses and branch
offsets
assigned during assembly. Therefore,
this
whole program could be moved to
KIM by
simply
changing the scratchpad
start
to any convenient spot in KIM zero-
page, changing the program
start
to any
appropriate spot
in
KIM RAM, and
re-
assembling, with object-output
to
tape
in KIM format.
That last phrase,
"output
to
tape in
KIM
format,"
is where
we
hit the
first
snag. The AIM User's Manual says the
assembler
will
do this,
but
the manual is
wrong. If you
try
OUT·OBJ =
K,
the poor
thing locks up in a trance, and the only
recovery is
RESET.
(If you would like
an
explanation from Rockwell on why
this
happens, call Dave Sawtelle, AIM Ap-
plications, 714-632-0975. This number is
worth
writing
down; AIM
Applications
is
a very
competent
and helpful group.)
In order
to
assemble
to
memory and
run,
try
to
avoid
putting
either program
or
data
on
either
Page Zero or Page One,
The above sort/print is a bad example
of
KIM-convertible
code,
for
two
reasons. The
first
is obvious; consider-
ing
its
function,
KIM
couldn't
do
anything
with
it. The second
illustrates
some
further
precautions.
20:44
MICRO
--
The 6502
Journal
January, 1980