home *** CD-ROM | disk | FTP | other *** search
/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / MACHINE-LANGUAGE < prev    next >
Encoding:
Text File  |  2019-04-13  |  7.3 KB  |  148 lines
  1. *********************************************************************
  2. This article is being presented through the *StarBoard* Journal of
  3. the FlagShip/StarShip, SIGS (Special Interest Groups) on the
  4. Delphi and GEnie telecommunications networks.  Permission is
  5. hereby granted to non-profit organizations only to reprint this
  6. article or pass it along electronically as long as proper credit
  7. is given to both the author and the *StarBoard* Journal.
  8. *********************************************************************
  9.  
  10.                        Machine Language Part VI
  11.  
  12.                             by Lyle Giese
  13.  
  14.                           (LYLEG on DELPHI)
  15.  
  16.  
  17. Last month I started explaining my SEQ file reader for you. I got up to
  18. putting the opening message on the screen.
  19.  
  20. Next we must get from you (the user) the filename of the file you want
  21. printed out. We have to start by deciding where we are going to store
  22. the filename. In BASIC, BASIC takes care of that automatically. But of
  23. course that convenience is offset by the slow speed of BASIC.
  24.  
  25. In this program I decided to use the cassette buffer at $033C. Again I
  26. will use the index and index+1 memory locations to point to the
  27. filename. I will also need another variable for the length of the
  28. filename. For that I used $FD and initialized it by putting a Zero byte
  29. in it.
  30.  
  31. I issued a call to the KERNAL CLRCHN routine next, just to make sure I
  32. was getting my input from the keyboard. Next call the GETIN routine to
  33. get the keypresses. If no keys are pressed it will return with a zero
  34. in the Accumlator, which the instruction in line 700 checks for.
  35.  
  36. Next we need to check for the delete key (we don't make typing mistakes
  37. do we?). If we haven't put any characters in the filename, it would be
  38. hard to delete one. So in line 730 & 740 we check to make sure we have
  39. characters there. Then delete the last character printed on the screen
  40. and DECrement the FLEN variable in line 770.
  41.  
  42. Next we have to check for a carriage return. The carriage return is
  43. used for two things. It will mark the end of the filename after we have
  44. typed it in. Also, we use it to exit the routine. By checking FLEN
  45. after getting a carriage return (in lines 810 & 820), if there are no
  46. characters yet, we exit by the RTS instruction in 830. Or Branch if Not
  47. Equal to the DOPEN routine.
  48.  
  49. Then if we get to line 840, we have a character we want to add to the
  50. filename. We need to first check the length of the filename before we
  51. add it to the filename. If the filename is too long we really don't
  52. want the extra characters. At this point, we branch back (line 860) to
  53. make you press the return button before trying to find the file.
  54.  
  55. But 18 characters? Filenames can be only 16 characters long! That's
  56. right, but add the prefix '0:' or '1:' for those of us that have dual
  57. drives and the max length now becomes 18.
  58.  
  59. I did not check for valid characters by limiting input to numbers
  60. and/or letters only. I only checked for the delete key and the return
  61. key. So that is something to watch out for or a feature for you to add.
  62.  
  63. Now echo the character to the screen for the you to see and jump back
  64. for more characters to NOKEY, which is at line 690.
  65.  
  66. After we have finished typing the filename, we need to go to the disk
  67. drive and open a read channel from which to get the characters. But
  68. since we are making a SEQ file reader, I added ',S,R' to the end of the
  69. filename and adjusted FLEN accordingly.
  70.  
  71. Now, open the command channel to the disk drive so we can see any disk
  72. errors that might occur. That takes us down to line 1090. That checks
  73. for errors opening the error channel.
  74.  
  75. Now we can open our read channel. We start by setting the filename for
  76. the system with the SETNAM routine. Next the SETLFS and the OPEN
  77. routine. Now we just performed the equivelent of OPEN8,8,8,"FNAM,S,R".
  78. Again go back to your Programmers Reference Guide if you have problems
  79. using the KERNAL routines. Knowing how to read that portion of the PRG
  80. is esstenial to programming in ML on a Commodore computer.
  81.  
  82. Note in opening the disk channel, I didn't have to remember many
  83. numbers? By using the names (which are defined at the beginning of the
  84. program), I didn't have to remember where I put the filename or where I
  85. put the file length number either. Sure makes it easy to write a
  86. program that way.
  87.  
  88. Also, what if I made a mistake in placing my filename buffer? If you
  89. didn't use a name for it, you would have to go through the program very
  90. closely changing every reference to it. But here I only have to change
  91. it in one location, in the beginning. It would be very easy to miss one
  92. spot in the program making debugging even harder!
  93.  
  94. Now that we have done that we must check to make sure that the file was
  95. there and the disk drive properly openned a channel for us. We do that
  96. two ways. The first one actually checks to make sure the computer was
  97. able to properly open the file to the drive. We do that in line 1190.
  98.  
  99. Next we will read the disk's error channel via a call to the subroutine
  100. CKERROR (line 1210). That takes us to line 4000. We open an input
  101. channel to file #$0F and read the error channel.
  102.  
  103. If the first two characters out are $30 and $30, that means an error of
  104. 00 occured, which of course means no error. Then we would just take all
  105. of the characters out of the error channel to tidy things up and ReTurn
  106. from Subroutine.
  107.  
  108. If anything else is returned in the first two characters, something
  109. went wrong. Then we want to read and print out the error message on the
  110. screen. That's why we store the first two characters. While printing
  111. the error message, we check for the end of the message by checking for
  112. a carriage return.
  113.  
  114. Now that we found an error, we can't return to where we were in the
  115. program, because that would lead us down into the file read and print
  116. routines. We want to go back to the beginning of the program.
  117.  
  118. So in line 4140, we start by printing the disk error message on the
  119. screen to the user. Now we have think about how ML handles a
  120. subroutine. When the JSR instruction is called, the return address has
  121. to go somewhere so that we can find our place when the RTS instruction
  122. is issued. That place is the stack. The 6510 pushes the return address
  123. as two bytes onto the stack.
  124.  
  125. Since I haven't used the stack for any other storage, it should be the
  126. last two entries on the stack. So we pull two bytes off of the stack
  127. and throw them away. Now this is an advanced technique, but it is
  128. important to understand it. In this case it can be quite handy. But if
  129. I had used the stack for other storage I could not have done this that
  130. easily.
  131.  
  132. At line 4220, we start closing things up by first restoring default I/O
  133. by calling CLRCHN. And then we close the read channel and then the
  134. error channel.
  135.  
  136. Now I decided to print a short message to indicate I wanted the user to
  137. press the return key and wait for him to press the return key. Why? It
  138. is to give you a chance to read the error message before clearing the
  139. screen when we go back to the beginning of the program.
  140.  
  141. So at this point we would restart the program. But I have rambled on
  142. enough for one month. Next month we will look at how I handled the
  143. screen or printer option and some of the problems encountered doing
  144. that.
  145.  
  146. [ED. NOTE: The partial source code to accompany this article is the
  147. next file in this month's edition of the *StarBoard* Journal.]
  148.