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

Allison ajp166 at bellatlantic.net
Wed Jan 30 17:27:23 CST 2008

>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
>   From: "Chuck Guzis" <cclist at sydex.com>
>   Date: Wed, 30 Jan 2008 10:57:15 -0800
>     To: cctalk at classiccmp.org
>> From: "Joshua Alexander Dersch": 
>> Were there similar problems in the CP/M world?  That is, was it
>> commonplace for there to be CP/M programs that bypassed CP/M BDOS calls
>> and wrote directly to a specific machine's hardware?  Seems like CP/M
>> developers were more disciplined in this fashion, but maybe it's just
>> because in the CP/M arena there were so many different pieces of hardware
>> it was the only way to do it?  (Whereas with IBM, the PC was seen as more
>> of a reference standard, even if it wasn't really that way in the
>> beginning?) 
>The great thing about CP/M (and I'm talking about the 8-bit version 
>here) was that it imposed a file system and made disk I/O uniform--
>128 byte sectors, regardless of how the information was actually 
>formatted onto a drive.  CP/M was really primitive when it came to 
>console I/O, giving only about 3 functions for output and input each. 
>No cursor positioning or screen control; basic TTY style I/O.  And, 
>while there was an IOBYTE facility to redirect I/O, implementation 
>was very nonuniform between vendors.

Things like Termcap and the lise were not needed.  However the console
IO was not so good.  Try printing a string containing $ using the print 
string call.  The other was passing 8bit data when needed.

IObyte was mostly uniform, the problem was often it wasnt even 
implemented.  This was a problem of allowing the BIOS spec to be 
minimal and it usually was.

>As a result, for other than simple command-line utility programs and 
>compilers/assemblers and the like with minimal I/O requirements, most 
>productivity and comms programs had to go to the hardware directly 
>for display and communications.
>And that, I think was the innovation of programs such as WordStar and 
>SuperCalc, and, to a lesser extent MODEM7 and Kermit--that you were 
>running on an operating system that was basically designed for TTY 
>I/O with no connectivity and the majority of systems were using CRTs 
>and had modems.  The problem became then how to make a single program 
>work for everyone--and that was done with custom patch overlays.
>DRI, for its part, seemed to remain blissfully ignorant of both of 
>these aspects.

Ignorant, I think no, they gave the hooks and basic requirements. It 
was up to the BIOS developer to do a good job or just enough.  I've 
repeatedly posted that if anything CP/M prevents little and you can 
do a great deal at the bios level to really deliver a better system.
The best way to illustrate this is try a system with basic IO and one
with a full interrupt drive IO.  The first thing you notice is the 
ability to type ahead and the system feels more responsive.

>Likewise, it wasn't MS-DOS that was the great advance for the IBM PC 
>platform, but rather the well-documented BIOS and I/O interfaces.  
>Heck, PC-DOS 1.0 wasn't that different from CP/M-86--you still had to 
>do your disk I/O through FCBs, just like CP/M.  I believe, to this 
>day, you can still issue your DOS calls by loading (CL) with the 
>request number and calling TPA:0005.

Well it was patterned (so say copied) after CP/M so.. No surpize 
there.  ;)


More information about the cctalk mailing list