Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.wanted,net.unix-wizards
Subject: Re: Wanted: info on ONYX i/o (parity discussion/question)
Message-ID: <1974@rlgvax.UUCP>
Date: Thu, 31-May-84 23:36:56 EDT
Article-I.D.: rlgvax.1974
Posted: Thu May 31 23:36:56 1984
Date-Received: Sat, 2-Jun-84 11:47:56 EDT
References: <7715@gatech.UUCP> <1963@rlgvax.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 41

I had asked earlier:

> While we're on the subject of parity, does anybody out there interpret the
> passage:

> 	EVENP	0000200 Even parity allowed on input (most terminals)
> 	ODDP	0000100 Odd parity allowed on input

> from the V7 and 4.1BSD manual page TTY(4) as meaning "if the EVENP bit is
> set, even parity will be checked for on input *but* the system will not
> generate even parity on output"?  Somebody was rather insistent on that
> being the correct interpretation, and no amount of logic could dissuade him
> from that conclusion.  It seems kinda silly to me - if taken that literally,
> it means that V7/4.1BSD systems can't generate parity on output at all
> (there's no "Even parity generated on output" bit in the sg_flags word, or
> anywhere else).

It turns out that the TTY(4) manual page in 4.1BSD says under "Output
processing" that "Even parity is normally generated on output".  So it
is stated that even parity can be generated on output, but it doesn't state
anywhere that the parity generated on output is partly conditioned by the
EVENP and ODDP bits (I say "partially" because if you turn on EVENP and ODDP,
even parity is generated on output and half-checked on input - the mux
(the DH-11 and DZ-11 muxes, anyway) will check for even parity but the
driver will ignore parity errors.

Somebody replied to my message saying that they wanted to have an 8-bit data
path to a printer and XON/XOFF flow control, and that they didn't see how
it could be done as RAW mode was the only way to get an 8-bit data path and
RAW mode disables XON/XOFF.  It turns out that on the VAX, on 4.1c at least,
turning the LITOUT bit on in the local flags word sets the DH-11 and DZ-11 to
transmit *and receive* 8-bit characters with no parity.  This may be the intent
of LITOUT (the 4.1 manual says only that LITOUT "Suppress(es) output
translations") or it may be an artifact of the implementation; I suspect the
former, as output translations (case mapping, delays, CRMOD, etc.) could be
suppressed without an 8-bit data path.  The person was using a Sun, and didn't
have source, so they couldn't check and a look at "dz.c" and "dh.c" doesn't say
anything about whether they'd be able to do it.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy