home *** CD-ROM | disk | FTP | other *** search
/ ftp.whtech.com / ftp.whtech.com.tar / ftp.whtech.com / club100 / ref / td2tip.009 < prev    next >
Text File  |  2006-10-19  |  10KB  |  230 lines
  1. TD2TIP.009 Direct Sector Access using FLOPPY (FLOPPY2)
  2. ======================================================
  3. Joel Dinda
  4. [75725,1134]
  5.  
  6. While FLOPPY isn't my favorite program, it provides TDD2 users the capability
  7. to bypass the TDD file structure and access disk sectors directly.  The most
  8. obvious applications for this capability are utility programs (there are
  9. several such in this Library) and (random access?) database programs (aside:
  10. database programmers will have to write their own file-management routines, a
  11. matter this discussion ignores).  This file lists all-in-one-place those things
  12. someone writing such a program will need to know.
  13.  
  14. First I'll talk about syntax, then I'll discuss some necessary concerns,
  15. finally I'll discuss some background matters.
  16.  
  17. **WARNING:  This is an advanced and fairly specialized programming tip.  Only
  18. fairly experienced M100(etc) programmers will understand some of this
  19. discussion.  Lots of it is pretty opaque.  While it's not intended to
  20. intimidate, you've got to be writing a pretty sophisticated program to want to
  21. know these things.
  22.  
  23. Powr-DOS/TDD1 users/programmers will want to read DOSTIP.009.
  24.  
  25. Syntax
  26. ======
  27. The necessary command is a conventional BASIC CALL:
  28.  
  29.       CALL Z,Y,X
  30. Where:
  31.       Z is the start of FLOPPY's file transfer routine (depends upon which
  32.       computer you're using)
  33.  
  34.       Y is the code for the activity you wish to provoke (details follow).
  35.       
  36.       X is the RAM address of some further instructions necessary for execution
  37.       of the routine.
  38.  
  39. Z options:
  40. ----------
  41.       In M100/T102, Z is 62297 (-3239 integer).
  42.       In T200, Z is 58980 (-6556).
  43.  
  44. Y options:
  45. ----------
  46.       1 attempts to format the diskette.
  47.       3 attempts to read the diskette.
  48.       4 attempts to write to the diskette.
  49.       5 checks (reports) the status of the drive (so do the other options).
  50.  
  51.       --TD2TIP.005 says, incorrectly, the Y=2 writes to the diskette (*easy*
  52.       mistake).  If someone figures out what Y=2 actually *does* do, I'd like
  53.       to hear about it.  Thanks.
  54.  
  55. X options:
  56. ----------
  57.       Any legal RAM address--but some are far better than others.  I'll return
  58.       to this momentarily.
  59.  
  60. Further information at location X:
  61. ----------------------------------
  62. The routine beginning at Z checks at X for two pieces of information:
  63.       X and X+1 store the address, in RAM, reserved (by you) for the file
  64.       transfer.  (Call it a buffer [BF]; this is its lowest address [possibly
  65.       HIMEM].  I discuss this further below.)  Like most M100 two-byte
  66.       addresses, these are stored LSB+MSB.  (I suggest a simple solution in
  67.       the discussion below.)
  68.  
  69.       X+2 is the diskette sector being transferred.
  70.  
  71.       It may help to think of the information at X this way:  You're
  72.       transferring data [content and direction unspecified] between a buffer
  73.       which is indicated at X & X+1 and a diskette sector which is indicated at
  74.       X+2.
  75.  
  76. Necessary Concerns:
  77. ===================
  78. M100 or T200?
  79. -------------
  80. By this time there's no excuse for donating a computer- specific program to
  81. this SIG without good reason.  PEEK(1) returns 51 in M100/T102; it returns 171
  82. in T200.  Once you know this, you can assign the appropriate value to Z and any
  83. other computer-related POKEs, PEEKs, or CALLs you'll be using.  (I like to
  84. work over the keyboard buffer, for instance.)
  85.  
  86. Is FLOPPY there?
  87. ----------------
  88. Next, check to see if FLOPPY's actually installed.  Tandy's BACKUP does this by
  89. checking four RAM locations; the following line is a slightly more compact
  90. version of theirs:
  91.       IF PEEK(Z)=229 AND PEEK(Z+1)=94 AND PEEK(Z+239)=4 AND PEEK(Z+240)=195
  92.       THEN continue ELSE error: "No System"
  93.  
  94. Buffers
  95. -------
  96. Next create one or more buffers for your program's use.
  97.  
  98. You'll need one buffer for each sector you intend to duplicate in RAM at any
  99. one time; the exact number will depend either upon the nature of your
  100. application or the amount of RAM available.  Each buffer will be 1284 bytes
  101. long; it should be locked in with some variation of the following instruction:
  102.       CLEAR256,HIMEM-(1284*(number of buffers))
  103.  
  104. It is *always* good practice to restore HIMEM to its previous value when the
  105. program finishes; there are at least two workable schemes.  Folks who use
  106. MAXRAM instead of HIMEM in programs which overwrite high memory are despicable
  107. creatures; they should, at least, warn users that they're destroying files.
  108.  
  109. Variable X:
  110. -----------
  111. The third CALL argument points to a RAM address containing address information
  112. for the CALL's use.  I know of two ways to do this, but suggest that everyone
  113. use this one:
  114.  
  115. If BF is the first (lowest) address in the buffer, and S is the sector number:
  116.  
  117.       0 ... :DEFINT T:DIM T(1): ...
  118.       16 ... :T(0)=BF:T(1)=S:CALL Z,Y,VARPTR(T(0)): ...
  119.  
  120.       This is a "cute trick"; it works because M100 stores T(0) and T(1)
  121.       together in RAM; VARPTR(T(0)) tells that location.  [Please notice the
  122.       DEFINT!  It matters!]
  123.  
  124. Some of the SIG's utilities use POKEs to accomplish this, but there's no
  125. advantage (and the coding's more difficult).
  126.  
  127. Detecting Errors
  128. ----------------
  129. While this CALL does not directly return error messages, it *does* return error
  130. information.  This information is stored at address X; if you've used
  131. VARPTR(T(0)), you only need to determine the value of T(0).  Good practice (and
  132. common sense) dictate that you check this value *immediately* after attempting
  133. any file transfer.
  134.  
  135. These are the documented errors:
  136.       T(0)=0 or 1       no error
  137.       T(0)=3            RS232 Not Ready (Powr-DOS Error 59/NR)
  138.       T(0)=5            Communications Error (61/CM)
  139.       T(0)=6            Write Protected (63/WP)
  140.       T(0)=8            No Disk in Drive (65/ND)
  141.       T(0)=9            Hard Trouble (66/HT)
  142.       T(0)=12           Drive Not Responding (60/DN) [not previously documented]
  143.  
  144. Presumably the "empty" numbers can be generated, but I haven't figured out how.
  145. If you discover one, please pass it along.  Thanks.
  146.  
  147. I've been using the following approach.  Obviously there are others, but I'm
  148. happy with this one:
  149.  
  150.       0 ON ERROR GOTO 99: ...
  151.             ...
  152.       16 ... :CALL Z,X,VARPTR(T(0)):GOSUB98: ...
  153.             ...
  154.       97 MENU
  155.       98 IF T(0)<2 THEN RETURN ELSE IF T(0)=6 OR T(0)=8 THEN ERROR 63 ELSE IF
  156.       T(0)=3 OR T(0)=5 OR T(0)=9 OR T(0)=12 THEN ERROR 60 ELSE ERROR 99
  157.       99 IF ERR=63 THEN PRINT "Disk Error" ELSE IF ERR=60 THEN PRINT "Drive
  158.       Error" ELSE PRINT "Error" ERR "in line" ERL:END
  159.  
  160. I've used ERROR 99 as a clue that we've found a new error code.  The other
  161. codes simplify conversion between Powr-DOS & FLOPPY.
  162.  
  163. You can modify this to RESUME or quit, as appropriate.  For instance, knowledge
  164. that T(0)=6 means the diskette is write protected can be used with CALL Z,5,X
  165. force the user to protect a diskette's files.
  166.  
  167. Background
  168. ==========
  169. Much of the technical information was obtained by studying Tandy's BACKUP.BA,
  170. which is supplied with the TDD2 drive, and by systematic experimentation.  Some
  171. of the other discussion follows from Powr-DOS experience.
  172.  
  173. Buffer Format:
  174. --------------
  175. The first byte in the sector (more exactly, in the buffer) (let's call it BF+0)
  176. indicates the diskette format in use.  0 means it's a TDD1 diskette; 22 means
  177. it's a TDD2 diskette.  This is evidently provided for our information, as
  178. changing it has no effect--if you "save" a sector with this byte changed, then
  179. retrieve it again, it's been restored to its original value.
  180.  
  181. The second byte in the sector (well, buffer) (BF+1) is the file vector:
  182.       0 means the sector's empty;
  183.       255 is an EOF marker; and
  184.       any other number indicates "file continues here".
  185. Since file deletions do *not* modify these vectors, these may be misleading.
  186.  
  187. Two bytes of unknown consequence follow at BF+2 & BF+3.  They appear to always
  188. be zero; presumably they could contain information with meaning to the drive.
  189.  
  190. The next 1280 bytes (starting at BF+4) duplicate the sector's contents.  If the
  191. sector is not 0 or 1, this could be anything (TDD2 doesn't inflict any format).
  192. Unless modified, Sectors 0 and 1 conform, with three significant modifications,
  193. to the information in SECTR0.TDD, available from this Library.  Discussion
  194. follows immediately....
  195.  
  196. Directory Structure:
  197. --------------------
  198. TDD directory structure is discussed at some length in my file SECTR0.TDD. 
  199. Since FLOPPY delivers a somewhat different copy of the sector to RAM, a few
  200. adjustments must be made; some of these adjustments result from differences
  201. between the drives, while others seem to be idiosyncratic programming
  202. decisions.
  203.  
  204. Perhaps the most important difference between sector buffers created by
  205. Powr-DOS and FLOPPY is that FLOPPY's sectors come with four leading bytes (two
  206. of which contain information), while P-DOS's come with 12 trailing bytes (one
  207. of which contains information).  When reading SECTR0.TDD, you must therefore
  208. add an offset of 4 to most counts, while the file vector check must be adjusted
  209. from BF+1281 to BF+1.
  210.  
  211. Since TDD2 diskettes contain two directories (Sectors 0 and 1), certain
  212. allowances must be made for this.  Except for the allocation table, the
  213. structure of the directory sector(s) is unchanged from that described in
  214. SECTR0.
  215.  
  216. The allocation table *is* changed.  Where TDD1 stores allocation information
  217. for 80 sectors on half of 160 bits, TDD2 (naturally) uses all 160 bits to store
  218. twice as much information.  The allocation table is duplicated on both
  219. directories, effectively describing the entire diskette for either. 
  220. *Important related matter:*  FLOPPY (and any other DOS, near as I can tell)
  221. updates *both* allocation tables when you add or subtract a file.  One side
  222. effect of this is that Sector 1 should be considered unavailable under all
  223. circumstances--unless you're writing your own file control routines and *never*
  224. use the TDD2's built-in routines for file transfers.
  225.  
  226.  
  227. Enough.  That should point you in the right direction....
  228. Joel Dinda
  229. July 4, 88
  230.