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

Allison ajp166 at bellatlantic.net
Wed Jan 30 17:03:54 CST 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
>



More information about the cctech mailing list