5 November 1989
                SPEEDUP - A Disk Directory Cache
	 (To augment Issue #41 of The Computer Journal)

PURPOSE:  SPEEDUP is a program originally designed to reduce the wear and tear 
on a portable computer equipped with a single floppy disk drive by minimizing 
the requirements to seek to the directory tracks.  This version is expanded to 
accomodate hard drives as well for improved execution of script files and in 
loading ZCPR3 system files.  It is a Resident System Extension (RSX) complying 
with the latest Plu*Perfect definitions, and occupies space in the high end of 
the Transient Program Area under CP/M 2.2, ZRDOS 1.x and ZSDOS.  It may be 
removed by the Plu*Perfect REMOVE.COM routine, or the companion SLOWDOWN.COM 
transient program.


EXECUTION:  SPEEDUP is loaded by entering its name as:

              SPEEDUP

If no arguments follow the name, the first four kilobytes (128 directory 
entries) of the currently logged drive will be loaded into a RAM buffer in the 
resident module.  Another drive may be specified by following the program name 
with an explicit drive designator as:

              SPEEDUP A:

In this case, the first 128 directory entries (or fewer if the specified disk 
is so defined) will be entered into the RAM buffer.

In a similar manner, the size of the buffer may be adjusted from one to eight 
kilobytes (32 to 256 directory entries) by appending a size number immediately 
after the drive separator as:

              SPEEDUP A:8

In this case, the maximum of 256 directory entries would be copied to the RAM 
portion of the module for access.

Built-in Help is available to provide assistance in the standard ZCPR manner by 
calling the program followed by a double-slash as:

              SPEEDUP //

A brief message will provide information on the invocation methods.


OPERATION:  When loaded in one of the above ways, all or a part of the disk 
directory is entered into protected memory within the resident portion of the 
RSX where it functions as a semi-permanent cache.  A DOS request to read one of 
these entries only accesses the RAM copy, and the physical disk does no seek to 
the directory tracks.  Instead, the requested file is located from the cached 
data, and the head positioned immediately to the data area on the disk.  A 
write operation will cause both the RAM and physical disk areas to be updated 
with the necessary operation, so little is gained by using SPEEDUP for 
write-intensive operations.

Perhaps the biggest effect of SPEEDUP may be obtained in loading ZCPR3 system 
files.  SPEEDUP may be called within a STARTUP file by adding lines as:

              SPEEDUP A:8         <== Buffer the boot drive, size arbitrary
              ...                 <== Load the SYS files, etc
              SLOWDOWN            <== ..and remove SPEEDUP

The only precaution in this is to avoid loading a permanent RSX while SPEEDUP 
is active.  Examples of such modules include DateStamper (tm) and BackGrounder 
(tm) from Plu*Perfect Systems.  If either of these are included in your startup 
file, either load them before SPEEDUP or after SLOWDOWN.  Clock driver modules 
for ZSDOS only fall into this catagory if the RSX load method is selected while 
running SETUPZST.

  ***************************************************************************
  * CAUTION: Since the directory is buffered, automatic disk change sensing *
  * may be defeated.  NEVER CHANGE A DISK UNDER SPEEDUP WITHOUT IMMEDIATELY *
  * FOLLOWING IT WITH A WARM BOOT (Control-C).  If you forget this step and *
  * write to the disk, you will copy a portion of the previous disk's dir-  *
  * ectory and the new file to the present disk and probably destroy exist- *
  * ing files!                                                              *
  ***************************************************************************

To remove SPEEDUP, the companion program SLOWDOWN will remove it ONLY IF IT IS 
THE LAST RSX LOADED!  SLOWDOWN is executed by simply entering its name as:

              SLOWDOWN

If SPEEDUP is the lowest RSX in memory, it will be removed without affecting 
any higher RSX modules in memory.  SLOWDOWN will NOT work if other Plu*Perfect 
RSX modules have been loaded after SPEEDUP.  In this case, Plu*Perfect's REMOVE 
utility must be used to remove the lower modules, and SPEEDUP as well.


CONFIGURATION:  Two configuration options exist to tailor SPEEDUP to your
desires or needs.  The file SPEEDUP.CFG contains all the pertinent data for use
with Al Hawley's excellent ZCNFG configuration tool.  Al is the SYSOP of Ladera
Z-Node which may be reached at (213)) 670-9465.  SPEEDUP is written such that
the proper SPEEDUP.CFG file will be located even if SPEEDUP.COM is renamed to
something else.  Begin the configuration sequence by entering:

		ZCNFG SPEEDUP

The first configuration item controls printing of a small reminder message
which is normally printed upon each Warm Boot.  It contains the program name,
the drive whose directory is buffered, and the number of kilobytes so buffered.
The purpose of this message is to remind you of the RSX to avoid the unnerving
experience of loading a large program and encountering the "Out of Memory"
condition.  ZCNFG will toggle this option on and off from the configuration
screen.

The second option should not be needed by most users, and should NEVER be
altered unless you KNOW what you are doing.  It sets the assumed size of the
Console Command Processor for calculations of where to place SPEEDUP in high
memory.  The normal size of the CCP is 0800H bytes, but some custom systems
use a slightly larger size.  Consult your system documentation on this matter.


TECHNICAL:  SPEEDUP is highly optimized for Z80 code and will NOT work on 8080 
or 8085 based systems.  It has been tested on Ampro Little Boards, SB180s and a 
number of S100 systems under the CP/M 2.2-compatible operating systems listed 
previously.  The overhead required is less than 1k for the resident module plus 
the buffer size determined in the invocation.  The RAM is obtained by 
protecting the Console Command Processor, and moving the BDOS vector at 
locations 6 and 7 to reflect the base of the resident module.  TPA reduction 
will therefore be the CCP size (normally 2k), plus 1k for the RSX, plus the one 
to eight k for the buffer.  In the default size, a reduction in TPA of 
approximately 7k will be noticed.  The maximum buffer size of 8k will cause a 
reduction of about 11k in available TPA space.

The cached directory information is updated at each warm boot to accomodate 
changes in disks.  The program flow first calls the BIOS disk select routine 
with a "New Mount" flag set to force updating of BIOS information.  Necessary 
parameters are then read into the RSX and the cache data is loaded.  This data 
may be examined with the ZCPR3 "Peek" command or with a debugger if you are 
curious about how it appears.

Hope you enjoy this tool.  To spread knowledge of the technology used in the
design and construction of SPEEDUP, Issue #40 of "The Computer Journal" details
the LINKPRL tool, and Issue #41 describes the inner workings of SPEEDUP in more
detail.  This library is meant to augment those articles by providing full
source code for Non-Commercial use.  Any comments, bugs etc. should be sent to:

              Harold F. Bower                         "Hal", WA5JAY
              P.O. Box 313
              Ft. Meade, MD  20755