Scor­pio News

to a directory record containing four 32 byte directory entries, the total required for each checksum vector is (DRM+1)/4 where DRM is one less than the total number of directory entries permitted on the disk. In the case of the QDDS format, the figure is 128/4=32 bytes.

Whenever the directory of a disk is accessed, a checksum is produced and compared with the appropriate value in the checksum vector. If the checksum is different, the BDOS knows that the disk has been changed and will set it R/O under CP/M 1.4 or CP/M 2.2 or log in the new disk under CP/M 3.

Clearly, this directory checking is a waste of time for drives, such as a Winchester hard disk, where the disk cannot be changed. This type of drive is said to have fixed media. Digital Research had the foresight, when designing CP/M 2.2 and CP/M 3, to allow for this type of drive. If no directory checking is required, the checksum vector may be omitted with a resultant saving of spaca in the BIOS.

The Allocation Vector

The last entry in the DPH is the allocation address. This is the address of a table which the DOS uses to keep track of the date blocks on disk. This table is called the allocation vector and it is a bit map of the blocks on the disk such that each individual bit represents one block. Consequently, the state of eight disk data blocks (ie allocated to a file or not) can be shown in one byte of the allocation vector. Block 0 is represented by bit 7 of the first byte in the table, block 1 by bit 6 and so on for each byte in the table. There is an allocation vector for each disk drive in the system and the address of the vector for the logged in drive may be obtained by calling BDOS function 27.

When a drive is logged in for the first tine, the BDOS scans the directory entries on the disk and extracts the numbers of the blocks already allocated to files. For each block used, the BDOS sets the appropriate bit in the allocation vector. Quite simply, when you wish to write to disk, the BDOS searches the allocation vector for a 0 bit. If none are found then the disk is obviously full. If a 0 bit is found then the BDOS may allocate the associated block to the file.

To compute the amount of free space on a disk, it is a simple matter to count the number of zeros in the allocation vector and then multiply by the block size. Programs such as STAT.COM obtain their free space figures in this manner and as you will probably noticed do not access the disk at all when, for example, STAT B: is typed in while currently logged into drive A and assuming that drive B has been accessed since a ^C was last typed.

The BDOS updates the allocation vector during disk write and delete operations so that the amount of free space shown by STAT.COM will always be correct. Having said that, imagine chat we are writing to a disk. The BDOS will set bits in the allocation vector according to which blocks are being allocated. If we return to CP/M by executing a RET instruction so that a warm boot is avoided and, at the same time neglect to close the file, STAT.COM will return an incorrect amount of free space as the allocation vector will not agree with the disk directory entries actually written to the disk. This is because the final directory entry for a file being written to disk isn’t written to the directory track until the file is closed. The only way to reclaim the lost disk space and obtain a correct free space figure is to force a disk reset by typing Control C.

Under CP/M 1.4 and CP/M 2.2, if a disk is changed without performing a warm boot to reset the disk system, the amount of free space indicated by STAT.COM will be inaccurate as the BDOS will have the allocation vector set up for the previous disk. Under CP/M 3, as soon as the BDOS realizes that a disk has been changed, it logs in the new disk and sets up the allocation vector accordingly.