CP/M survey

[Allison]

>
>Subject: Re: CP/M survey
>   From: "Chuck Guzis" <cclist at sydex.com>
>   Date: Thu, 19 Apr 2007 08:48:40 -0700
>     To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 19 Apr 2007 at 3:20, Sridhar Ayengar wrote:
>
>> How does it differ?  Aren't all drivers just fundamentally open, close, 
>> read, write and ioctl?
>
>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.  

Yes.

>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.   

While the OS didn't do that it was easy to have your own FCB(s) and 
the OS would not limit you. 

CP/M was a big step up from OSs like NSdos that only did sequential 
allocation and even more limited user interface.

>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.

The limit is for CP/M2 were 65535addressable sectors * 128bytes =8mb
it would be higher if the math didn't truncate at 16bits.  The improved 
BDOSs (P2DOS and friends) fixed the math and it was then:

65535 * allocation block size (up to 32k) =2gb

CPM3 and MPM allowed for 512byte sectors and 32mb max logical drive size.

>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.

CP/M2 is non multitasking, V3 and MPM which are related (same filesystem 
and bdos calls) it can be an issue. However, the non-multitask status 
of CP/MV2 didn't prevent things like background printing or interrupt 
driven IO though it meant the BIOS implmentor had to do the work.

One nasty with a flat file system and allocation scheme is with an 8mb 
drive and directory sized for say 2048 entries a directory search on a 
moderately full disk was SLOW.  It was a sequential search.

>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.

IDE helps as it has on drive buffering/cache and a few floppy and 
harddisk controllers were buffered and did deblocking in hardware.
One floppy controler that could do this was the JADE DoubleD.

Other oddities is there was no MBR or on disk partition tables for 
large drives. The partition info was kept in the DPH/DPB inside the BIOS.


>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. 

Only required for floppy or the uncommon removable harddisk 
(CDC hawk anyone).

>Later versions of CP/M supported multi-block I/O and file date and 
>time stamps.

They did significantly advancement CP/M as it allowed existing 
program base to live on.


Allison