ASSEMBY LANGUAGE PROGRAMMING

PART EIGTH: READING ARBITRARY MEMROY


     Last time we examined using macros to call our SWI
subroutines. As I'm sure you can see, these are extremely
useful. However, even with the routines we have designed
and implemented, these macros are useless unless all of
them are working.

     To that end, this time I present to you the routines
for reading a byte from arbitrary memory locations. I'm
sure most of you who have been following this series have
figured out how to do it by now, but you might find my
code interesting.

    I will also give you a warning. None of the code I
present here has been tested. There may be bugs in it. If
there are, that adds to the learning experience, as
debugging someone else's code can be a bigger learning
experience than just seeing working code. If you do find
a bug in the code, send me an email to
astlew@bigfoot.com, including the fix for the problem and
I'll update my sources.

    This time, I also provide the short code snippet to
assemble the project which due to its size is split tinto
several files. You can assemble the project by assembling
the file PART8.ASM. It is fairly obvious how this piece
of code works. Make absouutely certain that you have the
disk with the files for this installment in the default
drive when you do.

    Basically, the memory read routines make use of our
previously developed block/offset and linear address
conversion routines to obtain the correct block/offset to
read, after obtaining the parameters from the appropriate
locations. due to the limited number of registers on the
6809 processor, however, you may note some rather
interesting acrobatics with the registers and stack. It
should be fairly straight forward to unravel, so I will
not go further into it here.

    Next time, the routines to write to memory will be
presented. With those routines in our cookbook, we will
have all the tools we need to access the entire memory of
the CoCo3. Also, the principles transfer to any system
that uses memory management hardware separate to the CPU.
Notable examples of this were "Expanded Memory" on 8086
and higher CPUs in the IBM PC world. On modern
processors, this is no longer necessary, however, the
method for calling system functions remains fairly
similar, although it is helped by hardware somewhat.

    The reason for the discussion in the previous
paragraph is to give you an appreciation for the
complexity of this procedure and you will appreciate all
the more the amount the modern processors do if you ever
try doing assembly language on, for example, the Pentium
II CPU from Intel.

    I'll leave off with that for this installment. Until
next time, keep programming, and most of all, have fun.

P.S. If any of you have code you want to submit to this
project (yes, we might eventually have a working project
here), feel free to email it to me at astlew@bigfoot.com.