[ On , July 21, 2000 at 10:32:03 (-0700), Chris G. Demetriou wrote: ]
> Subject: Re: PMAGB-B Scrolling/Clearing
>
> Uh, that's not a 'corresponding mechanism' by a long shot; it's
> entirely different.  The sun console method does it via a an escape
> code that can be issued to the terminal from software -- see the
> source, or the manual pages from an old sun system (and maybe a
> current one).

OK, so I'm still not sure what you're talking about here.  In a later
message you clarify your memory of the "pixel-at-time" scroll mode,
which is what I meant by scrolling "one scan line at a time".  Anyway
let me blunder on here a bit....

> As far as I know, there's no way to do that on vtXXXs.

There is an escape sequence on a standard original VT100 to enable (SM:
ESC Ps;...;Ps h) or disable (RM: ESC [ Ps;...;Ps l) "smooth" scroll mode
using the DECSCLM private mode (parameter value 4, with a "?" to trigger
private mode interpretation), so "ESC ? 4 h" would turn on smooth
scrolling and "ESC [ ? 4 l" would turn it off [no spaces]).

The VT100 also supports the standard X3.64 method of setting of a
scrolling region smaller than the total height of the display.  The
region is only defined by start and stop lines, so entire lines are
always scrolled.

However I think the only way to initiate scrolling on a VT100 is to
either try to move the cursor out of the scrolling region with IND, RI,
NEL, or LF; or if wraparound mode is turned on to send output with the
cursor in the bottom right corner of the screen.

The original VT100 does not have the ability to do what one might
describe as "block scrolling" (though that's a slight misnomer because
it could imply column limits) where the content of the scrolling region
is moved by multiple lines at a time.  The vt220 can also only scroll
one line at a time (I think) under cursor control, but it will "add
lines to the screen as fast as possible" in jump-scroll mode.

Some point along the line various terminals started implementing
multi-line scrolling.  This is standardised in ECMS-48 as "ESC [ Pn S"
to scroll up and "ESC [ Pn T" to scroll down.  I don't know when/if any
DEC terminals implemented these codes though.

The following document is pretty comprehensive and includes references:

ftp://ftp.chiark.greenend.org.uk/users/bjharris/all-escapes/all-escapes.txt

> It _might_ be reasonable to implement it as a driver flag
> (i.e. "... flags 0xsomething") or a kernel option.  But really, the
> better solution is to make accelerated moves work and then see if it's
> still necessary.

Accelerated moves, or automatic "block scrolling" when data arrives
faster than it can be scrolled, is definitely a "good idea".  This is
indeed what the sun consoles do....  I'm pretty sure at least some newer
DEC terminals do this too.  I'm not sure how you best implement it in a
console driver -- perhaps by parsing the entire output buffer before
drawing anything to see if its got lots of newlines or other scrolling
sequences and if so to count them out and do one big scroll first.

> (Also, if i recall, my experience was that 'smooth scroll' actually
> had a different meaning than 'one line at a time', at least on my
> vt220... but i'll admit that it's been a while.)

The VT100 user's manual has this rather hilarious sentence to justify
the existence of smooth scrolling: "At the higher baud rates, the data
is very difficult to read due to the rapid movement of the lines." [in
jump scroll mode].  Anyone who's ever turned on smooth scrolling on a
real VT100 will remember that even at 1200baud it seemed REALLY SLOW!  ;-)
On the original VT220 the smooth scroll is limited to 6 lines/s and it's
probably the same speed on the VT100 -- the scan-line at a time is just
the way they implemented it.

(My VT100 can't even handle 9600 baud if the lines are short (or is it
long?) without doing flow control and these days even that speed seems
slow and easy to read.)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>