brat@gatech.UUCP (Steven Goldberg) (05/30/84)
I'm trying to use IOCTL to configure a port on our Onyx UNIX system
to have even parity output generation, and NO PARITY input detection.
There's supposedly an i_flag in the termio struct called INPCK that,
if not set, will turn off input parity detection.
For some reason (perhaps it's a bug with Onyx?), it's not working.
Any help or insights would be greatly appreciated.
Thanks in advance,
Steven Goldberg
--
Steven Goldberg
CSNet: brat@gatech ARPA: brat.gatech@csnet-relay
UUCP: ...!{sb1,allegra,ut-ngp}!gatech!brat
...!decvax!duke!mcnc!msdc!gatech!bratguy@rlgvax.UUCP (Guy Harris) (05/30/84)
> I'm trying to use IOCTL to configure a port on our Onyx UNIX system > to have even parity output generation, and NO PARITY input detection. > There's supposedly an i_flag in the termio struct called INPCK that, > if not set, will turn off input parity detection. > For some reason (perhaps it's a bug with Onyx?), it's not working. > Any help or insights would be greatly appreciated. The trick here may be that in most systems there are two cooperating pieces of equipment in parity handling; the terminal multiplexer and the computer. The c_cflag bits PARENB and PARODD control the terminal multiplexer; if PARENB is off the multiplexer doesn't generate output parity or check input parity, and if it is on it generates output parity and checks input parity. (I don't know of any hardware that permits you to generate parity but not check it.) If PARENB is set, even parity is generated and checked for if PARODD is off, and odd parity is generated and checked for if PARODD is on. However, if the multiplexer detects a character with invalid parity it usually just hands the character to the processor with a flag saying "bad parity". The INPCK bit controls whether the computer pays any attention to that bit or not (and has no effect on the terminal multiplexer). I don't know whether the particular terminal multiplexor Onyx uses strips the parity bit off if parity checking is enabled or not. It may depend on the particular UART (or equivalent) chip used by the multiplexor, but then again all such chips may do the same thing. By "it's not working", do you mean that the eighth bit is being stripped off on input (in which case make sure you're clearing the ISTRIP flag in the c_iflags word), or that it's reporting parity errors (either by throwing away input characters or marking them with PARMRK), or something else? 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). Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
thomas@utah-gr.UUCP (Spencer W. Thomas) (05/31/84)
Actually, the 4.2 (and maybe earlier) driver is somewhat broken, because, although it can check for either even or odd parity, it only (as far as I can tell) will generate EVEN parity. =Spencer
guy@rlgvax.UUCP (Guy Harris) (06/01/84)
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