ASSEMBLY LANGUAGE PROGRAMMING

                   PART TWO: ZAPPING MEMORY


     Zapping memory? Doesn't sound healthy, does it? Well, it
really isn't, especially if you wish to keep what's in the
memory in question. We are going to assume this time that there
is a chunk of memory you want to zap (i.e. clear). I have no
intention of actually physically opening a computer and
literally zapping the memory. That is too expensive.

     What we will actually be doing is developing a subroutine
(in assembly language of course) to clear an arbitrary section
of memory. By clearing, I mean that we will store a $00 byte
into every location between the start and the end of the block
inclusive.

     It looks to me that we have a fairly well defined problem
to solve. There is only one question which requires answering
now: How are we going to tell the subroutine what block of
memory it is supposed to clear. This is actually a very common
problem. Very frequently programmers wish to send information
into their subroutines. This is so frequent, in fact, that the
information is called "parameters". If you have done much BASIC
programming, you will have exerienced parameters first hand
since the value 3 in CLS 3 is a parameter to the command CLS
which is actually a subroutine in the BASIC interpreter.

     In assembly language, there are several methods of passing
parameters to a subroutine. The easiest way to do this is to use
registers. This works for simple data like the number of times
to do a task or a pointer to some memory location. This method
breaks down, however, when one has more parameters than
registers or strings of characters or whatever to pass to the
procedure or subroutine.

     One method of avoiding the above problem is to have a block
of memory locations through which information is passed to and
from the subroutine. This is cumbersome in most applications
since it does not allow much flexibility and the programs which
use that subroutine must be changed if the location of that
subroutine is changed. In other words, it does not make position
independant code. There is another method which can be used in
that situation, however. It involves using the stack as a
temporary storage location. This is, in fact, very common but
has the problem of cleaning up the stack after the subroutine is
finished. I will not go into detail on stack parameters in the
near future. There is, however, a method of passing a block of
parameters to a subroutine which involves just passing an
address which is assumed to have data in a specific
configuration. This method may be investigated later in the
series.

     Since we have only two parameters which need passing to our
subroutine, we can use the register method of passing
parameters. There are several methods of referencing memory in
the CoCo3, though. We could represent the address as a 24 bit
number but that would involve complicated decoding later. We
could refer to blocks of 8K (there are 64 of these in a 512K
computer) each with an offset ($0000 to $1FFF). This is actually
the best method since it mirrors the way the actual memory
management works.

     Now that we know what parameters need passing and what
format they will take, we need to know which registers will be
used. It is clear that we need 3 bytes for each parameter since
the block number will take one byte and the offset will take two
bytes. A little research reveals that there are two 8 bit
registers and 4 16 bit registers which can be used. We will, in
this case, pair A with X and B with U for our parameters and we
will call the A,X pair the start of the block and the B,U pair
the end of the block.

     I will not go into much detail about how the actual code
works. I will let you try to puzzle that out. A little thought
should reveal how it works. I will just say that it works by
clearing a byte then checking if that was the last and repeats
that procedure until the check returns true.

     The source code is included in EDTASM+ format in the file
"PART2.ASM" and there is a listing in the file "PART2.LST". I
will leave it to you to write a testing program.

     Until next time, keep programming. Be sure to keep your
subscription up to date.