Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!decwrl!sgi!mitch@rock.SGI.COM
From: mitch@rock.SGI.COM (Thomas P. Mitchell)
Newsgroups: comp.sys.sgi
Subject: Re: baud rates (was: wsh questions)
Summary: must be something
Message-ID: <32965@sgi.SGI.COM>
Date: 16 May 89 23:48:09 GMT
References: <84*doelz@urz.unibas.ch>
Sender: daemon@sgi.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 36

In article <84*doelz@urz.unibas.ch>, doelz@urz.unibas.ch (Reinhard Doelz) writes:
> Hmm - sound as if it is getting complicated with the non-4Sight environment.
> As far as I got the data out of the 'documentation', the baud rate of the 
> non-graphics environment is determined in the PROM monitor setting the environ-

On a pseudo terminal environment (wsh) it is usefull to set
the baudrate to something.   The value of 38400 is a
reflection of the update time.   Remember wsh is a 'gl'
aplication program which emulates a terminal and there is no
real serial conection from the machine to the 'pseudo terminal'.

There are a number of programs which use 'curses'.  Curses programmers
can pay attention to the baud rate when they update a screen.  Many of
the screen functions have a time associated with them  the use of
screen functions is then modified to optimize screen I/O.

Consider a real terminal -- the Qume 102.  It can refill the screen
faster at 19200 baud than it can open a single line.  So when a line is
inserted clever 'curses' code will use the terminal 'insert line'
command at 300 baud and redraw the screen at 19200.

Try a 'clever' program (emacs is a good one) at baud rates from slow to
vfast on a real terminal.  It is fun to see the differences.  For what
it is worth the source to an older version of  emacs had a full page
comment in its terminal I/O section which was a tombstone.  The
comments warned any who entered etc..

|--

Is this is any help?

--

-------------
Thomas P. Mitchell  (mitch@sgi.com)
Rainbows -- The best (well second best) reason for windows.