PART 10: DOING SOMETHING WITH THE CODE LIBRARY

Last time, I presented the final code for the arbitrary memory
locations on the CoCo. Now I will actually present some code
which may prove marginally useful.

One might do any number of things from using the extra memory
as a temporary location to store data to using it as a main
storage for something like a word processor. Now, the word
processor idea is rather complex, so we will not be doing
anything quite like that in this series, at least not for
some time. What we will do, however, is create a program
that will take an arbitrary memory block in the BASIC 64K
memory map and store it into the "extended" memory. This
might give you some interesting ideas on how to interface
with other assembly routines. The method I'm going to use
here is actually a bit of a hack, but it is rather easy to
use.

Essentially it will work by doing an EXEC command in BASIC.
That leaves the question of how to get the parameters into
it. The most common method of so doing would involve using
POKE to put the parameters into a known memory location. I
don't like this method for two reasons. One is that it is
ugly and values that need more than 8 bits are more complex
to put into the parameter block. The other reason is that it
requires several commands to do one essentially atomic task.
So how are we going to get the parameters then?

My method involves using some rather interesting features
in the BASIC interpreter that comes with the CoCo. We will
pass the parameters after the EXEC command. Essentially,
our syntax will look as follows:

EXEC<address>:<source>,<length>,<dest>

Note the ":" after the address. This is necessary so the
address is interpreted correctly.

The address will, of course, be the location of our
subroutine. There will need to be two subroutines to be
useful; one to store, one to load. Note that this method
of parameter passing requires neither pokes nor modification
of the BASIC interpreter. We will also be able to use
variables with the correct coding of the subroutine.
This gives us much versatility with relative ease of
use.

It should be noted at this point that the only reason using
SWI subroutine calling will work here is that BASIC does not
use the SWI instruction at all.

Initially, I will present the code to copy TO extended memory.
It should be relatively obvious how to reverse the process after
you look at this installment's code.

As noted last time, this is NOT the most efficient
method of so doing. It should, however, work. You can, if
you wish, use the priciples presented so far to build a far
more efficient bit of code for doing this.

As a side note - the block size is limited to 65535 bytes
due to the 16 bit size of the counter we will use.

Note that unlike previously, this code is known to assemble.
It also appears to work on very unimaginative tests. I did find
one typo in the library code when I assebled this, however. It
was in line 2500 of PART10B.TXT (PART9B.TXT last time).

Until next time, keep hacking.