home *** CD-ROM | disk | FTP | other *** search
/ ftp.whtech.com / ftp.whtech.com.tar / ftp.whtech.com / articles / archives / limanews.exe / ASSM_7.TXT < prev    next >
Text File  |  2006-10-19  |  4KB  |  102 lines
  1. ORIGINALLY PUBLISHED IN NOVEMBER 1994 LIMA NEWSLETTER
  2.  
  3.                                Assembler Executing #7. . 
  4.                                   By Bob Carmany 
  5.  
  6.      How about something simple for this month's column.  It is about time that
  7. we did something with our programming.  One of the easiest things to do in
  8. assembly is to put a line of text on the screen.  All you have to know is
  9. where, what, and how much.  Here is one way that you can do it. 
  10.  
  11.           REF VMBW
  12.  
  13. |         |    |
  14.  
  15. MSG1      TEXT 'This a test message'
  16.  
  17. |         |    |
  18.  
  19. DSPLY     BL   @VMBW
  20.           DATA 84,MSG1,19
  21.  
  22. |         |    |
  23.  
  24.      Obviously, there is quite a bit of code missing in this example but you
  25. can let you imagination fill in the details. 
  26.      What we have done is use the VDP Multiple Byte Write (VMBW) routine in the
  27. E/A cartridge to write the message to the screen.  We first must include it in
  28. the REFerence block to be able to use it.  The alternative would be to write
  29. our own routine and include it somewhere in the program.  Next we have the
  30. message that we want to display.  In this case, MSG1   TEXT 'This is a test
  31. message'.  To do the dirty work, we access VMBW and give it the data that it
  32. requires: where (screen position 84), what (MSG1), and how much (19 chars).
  33. Remember that when you count the characters in a TEXT message the spaces count
  34. as well as the alphabetic characters.  Oh yes, the screen position is
  35. calculated from the upper left corner of the screen which is 0. 
  36.      Remember when we went through all of those Jump instructions?  How about
  37. using them to create the A/L equivalent of the XB ACCEPT AT statement for a
  38. range of keypresses. 
  39.  
  40. |        |     |
  41.  
  42. ASC0     TEXT '1'
  43. ASC9     TEXT '9'
  44.  
  45. |        |     |
  46.  
  47. RNGE     CB   R1,@ASC1
  48.          JLT  KEYPRS
  49.          CB   R1,@ASC9
  50.          JGT  KEYPRS
  51.  
  52.      For the purpose of this example I have assumed that the keypress value was
  53. stored in R1.  The code is simple, the Compare Byte instruction is used to test
  54. whether the keypress returned was less that 1. If so, the program goes back to
  55. KEYPRS for new input.  If it is one or more then it is tested against 9.  If it
  56. is more than 9 contraol is once again passed back to KEYPRS for another input.
  57. If it falls within the range of 1-9 than the program continues to the next bit
  58. of code. 
  59.      This method is particularly valuable if you are going to be using 1 and 9
  60. in other capacities in the program.  That way, you would only have to define
  61. the ASCII character once and could use it in several ways. 
  62.      Another method that comes to mind is to use CB and the hexidecimal value
  63. of the number or letter (ie. >31 for 1 and >39 for 9).  The further abbreviated
  64. code would look like this: 
  65.  
  66. |       |      |
  67.  
  68. RNGE    CB    R1,>31
  69.         JLT   KEYPRS
  70.         CB    R1,>39
  71.         JGT   KEYPRS
  72.  
  73. |       |      |
  74.  
  75.      That is one of the beauties of A/L.  Whatever you want to do, there is
  76. always another way to do it.  Unlike XB or BASIC, you aren't constricted to a
  77. specific format.  By the same token, it is a bit frustrating at times as well.
  78. Invariably just after you finsih that 'masterpiece' program, you think of
  79. another way that you could have done --usually more efficiently and easier.
  80. But the best part is that for every potential problem, there always seems to be
  81. a 'workaround' if you spend the time to find it. 
  82.      Before I leave for the month, here is a little trick that has made the
  83. rounds of the TI community for years. Merle Vogt passed it on to Bruce Harrison
  84. who, in turn passed it on to me.  It has been used to help convert D/F 80
  85. object code to program image files for a long while. 
  86.  
  87.  
  88.        DEF   SFIRST,SLAST,SLOAD
  89. SFIRST EQU   >2000
  90. SLOAD  EQU   >2000
  91. SLAST  EQU   >23BA
  92.        END
  93.  
  94.      When this bit of code is assembled through the E/A cart, it becomes a
  95. 5-sector files with the E/A utilities.  It can be used as the second file of a
  96. program image file that will run independently of the E/A cartridge.  Thus you
  97. can make use of all of the E/A utilities with a simple program image file
  98. loader. 
  99.      this is getting a bit long.  There are some other projects that need a bit
  100. of attention.  'Til next month . . . 
  101.  
  102.