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

[Allison]

>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
>   From: "Roy J. Tellason" <rtellason at verizon.net>
>   Date: Tue, 05 Feb 2008 01:21:19 -0500
>     To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On Sunday 03 February 2008 09:19, Chuck Guzis wrote:
>> > 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.
>
>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.

Defragger for CP/M is both easy and fun... Use pip to copy the source disk 
to the destination disk.  Best with two or more drives.  the real problem
is it's hard to defrag with limited on disk space without buffering in
ram and thats doable too.

>I thought I had remembered one,  but can't seem to find it at the moment.
>
>> 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.

Makes sense where the file is static in size and whats really being done 
a loader.  what happens if your doing data bases or data collection 
and the assumed file size exceeds the as built file... oops.


>> > 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.

It supported drives to 8mb as a logical unit.  ou can have up to 16(less
if you have floppies) logical units (A->P) for a total of 128mb.

All of the CP/M derived works starting with P2DOS and on fixed the math
inside the BDOS allowing for drives to 1Gb.


>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.

Thae allocation scheme used makes it hard to keep track of how many blocks 
are used by the content of a subdirectory...  you can do it but lots of 
recursion needed and that means a rewrite of the whole files system
code and also compatability issues as none of the apps will have any idea
of subdirs.

>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.

Many of the ZCPR and later improved CP/M work alikes added named directories
that equated to user numbers.

>Any of you know how some of the CP/M variants dealt with HDs and these other 
>issues?

Briefly CP/M doesn't, the BIOS writer does.  Since basic CP/M has a
hard limit of 8mb per logical disk drives larger than 8mb are divided 
into logical partitions as needed.  I have many (6 or more) systems 
with hard disks and all have disks greater than 10MB. The system with 
a 45mb is partitioned (in bios not using MBR or other dosisms) into 
5 logial disks four 8mb and one 5mb.  The bios also allows for 
assigning what partition is what letter though a user utility.  I 
also have a system with a 120mb disk set up so any four 8mb partitions
can be "mounted" and "dismounted" as needed.  Reason for this is 
each disk in the BIOS has buffers associated and they can become 
significant in space used.  By limiting the number of active drives 
I save that space at the cost of only have 32mb on line at any given 
time.  That was a fair trade for a large TPA in a non banked machine.
that and by most users even 8 megs of disk in one lump is luxury
afer using floppies.


Allison