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 / SPEEDUP.ARC / SPEEDUP.DOC < prev   
Text File  |  1991-07-16  |  8KB  |  142 lines
  1.                                                       10 March 1989
  2.                 SPEEDUP - A Disk Directory Cache
  3.  
  4. PURPOSE:  SPEEDUP is a program originally designed to reduce the wear and tear 
  5. on a portable computer equipped with a single floppy disk drive by minimizing 
  6. the requirements to seek to the directory tracks.  This version is expanded to 
  7. accomodate hard drives as well for improved execution of script files and in 
  8. loading ZCPR3 system files.  It is a Resident System Extension (RSX) complying 
  9. with the latest Plu*Perfect definitions, and occupies space in the high end of 
  10. the Transient Program Area under CP/M 2.2, ZRDOS 1.x and ZSDOS.  It may be 
  11. removed by the Plu*Perfect REMOVE.COM routine, or the companion SLOWDOWN.COM 
  12. transient program.
  13.  
  14.  
  15. EXECUTION:  SPEEDUP is loaded by entering its name as:
  16.  
  17.               SPEEDUP
  18.  
  19. If no arguments follow the name, the first four kilobytes (128 directory 
  20. entries) of the currently logged drive will be loaded into a RAM buffer in the 
  21. resident module.  Another drive may be specified by following the program name 
  22. with an explicit drive designator as:
  23.  
  24.               SPEEDUP A:
  25.  
  26. In this case, the first 128 directory entries (or fewer if the specified disk 
  27. is so defined) will be entered into the RAM buffer.
  28.  
  29. In a similar manner, the size of the buffer may be adjusted from one to eight 
  30. kilobytes (32 to 256 directory entries) by appending a size number immediately 
  31. after the drive separator as:
  32.  
  33.               SPEEDUP A:8
  34.  
  35. In this case, the maximum of 256 directory entries would be copied to the RAM 
  36. portion of the module for access.
  37.  
  38. Built-in Help is available to provide assistance in the standard ZCPR manner by 
  39. calling the program followed by a double-slash as:
  40.  
  41.               SPEEDUP //
  42.  
  43. A brief message will provide information on the invocation methods.
  44.  
  45.  
  46. OPERATION:  When loaded in one of the above ways, all or a part of the disk 
  47. directory is entered into protected memory within the resident portion of the 
  48. RSX where it functions as a semi-permanent cache.  A DOS request to read one of 
  49. these entries only accesses the RAM copy, and the physical disk does no seek to 
  50. the directory tracks.  Instead, the requested file is located from the cached 
  51. data, and the head positioned immediately to the data area on the disk.  A 
  52. write operation will cause both the RAM and physical disk areas to be updated 
  53. with the necessary operation, so little is gained by using SPEEDUP for 
  54. write-intensive operations.
  55.  
  56. Perhaps the biggest effect of SPEEDUP may be obtained in loading ZCPR3 system 
  57. files.  SPEEDUP may be called within a STARTUP file by adding lines as:
  58.  
  59.               SPEEDUP A:8         <== Buffer the boot drive, size arbitrary
  60.               ...                 <== Load the SYS files, etc
  61.               SLOWDOWN            <== ..and remove SPEEDUP
  62.  
  63. The only precaution in this is to avoid loading a permanent RSX while SPEEDUP 
  64. is active.  Examples of such modules include DateStamper (tm) and BackGrounder 
  65. (tm) from Plu*Perfect Systems.  If either of these are included in your startup 
  66. file, either load them before SPEEDUP or after SLOWDOWN.  Clock driver modules 
  67. for ZSDOS only fall into this catagory if the RSX load method is selected while 
  68. running SETUPZST.
  69.  
  70.   ***************************************************************************
  71.   * CAUTION: Since the directory is buffered, automatic disk change sensing *
  72.   * may be defeated.  NEVER CHANGE A DISK UNDER SPEEDUP WITHOUT IMMEDIATELY *
  73.   * FOLLOWING IT WITH A WARM BOOT (Control-C).  If you forget this step and *
  74.   * write to the disk, you will copy a portion of the previous disk's dir-  *
  75.   * ectory and the new file to the present disk and probably destroy exist- *
  76.   * ing files!                                                              *
  77.   ***************************************************************************
  78.  
  79. To remove SPEEDUP, the companion program SLOWDOWN will remove it ONLY IF IT IS 
  80. THE LAST RSX LOADED!  SLOWDOWN is executed by simply entering its name as:
  81.  
  82.               SLOWDOWN
  83.  
  84. If SPEEDUP is the lowest RSX in memory, it will be removed without affecting 
  85. any higher RSX modules in memory.  SLOWDOWN will NOT work if other Plu*Perfect 
  86. RSX modules have been loaded after SPEEDUP.  In this case, Plu*Perfect's REMOVE 
  87. utility must be used to remove the lower modules, and SPEEDUP as well.
  88.  
  89.  
  90. CONFIGURATION:  Two configuration options exist to tailor SPEEDUP to your
  91. desires or needs.  The file SPEEDUP.CFG contains all the pertinent data for use
  92. with Al Hawley's excellent ZCNFG configuration tool.  Al is the SYSOP of Ladera
  93. Z-Node which may be reached at (213)) 670-9465.  SPEEDUP is written such that
  94. the proper SPEEDUP.CFG file will be located even if SPEEDUP.COM is renamed to
  95. something else.  Begin the configuration sequence by entering:
  96.  
  97.         ZCNFG SPEEDUP
  98.  
  99. The first configuration item controls printing of a small reminder message
  100. which is normally printed upon each Warm Boot.  It contains the program name,
  101. the drive whose directory is buffered, and the number of kilobytes so buffered.
  102. The purpose of this message is to remind you of the RSX to avoid the unnerving
  103. experience of loading a large program and encountering the "Out of Memory"
  104. condition.  ZCNFG will toggle this option on and off from the configuration
  105. screen.
  106.  
  107. The second option should not be needed by most users, and should NEVER be
  108. altered unless you KNOW what you are doing.  It sets the assumed size of the
  109. Console Command Processor for calculations of where to place SPEEDUP in high
  110. memory.  The normal size of the CCP is 0800H bytes, but some custom systems
  111. use a slightly larger size.  Consult your system documentation on this matter.
  112.  
  113.  
  114. TECHNICAL:  SPEEDUP is highly optimized for Z80 code and will NOT work on 8080 
  115. or 8085 based systems.  It has been tested on Ampro Little Boards, SB180s and a 
  116. number of S100 systems under the CP/M 2.2-compatible operating systems listed 
  117. previously.  The overhead required is less than 1k for the resident module plus 
  118. the buffer size determined in the invocation.  The RAM is obtained by 
  119. protecting the Console Command Processor, and moving the BDOS vector at 
  120. locations 6 and 7 to reflect the base of the resident module.  TPA reduction 
  121. will therefore be the CCP size (normally 2k), plus 1k for the RSX, plus the one 
  122. to eight k for the buffer.  In the default size, a reduction in TPA of 
  123. approximately 7k will be noticed.  The maximum buffer size of 8k will cause a 
  124. reduction of about 11k in available TPA space.
  125.  
  126. The cached directory information is updated at each warm boot to accomodate 
  127. changes in disks.  The program flow first calls the BIOS disk select routine 
  128. with a "New Mount" flag set to force updating of BIOS information.  Necessary 
  129. parameters are then read into the RSX and the cache data is loaded.  This data 
  130. may be examined with the ZCPR3 "Peek" command or with a debugger if you are 
  131. curious about how it appears.
  132.  
  133. Hope you enjoy this tool.  To spread knowledge of the technology used in the
  134. design and construction of SPEEDUP, I am preparing an article for a future
  135. issue of The Computer Journal (TCJ).  The article will contain source code for
  136. the PRL linker used to build RSXes such as SPEEDUP, and the source code for all
  137. of SPEEDUP and its loader.  Any comments, bugs etc. should be sent to:
  138.  
  139.               Harold F. Bower                         "Hal", WA5JAY
  140.               P.O. Box 313
  141.               Ft. Meade, MD  20755
  142.