19 Apr
2007
19 Apr
'07
6: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
19 Apr
19 Apr
11:30 p.m.
On 19 Apr 2007 at 13:07, Allison wrote:
> While the OS didn't do that it was easy to
have your own FCB(s)
and
the OS would not limit you.
...unless you were porting to MP/M, in which case too-ambitious
manipulation of FCBs could come back and bite you, since MP/M did
track file opens
CP/M was a big step up from OSs like NSdos that only
did sequential
allocation and even more limited user interface.
Sequential or consecutive? Consecutive allocation was not a bad
thing, provided that it allowed for expansion of a file by adding
additional extents. Indeed, it could be much faster than simple
granular allocation when seek time is an issue. I've worked on a
couple of mainframe allocation systems that used consecutive-with-
extension allocation with no particular problems. I routinely run
into them in conversion (e.g. IBM DIsplaywriter). A Smith-Corona
typewriter uses sequential allocation in that each allocation unit
is placed physically later on the disk than the previous one, but not
necessarily adjacent to the preceding one.
CPM3 and MPM allowed for 512byte sectors and 32mb max
logical drive size.
You must be looking at MP/M I. The maximum drive size for MP/M II is
512MB using 16K allocation units. The maximum file size, however is
still 8 MB.
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.
Didn't the CP/M SPOOL program simply hook the printer BIOS vector and
install itself below CCP like the XSUB program? It's been a long
time, so it might have been above the CBIOS also.
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.
I suspect that DRI considered that area to be an issue left to the
implementor. We certainly allowed two OS-es to reside on the same
drive by simply implementing our own partition table scheme and
making the hard disk access routines aware of it. MS-DOS scarcely
does anything much more elegant.
Only required for floppy or the uncommon removable
harddisk
(CDC hawk anyone).
...or Syquest removables (SQ100) which were around early enough,
albeit after the PC, to find their way onto some Z80 CP/M systems.
I seem to recall seeing an OS being advertised in one of the mags in
the late 70's that offered CP/M functional compatibility, but also
featured a hierarchical directory structure. I don't recall the
name, but a friend was all fired up about it.
Cheers,
Chuck
6488
days inactive
6488
days old
1 comments
2 participants
participants (2)
-
ajp166＠bellatlantic.net -
cclist＠sydex.com