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

[Roy J. Tellason]

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"?

(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