"CP/M compatible" vs. "MS-DOS Compatible" machines? - test-drb@ccmp.vtda.org

3 Feb 2008

...

Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
   From: "Roy J. Tellason" <rtellason at verizon.net>
   Date: Sat, 02 Feb 2008 20:48:33 -0500
     To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>

On Thursday 31 January 2008 10:07, Allison wrote:
  Whats more interesting is there was nothing to
prevent a termcap file
 and later improved CP/M work alikes did exactly that and many more things. 
What sort of stuff would you put into the category of "CP/M work alikes"?

NOvados, DOS+, ZRdos, Zsdos and ZCPR addons to CP/M.  They all could run
CP/M programs but added things missing from basic V2.2.  The gotacha was 
they required z80 as they were stuffing all that into the same space 
required by V2.2.

Allison

...
 (Snip)
  Andy Johnson-Laird The Programmers CP/M Handbook
went far to extend
 and clarify both what the BIOS can do and more. 
Good book,  that one. I dug it out of a box recently,  and should probably get 
to re-reading it sometime soon,  maybe.

(Snip)
  As you can se the whole interrupt thing was not
CP/M as a limiting
 factor but hardware or implementor understanding. 
I'd like to implement something that'd not only use one of those single-byte 
calls,  but take the data inline,  as well -- no need to load it into 
registers to pass it along,  though there are some rather clumsy aspects to 
getting the stack pointer and fixing it...

  For those that never used a really nice bios try
a VT180, it didn't
 do two sided but those disks where just emerging at the time.  It did
 implement interrupts with ring buffers for IO. 
Can you point to anything specific with regard to this?

  The other thing was DMA. On S100 is was a timing
and bus nightmare
 and took years to almost get right.  Many of the single baord systems
 omitted it as it took space (8257 or later 8237 40 pin chips and a latch). 
Hmm,  I seem to have some number of those on hand here.  :-)

  It works fine and made useful systems.  However
it means the CPU is locked
 up for the duration of the transfer and cannot respond to interupts
 making for poor latency as floppies are slow.  Again CP/M doesn't care
 how the transfer happens only that it does happen. So the fist system
 built with DMA was a real eye opener.  First it allowed background
 activities to run faster and smoother like a line printer spooler.
 also interrupts could be used byy the disk system to say "ready"
 or "ready with error". Thats a lot of available CPU cycles.
 the biggest areas of change is that modem programs werent pausing
 for disk IO, they could fill a big (say 16k) circular buffer and
 the cpu can be processing interrupts for IO and disk to manage
 transfers rather than doing a lot of waiting in loops.  It doesn't
 take a lot more code but the complexity and debugging is greater
 due to the near concurrent activities. 
One of the real problems I had with early BBSing was the fact that I was using 
a CP/M box and that had only a lmiited buffer in the modem program (probably 
MDM740 at first,  IMP a bit later I think),  while the guy at the other end 
had a newer and higher-speed modem that had several K of buffer in it that it 
would continue to empty after my end had asked it to hold on a minute...

That same program had a print or capture buffer (I forget exactly now) that 
was way bigger,  something on the order of 16K,  and it came to me to use 
that for buffering the input rather than the teeny buffer provided,  but I 
never did get around to making that particular modification to it.

(Snip)

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin 