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

30 Jan 2008

...

Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
   From: Dave McGuire <mcguire at neurotica.com>
   Date: Wed, 30 Jan 2008 13:27:25 -0500
     To: "General Discussion: On-Topic Posts Only" <cctech at
classiccmp.org>

On Jan 29, 2008, at 4:33 PM, Joshua Alexander Dersch wrote:
   In the
early-mid 80's a program was "well behaved" if it did it's  
 I/O thru DOS calls. Those programs would run on just about anything. 
 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?)
 I'd be interested to hear opinions from people who were there at  
 the time, since it was a little before my time. 
   I was there; I was a CP/M weenie for many years.  I still use it  
from time to time; it's lots of fun.

   The CP/M BIOS definition doesn't provide for all the things a user  
might want his/her hardware to do.  Accessing serial ports  
efficiently is one thing...Some popular CP/M communications programs,  
such as the MODEM7 family, used the concept of "overlays" (not the  
kind that we use in the PDP-11 world!), which are assembly language  
modules which are written for your specific hardware that present a  
unified (BIOS-like!) interface to the rest of the MODEM7 code.  It  
was intended that end users would write these routines for their  
specific hardware.  (in a day when end users were typically highly  
technical people)

   Formatting floppy disks is another example.  The CP/M BIOS has no  
provision for floppy disk formatting, so a formatter program had to  
be written for each floppy controller, and it accessed the  
controller's registers directly to perform the formatting (and  
sometimes verification) function.

   Other than specialized hardware (lab I/O, speech synthesizers,  
real-time clocks) there weren't many instances of programs directly  
accessing I/O in my experience. 
Another way to say that is if the application used BDOS calls there was
a near 100% assurance of proper operation.  If it did BIOS calls corectly
that was near 100% as well.  If it played with hardware direct all bets 
were off.  Generally the hardware was simple enough that was a minor 
issue.  The most common case was extra serial IO (modems and the like).

Even then there is a YABUT..  If the system was IO interrupt driven and 
also fully implemented IObyte then doing modem IO was a easy task.  The 
problem with that is CP/M didn't REQUIRE it but would certainly be nicer
to use if you had it.  

Therein lies the statement: Most BIOS were minimal implmentations.  It 
was the Ampro's, Kaypros, DEC vt180 and many others that were more 
than minimal BIOS and those you could actually count on more things 
as the bios did the lifting.

Allison

...
            -Dave

-- 
Dave McGuire
Port Charlotte, FL