home *** CD-ROM | disk | FTP | other *** search
/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / MACHINE-LANGUAGE-09-86 < prev    next >
Encoding:
Text File  |  2019-04-13  |  7.4 KB  |  152 lines
  1. *********************************************************************
  2. This article is being presented through the *StarBoard* Journal of
  3. the FlagShip/StarShip SIGs (Special Interest Groups) on the Delphi
  4. and GEnie telecommunications networks.  Permission is hereby granted
  5. to non-profit organizations only to reprint this article or pass it
  6. along electronically as long as proper credit is given to both the
  7. author and the *StarBoard* Journal.
  8. *********************************************************************
  9. [ED. NOTE: This is LYLEG'S final article in his multi-part series on a
  10. Sequential File Reader.  Included in this issue of the *StarBoard*
  11. Journal is the full PAL source code and the object code.  Load Object
  12. Code,8,1 and then SYS49152 to use. If you haven't been following along
  13. for the last few months, be sure to go back and retrieve his earlier
  14. articles.  They are excellent!
  15. *********************************************************************
  16.  
  17.                    MACHINE LANGUAGE PART VII
  18.  
  19.                  by Lyle Giese (LYLEG on DELPHI)
  20.  
  21.  
  22. It looks like this month we will finish up the Sequential File Reader.
  23. So what will I do next month? Let me know what YOU want written about.
  24. I really want to write about something that will interest you, and the
  25. best way to do that is to tell me! My DELPHI username is LYLEG, and if
  26. you are on Genie tell deb! and she will forward the comments to me.
  27.  
  28. When we left off last month we just opened the file to be read and now
  29. are ready to decide if we want to send it to the printer or the
  30. screen. Of course, we first print a message to the screen asking
  31. Screen or Printer?
  32.  
  33. In line 1280, we get a character from the keyboard (if there is one,
  34. remember this routine will a CHR$(0) if there are no keys pressed). We
  35. check for an "s" for the screen. If we found one we JSR to the screen
  36. setup routine. If not we check for a "p".
  37.  
  38. Let's look at the 'OSCR' subroutine starting at line 6500. Why are we
  39. opening a logical file for the screen? Doesn't the Programmers
  40. Reference Guide say it is not needed? Yes, that is true. But our
  41. output routine will need to be able to send to the screen or the
  42. printer. The printer needs the logical file to be there. So it can be
  43. easier to send the output to a logical file rather that decide for
  44. each character how to send it, depending on the output device
  45. selected.
  46.  
  47. Of course, we could have written two output routines. Then every time
  48. we sent a character, we would have to check and see which output
  49. device was selected and branch to the proper routine.
  50.  
  51. Ok, now if we want to send our file to our printer we will go to line
  52. 6000 for the PRINTER subroutine. There we ask what device number we
  53. are going to use. Here (in lines 6060-6090) we limit the device number
  54. to 4 through 7. After we get the device number we convert it from
  55. PETSCII to the number we must use for the SETLFS routine.
  56.  
  57. Next we can select the secondary address within the limits zero to
  58. nine. I limited myself to this range to make the routines here simple.
  59. Again, we have to convert from PETSCII to the number to be used for
  60. the SETLFS routine.
  61.  
  62. Now we can open the logical file. For a printer channel, we don't need
  63. a file name and set the length of the filename to zero and finally JSR
  64. OPEN. Why don't we check the printer file the same way we did the disk
  65. file?
  66.  
  67. Well, first of all, nothing has been sent to the printer yet. Until we
  68. open the output channel (JSR CHKOUT) the secondary address and the
  69. listen commands are not sent. At that time is when we find out if the
  70. printer is not there, when the program hangs up (depending on the
  71. printer and interface).
  72.  
  73. Finally we are getting to the heart of the whole thing! Read a
  74. character and send it to our output device. First (in line 1400-1410)
  75. we open an input channel to the disk drive. And then we try to get
  76. our first character from the disk drive.
  77.  
  78. Some of CBM's DOS routines (depending on the type of drive) will send
  79. several null bytes before sending the first byte of the file, and here
  80. we trap them. Next we must store that character as we must read the
  81. status byte and store it also.
  82.  
  83. Now here is where I made the routine "generic", by loading up the byte
  84. representing the outfile and opening an output channel to it. At this
  85. point we could care less if the output device was the screen, printer
  86. or even a disk drive (of course we would have to write a different
  87. subroutine for opening an output file on the disk drive.)
  88.  
  89. In line 1490, we are checking for a successful opening of the output
  90. channel. If the channel is not openning, I do a CLRCHN (restore default
  91. I/O) and try again. Why? I had quite a bit of trouble with this
  92. routine locking up when sending a file to my printer until I put lines
  93. 1490-1530 in.
  94.  
  95. It seems that my printer interface could not keep up with the rapid
  96. opening and closing of channels on the serial bus. It would miss the
  97. JSR CHKOUT in line 1480 once in a while. Then in line 1550, CHROUT
  98. assumes the channel is properly opened and will crash your program.
  99.  
  100. This one place where the PRG misses an important point. If you look at
  101. the description of CHROUT on page 278-279 (of the PRG for the C-64),
  102. they miss that little detail. And of course I put in a way to break
  103. out of this loop in case the printer realy wasn't there (lines
  104. 1510-1530).
  105.  
  106. Now is the time to check the status byte we stored in line 1460. At
  107. this point we are only interested in the end of file bit and use the
  108. AND instruction to look at only that bit. If it is not set we will
  109. continue on as we have not reached the end of the file yet.
  110.  
  111. I decided that it would be nice to be able to pause the output in
  112. order to take time to read the contents of the screen before it
  113. scrolls out of sight. Or a way to abort out if we found out this file
  114. was not the one we really wanted to look at or if we wanted to just
  115. see what the file contained.
  116.  
  117. I used the SHFLAG byte at $028D to see if the Shift key is pressed.
  118. This byte is updated by the systems normal IRQ routines. If the shift
  119. key only is down this byte holds a value of 1. If the CTRL key is
  120. down, a 4 is placed there. And if the logo key is down a 2 is found
  121. here. If 2 or more of these keys are depressed the sum of the key
  122. values is found there at $028D.
  123.  
  124. As long as the shift key is down (or shift lock), the program will go
  125. into a loop rechecking the SHFLAG byte. If the Shift and Control keys
  126. are down (for a value of 6), then abort out just as if we hit the end
  127. of the file.
  128.  
  129. In line 1650 we jump back to and get another byte for outputing.
  130.  
  131. Now when we finish we have to start closing channels and logical files
  132. in line 1680. We have to close the read file before the disk command
  133. channel. In this program, it is not as important. But if we were
  134. writing to a disk file and closed the command file, that would close
  135. ALL open files in the drive, even if we didn't want them closed yet.
  136.  
  137. Next we go after the printer (or screen). On some printers, incoming
  138. characters are buffered until the buffer is full or a carriage return
  139. is received. So here we send a carriage return to make sure the buffer
  140. is emptyed before we close up.
  141.  
  142. Now a message is printed to tell us to press the return key before the
  143. program is allowed to start over, which clears the screen. There (if
  144. you remember) hitting the return with no character in our filename
  145. buffer will exit this program.
  146.  
  147. And that concludes our file reader finally! Next month??? You tell me.
  148. PLEASE!
  149.  
  150. Lyle Giese
  151. AKA LYLEG
  152.