Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!van-bc!rsoft!mindlink!a344
From: Tom_Klok@mindlink.UUCP (Tom Klok)
Newsgroups: comp.sys.atari.8bit
Subject: Re: 80 columns and baud rate
Message-ID: <5402@mindlink.UUCP>
Date: 6 Apr 91 23:56:03 GMT
Organization: MIND LINK! - British Columbia, Canada
Lines: 48

> wilmott@utopia.rutgers.edu (Ray Wilmott) writes:
>
> Isn't a graphics 0 screen made up of 8x8 bit characters, 40 column
> across and 20 columns down? And a graphics 8 screen 320x192 pixels?
> (this is from memory so...) If so, thats 51,200 pixels versus 61,440
> pixels. So why can one only go 1200 baud while the other can go 9600
> baud? Seems to me its only because one *directly* uses the OS to draw
> the screen in a native manner, while the other fights against the OS to
> forcibly draw a slightly higher res screen.

Actually, both ANTIC mode 2 (graphics 0) and ANTIC mode F (graphics 40,
fullscreen gr 8) use 320x192 pixels.  The difference isn't really in the OS,
though.  The OS's responsibility is to set up the screen, and it handles screen
operations via S: and E: devices.  However, the OS has no support at all for
text in a graphics mode, so any text in mode F has to be written to screen ram
by the application.  Not that it matters... the speed difference has nothing to
do with the OS.  The problem is in ANTIC, and what you expect it to do.

In text modes, ANTIC fetches a single byte from screen ram.  This is the
character to be displayed.  ANTIC then goes off and fetches 8 more bytes of
character set data, all by itself, during DMA transfer.  As far as the program
is concerned, a graphics 0 screen is made up of 960 bytes of data.  A graphics
40 screen consists of 7680 bytes of data, because there is no character set
lookup.  It doesn't matter much to ANTIC, but it sure makes a big difference to
the poor application that wants to move stuff around.  If the OS supported text
in graphics 40, it would be the same problem... far more screen memory to deal
with.

The biggest speed killer is scrolling.  Imagine a 80-col terminal at 9600 baud.
Every time it gets a LF at the bottom of the screen, it has to move 7360 bytes
and clear 320 bytes.  If the LF's come consecutively, that means it's expected
to move all that ram at up to 960 times a second.  The Atari just ain't up to
it.  Hopefully, the scrolling won't be that demanding, and the Atari can buffer
the input and catch up as soon as some regular text or terminal codes come by.
Long strings of LF's can cause buffer overflow, and the the software gags.

There is a well-known technique to speed the scrolling up, taking advantage of
ANTIC's smarts.  Instead of blindly moving all that screen ram around, the
80-col emulator constructs a custom display list.  When it's time to scroll, it
moves the DL pointers instead of the actual ram.  Now it has 320 bytes to clear
and 48 bytes to calculate, which is much easier to accomplish.  I wrote an
80-column ADDS ViewPoint emulator a few years ago that did this, and it could
keep up to 2400 baud without difficulty.  Never had an opportunity to try
anything faster.  I never got around to adding typical terminal features like
capture or file transfers, so please don't request a copy. :)

Tom Klok
a344@mindlink.UUCP