"CP/M compatible" vs. "MS-DOS Compatible" machines?
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
>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
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
More information about the cctalk