20 Apr
2007
20 Apr
'07
12:22 p.m.
Subject: Re: CP/M survey
From: "Chuck Guzis" <cclist at sydex.com>
Date: Thu, 19 Apr 2007 15:30:37 -0700
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
On 19 Apr 2007 at 13:07, Allison wrote:
True but many applications ran well under it anyway.
> 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.
There may have been one but I never saw one in action. The idea of
hierarchical directory pre 1980 was pretty radical for a micro system.
Allison
20 Apr
20 Apr
3:20 p.m.
Allison wrote:
Back then two OSs on a disk would have been truly extravagant.
Only in the microcomputer world. 8-)
IBM mainframes have been doing multiple OSes on the same disk since 1967.
Peace... Sridhar
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.
6487
days inactive
6487
days old
1 comments
2 participants
participants (2)
-
ajp166＠bellatlantic.net -
ploopster＠gmail.com