Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 Adelie 8/14/85; site adelie.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!adelie!barry
From: barry@adelie.UUCP (Barry A. Burke)
Newsgroups: net.unix
Subject: Re: calling non-unix systems (really tip)
Message-ID: <525@adelie.UUCP>
Date: Fri, 25-Oct-85 09:06:23 EDT
Article-I.D.: adelie.525
Posted: Fri Oct 25 09:06:23 1985
Date-Received: Sat, 26-Oct-85 08:05:59 EDT
References: <8@dolphy.UUCP> <158900001@hpfcdc.UUCP> <384@varian.UUCP> <5219@amdcad.UUCP>
Organization: Adelie Corporation, Newtonville MA
Lines: 24

> BSD4.2 tip has a variable called "echocheck" which requires each
> character be echoed before sending the next character. This is
> probably ideal as it will send as fast as the receiving system
> can accept data. Are there any systems which echo even when the
> data is coming in too fast?
> -- 
Yeah- All Prime 50 Series systems.  Primos let's the asynchronous controller
(AMLC, ICS) do the echo so long as it has room in it's "tumble tables".  When
the tables fill up, the AMLC stops echoing.  HOWEVER, any un-echoed(sp?)
characters are dropped as well (and if so instructed, the AMLC will stick in
a NAK in the input stream to tell Primos it lost chars)...

Working with "echocheck" with Primos is thus dangerous.  The buffers rarely
ever actually fill up, though, and if it's a problem Primos can be configured
to have bigger tumble tables.  I used to speak poorly about the Primos support
for asynchronous devices- after getting out into the UNIX world, I learned that
Primos is still a lot better than the alternatives (eg DEC).  Even if it is
just re-fried Honeywell support, the AMLC is faster, with less overhead, and
it handles high-speed input *much* better than what I've seen from DEC/UNIX.
-- 
LIVE:	Barry A. Burke, (617) 965-8480 x26
USPS:	Adelie Corporation, 288 Walnut St., Newtonville, MA  02160
UUCP:	..!{harvard | decvax!cca!emacs}!adelie!barry
ARPA:	adelie!barry@harvard.ARPA