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

[Allison]

>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
>   From: "Chuck Guzis" <cclist at sydex.com>
>   Date: Thu, 31 Jan 2008 18:56:41 -0800
>     To: cctalk at classiccmp.org
>
>> Date: Wed, 30 Jan 2008 18:27:23 -0500
>> From: Allison 
>
>> 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.
>
>Many avoided the issues with the BDOS and simply went through the 
>CBIOS vector.  That's why it was important that your "cold boot" jump 
>at 0000 point to the proper entry in the BIOS jump vector list and 
>not to the cold boot routine directly.  A lot programs used the cold 
>boot jump at 0000 to find the BIOS jump list--just take the address 
>in the jump instruction and set the low byte to 00.

Done right it was portable.  However I encounterd at least one system
where the BIOS calls were unusuable for 8bit serial because every 
transaction in or out was masked with 07Fh..

>Timer as well as console interrupt I/O was pretty much necessary for 
>MP/M functioning (interrupt-driven disk I/O was *strongly* suggested) 
>and recommended for CP/M 3.0, as was bank-switching.
>
>I did a CP/M 2.2 implementation using interrupt-driven I/O for 
>everything but the memory-mapped display.  It worked pretty well, but 
>the effort was wasted for the disk I/O--there was nothing to do while 
>you were waiting for the operation to complete.  On the other hand, 
>it did make writing an MP/M XIOS much simpler.

I'm still running a cp/m S100 box with interupt driven everything 
including disk.  the disk get a parameter block and start and goes and
pulls and interrupt wwhen done.  It has local cpu for the IO.

What to do with the freed up cycles... print spooler was first rans 
as a system background job as part of the BIOS.  Later I tried other 
things but printing was a big step forward.  At that time still using
V2.2 I started working with romdisk/ramdisk and banked BIOS and having
the bios where it could be any size I wanted with large buffers allowed
for lots of things.

> 
>> 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.
>
>The problem with IOBYTE is that it was defined in terms of console, 
>reader, punch and list.  Well, most systems didn't have a "reader" or 
>"punch".  This made what to do with those items a matter of 
>implementation.  BDOS Function 3 is defined as "Reader Input" and 4 
>as "Punch Output".

Yes and Reader didn't have a status bypass so once it was called
you hung if nothing was happening.  I used to make them null and 
return(0).  I cound never thing of a good use for either Punch 
or Reader.  Since the rules didn't say they were required... I didn't.

>
>> 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.  
>
>By the time that 2.2 was offered, most CP/M systems were CRT oriented 
>with a printer and perhaps a serial port used to connect to a modem. 
>Instead of acknowledging that as the model configuration, DRI 
>stubbornly stayed with TTY and paper tape as their model of character 
>I/O.

Not quite but very soon after.  The problem was the paradiem of V1.4 
was ingrained enough already.  What DRI stuck with for a model was 
not what it had to be and that was their error.  What was implmented 
generally for a BIOS was a whole other story.

We can look back at CP/M and call it primitive but it was for the 
time a fair improvement and inovation.  One only has to look at the 
8080/z80 DOS of the day and compare, There were few really viable 
choices that werent tied to a fixed hardware or non-portable.


Allison


>
>Cheers,
>Chuck
>
>