Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!well!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: net.micro.amiga
Subject: Re: Picking a terminal emulator
Message-ID: <951@hoptoad.uucp>
Date: Mon, 4-Aug-86 04:11:19 EDT
Article-I.D.: hoptoad.951
Posted: Mon Aug  4 04:11:19 1986
Date-Received: Mon, 4-Aug-86 18:47:46 EDT
References: <232@neoucom.UUCP> <18100001@ico>
Organization: Nebula Consultants in San Francisco
Lines: 38

In article <18100001@ico>, farmer@ico.UUCP writes:
> >This brings up a question to CBM:  why is it so stinking hard to get
> >fast emulation going on a 68000 box with a separate IOP!
> Have you ever used a sun console?  It has a hard time doing 9600 baud -
> doing bitmapped screens is expensive.  When someone is using the console,
> the whole machine is slowed down dramaticly.  Of course the screen is
> higher resolution.

I wrote the original Sun console driver.  It's actually pretty fast to
write characters up on the screen; for example, vnews or "page" is very
fast.  The slow part is scrolling -- you have to move about 128K of
memory for each scroll (1152 x 900 = a million bits of image).  The
trick I finally settled on is that anytime I had to scroll the screen,
I would look ahead in the data stream and count up how many lines of
data were there, and scroll that many in one leap.  This looks a little
odd on the screen until you get used to it, but it lets the console run
at very high speeds (9600 forever when running standalone at the time;
I haven't measured it in years).

Of course, your terminal emulator, window system, application program,
or whatever must be smart enough to buffer up chunks of stuff to send
to the screen, so that when it looks ahead it will find several lines
of stuff.  (This also cuts down on the function call/system call
overhead of passing the data around.) In particular, when emulating a
terminal over a serial port, you have to use interrupts to grab the
received characters; if you poll, moving that 128K will cause big gaps
in the polling and you will drop chars.  I used a simple circular buffer
that the interrupt routine would just drop chars into; the mainline
code did nothing but look in the buffer all the time.  Anytime it found
new data, it would send ALL the new data to the screen.  By the time
the screen painting code returned, there would often be another block
of new data, etc.

The Amiga should be able to cope with fast serial lines with similar
methods.
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa
		     May the Source be with you!