home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / BEEHIVE / UTILITYS / FIRE12.ARC / FIRE12.DOC < prev    next >
Text File  |  1991-08-11  |  8KB  |  195 lines
  1.         'FiRe - File Restoral Utility Program'
  2.  
  3.         FIRE    v12  by George F Reding     08/10/87
  4.  
  5. Utility program to restore disk files to like-new condition, where the
  6. file allocations for each file are in a sequential order rather than
  7. being scattered all over the disk (such as after a file/program has been
  8. modified).  Usable on any CP/M 2.2 or 3.0 system which has a Z80 CPU.
  9. Can be used regardless of TPA memory and/or if the system directory max-
  10. imum capacity is too large.
  11.  
  12. Version 10 clobbered the DE registerd in the XBIOS2 routine which would
  13. make the sectran for CP/M 2.2 to not work properly.
  14.  
  15. ------------------------------------------------------------------------
  16.  
  17. Created from:    RESTORE v12
  18.     by:    Steve Dirickson
  19.         21145 Raintree Place NW
  20.         Poulsbo, WA  98370-9726
  21. Other credits:
  22.         CPM22E by Mike Griswold
  23.         SYSLIB by Richard Conn
  24.  
  25. ------------------------------------------------------------------------
  26.                 CONFIGURATION
  27.  
  28. There's very little (if any) configuration required in order to use this
  29. program. The following bytes may be changed with DDT, SID, or SZAP:
  30.  
  31.    103    byte    Disk change wait.
  32.            set non-zero for no waiting.
  33.    104    byte    File relocation linefeed character.
  34.            set 0Ah for scrolling of file names,
  35.            0 for no scrolling (updates 1 line),
  36.            as each file is worked on.
  37.    105    word    For CP/M 3.0 only.
  38.            value of your largest sector size.
  39.            (Morrow hard-disk systems is 1024)
  40.  
  41. ------------------------------------------------------------------------
  42.              NOTES FROM THE SOURCE CODE
  43.  
  44. DPB offset and table lengths for CP/M 2.2 are different from those for
  45. CP/M 3.3.  They are now automatically set by the program, and the BIOS
  46. access is performed differently, eliminating the need to copy BIOS vec-
  47. tors into the program.    Much 8080 code is changed to Z80 which conserves
  48. memory space and increases the speed of the program.  You may use the
  49. program even if available (TPA) memory falls short of the capability to
  50. handle your system maximum directory entry capacity (BSH, BLM, DRM, and
  51. AL0 and AL1 values are all factors).  Either your TPA may be too low, or
  52. your system directory capacity (DRM) is too large (eg., 2048 or more?
  53. maximum entries capacity).  If the situation does arise, a message is
  54. given of the MAXIMUM ACTIVE entries that you may have to be able to con-
  55. tinue, and you may abort if you desire not to continue.  The user should
  56. ensure that there are LESS active directory entries by using DU, after
  57. using SAP. >>
  58.  
  59.      WARNING <<  To CONTINUE with MORE entries ACTIVE than
  60.      the figure shown WILL TRASH both files and directory.
  61.      Because of the memory limitation and differences among
  62.      among systems, no warranties are expressed or implied
  63.      and a user of this program shall assume any and all re-
  64.      sponsibility for results arising from usage of the program.
  65.  
  66.  
  67. adjust maximum directory number (DRM) to a smaller/fake value for cases
  68. where the directory has a capacity to hold 2048 (or more??) entries, or
  69. in cases where the tpa may fall short of of capability to handle all of
  70. the directory entries.    Adjust the directory group count (AL0 and AL1)
  71. which varies with BLM (block size BLS) so that it matches with the smal-
  72. ler/fake DRM value.  In order to use the program in such cases of too
  73. many directory entries and/or of too little tpa space the TOTAL of
  74. ACTIVE directory entries will have to be verified by the user with "DU"
  75. or some equivilent program (after using "CLEANDIR", "SAP", "SAPP", etc).
  76. A warning message and the maximum number of active entries that the pro-
  77. gram can handle is given, with opportunity for the user to abort. Faking
  78. of the DRM value is similar to that which "SAPP" (for CP/M 3.0) is capa-
  79. ble of (an assembly time option).  The way I have implemented it here is
  80. an improvement though and "SAPP" will subsequently be updated to imple-
  81. ment this means of "auto-faking".
  82. ;
  83. ;
  84.     CALL    DOCOLL        ; Get group count and 1st group
  85.                 ;   don't save real group count
  86.     LD    A,(NEWGRP)    ; Get our fake group count
  87.     LD    (DIRGRP),A    ; Save fake number of groups instead
  88.     JR    FAKGRP        ; Save real start/search group
  89. ;
  90. ; If enough memory, set up variables (see above about faking)
  91. ;
  92. CKDRBF: CALL    DOCOLL        ; Get group count and 1st group
  93.     LD    (DIRGRP),A    ; Save number of groups in directory
  94. ;
  95. FAKGRP: LD    (STRTGP),HL    ; Starting group in case faked
  96.     LD    (SRCHGP),HL    ; Save 1st group after directory
  97. ;
  98.  
  99. ------------------------------------------------------------------------
  100.                  CP/M 3 TEST
  101.  
  102. CP/M 3.0 tests made on a Morrow MD-11 with two 20 Mb CMI hard disk
  103. drives, formatted capacity is 22,004k each, block size of 4k, and a
  104. maximum capacity of 2048 directory entries.  In my test, 2,488k of
  105. files were present on the test hard drive.
  106.  
  107. In performing the test I newly formatted one hard drive then randomly
  108. PIP'ed some files to it eg., *.MAC, *.BIN, *.TXT, *.ASM.. etc., which
  109. didn't make things totally scrambled, but it was a start.  Then, I ran-
  110. domly PIP'ed some more files to another user area.  But that still was
  111. not random enough for my test.
  112.  
  113. Then I edited a few of those files in conjustion, along with erasing,
  114. etc.  That broke things up just enough for the test to soon begin.
  115.  
  116. I used SAPP (for CP/M 3.0) as the directory MUST BE sorted with any un-
  117. used or erased entries set to 0E5H's.  Then used DU to list the active
  118. directory entries to my printer to see where the allocations for each
  119. file were now at, before use of this program.
  120.  
  121. Then came the big test with the program.
  122.  
  123. The Morrow can have up to 2048 maximum directory entries, so I was given
  124. the warning message and shown the maximum number of active entries that
  125. I could have (1536 for my system).
  126.  
  127. I already knew that I had MUCH less than that amount active, so I con-
  128. tinued.  In a moment, I was given the statistics of the drive which was
  129. displayed as follows:
  130.  
  131.     Statistics
  132.  
  133.         Active dir  entries: 94
  134.         Tot grps  allocated: 372
  135.         Group swaps  needed: 156
  136.         Group reads  needed: 312
  137.         Group writes needed: 312
  138.         Dir rewrites needed: 61
  139.  
  140.     Press 'Y' to continue, else aborts:
  141.  
  142. And I chose to continue at the prompt, after those stats.
  143.  
  144. The program was roughly halfway through listing the files as it works on
  145. each one takes a bit of time when it just zipped through the remaining
  146. file names and said completed.    I then used DU to inspect and everything
  147. is fine. CRC check of the those files that were just relocated compared
  148. to the CRC of their originals resulted in an exact match.
  149.  
  150. Final test was made on the other hard disk drive where there were 5,824k
  151. of files present.  The statistics were:
  152.  
  153.     Statistics
  154.  
  155.         Active directory  entries: 427
  156.         Total  groups    allocated: 1456
  157.         Group     swaps       needed: 1449
  158.         Group     reads       needed: 2889
  159.         Group     writes    needed: 2889
  160.         Directory rewrites needed: 424
  161.  
  162. The final test took approximately 3.5 hours for the program to complete
  163. its task.  Most definitely the program does take quite a bit of time to
  164. do its work, but in comparison to the act of copying files to floppy or
  165. other drive, then erasing or reformatting the source drive, and copying
  166. the files back to the source drive, this program is a labor saving de-
  167. vice.
  168.  
  169. Result:  TEST SUCCESSFUL FOR CP/M 3.0.
  170.  
  171. ------------------------------------------------------------------------
  172.                  FINAL NOTES
  173.  
  174. Definitely the wear and tear that this program may save on a drive will
  175. justify its periodic usage.
  176.  
  177. Much of the original source code is still intact, although I did change
  178. labels to a limit of 6 characters and removed the 8080 code which was in
  179. the program for conditional assembly.
  180.  
  181. Plus some minor changes were made, replacing some 8080 code with Z80 eg.,
  182. usage of direct load of DE, etc), addition of my own code for compati-
  183. bility with CP/M 3.0 utilizing routines from CPM22E, and accomodation
  184. for low TPA systems and/or any systems with too large of a directory
  185. entry capability.
  186.  
  187. The author of RESTORE from which this program has developed, should have
  188. a field day figuring out where all of the mods have been made.    Much
  189. credit should be given to him, for his work.  Thanks much to Steve Dir-
  190. ickson.
  191.  
  192. ------------------------------------------------------------------------
  193.  
  194.                     - George Reding
  195.