3 Feb
2008
3 Feb
'08
4:27 a.m.
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:
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
......
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.
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
4 Feb
4 Feb
4:21 a.m.
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
...... 
11:06 p.m.
On Monday 04 February 2008 07:21, Dave Dunfield wrote:
I don't think he was talking about pushing data on
the stack,
I thought he was refering to putting the system service request
number inline with the code.
Yup...
This is exactly what I do on both my DMF (8080) and
CUBIX (6809)
OS's.
I use an 'SSR' macro which looks something like (DMF/8080):
SSR MACRO
RST 2
DB \1
END
It's fairly easy to fetch this:
SSRENT: STA savea ; Save accumulator
XTHL ; HL = calling address
MOV A,M ; Get service request number
INX H ; Skip for return
XTHL ; Restore HL & new return address
; Now you have the SSR number in A
; most likely you would use it to index into a handler
; table sith something like: (untested)
PUSH H ; Save application HL
MOV L,A ; L = SSR number
MVI H,0 ; Zero high
DAD H ; x2 for two byte entries
PUSH B ; Save BC
LXI B,JMPTAB ; Point to jump table
DAD B ; Offset to table
POP B ; Restore B
MOV A,M ; Get low address
INX H ; Advance to high
MOV H,M ; Get high address
MOV L,A ; Set low address
XTHL ; Restore HL, dest on stack
LDA savea ; Restore A
RET ; Jump to caller
'JMPTAB' would contain a series of 2-byte addresses of
the individual SSR handlers.
Only I called mine "OPTAB". And the register usage was slightly different,
but that's pretty darn close to what I was doing. :-)
In practice it's usually a bit more complex ...
iirc
in my SSR entry I save most of the registers (so that
the handlers don't have to) and switch to my own stack
(but it's been a very long time so I may be mistaken).
Yup I had some entry points just do as little as what was necessary and
others save *all* registers so we could do things like display them if we
wanted to or whatever, and that included switching to the monitor's stack as
well.
In the application code, you can then do things like:
MVI A,'?' ; Get prompt
SSR 3 ; Output to console (two byte OS call)
Just so, which strikes me as a whole lot more efficient than having to use a
3-byte CALL instruction after loading a function code into one register (and
maybe needing to save that beforehand) and maybe the same with some other
registers as well. It was the days when every byte counted, right? :-)
--
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
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.
6165
days inactive
6167
days old
3 comments
3 participants
participants (3)
-
ajp166＠bellatlantic.net -
dave06a＠dunfield.com -
rtellason＠verizon.net