dg@lakart.UUCP (David Goodenough) (09/07/88)
From article <3854@bsu-cs.UUCP>, by dhesi@bsu-cs.UUCP (Rahul Dhesi): > We have users here who use both VMS and UNIX from the same terminals. > Terminal settings that work for VMS (e.g. no autowrap) ought not to > stop working for UNIX, since it's commonly known that UNIX is so much > more flexible than VMS. For the same reason, I hope 4.3BSD people > will give us no-parity input/output too in the future. > -- > Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi Correct me if I am wrong, but I thought clearing both the EVEN and ODD bits in the flags member of the sgtty (or whatever) structure provides no parity I/O. On a related note, I log in from home quite a bit & use xmodem to transfer data. I set my local machine to 8 data, no parity (which works !!) and 1 stop bit. All is well till I try an upload, at which point the system chokes. If I reset my local end to 8 N 2 all is well, i.e. I assume the UNIX box is running 8 N 2. Is there any way to get it going 8 N 1 - I thought getty was supposed to spot such things, and although my login id is only 2 characters ('dg') they are sent full speed at 8 N 1 as I'm using a terminal program with a chat script mechanism. I haven't tried this, but if I send a pile of junk (say a dozen random characters followed by a dozen backspaces to clear them) again at full speed, could this help? Thanks in advance, -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!cca!lakart!dg +-+-+ | +---+
guy@gorodish.Sun.COM (Guy Harris) (09/08/88)
> Correct me if I am wrong, but I thought clearing both the EVEN and ODD > bits in the flags member of the sgtty (or whatever) structure provides > no parity I/O. It doesn't - at least it doesn't on 4.[23]BSD nor on any SunOS release with which I'm familiar. In those systems, it requests 7 bits and even parity, but tells the system not to discard characters that have parity errors. This is not the same as what is being requested, which is to send and expect 8 bits and neither send nor expect a parity bit. The latter mode is useful, for example, with terminals that have a "meta" key that turns the 8th bit on for characters transmitted when that key is held down, or for terminals such as the VT220 that support an 8-bit character set. In 4.2BSD, you can get 8 bit, no parity I/O only by turning RAW or LITOUT mode on. These are not generally useful for everyday use; RAW turns off minor features such as line editing and interrupt characters, while LITOUT turns off equally minor features such as mapping '\n' to CR-LF. In 4.3BSD, and in SunOS 3.2 and later (and in other systems that have picked up the 4.3BSD tty driver), you can get 8 bit, no parity I/O by turning PASS8 mode on. This puts the hardware into 8 bit, no parity mode, *and* tells the tty driver not to strip input to 7 bits. Unfortunately, it doesn't tell the tty driver not to strip *output* to 7 bits; to get that, you have to turn RAW or LITOUT mode on, with the problems already mentioned. In System III, System V, SunOS 4.0 and later, and other systems that have a tty driver with the S3/S5 interface, you can get 8 bit, no parity I/O by setting the character size to CS8, turning off PARENB, and turning off ISTRIP. In this mode, the tty driver will strip neither input nor output to 7 bits (definitely true for SunOS 4.0, probably true for S5, possibly true for S3; the S3 and S5 drivers use 8-bit bytes internally to indicate delays, so there may be some problems - I think the S3 driver didn't handle these problems, but the S5 driver, or at least the S5R2 and later driver, does). In SunOS 4.0, which also supports the V7/BSD-style "ioctl"s, turning PASS8 mode on sets the character size to CS8 and turns off PARENB and ISTRIP, so it gives you a true 8-bit data path in both directions. > On a related note, I log in from home quite a bit & use xmodem to > transfer data. I set my local machine to 8 data, no parity (which > works !!) and 1 stop bit. All is well till I try an upload, at which point > the system chokes. If I reset my local end to 8 N 2 all is well, i.e. I > assume the UNIX box is running 8 N 2. If the UNIX box is running a V7-style (which includes 4.xBSD) driver, the only way it can run with 2 stop bits is when it's running at 110 baud. If it's running an S5-style driver, you can control the stop bits and the baud rate independently.
mikep@ism780c.isc.com (Michael A. Petonic) (09/09/88)
In article <236@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >On a related note, I log in from home quite a bit & use xmodem to >transfer data. I set my local machine to 8 data, no parity (which >works !!) and 1 stop bit. All is well till I try an upload, at which point >the system chokes. This is just a shot in the dark, but do you have flow control disabled? I had a similar problem when uploading files to other machines (using Xmodem) through a Sytek LAN. It seems that flow control was set on the LAN and whenever I got to block #19, the Xmodem representation of that block in the header was an XOFF, so that it barfed on anything else sent. -MikeP -- Michael A. Petonic mikep@ism780c.isc.com ``Have a heart... But don't take mine.''