19 Apr
2007
19 Apr
'07
1:07 p.m.
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:
Yes.
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. 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