ORIGINALLY PUBLISHED IN NOVEMBER 1994 LIMA NEWSLETTER
 
                               Assembler Executing #7. . 
                                  By Bob Carmany 
 
     How about something simple for this month's column.  It is about time that
we did something with our programming.  One of the easiest things to do in
assembly is to put a line of text on the screen.  All you have to know is
where, what, and how much.  Here is one way that you can do it. 
 
          REF VMBW
 
|         |    |
 
MSG1      TEXT 'This a test message'
 
|         |    |
 
DSPLY     BL   @VMBW
          DATA 84,MSG1,19
 
|         |    |
 
     Obviously, there is quite a bit of code missing in this example but you
can let you imagination fill in the details. 
     What we have done is use the VDP Multiple Byte Write (VMBW) routine in the
E/A cartridge to write the message to the screen.  We first must include it in
the REFerence block to be able to use it.  The alternative would be to write
our own routine and include it somewhere in the program.  Next we have the
message that we want to display.  In this case, MSG1   TEXT 'This is a test
message'.  To do the dirty work, we access VMBW and give it the data that it
requires: where (screen position 84), what (MSG1), and how much (19 chars).
Remember that when you count the characters in a TEXT message the spaces count
as well as the alphabetic characters.  Oh yes, the screen position is
calculated from the upper left corner of the screen which is 0. 
     Remember when we went through all of those Jump instructions?  How about
using them to create the A/L equivalent of the XB ACCEPT AT statement for a
range of keypresses. 
 
|        |     |
 
ASC0     TEXT '1'
ASC9     TEXT '9'
 
|        |     |
 
RNGE     CB   R1,@ASC1
         JLT  KEYPRS
         CB   R1,@ASC9
         JGT  KEYPRS
 
     For the purpose of this example I have assumed that the keypress value was
stored in R1.  The code is simple, the Compare Byte instruction is used to test
whether the keypress returned was less that 1. If so, the program goes back to
KEYPRS for new input.  If it is one or more then it is tested against 9.  If it
is more than 9 contraol is once again passed back to KEYPRS for another input.
If it falls within the range of 1-9 than the program continues to the next bit
of code. 
     This method is particularly valuable if you are going to be using 1 and 9
in other capacities in the program.  That way, you would only have to define
the ASCII character once and could use it in several ways. 
     Another method that comes to mind is to use CB and the hexidecimal value
of the number or letter (ie. >31 for 1 and >39 for 9).  The further abbreviated
code would look like this: 
 
|       |      |
 
RNGE    CB    R1,>31
        JLT   KEYPRS
        CB    R1,>39
        JGT   KEYPRS
 
|       |      |
 
     That is one of the beauties of A/L.  Whatever you want to do, there is
always another way to do it.  Unlike XB or BASIC, you aren't constricted to a
specific format.  By the same token, it is a bit frustrating at times as well.
Invariably just after you finsih that 'masterpiece' program, you think of
another way that you could have done --usually more efficiently and easier.
But the best part is that for every potential problem, there always seems to be
a 'workaround' if you spend the time to find it. 
     Before I leave for the month, here is a little trick that has made the
rounds of the TI community for years. Merle Vogt passed it on to Bruce Harrison
who, in turn passed it on to me.  It has been used to help convert D/F 80
object code to program image files for a long while. 
 
 
       DEF   SFIRST,SLAST,SLOAD
SFIRST EQU   >2000
SLOAD  EQU   >2000
SLAST  EQU   >23BA
       END
 
     When this bit of code is assembled through the E/A cart, it becomes a
5-sector files with the E/A utilities.  It can be used as the second file of a
program image file that will run independently of the E/A cartridge.  Thus you
can make use of all of the E/A utilities with a simple program image file
loader. 
     this is getting a bit long.  There are some other projects that need a bit
of attention.  'Til next month . . .