CP/M survey

On 19 Apr 2007 at 3:20, Sridhar Ayengar wrote: Well, CP/M 2.2 have no "open" and "close" function, just read and write--single character for character devices and a single 128 byte block for mass storage. The closest thing to ioctl is the "select unit", "set track" and "set sector" entry points. While BDOS supports open and close functions, it's entirely up to the user to track open files--the BDOS doesn't contain so much as a list of open files. Early MS-DOS operated the same way--using FCBs for file I/O like CP/M. Directories are, of course, flat, though you could qualify entries with a "User area" field that was not considered to be part of the filename. Allocation information is kept with each directory name entry; when a file got large enough, another directory "extent" was allocated. There was a very firm upper limit (implementation defined) on the number of files one could have on a volume. IIRC, the upper limit on disk storage was about 8 MB per volume. One needn't worry about reentrancy, multiple character/block requests or interrupts. Everything's done with a jump vector table; since CP/M is non-multitasking, management of driver data is simple. If you were dealing with disks with sector sizes larger than 128 bytes, some write-behind, read-ahead logic was unavoidable, but even there, the BDOS would help out by signifying if the read was for a directory block or the write was for a newly-allocated block. If you had sufficient RAM to do full track reads and writes, you could often improve the speed of CP/M I/O significantly. Disk volume tracking was done using a simple "checksum" on a installation-defined number of directory entries. If a disk was changed unexpectedly, the BDOS responded by setting its status to Read-Only and displaying an error. Later versions of CP/M supported multi-block I/O and file date and time stamps. Cheers, Chuck