david@bragvax.UUCP (David DiGiacomo) (11/20/84)
In article <1165@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >Sigh. You can't *get* an 8 bit data path *and* flow control in >standard 4.2BSD. If you have some wizards lying around (``Heeeerrre, >wizard! Good boy! Here's your CPU crunchon snack'') you can hack in a >``lightly browned'' mode to do this. Did they really take "litout" out of the 4.2BSD tty driver? -- David DiGiacomo, BRAG Systems Inc., San Mateo CA (415) 342-3963 (...decvax!ucbvax!hplabs!bragvax!david)
Ron Natalie <ron@BRL-TGR> (11/21/84)
LITOUT is still there. He probably wants Eight bit input and flow control. Funny combination of modes. Raw mode doesn't have flow control. -Ron
chris@umcp-cs.UUCP (Chris Torek) (11/21/84)
LITOUT is there, but it only gives you 8 bits of output. Or is that
all one needs for a LaserJet?
--
(This line accidently left nonblank.)
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylanddmmartindale@watcgl.UUCP (Dave Martindale) (11/21/84)
> In article <1165@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: > >Sigh. You can't *get* an 8 bit data path *and* flow control in > >standard 4.2BSD. If you have some wizards lying around (``Heeeerrre, > >wizard! Good boy! Here's your CPU crunchon snack'') you can hack in a > >``lightly browned'' mode to do this. > > Did they really take "litout" out of the 4.2BSD tty driver? Depends on what you want. You can get a full 8-bit path on OUTPUT with flow control just by setting LITOUT. You can get a full 8-bit path with flow control on INPUT if you hack the driver a bit to support TANDEM even in RAW mode. But you cannot get an 8 bit data path in BOTH directions with flow control at all, ever. The problem is fundamental: if you receive an XON or XOFF, how do you decide if it is part of the data or a flow control instruction from the other machine? You just cannot transmit flow-control instructions along with all-256-codes-valid data on the same wire without some sort of additional encoding being done.
henry@utzoo.UUCP (Henry Spencer) (11/22/84)
> LITOUT is there, but it only gives you 8 bits of output. Or is that > all one needs for a LaserJet? That's all you need: 8-bit output with XON/XOFF flow control. Unless there is something about the LaserJet that HP's manuals haven't told us, the only things it ever sends are XON and XOFF. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
malcolm@ecn-ee.UUCP (11/28/84)
From: bragvax!david Did they really take "litout" out of the 4.2BSD tty driver? -- David DiGiacomo, BRAG Systems Inc., San Mateo CA (415) 342-3963 (...decvax!ucbvax!hplabs!bragvax!david) And don't forget that the LLITOUT mode is slightly broken. If you do a "stty litout" I think it always works but if you just set the appropiate bit with an ioctl it doesn't catch. At least on DH's the software bit never makes it into the hardware registers. To make it always work you need to do something that actually mucks with the hardware DH registers. (For example I get and set the tty speed to its original value). Doing this has the side effect of setting the litout mode and lets you have 8 bits of output. If you have questions please mail me a note....It really does work (an eight bit path and flow control....I have it driving an Epson printer.) Cheers, Malcolm
Ron Natalie <ron@BRL-TGR> (11/28/84)
> Depends on what you want. You can get a full 8-bit path on OUTPUT with > flow control just by setting LITOUT. You can get a full 8-bit path with > flow control on INPUT if you hack the driver a bit to support TANDEM > even in RAW mode. But you cannot get an 8 bit data path in BOTH directions > with flow control at all, ever. The problem is fundamental: if you > receive an XON or XOFF, how do you decide if it is part of the data or > a flow control instruction from the other machine? You just cannot > transmit flow-control instructions along with all-256-codes-valid data > on the same wire without some sort of additional encoding being done. Give me a break. What does processing control-S and control-Q have to do with whether the incoming character is and-ed with 0177? Why cant I have a mode that gives me all eight bits and XON and XOFF processing. This would be 254 bits processed instead of the normal 126 bits that you get with LITOUT or RAW off. -Ron
chris@umcp-cs.UUCP (Chris Torek) (11/30/84)
> ...the LLITOUT mode is slightly broken. If you do a "stty litout" I > think it always works but if you just set the appropiate bit with an > ioctl it doesn't catch. Someone posted a note about this recently. If you apply the following change in ..ioctl (dhioctl, dzioctl, dmfioctl, whatever else you have) then TIOCLBIS, TIOCLBIC, and TIOCLSET (which change the local mode word) will force the line parameter registers to be fixed up. sys/vaxuba/dh.c (original): error = ttioctl(tp, cmd, data, flag); if (error >= 0) { if (cmd == TIOCSETP || cmd == TIOCSETN) dhparam(unit); return (error); } new: error = ttioctl(tp, cmd, data, flag); if (error >= 0) { if (cmd == TIOCSETP || cmd == TIOCSETN || cmd == TIOCLBIS || cmd == TIOCLBIC || cmd == TIOCLSET) dhparam(unit); return (error); } (of course, change "dh" as appropriate). -- (This line accidently left nonblank.) In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690 UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
dmmartindale@watcgl.UUCP (Dave Martindale) (12/03/84)
> > The problem is fundamental: if you > > receive an XON or XOFF, how do you decide if it is part of the data or > > a flow control instruction from the other machine? You just cannot > > transmit flow-control instructions along with all-256-codes-valid data > > on the same wire without some sort of additional encoding being done. > > Give me a break. What does processing control-S and control-Q have to > do with whether the incoming character is and-ed with 0177? Why cant > I have a mode that gives me all eight bits and XON and XOFF processing. > This would be 254 bits processed instead of the normal 126 bits that you > get with LITOUT or RAW off. > Sure you can do this, with a bit of hacking of the tty driver. What's it useful for? Anything I've ever seen that wanted to transmit 8-bit ASCII wanted to be able to send all 256 codes, not restrict itself to 254.