Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!src.dec.com!ehs
From: ehs@src.dec.com (Ed Satterthwaite)
Newsgroups: comp.sys.atari.8bit
Subject: displays vs. baud rate
Message-ID: <1991Apr7.103154.27547@src.dec.com>
Date: 7 Apr 91 17:31:54 GMT
Sender: news@src.dec.com (News)
Organization: DEC Systems Research Center
Lines: 29
Originator: ehs@jumbo.pa.dec.com

In a previous posting Ordania-DM@cup.portal.com (Charles K Hughes) writes:

> When a gr.0 screen is scrolled, only 1k has to be moved.  When a gr.8 screen 
> is scrolled, 8k has to be moved.  This movement is the real killer.
...

>  The only adequate reason for 1200 only term programs is because the authors
> just couldn't figure out how to get 2400 to work.  It's possible, but 
> not worth the effort (to the authors in any case).

I think the latter is the real problem.

The Atari display commands and display lists partition the screen into
horizontal bands.  This is a real pain for some applications, but it's
perfect for scrolling.  Just use one display command per line and scroll
by updating the display list -- a very fast operation compared to moving
all the bits on a gr.8 screen.  I once modified a VT52 emulator written in
ACTION! to use this technique and it easily kept up with 2400 baud.  I
believe Kermit65 uses the same technique.

A serious problem with an 80 x 24 display is that a standard Atari 8-bit
doesn't provide enough pixels to allow a decent looking rendition of the
character set, at least in my opinion.  The VT52 program used characters
that were quite legible on my monitor (a 1702) but had all the charm and
grace of an OCR font.  Perhaps that's why authors haven't worked very hard
to support such displays.

Ed Satterthwaite
ehs@src.dec.com