"CP/M compatible" vs. "MS-DOS Compatible" machines?
Roy J. Tellason
rtellason at verizon.net
Tue Feb 5 00:58:20 CST 2008
On Sunday 03 February 2008 07:27, Allison wrote:
> >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
> caller: push bc ;data in bc
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. :-)
I'd been playing with some monitor code a while back, and haven't been able
to find it until recently when I found a handwritten set of notes on it,
which I suppose it better than nothing. I used a dispatch table, and an
8-bit function code. The lower half of the table was indexed according to
ascii characters and was therefore for stuff that would make sense to key in,
while the upper half wasn't. A function code corresponding to unwritten
eprom (0ffh) would print "crash!" and return control to the monitor, though
it occurs to me lately that printing out a bit more info might be useful.
Anyhow I'd had some code there that would pull the function code out of the
calling code's stuff, and then also whatever parameters might be needed for
that function, and adjust the return address as necessary to bypass all that
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.
> >> 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.
Sounds worth looking at, is it out there anywhere?
> >> 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...
> 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.
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
More information about the cctech