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