CP/M survey

[Allison]

>
>Subject: Re: CP/M survey
>   From: Jules Richardson <julesrichardsonuk at yahoo.co.uk>
>   Date: Wed, 18 Apr 2007 15:43:45 -0500
>     To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
>Chuck Guzis wrote:
>> On 18 Apr 2007 at 12:28, Jules Richardson wrote:
>> 
>>> I doubt there's any shortage of CP/M capable hardware owned by people on the 
>>> list - there's just a shortage of CP/M "hardcore" knowledge, because the 
>>> systems don't get used often enough for people to remember the real nuts and 
>>> bolts.
>> 
>> ...and how many of us could assemble a CP/M capable machine from 
>> what's in our junkbox?  Really, for a functional system, you'd need a 
>> x80-capable processor, some RAM, a UART (if it's not already on the 
>> processor chip) and an FDC (a WD1770/1772 will do just fine)--and a 
>> bit of PROM to get it booted.
>
>Interesting; did CP/M ship with a range of UART and FDC drivers then, so you 
>just tell it what particular ICs you're using and at what port addresses, and 
>away it goes? Or was it more complex than that, and realistically you'd have 
>to write your own comms / FDC driver which exposed some defined interface to 
>CP/M itself?

No.  The bios was the interface between CP/M core and the hardware and it was 
hardware specific.  So if you created a new system with new hardware you needed
a new bios.  CP/M bios writing once understood was fairly reasonable task.

>> What there's not a lot of knowledge for are the CP/M "add-ons" such 
>> as Display Manager and Access Manager and the networking (was it 
>> CP/Net or something like that?).
>
>Hmm, one of my Research Machines (RML) systems has the networking add-ons; I 
>think they called their implementation Z-net. Clients have enough ROM-resident 
>code to invoke some form of network boot from the server - what I'm not sure 
>is whether the OS image transfer is part of core "network aware CP/M" or 
>whether that's a Research Machines extension (with the core stuff only really 
>providing network-aware file services).
>
>The manuals are rather buried at the moment, but I seem to recall that they 
>weren't exactly big on details anyway (RML were great at producing hardware 
>documentation, but not so hot at writing down how the software side worked)

Unfortunatly that was common in smaller companies. There were those that 
thought some aspect of their system should be "secret" to prevent copying.


Allison