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