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

Holger Veit holger.veit at iais.fraunhofer.de
Wed Jan 30 08:44:40 CST 2008

Joshua Alexander Dersch schrieb:
> scheefj at netscape.net writes:
>> 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?)
MS-DOS and CP/M were suffering from similar problems.

For CP/M, namely the 1.x and 2.x versions, the difficulty was that the 
BIOS was not sufficient to abstract all hardware that was available. 
Typically, floppy low level formatters had to be written to directly 
talk to the FDC
rather than having an available call "format the floppy in drive A:" as 
there were so many different FDC boards.
The interrupt and DMA handling was also lousy thanks to DR abusing some 
8080 and even worse Z80 RST vector locations for the BDOS and CCP 
buffers and FCBs. Finally, there was no portable way of abstracting 
additional serial or parallel ports that did not fit into the IOBYTE 
scheme. The whole improved somewhat with CPM+, but still was not good 
enough to allow writing portable code.

MSDOS was much better in abstracting hardware, because it had a loadable 
driver concept. Difficulty was again the BIOS which required to be "IBM 
compatible". For the original IBM PC and XT BIOS, Microsoft made some 
hacks of not calling the official entry points but also silently jumping 
into unofficial locations which forced them to be fixed and supported in 
later AT and AT386 and particularly clone BIOS. Unfortunately, IBM 
hardware developers didn't define reasonable interfaces to the hardware 
interrupts in the BIOS already, but left this task to the OS. While it 
was possible to access serial lines through BIOS software interrupts, 
these were (compatibility to old CP/M?) polling interfaces, that didn't 
use the available interrupt controllers. Effect was that some hardware 
vendors implemented such interfaces differently, and provided some 
loadable drivers, but prominently, software vendors who made serial 
communications software, like Procomm, pc-terminal etc. again wrote 
their own, less portable interrupt-driven,direct-I/O software because 
I/O through BIOS was unusable except for 110 Baud TTYs.
When 640K was found to be insufficient, numerous unportable solutions 
came up to increase memory, from EMS to XMS, filling the gaps between 
video memory and extension ROMs, and reusing the wraparound bug of the 
286 that allowed to access 64K beyond 1M without protected mode. The A20 
gate came from there, but when I once disassembled and analyzed 
HIMEM.SYS, I found about a dozen different ways to switch this bit - 
through KBD controller, certain chipset ports, through some reserved 
memory cells, by issuing some obscure interrupt. Intels LOADALL also was 
played out there - everything done to circumvent the deficiency of the 
original design.

Point is there in both cases: the hardware designers did not foresee how 
their hardware could or should be used by software, so they basically 
implanted the bare chips, not even respecting IRQ and DMA requirements; 
the OS developers did not foresee usable and extensible interfaces to 
access and abstract various hardware and just hacked something that it 
would somehow work; and finally the application designers found the 
whole base OS functions where plain unusable and reinvented, each one 
differently, the wheel, leaving burnt ground for others that somehow 
required similar functions - "thou shall not use the printer port for 
your dongle, I have it already."


More information about the cctech mailing list