home *** CD-ROM | disk | FTP | other *** search
- 'FiRe - File Restoral Utility Program'
-
- FIRE v12 by George F Reding 08/10/87
-
- Utility program to restore disk files to like-new condition, where the
- file allocations for each file are in a sequential order rather than
- being scattered all over the disk (such as after a file/program has been
- modified). Usable on any CP/M 2.2 or 3.0 system which has a Z80 CPU.
- Can be used regardless of TPA memory and/or if the system directory max-
- imum capacity is too large.
-
- Version 10 clobbered the DE registerd in the XBIOS2 routine which would
- make the sectran for CP/M 2.2 to not work properly.
-
- ------------------------------------------------------------------------
-
- Created from: RESTORE v12
- by: Steve Dirickson
- 21145 Raintree Place NW
- Poulsbo, WA 98370-9726
- Other credits:
- CPM22E by Mike Griswold
- SYSLIB by Richard Conn
-
- ------------------------------------------------------------------------
- CONFIGURATION
-
- There's very little (if any) configuration required in order to use this
- program. The following bytes may be changed with DDT, SID, or SZAP:
-
- 103 byte Disk change wait.
- set non-zero for no waiting.
- 104 byte File relocation linefeed character.
- set 0Ah for scrolling of file names,
- 0 for no scrolling (updates 1 line),
- as each file is worked on.
- 105 word For CP/M 3.0 only.
- value of your largest sector size.
- (Morrow hard-disk systems is 1024)
-
- ------------------------------------------------------------------------
- NOTES FROM THE SOURCE CODE
-
- DPB offset and table lengths for CP/M 2.2 are different from those for
- CP/M 3.3. They are now automatically set by the program, and the BIOS
- access is performed differently, eliminating the need to copy BIOS vec-
- tors into the program. Much 8080 code is changed to Z80 which conserves
- memory space and increases the speed of the program. You may use the
- program even if available (TPA) memory falls short of the capability to
- handle your system maximum directory entry capacity (BSH, BLM, DRM, and
- AL0 and AL1 values are all factors). Either your TPA may be too low, or
- your system directory capacity (DRM) is too large (eg., 2048 or more?
- maximum entries capacity). If the situation does arise, a message is
- given of the MAXIMUM ACTIVE entries that you may have to be able to con-
- tinue, and you may abort if you desire not to continue. The user should
- ensure that there are LESS active directory entries by using DU, after
- using SAP. >>
-
- WARNING << To CONTINUE with MORE entries ACTIVE than
- the figure shown WILL TRASH both files and directory.
- Because of the memory limitation and differences among
- among systems, no warranties are expressed or implied
- and a user of this program shall assume any and all re-
- sponsibility for results arising from usage of the program.
-
-
- adjust maximum directory number (DRM) to a smaller/fake value for cases
- where the directory has a capacity to hold 2048 (or more??) entries, or
- in cases where the tpa may fall short of of capability to handle all of
- the directory entries. Adjust the directory group count (AL0 and AL1)
- which varies with BLM (block size BLS) so that it matches with the smal-
- ler/fake DRM value. In order to use the program in such cases of too
- many directory entries and/or of too little tpa space the TOTAL of
- ACTIVE directory entries will have to be verified by the user with "DU"
- or some equivilent program (after using "CLEANDIR", "SAP", "SAPP", etc).
- A warning message and the maximum number of active entries that the pro-
- gram can handle is given, with opportunity for the user to abort. Faking
- of the DRM value is similar to that which "SAPP" (for CP/M 3.0) is capa-
- ble of (an assembly time option). The way I have implemented it here is
- an improvement though and "SAPP" will subsequently be updated to imple-
- ment this means of "auto-faking".
- ;
- ;
- CALL DOCOLL ; Get group count and 1st group
- ; don't save real group count
- LD A,(NEWGRP) ; Get our fake group count
- LD (DIRGRP),A ; Save fake number of groups instead
- JR FAKGRP ; Save real start/search group
- ;
- ; If enough memory, set up variables (see above about faking)
- ;
- CKDRBF: CALL DOCOLL ; Get group count and 1st group
- LD (DIRGRP),A ; Save number of groups in directory
- ;
- FAKGRP: LD (STRTGP),HL ; Starting group in case faked
- LD (SRCHGP),HL ; Save 1st group after directory
- ;
-
- ------------------------------------------------------------------------
- CP/M 3 TEST
-
- CP/M 3.0 tests made on a Morrow MD-11 with two 20 Mb CMI hard disk
- drives, formatted capacity is 22,004k each, block size of 4k, and a
- maximum capacity of 2048 directory entries. In my test, 2,488k of
- files were present on the test hard drive.
-
- In performing the test I newly formatted one hard drive then randomly
- PIP'ed some files to it eg., *.MAC, *.BIN, *.TXT, *.ASM.. etc., which
- didn't make things totally scrambled, but it was a start. Then, I ran-
- domly PIP'ed some more files to another user area. But that still was
- not random enough for my test.
-
- Then I edited a few of those files in conjustion, along with erasing,
- etc. That broke things up just enough for the test to soon begin.
-
- I used SAPP (for CP/M 3.0) as the directory MUST BE sorted with any un-
- used or erased entries set to 0E5H's. Then used DU to list the active
- directory entries to my printer to see where the allocations for each
- file were now at, before use of this program.
-
- Then came the big test with the program.
-
- The Morrow can have up to 2048 maximum directory entries, so I was given
- the warning message and shown the maximum number of active entries that
- I could have (1536 for my system).
-
- I already knew that I had MUCH less than that amount active, so I con-
- tinued. In a moment, I was given the statistics of the drive which was
- displayed as follows:
-
- Statistics
-
- Active dir entries: 94
- Tot grps allocated: 372
- Group swaps needed: 156
- Group reads needed: 312
- Group writes needed: 312
- Dir rewrites needed: 61
-
- Press 'Y' to continue, else aborts:
-
- And I chose to continue at the prompt, after those stats.
-
- The program was roughly halfway through listing the files as it works on
- each one takes a bit of time when it just zipped through the remaining
- file names and said completed. I then used DU to inspect and everything
- is fine. CRC check of the those files that were just relocated compared
- to the CRC of their originals resulted in an exact match.
-
- Final test was made on the other hard disk drive where there were 5,824k
- of files present. The statistics were:
-
- Statistics
-
- Active directory entries: 427
- Total groups allocated: 1456
- Group swaps needed: 1449
- Group reads needed: 2889
- Group writes needed: 2889
- Directory rewrites needed: 424
-
- The final test took approximately 3.5 hours for the program to complete
- its task. Most definitely the program does take quite a bit of time to
- do its work, but in comparison to the act of copying files to floppy or
- other drive, then erasing or reformatting the source drive, and copying
- the files back to the source drive, this program is a labor saving de-
- vice.
-
- Result: TEST SUCCESSFUL FOR CP/M 3.0.
-
- ------------------------------------------------------------------------
- FINAL NOTES
-
- Definitely the wear and tear that this program may save on a drive will
- justify its periodic usage.
-
- Much of the original source code is still intact, although I did change
- labels to a limit of 6 characters and removed the 8080 code which was in
- the program for conditional assembly.
-
- Plus some minor changes were made, replacing some 8080 code with Z80 eg.,
- usage of direct load of DE, etc), addition of my own code for compati-
- bility with CP/M 3.0 utilizing routines from CPM22E, and accomodation
- for low TPA systems and/or any systems with too large of a directory
- entry capability.
-
- The author of RESTORE from which this program has developed, should have
- a field day figuring out where all of the mods have been made. Much
- credit should be given to him, for his work. Thanks much to Steve Dir-
- ickson.
-
- ------------------------------------------------------------------------
-
- - George Reding