4 Feb
2008
4 Feb
'08
10:58 p.m.
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. :-)
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
stuff.
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.
Interrupt driven, has some basic terminal sense (vt100 specific)
and uses IObyte.
Sounds worth looking at, is it out there anywhere?
(Snip)
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...
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? 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... 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.
Noted. :-)
--
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
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.