Scor­pio News

A quick tap on the calculator keyboard will have told you that, assuming say, a 2K block size and 8 bit directory entries will allow a maximum of 32K to be referenced by a directory entry. This implies (correctly) that more than one directory entry will be required to hold the block numbers for larger files. CP/M automatically takes care of this problem for us. When writing to disk, if a directory entry is filled, CP/M closes it (by writing it to disk) and opens a new one. It should be noted that each time CP/M has read or written all of the blocks allocated by a single directory entry, it has to read the next entry from, or write the next entry to disk. Logically, it would appear that to improve the performance of the disk system (i.e. speed up access), the block size should be as large as possible so that CP/M would need to access the directory track of the disk less often (since extra time is needed to move the disk drive head from where it is now to the directory track and back again). It would also appear that with a 16K block size and 8 bit directory entries, CP/M would only have to access the directory track once for every 256K of a file that it is reading or writing. However, maybe due to a hangover from CP/M 1.4 (which always held 16Ks worth of block information per directory entry), CP/M 2.2 and CP/M Plus STILL access the directory track every 16K.

If we return briefly to the number of blocks reserved for directory entries, we can see that we must have enough to allow access to the available disk space. With the Gemini QDDS format, each directory entra can refer to 64K since 8 bit entries are used with a 4k block size. The minimum number of directory entries required to access the 196 data blocks on disk will be 13. However, if we were to take the average sized file to be about 8K then to fill a disk with them we shall need at least 98 directory entries. In practice, Gemini chose 128 directory entries which, while entirely adequate for most purposes, try filling a disk with 4K files or programs. When all 128 directory entries have been used, there is still 272K of free space remaining. To be fair, this is an extreme example and will occur very rarely (unless you use dbaseII, in which case it will probably occur daily as the average dbaseII .CMD file seems to fit in a 4K block).

The choices, then, facing a manufacturer when deciding upon block sizes are a compromise of disk size, number of directory entries and speed of access. If Gemini had used a smaller block size for their QDDS format (2K for example), CP/M 2.2 (or CP/M 3) would have used 16 bit entries in the directory. Consequently, four times as many directory entries would have been required. Why four? Each directory entry would refer to 2 blocks – hence twice as many directory entries would be required to hold the block numbers for the same sized file BUT each block number would now occupy twice as much room in the directory entry so double the number of directory entries again. Similarly, the BDOS would have to access the directory track four times as often with a corresponding reduction in disk performance.

A further complication that prevents the use of a 1K block size with larger disks is due to the way CP/M itself works. Let’s have a quick history lesson.

CP/M 1.4 uses single density disks (although some micro manufacturers have made it work with double density) with a fixed 1k block size and 8 bit directory entries. Each directory entry, therefore. refers to 16K (which we all recognise as an extent). CP/M 1.4 allows a file/​disk to contain a maximum of 16 extents numbered 0-15, hence a maximum file/​disk size of 256K (16 x 16K). A hangover from CP/M 1.4 is that each directory entry MUST be able to control at least one extent. If we are using 16 bit directory entries, each block must be at least 2K long since the directory can only hold 8 block numbers. This applies equally to CP/M 2.2 and CP/M 3.

We have already seen that the directory occupies at least one block in the data area of the disk. Under CP/M, the directory blocks are always the first ones in the data area and it follows that block 0 will always contain directory information. This being the case, at no time will CP/M ever need to allocate block 0 to a file. For these reasons, zeros in the directory entry may be used to signify that no further blocks have been allocated to a file.