Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!caip!clyde!cbatt!cbosgd!ihnp4!houxm!homxb!gemini From: gemini@homxb.UUCP (Rick Richardson) Newsgroups: net.periphs,net.micro,net.wanted Subject: Re: update on **real** 19200 CRT Message-ID: <1832@homxb.UUCP> Date: Wed, 30-Jul-86 12:27:59 EDT Article-I.D.: homxb.1832 Posted: Wed Jul 30 12:27:59 1986 Date-Received: Fri, 1-Aug-86 01:14:24 EDT References: <671@mordred.purdue.UUCP> <71@winfree.UUCP> <2349@cbosgd.UUCP> <1828@homxb.UUCP>, <678@mtune.UUCP> Organization: PC Research, Inc. Lines: 61 Xref: mnetor net.periphs:484 net.micro:5718 net.wanted:3560 >> In article <1828@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes: >>19.2 Kbs ought to be easily achievable in a standalone situation as >>the original poster suggested, even on a stock IBM PC running at 4.77Mhz. >>The key is to use a truly dual ported video card, so you won't have to >>wait for retrace. At 1920 cps coming in from the 8250 you have >>about 500 usec to handle each interrupt. That's about 125 >>"average" instructions on a stock PC, or 250 on a fast clone. >>Now, reading the 8250 and putting the character in the video >>RAM is maybe a handfull of instructions. The tricky part is display scroll > > Jonathan Clark writes: >emulating a terminal is *SLOW*. Rick is correct in stating that >reading a character from a UART and writing it to a screen should take >a few (<100) instructions. Unfortunately going through all the lookup >tables, and modifying the program's behavious depending on the last >character received, takes a lot of cycles. If you can set up a >situation where you don't need to emulate then this is fastest. The amount of work needed to emulate a terminal depends upon what terminal is being emulated, of course. To continue with my analysis of the problem, I can relate the facts of the first terminal I homebrewed, which was a 6800 uP with a dual ported display RAM. The entire ASSEMBLER code for emulating a VT52 with insert/delete line fit into a 2708 EPROM (1K)! The second terminal (Bellmac-8 uP, 6845 CRTC, dual ported display RAM) emulated an HP2645 and the "C" code fit in 16K. The second terminal also included both "Breakout" and "Space Invaders" local modes (No kidding, you could play games locally!). As I recall, the display code was basically a switch on the current state of Escape processing followed by a switch on the current character, followed by the actual work to be done for that combination of state/input character. Even in "C", I'm sure this was less than 100 instructions for each input character. > >Second: >The BIOS in the AT&T PC6300 executes a loop something like this when it >writes to the screen: > > di >loop: > inb > beq , loop > outb screen, char > >which means that anytime you write to the screen it busy-waits until >the display is retracing. This is bad enough in the normal case, but I >think that it actually waits for horizontal retrace, so when the >display is in flyback it busy-waits. > >Anyone know what the IBM PC does? The IBM PC with CGA adapter has the same sort of loop; the display RAM is not dual ported. I believe that many of the clone cards ARE dual-ported and so don't require this sort of nonsense. The Video-7 VEGA EGA that I use is also dual ported: you can write the display RAM anytime you want to. As I stated before, if you want to run true 19.2 Kbaud, you'll need to use one of these dual ported display adapters AND you'll need to use the hardware scroll feature of the 6845 CRTC. Don't even think of using BIOS. Rick Richardson, PC Research, Inc. (201) 922-1134, (201) 834-1378 @ AT&T-CP ..!ihnp4!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!gemini, please.