Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!harvard!panda!genrad!decvax!decwrl!pyramid!pesnta!peora!codas!akguc!mtune!jhc
From: jhc@mtune.UUCP
Newsgroups: net.periphs,net.micro,net.wanted
Subject: Re: update on **real** 19200 CRT
Message-ID: <678@mtune.UUCP>
Date: Tue, 29-Jul-86 22:28:57 EDT
Article-I.D.: mtune.678
Posted: Tue Jul 29 22:28:57 1986
Date-Received: Thu, 31-Jul-86 21:10:55 EDT
References: <671@mordred.purdue.UUCP> <71@winfree.UUCP> <2349@cbosgd.UUCP> <1828@homxb.UUCP>
Reply-To: jhc@mtune.UUCP (Jonathan Clark)
Organization: AT&T ISL Middletown NJ USA
Lines: 69
Xref: mnetor net.periphs:483 net.micro:5715 net.wanted:3554

In article <1828@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes:
>> Before you decide to do this, I suggest you buy one, get your software
>> running, and see if you like it.  We have lots of users here using AT&T
>> 6300's as terminals.  (The 6300 has an 8MHz 8086 which will do at least
>> as well as what you describe.)  The terminal emulation programs don't come
>> anywhere near 19200 bps; typical throughput is more likd 2400 bps or so.
>> (I can't remember the exact figures, it might have been as high as 4000
>> bps.  But it was nowhere near 19200.  And it does vary from program to
>> program.)
>
>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

I can comment from significant personal experience here, especially with the
AT&T PC 6300. One point is generic, and I presume that the IBM does the same
thing (in the other point) although I haven't looked at the BIOS sources. 

First:
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.

Second:
The BIOS in the AT&T PC6300 executes a loop something like this when it
writes to the screen:

	di
loop:
	inb	<display status>
	beq	<retrace>, 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.

Now I am unable to comment on the competence of the Olivetti engineers
who wrote that code, and I'm not a BIOS expert, but it did seem to me
that one additional byte would have made everything a lot easier:

loop:
	di
	inb	<display status>
	ei
	beq	<retrace>, loop
	outb	screen, char

NB the display status read and test had to be atomic.

This does not clear up the vertical retrace stuff, and I don't know
enough about the hardware to comment on that.

Anyone know what the IBM PC does?

-- 
Jonathan Clark
[NAC,attmail]!mtune!jhc

My walk has become rather more silly lately.