rbloom@APG-1.ARPA (Robert Bloom AMSTE-TEI 3775) (11/10/86)
I'm trying to use my NorthStar Advantage (a all-in-one computer) as a dumb terminal to a TurboDOS system. The problem is that every commo package I've tried so far is too slow for any speeds higher then 1200 baud or so. I want 4800 baud minimum, 9600 baud desired. (19.2k? dream mode on) I don't need *any* facilities in the way of file handling, just a basic terminal with editing (cursor control, clear screen, insert/delete line, inverse video - which are all provided by the video driver anyway.) The modem7/mex overlays are not fast enough - or more properly, the computer does not execute the video driver bdos/bios calls fast enough. The effect is characters are lost, most commonly one or two after a linefeed. The 'host' TurboDOS does recognise the DTR line and stops output accordingly if DTR drops. The Advantage i/o also can be interrupt driven (but is not under cp/m). I've written a tiny commo program that does nothing but ship characters to/from the modem port from/to the console output/input via IN/OUT and bdos func 6. All my attempts to control DTR to avoid character loss has been unsuccessfull. (I don't know how to write a interrupt-driver or I would have tried that too.) So, has anyone tried/done a hack for the Advantage to allow serial i/o at speed above 2400 baud? My normal dealer says max is 1200 baud and won't help further. With a cooperating host (i.e. acknowledges the DTR line) I'm sure higher speeds are possible. But how? bob
mark@cogent.UUCP (Mark Steven Jeghers) (11/10/86)
In article <5349@brl-smoke.ARPA> rbloom@APG-1.ARPA (Robert Bloom AMSTE-TEI 3775) writes: >I'm trying to use my NorthStar Advantage (a all-in-one computer) >as a dumb terminal to a TurboDOS system. The problem is that >every commo package I've tried so far is too slow for any speeds >higher then 1200 baud or so. I want 4800 baud minimum, 9600 baud >desired. (19.2k? dream mode on) Having used the N* Advantage in past years, I can testify that a major part of your problem is simply that it is not a very quick computer. This is especially true of it's screen. On this basis I must sadly say that you may not get much more speed than what you currently have. -- +----------------------------------------------------------------------------+ | Mark Steven Jeghers - the living incarnation of "Deep-Thought" | | ("You won't like the answer ... you didn't ask it very well.") | | | | {ihnp4,cbosgd,lll-lcc,lll-crg}|{dual,ptsfa}!cogent!mark | | ^^^^^^-------recommended------^^^^^ | | | | "A poodle-free world within a decade. We can do it...together!" | | | | Cogent Software Solutions can not be held responsible for anything said | | by the above person since they have no control over him in the first place | +----------------------------------------------------------------------------+
GRUPP@mit-ai.ARPA (Paul R. Grupp) (11/14/86)
Date: Mon, 10 Nov 86 8:32:26 EST
From: Robert Bloom AMSTE-TEI 3775 <rbloom at APG-1.ARPA>
I'm trying to use my NorthStar Advantage (a all-in-one computer)
as a dumb terminal to a TurboDOS system. The problem is that
every commo package I've tried so far is too slow for any speeds
higher then 1200 baud or so. I want 4800 baud minimum, 9600 baud
desired. (19.2k? dream mode on)
...
The effect is characters are lost, most commonly one or two after
a linefeed.
...
This is a common problem with any memory mapped display that is updated
by the host CPU. The problem here is that any line feed that requires
the screen to scroll (e.g. <LF> on the last line) will need the CPU
to move EVERY character on the screen up one line then clear the last
line. This takes a great deal of CPU time and while this is going on
the CPU can't poll the port to check for new incomming data. Here are
three solutions that I've used in order of ease to implement.
1. Have the host send PADD characters (or pause time) after it sends
a <LF>. (note clear screen takes a while too)
2. Write interupt drivers for the COMM port that fills a buffer that
the term program goes to when looking for input.
3. Write your own screen driver that looks at the comm port after
each single line is moved, and buffers any waiting data between
it's moves.
(4) Get a terminal or new system! 8^)
Using any of 1-3 I've gotten an AVERAGE throughput of about 80K baud!
-Paul