PACK is a program for reorganising CP/M disks. It is most useful for hard disk users who want to improve system performance by speeding access to frequently used files. It ensures that all data belonging to each file is contiguous on the disk. It also allows the user to specify that certain files or groups of files should not be moved, and that other files or groups of files should be moved to the beginning of the disk, where access to them is assumed to be faster (involving less head movement to and from the directory). As with all programs which reorganise a disk or its directory, you should be extremely careful when using PACK. Only run it after you have backed-up all data to a safe place. You should do that regularly anyway, as disasters can always occur, but if your system crashes while PACK is running you will definitely have to restore the disk from backup. As far as I know PACK itself is bug-free (though I offer no guarantee whatsoever), but power failures, hardware glitches or itchy fingers on the RESET button will trash your disk. PACK takes the fast and loose approach to the disk packing task. It first of all plans exactly what it is going to do, recording the plan in an allocation group permutation schedule. It then asks the user for confirmation, and if given it permutes the groups and then updates the directory to reflect the new situation. Until the directory update is complete the disk is in an undefined state and the system had better not crash. The time required obviously depends on how disorganised the disk was and what its data transfer rate is. On my NEC D3126 it takes about 10 minutes to pack a badly fragmented 7MByte partition. The alternative approach to disk packing (taken by Steve Dirickson in his RESTORE utility), is to keep the directory up to date while moving data groups around the disk. This means that the disk will probably be intact if the program is interrupted, but it involves an inordinate number of writes to the directory during the packing process. This slows the whole process down by a large factor, and increases the probability that, if there is a power failure or unscheduled reset, the system will be in the middle of writing a directory sector at the time. My philosophy is that packing is a potentially risky business, and the quicker it is over with the better. Writes to the disk are not checked by re-reading. RESTORE does this (and checks the CRC of the read-back data). If you have flakey disk hardware you should concentrate on fixing it rather than using PACK. If your BIOS caches disk blocks or tracks, read-after-write at the user program level is pointless anyway. Alternatively, put read- after-write logic in your BIOS, so that all programs which write to the disk benefit (and run like treacle). PACK does a lot of writing, but is not fundamentally different from any program which writes to disk; it has to trust that what it has written is successfully recorded. PACK reads and writes the disk (necessarily) via direct BIOS calls. Sector read or write errors reported by the BIOS are treated as follows. During the initial directory scan any read error causes the program to report the error and quit. Read or write errors during the permutation phase cause the program to stop moving groups and try to extricate itself as gracefully as possible. The directory is fixed up to reflect the moves that were accomplished. The group that caused the problem will generally end up allocated twice, so up to two files may be lost. A degree of DU3 wizardry is necessary to recover the disk. PACK reports which group could not be read/written. Use the DU3 M command to find which file the group is allocated to, erase that file, then check with DU3 again to see if the group is still allocated to another file and erase that one too if so. Finally allocate the group by hand or with a suitable utility to a BADSECT file to stop it being used again. The one or two erased files can be restored from backup (you have got a backup, haven't you). Read or write errors during the final directory update are ignored. There is no way to recover if the directory is flakey. The write type is passed to the BIOS in register C using the following strategy: 1st sector of group, C=2 (write unallocated data); remaining sectors, C=0 (write normal); last sector of a directory group, C=1 (write to directory). Note that the first and intermediate writes to directory groups are not declared as directory writes. This eliminates unecessary reading and writing of the directory groups by the BIOS blocking/unblocking logic, and should be quite legitimate. It could be a problem if your BIOS has strange ideas about blocking/deblocking though. In that case you should set the byte at location 010BH in PACK.COM to a non-zero value, which will force PACK to pass C=1 on all directory writes. The memory requirements of PACK in addition to the program itself are 4 bytes per allocation group on the disk (4*DSM) plus space for 2 allocation groups, so 40K of TPA is sufficient to pack a worst case disk (5K program + 4*512 tables + 2*16K group buffers). The memory is allocated before any changes are made to the disk, and if there is not enough PACK says so and quits. The directory is scanned a few times during the planning phase, and as much as will fit is cached in the TPA at that time. Any excess is re-read from the disk on each scan. PACK resets the disk via BDOS function 37 after packing it, so there is no need to run DISKRST after PACK. BDOS will rebuild the allocation vectors the next time the disk is logged-in. PACK refuses to process a disk which the BDOS considers is read-only. PACK is written to run under ZCPR3 with either CP/M 2.2 or ZRDOS 1.7 as the BDOS. It was developed using Echelon's ZAS/ZLINK assembler and linker, and uses library routines from SYSLIB and Z3LIB. Disk and directory sizes under CP/M 2.2 (and ZRDOS 1.7): The contraints on disk and directory size in CP/M 2.2 are as follows. There can be at most 2**16 (65536) logical sectors (@128 bytes) on the disk. The BDOS assumes it can use 16 bit arithmetic when calculating sector numbers, and values in the random record field of the fcb are limited to 16 bits. This gives us the CP/M 2.2 file and disk size limit of 8MBytes. CP/M 3 extends this to 32MBytes by using 2 more bits in sector numbers. There are two separate limits on directory size. The allocation groups reserved for the directory must be representable in the 16 bits available in the disk parameter block (AL0 and AL1 in DRI parlance). This gives a limit of 16 * Group size / 32 entries. But the number of directory entries that can ever be needed is also limited to one per allocation group when the disk is full of minimal size files. The number of files is then given by the total allocation groups less those assigned for the directory. Allocation Max Disk Max Groups Max Number of Directory Entries Group size size per Disk 16 Groups 1 entry per Group 1K 256K 256 (512) 248 2K 8M 4096 1024 (4032) 4K 8M 2048 (2048) 2032 8K 8M 1024 (4096) 1020 16K 8M 512 (8192) 511 Therefore the worst case directory size is 65024 Bytes, on a disk with a group size of 4K containing 2032 small files. Worst case number of groups is 4096 Author: Frank Cringle 22 Ellens Glen Road Edinburgh EH17 7QP Scotland (031) 664 4616