[comp.terminals] BitGraph termcap problems

jr@bbn.com (John Robinson) (03/17/89)

In article <12698@pearl.BBN.COM>, milazzo@bbn (Paul Milazzo) writes:
>In article <36764@bbn.COM> ellard@vax.bbn.com (Dan Ellard) writes:
>>
>>	I've noticed that when I am logged into a SUN through my BitGraph
>>vi takes a loooonnng time to scroll a new line onto the screen.  A control-D
>>(scroll half a screen down) takes thirty seconds to complete!
>
>The bg termcap entry on my SUN specifies massive amounts of padding; the
>sf (scroll forwards) capability gives 280 ms of padding, or almost 18
>seconds for 64 lines.  I don't think the BitGraph is THAT slow...
>
>See whether reducing the amount of padding speeds things up.

The termcaps that have that bogosity were constructed when the
Bitgraph had really Really dumb bitblit software, and took a verrrrry
long time to scroll.  Also, the scroll would take several refreshes,
and since the raster is vertical (!), you'd get this sort of queasy,
swimming effect watching it.  The intent of the termcap was to
encourage editors that used it *never* to scroll the screen.  Reducing
the padding should improve things muchly.

Another problem may be that your terminal "speed", as indicated by
stty, may be wrong for you actual serial line.  This happens, for
example, over telnet and rlogin connetions.  Since these connections
have no true "speed", you can safely issue an stty call to tell the
remote machine your actual line speed to the bitgraph.  A higher speed
will generate extra padding proportional to the bitrate for things
like scrolling.

If this still doesn't improve things, post your termcap here and we'll
see if we can turbocharge it.  Also, maybe you should indicate the
prom version number (what it tells you when you power on).  Contact me
by email if you'd rather not air this stuff.


/jr
jr@bbn.com or bbn!jr
C'mon big money!