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

[Holger Veit]

Allison schrieb:
>> 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.
>   
Termcap was very needed, but not present. Net result was that almost any 
software that required terminal control beyond backspace and CRLF had to 
be tweaked manually. I remember having written code to fit in the 
Wordstar patch area to adapt to some obscure or not so obscure terminal 
dozens of times. Termcap and terminfo under the various Unixes of the 
time was god-sent then even if some entries were plainly buggy - maybe 
just estimated from some hear-say information.

The print string BDOS function was indeed an example that was almost 
immediately replaced by do-it-yourself routines, often by using the '\0' 
delimiter (which then caused trouble with slow terminals that require 
some delaying NUL bytes after a CRLF).
> 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.
>   
IO byte, besides as you correctly remarked not being implemented at all, 
was outdated soon after CP/M was released for the Altair. I haven't seen 
many paper tape readers and punches connected to CP/M systems for 
serious business work. IObyte did not take care of additional devices 
beyond the 4 standard devices; it did not deal well with additional 
serial or parallel ports for more terminals and printers. This resulted 
in unofficial BIOS extensions to get such available hardware into the 
boat, and again unportable programs to swap vectors in to BIOS to write 
output to a second printer, for instance. Needless to say that 
"well-written" software to use the IOByte failed to use these additional 
devices - there was even software that insisted that PTP is dumb and AUX 
is intelligent, so abusing these pseudo devices for two printers 
resulted in different behaviour.

> 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.
>   
Since the BIOS reduced the available space for BDOS and TPA - which 
admittedly improved with CP/M+, which, however, IMHO came too late - 
many vendors came up with a not so elaborate BIOS but rather tweaked the 
sample code from DRI. It was plainly easier to add some custom program 
to directly hack the non standard hardware than extend the BIOS with 
useful, clever and portable features. What has been the GHz mania of the 
processor later was at that time the "xxK TPA available" selling argument.
>> 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.
>>     
CP/M-86 and MS DOS were initially designed to allow a simple 8080->8086 
cross translator to run the whole set of already existing CP/M 
applications without reinventing the wheel. Later DOS versions added 
Xenix compatible calls (equivalents of Unix raw I/O: open, close, read, 
write, lseek, unlink) but often still the well-understood FCB crap was 
used. The call to TPA:0005 is still present in contemporary MS-DOS 
versions, as well as INT21h calls;
however today the "DOS box" under Windows just prepares the environment 
for such old DOS programs and uses virtualization to fake an existing 
DOS. You can't trace an INT21h call any longer into an MSDOS.SYS or IO.SYS.

-- 
Holger