Qterm/vt100
Steve....@ub.cc.umich.edu
our mainframe (UB-MTS) full-screen message system.
I am running QTERM on a Kaypro-II, a slow machine.
The problem I am having is that even at 1200 baud sometimes the vt100 codes
coming in from MTS go by too fast for the Kaypro to keep up, and the screen
gets scrambled. I checked this out at 300 baud, and at that speed it works
first time, every time, but that is impractical.
What I need is either a way to halt input from MTS while the Kaypro processes
the cursor and screen control codes, or a way to patch QTERM with what I believe
is called an "interrupt driver". I'm just parroting the term, I don't know
what it means.
I have a fast terminal emulator (fastterm.com) that works at high speeds without
dropping characters, apparently because it is interrupt driven.
Suggestions are solicited. Please keep in mind that I relatively ignorant of
these matters, and have almost no experience in working with assembler. If
patching is an option you'll have to tell me how, as well as what to patch.
Thanks.
Frank Zsitvay
>I am using the cpm QTERM comm program with its vt100 emulator to talk to
>our mainframe (UB-MTS) full-screen message system.
>I am running QTERM on a Kaypro-II, a slow machine.
>The problem I am having is that even at 1200 baud sometimes the vt100 codes
>coming in from MTS go by too fast for the Kaypro to keep up, and the screen
>gets scrambled. I checked this out at 300 baud, and at that speed it works
>first time, every time, but that is impractical.
Kinda common on 2Mhz z80 machines...
>What I need is either a way to halt input from MTS while the Kaypro processes
>the cursor and screen control codes,or a way to patch QTERM with what I believe
>is called an "interrupt driver". I'm just parroting the term, I don't know
>what it means.
well, most mainframes don't have the response time needed to tell them
to stop sending in time. the interrupt driven approach is the best
alternative, but bear in mind it might not solve the problem.
most cp/m com programs use an "overlay" to allow the same executable code
to work on different serial port hardware. your best bet would be to
rewrite the overlay so it does interrupt driven input/output. the hardware
is definately able to support it.
but the reason why i said this might not work is because interrupt driven
input will allow the terminal/computer to store characters it otherwise would
miss in a circular buffer in RAM. If the serial port baud rate is too fast
for the processor to handle, then interrupt driven input won't do a scrap of
good. it will, however, allow your machine to handle the data as fast as
it can when the baud rate is faster than the processor can handle, for short
periods of time. (like, the the processor is handling those vt100 codes.)
you may find that you'll have to get your mainframe to add nulls to the end
of every line, to give the kaypro time to catch up.
handling interrupt requests on a z80 system (using z80sio chips) is
very straightforward and reading the data sheets will give you all the
information you need. (whether it is comprehendable or not is left as
an excercise for the student... ;) there are many books on the subject,
if you can still find them.
someone may have already gone ahead and written an interrupt driven
overlay for QTERM for the kaypro II, so if you can find someone who has one
you may have the easy way out there.
but if you can't find one, i'll help you with it. I have a kaypro II 83,
which is probably the same thing you have, and could help debug the code.
all you need as a starting point is a virgin copy of the QTERM distribution,
which should have the overlay information in it.
--
fzsi...@techbook.COM - but don't quote me on that....
No wonder I can't hold a regular sleeping schedule. My subconcious mind
knows we are only one well-placed bullet from having Quayle as president.