"CP/M compatible" vs. "MS-DOS Compatible" machines?

Chuck Guzis cclist at sydex.com
Sun Feb 3 08:19:56 CST 2008

> 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 

> 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 

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.


More information about the cctech mailing list