Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!portal!cup.portal.com!Ordania-DM From: Ordania-DM@cup.portal.com (Charles K Hughes) Newsgroups: comp.sys.atari.8bit Subject: Re: 80 columns and baud rate Message-ID: <41006@cup.portal.com> Date: 7 Apr 91 04:50:53 GMT References: Organization: The Portal System (TM) Lines: 33 Ray asked about 80 columns (software) and baud rate. Ok Ray, here's the scoop - graphics 0 uses about 2k of memory - 1k for the character set, 1k for the actual screen, and about 50 bytes for the display list. graphics 8 text uses about 9k of memory - 1k for the character set, 8k for the actual screen, and another 250 bytes or so for the display list. Antic is what generates the screen displays. To do this it interrupts the 6502, reads memory, and then returns control to the 6502. It performs this interrupt once per screen line. In a gr. 0 screen there are only 24 lines. In a gr. 8 screen there are 192. As you can see, this means that a gr.8 screen takes about 8 times more interrupts. That isn't all of it... 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. Ok, continuing along...most programs just use the standard handlers for the screen and the modem. The screen handler is slow, and the modem handlers usually aren't super fast either. Bobterm will work at 2400 (and probably higher) using an XEP80. Express 3.0 tends to fail at 2400 using the XEP80. The difference (so I've been told) is in the screen handlers - Bobterm uses a custom one which is faster. 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). As for rewriting the OS to use the 80 column screen normally - this can be done, but isn't worth it unless the screen memory (8k) is taken from extended memory and only the 130xe has that feature. Charles_K_Hughes@cup.portal.com