"CP/M compatible" vs. "MS-DOS Compatible" machines? - test-drb@ccmp.vtda.org

1 Feb 2008

...

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