Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!think!ames!amdahl!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.dcom.modems,news.sysadmin
Subject: Re: Hardware Protocol
Message-ID: <26425@sun.uucp>
Date: Mon, 24-Aug-87 19:05:58 EDT
Article-I.D.: sun.26425
Posted: Mon Aug 24 19:05:58 1987
Date-Received: Wed, 26-Aug-87 01:00:14 EDT
References: <192@caeco.UUCP>
Sender: news@sun.uucp
Lines: 52
Keywords: Telebit, TrailBlazer, Modems, UUCP, 'g' Protocol, Mimicry
Xref: mnetor comp.dcom.modems:865 news.sysadmin:340

> A. The Sun 3/160 (and all the sun 2's and the 3/110's also) cannot
> 	hardware handshake AT ALL. They say they do, but in one
> 	direction only, usually so the external device can shut up
> 	the CPU, but not vice-versa.

OK, so what is the proper protocol by which the CPU can control the flow of
data from the external device?  RTS/CTS handshaking permits a DCE to control
the flow of data from a DTE; how does the DTE control the flow of data from the
DCE?

Now maybe some boxes listend to RTS and stop sending data when it drops.  IF
this is a commonly-adhered-to (if non-RS-232-compliant) protocol, it might get
implemented in a future release; however, you'll definitely have to TURN IT ON
because it's rather non-standard, to say the least.

>	And, as far as I know, this is available as a special kernel fix
>	(zs_asynch.o) for some $$$.  But, you have to TURN IT ON.

A future release may provide the ability to enable RTS/CTS handshaking on
individual ports with an "ioctl", but if it's implemented you're still going to
have to TURN IT ON.  That's because some hardware and/or cabling doesn't hold
CTS high; you shouldn't be forced to jumper RTS and CTS (see below).  (Turning
it on also requires you to provide DCD; see below.)

> 	Even more Ludicrous: Sun OEM's MTI 8/16 port asynch port cards
> 	--which have hardware handshake capability; SUN DISABLES THIS
> 	FEATURE IN IT'S DRIVER. Sun is very philosophical about this.

I don't know who from Sun was "very philosophical about this", but they were
also very WRONG about this.  You *CAN'T* disable RTS/CTS handshaking on the
Systech board from software.  PERIOD.  The bloody Signetics 2661 *chip* on the
board doesn't let you turn it off, and there's no extra hardware on the Systech
board to fake CTS.  We have several cables here at Sun with RTS and CTS
jumpered, attesting to that fact and yes, it's a pain; when I wanted to do some
testing on a Systech board, I had to dig up such a cable.

Oh yes, one more thing.  Both the Zilog 8530 SCC chip on the Sun CPU serial
ports, and the Signetics 2661 on the Systech board, will, when doing RTS/CTS
flow control, *also* shut the receiver *off* when DCD is dropped!  You can shut
this off on the SCC, by turning off the bit that enables both RTS/CTS outgoing
flow control and DCD/receiver-enable switching; however, you can't control them
independently.  This is another reason not to forcibly turn RTS/CTS flow
control on.

You're STUCK with this behavior on the 2661; this is handled by forcing DCD
high and wiring the DCD line on a cable to the DSR pin, and using DSR as a
"fake" carrier.  This requires the driver to know about this; perhaps this is
what the alleged disabling of RTS/CTS handshaking in the software reall refers
to?
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com