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

5 Feb 2008

...

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

On Sunday 03 February 2008 07:27, Allison wrote:
(Snip)
Yup,  but that assumes that you want two bytes.  CP/M would give a function 
code and then anywhere from zero parameters to several of varying lengths and 
some even were pointers to tables and data areas.  You might also want to 
bump the return pointer past the data.  :-) 
The general methodology works for any length but I showed it for two.

...
 I think rather than use a scratchpad location to save
HL into I just swapped 
it with the top of the stack,  which would give you HL pointing to the first 
byte beyond the call,  though it's been several years since I worked on this 
and my recollection is a bit more than fuzzy about the whole thing. 
You can but if you need HL to do 16bit arithmetic of some such you may 
have to save it.  I've done code that passed variable length parameters on 
the stack but after 3 maybe 5 bytes you have to start storing something 
somehwere.  Even Z80 has a finite number of registers.

...

 Interrupt driven, has some basic terminal sense (vt100 specific)
 and uses IObyte. 
Sounds worth looking at,  is it out there anywhere? 

Never looked but whole VT180s are findable.

...
 (Snip)
    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. 
I could be mistaken but I think those early comm programs had something like 
128 or 256 bytes of buffer in them.  Which was like nothing when the 
higher-speed modem on the other end had several K... 

Makes little differnce as the reall pain is when you have to hit the 
disk be floppy or hard, most systems the CPU is totoally involved 
in doing PIO for the disk transfer(expecially floppy) and the rest
of the world is left to hang.  You have to stop the transfer prior
to going to the disk.  Many cases that doesnt work well.

When you need speed this is where releaving the CPU of that 
using DMA pays.

allison