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. ;)
Allison
Cheers,
Chuck