home *** CD-ROM | disk | FTP | other *** search
/ ftp.whtech.com / ftp.whtech.com.tar / ftp.whtech.com / club100 / ref / sectr0.tdd < prev    next >
Text File  |  2006-10-19  |  12KB  |  308 lines

  1. A MAP OF SECTOR 0
  2. =================
  3. joel dinda
  4. [75725,1134]
  5.  
  6. This is a map of the Directory Sector (0) on the TDD disk.  Near as I can
  7. tell it's complete, though I suppose I may have missed something.  It also
  8. includes some information on related matters, poses some questions for
  9. investigation, and offers a few opinions.
  10.  
  11. A couple definitions are in order:  Counts are from 0.  I speak here of a
  12. disk sector (Sector 0) which is divided into 2 sections.  The first of these
  13. sections is further subdivided into records.  If you keep these things in
  14. mind, what follows may make sense:
  15.  
  16. The directory in Sector 0 is 1292 bytes long (not all of these bytes are
  17. used). It is divided into two main sections:  One which tells about files, and
  18. one which keeps track of sector allocation.
  19.  
  20. FILE INFORMATION SECTION
  21. *40 records of 31 bytes
  22. *Begins at Sector 0 Byte 0
  23.  
  24. The files section is a 40 record database.  It begins with the first (0) byte
  25. and contains 1240 bytes; that's 40 records of 31 bytes to keep track of up to
  26. 40 files.  Each record has the following format:
  27.  
  28.         24 bytes reserved for filenames
  29.         **start at Record byte 0
  30.          -Tandy filenames use only nine of these bytes (REQUIRED period at
  31.           byte 7, spaces are used to pad the name as necessary)
  32.          -the remaining bytes are filled with CHR$(32) (spaces) if there's a
  33.           filename in the record
  34.  
  35.         The next byte is CHR$(70) (letter F) if there's a file
  36.         **this is Record byte 24
  37.          -seems to be a simple(?) flag
  38.          -see further comments below
  39.  
  40.         The next two bytes are the length of the file, stored MSB+LSB
  41.         **Record bytes 25 & 26
  42.          -this format creates the 64K file length limit
  43.  
  44.         Next two bytes blank (CHR$(0))
  45.         **Record bytes 27 & 28
  46.          -likely reserved for system use; NOT used here
  47.  
  48.         Next byte locates the sector holding the start of the file
  49.         **Record byte 29
  50.  
  51.         Next (final) byte in each record tells the end-of-file sector
  52.         **Record byte 30
  53.          -see further comments below
  54.  
  55. There are forty such records.  Any record without a file is completely filled
  56. with CHR$(0) and can be reasonably called empty.
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68. SECTR0.TDD                                                            11/15/85
  69. Page 2 
  70.  
  71.  
  72.  
  73. SECTOR ALLOCATION SECTION
  74. *Begins at Sector 0 Byte 1240
  75.  
  76. The next 21 bytes store information about sector allocation.
  77.  
  78. Twenty bytes starting with 1240 report the current allocation of the 80 disk
  79. sectors.  This status is stored as binary information on alternate bits, but
  80. can be read as decimal numbers (bytes) indicating allocation patterns.  Each
  81. byte stores information on 4 sectors; 1240 tells about sectors 0 thru 3, the
  82. next reports 4 thru 7, and so forth.
  83.  
  84. The patterns:
  85.         BINARY       DECIMAL    SECTORS IN USE
  86.         0000 0000       0       none
  87.         0000 0010       2       4th
  88.         0000 1000       8       3rd
  89.         0000 1010      10       3rd & 4th
  90.         0010 0000      32       2nd
  91.         0010 0010      34       2nd & 4th
  92.         0010 1000      40       2nd & 3rd
  93.         0010 1010      42       2nd, 3rd & 4th
  94.         1000 0000     128       1st
  95.         1000 0010     130       1st & 4th
  96.         1000 1000     136       1st & 3rd
  97.         1000 1010     138       1st, 3rd & 4th
  98.         1010 0000     160       1st & 2nd
  99.         1010 0010     162       1st, 2nd & 4th
  100.         1010 1000     168       1st, 2nd & 3rd
  101.         1010 1010     170       all
  102.  
  103. Keep in mind that these are patterns within 4 sector blocks and that sectors
  104. are counted (by the TDD software) from 0.  (Sector 0 is, of course, the disk
  105. directory, and is always allocated.)  To use this information, you have to
  106. keep track of which four sectors you are examining.
  107.  
  108. TDD uses the allocation table when it writes a new file to the disk; it
  109. checks it to see which sectors are in use and always writes to the
  110. lowest-numbered sector(s) available.  When a file is erased, TDD also rewrites
  111. the allocation table.  Note that erasures take more time than might be
  112. expected because the software must needs traipse 'round the disk to check the
  113. sectors being freed up.
  114.  
  115. TDD's internal software assumes the allocation table is correct, and NEVER
  116. corrects it (it only modifies it as noted above).  If somehow the table's been
  117. changed, there's some risk that a file will be overwritten.  Note that this
  118. behavior can also be used to take a disk damaged sector out of circulation.
  119.  
  120. One more byte: Byte number 1260 reports the number of sectors in use on the
  121. disk.  This count does NOT include the directory sector.
  122.  
  123. TDD doesn't care if byte 1260 is correct.  It modifies whatever number it
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135. SECTR0.TDD                                                            11/15/85
  136. Page 3 
  137.  
  138.  
  139. finds here when you add or delete a file, but doesn't check to see if the
  140. number's accurate (or even reasonable).
  141.  
  142.  
  143. That's everything I can tease out of the zero sector.  I suspect there are
  144. things I've overlooked, but there's more information here than I expect we
  145. need to know to effectively use the drive.
  146.  
  147.  
  148. SECTORS 1 TO 79
  149. Only Sector 0 is heavily formatted.  The other 79 sectors are free-form
  150. through byte 1279; bytes 1280 through 1291 are apparently reserved for system
  151. use.  In reality, however, it seems that only byte 1280 actually gets used. 
  152. 1280 stores the next sector number in the file's "chain", so TDD can find the
  153. next portion of the file.  If the sector's never been used, the number stored
  154. at 1280 is zero; if the sector is the last in the file, the number at 1280 is
  155. 255.
  156.  
  157. The remaining 11 bytes in the sector apparently never get used.
  158.  
  159. What happens if the number at 1280 is wrong?  There seem to be three cases: 
  160. If the vector's to the wrong sector, TDD has no way to recognize the problem. 
  161. If the sector's the last in the file, TDD doesn't care and doesn't err (it
  162. just counts bytes until it locates however many the directory tells it to
  163. deliver to the computer).  If it's not the last sector in the file, and the
  164. vector is to a non-existent sector, Powr-DOS reports a drive error (number 59)
  165. and FLOPPY.CO hangs.  (This is the only condition I've discovered where FLOPPY
  166. doesn't gracefully handle problems, by the way).
  167.  
  168. A possible complication is that these vectors are NOT erased when a file is
  169. KILLed -- the sector is removed from the allocation table, but the "next"
  170. sector might be reassigned when another file is added.  This should only be an
  171. issue with file recovery programs, though.
  172.  
  173. TDD IS "INTELLIGENT"
  174. The TDD is what is commonly called an intelligent disk drive.  This means
  175. that TDD contains software (in ROM and RAM) which it uses for such things as
  176. file management, disk head positioning, and other mundane tasks.  This
  177. intelligence is important because it's the TDD, not your computer, which
  178. dictates the structure of the disk directory.
  179.  
  180. The intelligent disk drive arrangement has advantages and disadvantages.  The
  181. main advantage is that the drive's ROM routines don't need to be duplicated in
  182. the computer itself; this makes writing disk driver software mainly a matter
  183. of collecting and organizing the commands the drive's internal software
  184. expects (there are complications, especially in this case, but there's no
  185. reason to go into detail here.)  This is advantageous both because it
  186. simplifies the composition task and because it saves precious memory.
  187.  
  188. There are trade-offs, however.  The most important is that the computer is
  189. pretty much obliged to tolerate the ideosyncracies of the drive's design; for
  190. instance, while M100 and its kindred expect filenames to be 9 characters long
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. SECTR0.TDD                                                            11/15/85
  203. Page 4 
  204.  
  205.  
  206. (including a period), TDD reserves 24 spaces for this purpose.  Near as I can
  207. tell, Tandy's FLOPPY.CO (by default the software standard, here) invariably
  208. used the SIMPLEST compromise.  While the third party DOSses COULD adopt other
  209. solutions, they'd do so at the cost of software compatibility.
  210.  
  211. Such compatibility may or may not be important, by the way.  Powr-DOS sticks
  212. to the standard, but offers facilities (DSKO$) with which individual
  213. programmers might choose to ignore those standards.  This will be a gain only
  214. if software developers decide to utilize the added capabilities possible with
  215. such "non-standard" file formats.  (This comment doubtless also applies to
  216. TS-RANDOM.)
  217.  
  218. ASSORTED NOTES
  219. There's a LOT of wasted space here.  Most of it is due to the provision the
  220. drive's software makes for file names longer than 9 characters.
  221.  
  222. Not all the numbers in the directory are crucial.  I see no evidence, for
  223. instance, that any software checks to see if the directory's accurate about
  224. which sector contains the last piece of the file.  Nor does it particularly
  225. matter if the number reporting sectors-in-use is wrong.  And while I wouldn't
  226. recommend modifying the allocation table, the drive doesn't use it when you
  227. LOAD a file to the computer, or just read the directory.
  228.  
  229. While the "F" at byte 24 in each file record appears to be a simple (and
  230. unnecessary) flag, modifying it results in some peculiar behavior.  Seems that
  231. the drive's software doesn't really care what's there, but it sorts any files
  232. with an "F" there to the beginning of the list for LFILES or for FLOPPY's LIST
  233. function.  Near as I can tell, this doesn't change any other behaviors.  Odd. 
  234. Inexplicable.
  235.  
  236. Acroatix' documentation for Powr-DOS seems to claim that the computer
  237. (probably the file transfer software, actually) recognizes the type of file by
  238. the first character in the extension.  Must be true.  There's certainly no
  239. better information in the directory.
  240.  
  241. There does not seem to be an explicit EOF marker for any file on the
  242. diskette.  This implies that TDD uses the file length information in the
  243. directory to locate the precise end of the file.  Tests suggest the same
  244. thing.
  245.  
  246. My Tandy Utilities disk has CHR$(255) at byte 1280 in Sector 0.  (Note that
  247. this means EOF in any other sector.  Wonder if it means something similar
  248. here.)  No copy I've made of the disk has that.  But the Powr-DOS source disk
  249. has what appears to be a machine language routine beginning at the same
  250. location.  (Naturally: It doesn't copy either.)  No other disk in my
  251. collection has ANYTHING beyond 1260 in that sector.
  252.  
  253. The directory is stored in alpha order and has no intermediate blank entries.
  254. Deleting or adding a file moves everything around.
  255.  
  256. On Renames.  Using FLOPPY to rename a file rearranges the directory.  POKEs
  257. to the same purpose have interesting effects:  It appears that the TDD's
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269. SECTR0.TDD                                                            11/15/85
  270. Page 5 
  271.  
  272.  
  273. built-in software cares what order the directory's in, as it stops reading the
  274. directory when it finds an out-of-order filename.  Software which renames a
  275. file on the disk has to allow for this behavior.
  276.  
  277. The TDD software also cares about the name of a file to 24 digits:  This
  278. means that "other" information (I have file creation/modification dates in
  279. mind) cannot be easily stored in all that empty space.  (Presumably FLOPPY,
  280. P-DOS, et al, tack spaces onto the end of the name to accomodate TDD.)
  281.  
  282. It appears to me that a disk name (or other information) could be safely
  283. stored on the disk from 1261 to 1279 -- and quite likely beyond 1280.
  284.  
  285.  
  286. My program MAPTDD.100 (in DL5) reports all of these numbers.  If you're
  287. interested in more detailed explorations, see Phil Wheeler's TDDMON (a
  288. DANGEROUS program; use with CARE!) and DMPTDD, also in DL5.  Don Ziekel's
  289. SECDOS (same DL), though its printout is similar to MAPTDD, could be more
  290. easily adapted to more general explorations than the mapper.  See, too, Don's
  291. DOSTIP.004.
  292.  
  293. Remember:  PEEKs are safe.  POKEs are risky, but can teach.
  294.  
  295. Don and I are clearly tracing the same paths, and Phil's known to be
  296. interested.  Anyone else chasing this information down?  PLEASE share what you
  297. learn!  Thanks!
  298.  
  299. My heartfelt thanks to Ed Giese for Powr-DOS, DSKO$, and for clues about some
  300. of these things.
  301.  
  302. joel
  303. LSJ-Access TBBS
  304. 517-482-8144
  305. 9 October 86
  306. 12 October 86
  307. 15 November 86
  308.