home *** CD-ROM | disk | FTP | other *** search
- ;
- SPEEDUP.COM
-
- Size (recs) CRC Version Author/Latest Issue Disk
- SPEEDUP.COM 3k (20) 8768 1.1 Hal Bower 8/89 Z3COM11
- SLOWDOWN.COM 1k (5) BC1B 1.1 Hal Bower 8/89 Z3COM11
-
- 1- Syntax 2- Operation 3- Configuration 4- Notes 5- Examples of Use
-
- 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.
- :1
-
- Syntax SPEEDUP [d:][s]
-
- Options d: - Drive letter followed by colon
- s - Size of Cache in K (1-8)
-
- Defaults Drive is currently logged
- Size is 4K (128 entries)
-
- 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. If a drive is specified, the first 128 directory entries (or
- fewer if the specified disk is so defined) will be entered. 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 (from 1k, 32 directory entries, to 8k, 256 entries).
- :2
-
- Operation - 1/2
-
- When loaded, 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.
-
- 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.
- Operation - 2/2
-
-
- ***************************************************************************
- * 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.
- :3
- 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.
-
- 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.
- :4
- SPEEDUP Notes - 1/2
-
- a. 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.
- SPEEDUP Notes - 2/2
-
- b. 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.
- :5
- Examples of Use
-
- a. 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
-
- b. SPEEDUP <-- Cache 4K of current drive
-
- c. SPEEDUP 6 <-- Cache 6K of current drive
-
- d. SPEEDUP D: <-- Cache 4K of drive D:
-
- e. SPEEDUP C:8 <-- Cache 8K of drive C: