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

[Allison]

>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
>   From: Dave Mabry <dmabry at mich.com>
>   Date: Sat, 02 Feb 2008 13:39:09 -0500
>     To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
>Roger Ivie said the following on 2/2/2008 1:16 PM:
>>
>> I did a small amount of work with ISIS, but after I had used CP/M. I
>> used an Intel PDS development system for the 8051 to debug some
>> firmware; I think it was for DEC's SCSI floppy controller.
>>
>> The PDS was interesting in that it was a portable system about the size
>> of a Kaypro and had *two* 8085s. ISIS gave you an A> or B> prompt, but
>> it indicated to which processor you were speaking rather than which
>> drive was the default.
>
>
>Now *that* was multiprocessing!  I remember it well.  In fact I still 
>have a working one.  With ISIS-PDS there was a logical locking so that 
>you could have both processors (actually *two* complete computers, each 
>with its own 64KB of RAM) doing disk i/o concurrently and they wouldn't 
>scramble each other's files.

Interesting.  Before I'd seen a PDS I experimented with S100 boards of 
my own design with the goal of getting 3 z80s complete with local ram 
and public ram to do mutiprocessing.  By time I was done I'd achieved 
that and more.  All the disks had their own CPU and DMA to public ram
as well as the IO system having it's own CPU to manage buffers and 
pending IO.  Each Z80 had it's own boot and 64K ram plus a mapper to 
page out any 4k portion to public ram or make any 4k pag of public ram
part of the 64k private space.  Public ram was initially 256k 
and grew to 512k.  The 3 Z80 has doorbell interrupts and used public 
ram for data and status passing.  It ran CP/M2.2.  The mostbizare hack 
was one cpu running CCP attached to console, the second running the 
BDOS nad dispatch bios and the third running the application (any cpm app).
Since the disks and IO was smart they acutally ran the Bios abstraction
so the dispatch bios really only routed calls and data pointers for 
the DMA.  

Learned some things.

3 cpus can be fast, and takes nine times longer to program
 and 9times that to debug.
Keeping everyone from killing each other is hard.
One really fast cpu with smart peripherls is faster.
Smart peripherals that can DMA to public memory are
 a a definate win.
You end up adding time slice and process management
 in some form to keep everyone doing the right thing 
 in the right order.
CP/M is not safely recusive.
Hardware for prioritizing bus access is complex for S100.
S100 bus will make you crazy.

I learned a huge amount about multitasking, multiprocessing
and process management in real time.

It was successful but I would later pull two two of the three
4mhz cpus and upgrade one to a 10mhz Z80 to far greater advantage.
I still used that highly modified NS* Horizon running a 10mhz z80
and a smart controller for floppy, HDC and IOP board with an 8085
to handle the two serial ports, parallel printer and RTC.

Years later I would get a Compupro MPX1 (8085 system IO MUX).
It was much like what I did for the IOP save for the IOP use 
real DMA (8257A) where the MPX1 does PIO.


File locking: You can lock CP/M files by marking them system or RO 
so other cpus/processes can crunch them.  The real trick is getting the
"owner to" not recognize the lock.

>It came with a single full-height floppy drive.  I changed mine to have 
>two half-height ones and if I was careful I could run ISIS-PDS on one of 
>the processors and CP/M-80 or CP/M Plus on the other.  ISIS-PDS would 
>boot from the internal bubble memory (128KB) and CP/M would boot from 
>the floppy.  I would do my Intel development work on the ISIS side and 

I still have a pair of BPK72s working with spare bubbles.

>document it in Wordstar on the  CP/M side as I was developing. it.  
>There was no mechanism to keep one side from clobbering the other side's 
>files on floppies, so I had to keep that straight in my head.  At the 
>time it was not hard to do, but today I am probably too lazy to keep it 
>all straight. ;)

It's still a cool thing to see "lowly" 8085 doing fancy stuff.

Allison


>
>Dave
>