[net.micro.cbm] 80 columns and 1200 baud on C64

prindle@nadc (08/18/86)

From: prindle@NADC

First of all, to answer the question about 80 column software displays on the
C64 - these are generated by using high resolution bit mapped mode and display-
ing a character font that is essentially 6 or 7 pixels high by 3 pixels wide.
I know 3 pixels width doesn't sound like much, but there are at least three
fonts designed around this specification (the one in Kermit, the one in TERM.
PLUS, and the one in Compute!'s SCREEN-80), and they all are quite readable
on a good monochrome monitor, though not as nice as hardware generated 80
columns (as in a C128).  Personally, I like the set in TERM.PLUS (having
designed it); the others are a pixel higher and seem somewhat out of proportion.
So if you want a good 80 column terminal emulation try Kermit or TERM.PLUS,
both of which are public domain.

Second, on the subject of using a software 80 column display at 1200 baud - as
noted in a previous message, Kermit's 80 column display keeps up quite well 
with 1200 baud.  There is no problem adding a character to the screen in 1/120
second.  The real problem is scrolling the screen up a line (when a line-feed
is received).  The software move loop to do this in Kermit is highly optimized
for speed; yet it cannot do it in 1/120 second.  The redeeming characteristic
incoming data.  Thus, while the software is scrolling up the screen (which takes
about 1/10 second), the Kernel interrupt routines are faithfully receiving the
incoming data and buffering it.  Then when the scroll is complete, the emulator
quickly catches up since it takes much less than 1/120 second to write
single characters to the hi-res screen.

However, if the incoming text contains many short lines (e.g. 5 characters
not enough characters between line-feeds to allow the software to catch up.
The emulator is constantly watching the RS-232 input buffer, and if it gets too
close to full (in which case characters would be lost), it issues an XOFF
control protocol (most do), it will shortly cease sending data to the terminal
so that it can catch up.  When the RS-232 input buffer again becomes relatively
empty, the emulator sends out an XON character (^Q) to tell the remote host to
once again resume transmission.  The net effect is an apparently smooth data
flow to the screen, with full 1200 baud sustained as long as the average text
line is greater than about 12 characters, and with a reduced rate (via flow
control) whenever a large burst of short lines occurs (or when the no-scroll
key is depressed).

I'd be glad to send a full listing of TERM.PLUS to anyone interested in seeing
how all this is done (80 column screen management, 1200 baud, flow control).
The terminal emulation portion of Kermit is essentially identical (but the
listing is too large to send and the terminal emulator is somewhat difficult
to isolate).

I have no experience with 2400 baud, though I would imagine that the VIC-II
chip *is* indeed the limiting factor.  Also, the bit-banging pseudo-uart
interrupt code eats away at the available CPU time for doing the terminal
lines.

Sincerely,
Frank Prindle
Prindle@NADC.arpa