3 Feb
2008
3 Feb
'08
6:19 a.m.
Date: Sat, 02 Feb 2008 13:07:03 -0500
From: Allison <ajp166 at bellatlantic.net>
Actually PDP-8 OS8 started that, all the other DEC OSs
TOPS-10 and RT had
it as well.
"PIP" should be the giveaway. Odd that ISIS used "COPY xxx TO xxx".
Some hated the mandatory "TO" in ISIS copy, but I thought it was a
good idea. How many times under MS-DOS have you mistakenly typed
"COPY D:*.*" and then hit the "enter" key before completing your
thought? On faster machines, it makes a mess before you can stop it.
The PIP "mathematical" syntax with all the strange options could be
confusing in CP/M; some vendors supplied their own version of a file
copier.
However while the IO was better CP/M had a far better
file system that
accomodated fragmentation (scatter/gather) where RT-11 (and NS* DOS) had
the linear tag and dump that made enlarging a files or creating variable
length files harder.
On the other hand, fragmentation on a floppy can result in very bad
performance--and CP/M had no "defragment" utility. I can see the
advantages of a system that tends to keep files in a small number of
pieces. I've seen the single-piece file structure a lot on
industrial equipment controllers.
Assemble CP/M BDOS at around 100k using ASM
and you find any disk under 400K free space is too small. You still see
that today with faster disks and interfaces.
CP/M was singularly ill-equipped to support hard disks of any size
beyond a couple of megabytes. We'd started offering SA-8000 14"
drives as an option and before too many months, we were getting 40MB
drives for what we'd been paying for the single-platter ones. 5.25"
HD size increases went even more quickly. We bought 7 and 14MB
drives from Rodime and it wasn't long before Rodime was telling us
that they were substituting 10MB and 20MB drives. I was asked if I
could artificially (via software) limit the new drives to 7MB and
14MB so that marketing could charge for the extra storage. I
discouraged the idea very strongly, pointing out that the customers
weren't stupid--someone was going to peek inside and read the drive
nameplate.
CP/M's single-level directory wasn't suited at all to this kind of
thing, even using the "user number" feature--something for which DRI
never came up with a command-line syntax to express, which further
hurt matters.
But then DRI was really thinking of the "user number" feature as that-
-there was the system (user 0) and your own files under your number,
never considering that some users might want to use the feature to
organize their data and go cross-number frequently.
Cheers,
Chuck
4 Feb
4 Feb
10:21 p.m.
On Sunday 03 February 2008 09:19, Chuck Guzis wrote:
Sure it did. It was whatever you used to format a disk... :-) Seriously,
I'd copy stuff off elsewhere and then with a clean start re-copy it back
again, no fragmentation.
I thought I had remembered one, but can't seem to find it at the moment.
However while
the IO was better CP/M had a far better file system that
accomodated fragmentation (scatter/gather) where RT-11 (and NS* DOS) had
the linear tag and dump that made enlarging a files or creating variable
length files harder.
On the other hand, fragmentation on a floppy can result in very bad
performance--and CP/M had no "defragment" utility. I can see the advantages of a system that tends to
keep files in a small
number of pieces. I've seen the single-piece file structure a lot on
industrial equipment controllers.
I have a couple of different boxes for HDs under CP/M. One has the "Design
One" brand name on the box, and a WD-1000 (?) card in it, and is designed
to plug into my Osborne Executive. It originally had a Tulin HD in it (the
only time I've ever encountered one) which had some really bad bearings in
it. They were so bad you didn't want to be in the room when it was on. This
got replaced by an ST-225, only I was never able to access and use all of
that drive and it made some really horrible noises when you tried to. I was
able to hack at the software that came with it (some kind of custom boot disk
I can't recall the details of now) and suspect that the problem had to do
with write precomp, which I think the -225 required past a certain cylinder,
but what was a meg and change of unusable HD space out of 20M under CP/M?
Not all that much. The box also came with a linear power supply originally,
but that got replaced with a switcher after an otherwise minor power glitch
ate the first track and I had to painstakingly rebuild lots of directory
entries, something I don't think I'd care to try these days.
The other box is carrying the Westwind (?) name, also sold earlier on under
the Trantor brand, and has a pair of ST251s in it, and is intended to be
used with this one Kaypro I have here. That one put a small adapter board
under the Z80 and fed a 50-wire ribbon cable out the back. I forget how many
drive letters that setup used offhand. Still worked the last time I tried
it, but that wasn't any time recently at all.
Assemble CP/M BDOS at around 100k using ASM and
you find any disk under
400K free space is too small. You still see that today with faster disks
and interfaces.
CP/M was singularly ill-equipped to support hard disks of any size beyond a
couple of megabytes. We'd started offering SA-8000 14" drives as an option
and before too many months, we were getting 40MB drives for what we'd been
paying for the single-platter ones. 5.25" HD size increases went even more
quickly. We bought 7 and 14MB drives from Rodime and it wasn't long before
Rodime was telling us that they were substituting 10MB and 20MB drives. I
was asked if I could artificially (via software) limit the new drives to 7MB
and 14MB so that marketing could charge for the extra storage. I
discouraged the idea very strongly, pointing out that the customers weren't
stupid--someone was going to peek inside and read the drive nameplate. CP/M's single-level directory wasn't suited at
all to this kind of thing,
even using the "user number" feature--something for which DRI never came up
with a command-line syntax to express, which further hurt matters.
Oh yeah. I think if there were one thing I'd like to change about CP/M that
would probably be it, give me a multi-level directory. Last time I gave
that some thought I was considering using something like *.LBR files do,
only in those the utilities commonly used would have you set the number of
entries you wanted to add at the outset, and you had to go through some
stuff to add more or compact it., and compressing/decompressing library
members was a whole separate operation and also had to be done manually. But
I think it's possible.
I did have a "COMMAND.LBR" that was around 600K in size, had all sorts of
stuff in it, though mostly I used a fairly small handful of utilities.
But then DRI was really thinking of the "user
number" feature as that-
-there was the system (user 0) and your own files under your number,
never considering that some users might want to use the feature to
organize their data and go cross-number frequently.
Yup, that's exactly what I did.
I used utilities like NSWEEP that would, if you invoked them right, show you
all of the files under all user numbers and display which one a file belonged
to, which was handy (and I've been way too much of a user of "show me a
list" file utilities ever since). I also remember that showing me some
really odd things when I tried it on some of the variants, like whatever it
was that Televideo I had was running. Oh, and I forgot about that one, it
has a 40M HD in it -- eight inch! And belt-driven. I started having
problems reading that drive the last time I played with it, and Don Maslin
was nice enough to send me a belt for it, though I never did get around to
putting it in there. One of these days, maybe I will...
Any of you know how some of the CP/M variants dealt with HDs and these other
issues?
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
6164
days inactive
6166
days old
1 comments
2 participants
participants (2)
-
cclist＠sydex.com -
rtellason＠verizon.net