Scor­pio News

ALV is similar to that for CP/M 2.2 in that the BDOS uses the allocation vector to identify which data blocks have been allocated to files and which are free for use. CP/M’3, however, uses two bits in the allocation vector for each block on the disk. The only exception to this is in a non-banked CP/M 3 where the option is given to use single bit entries as with CP/M 2.2. Since there should be no non-banked CP/M 39 sold commercially (the non-banked version of CP/M 3 is merely an aid in the generation of a banked system), all users of CP/M 3 can assume that their system uses double bit entries in the allocation vector.

Obviously, a double bit allocation vector is going to occupy twice as much memory as a single bit allocation vector so why then use two bits per entry? Remember how STAT.COM calculates free disk space under CP/M 2.2 and how it is possible to fool it by forgetting to close a file. The only way to update the allocation vector under CP/M 2.2 is to hit ^C to reset the disk system and log in the drives again. This of course takes time and CP/M 3 boasts better disk performance. Digital Research have gone to great lengths to avoid resetting the disk system with each warm boot – particularly since CP/M 3 has also spent time buffering both directory and data blocks to reduce disk accesses still further. Control C is still available under CP/M 3, when running the CCP, to allow the user to force a disk reset but, to improve performance, this should be done as little as possible.

To eliminate the need for disk resets on warm boot, Digital Research came up with the double bit allocation vector. If, as before, a file is written to disk, the BDOS will keep track of which data blocks it is allocating by using one of the two bit in the allocation vector for each of those blocks. When a file is closed, the second set of bits for the affected blocks are updated to match the first. If, on the other hand, the file is not closed before returning to CP/M the first set of bits can be reset to their original state because the second set provide a record of which blocks remain free. Consequently, the disk free apace shown by SHOW.COM (CP/M 3’s equivalent to STAT.COM) is always correct and the need for a disk access has been alleviated. Unlike CP/M.2.2, the size of the allocation vector for CP/M 3 is calculated as (DSM/4)+2. The “2” gives us the clue that the double bit allocation vector is in fact configured as two single bit allocation vectors joined end to end.

MF is referred to as the media flag. This byte is set to zero by the BDOS when a drive is logged in. If the disk/​computer hardware supports “door open” interrupts, the BIOS can set this byte to 0FFH when a drive door is opened. If this is the case, before the BDOS next performs a file operation on the affected drive, it will check for a disk change and perform a login if necessary.

NOTE. The Media Flag is used in conjunction with the variable @MEDIA contained in the CP/M 3 System Control Block and will normally only be implemented on systems supporting “door open” interrupt.

DIRBCB is the address of the directory buffer control block on non-banked CP/M 3 systems. On banked systems, DIRBCB points to the head of a list of buffer control blocks (BCB’s). The list head is a 16 bit address which points to the first BCB in the list. The first and subsequent BCB’s contain a 16 bit address field which points to the next BCB in the list while the last BCB contains a zero value in this field. This type of list is, for obvious reasons, known as a linked list. A comprehensive description of the BCB format is given later so, all I shall say at this point is that each BCB contains the address of a directory buffer which will be one physical sector in length (sound familiar to CP/M 2.2 users?). The maximum number of directory buffers required will be (DRM+1}*32/​Physical sector size. For the Gemini QDDS format, this figure will be 8 per drive. Different drives may share directory buffers under CP/M 3 and consequently one or more drive XDPH’e may refer to the same BCB list.

DTABCB is the address of the data buffer control block on non-banked CP/M 3 systems or a list head on banked systems. THE BCB format is identical to that for directory BCB’s except that each BCB points to a data buffer which will be one physical sector in length. CP/M 3 usys the physical record buffers for blocking and deblocking the physical sector into 128 byte CP/M records and