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

[Allison]

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

That was easy in 8080.


;routine gets 16bit word passed on stack before call
; doesn't do anthing but put that item in bc
RRST:     org   010h
          shld  hlsave
          pop   hl      ;hl has return address
          pop   bc      ; BC has data
          push  hl      ; hl back to stack
          lhld  hlsave  ; restor hl
          ret   

;caller
caller:    push bc   ;data in bc
           rst2
           ......


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

Interrupt driven, has some basic terminal sense (vt100 specific)
and uses IObyte.

>
>> 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...

In many cases no buffer. it was more like the other end would stop but by 
time you told it to your 1 byte maybe 2 buffer overflowed.

Often the probem with byte at a time IO without interrutps.  A more 
reasonable IO would be buffered 64 or 128 chars sing style with high
water marking. Interrupt driven of course.

>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.

16k was magical as that was the size of a standard CP/M extent and usually
assumed to be enough space for capture.

Allison

>
>(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