jumper@trwrb.UUCP (Gregory S. Jumper) (12/24/87)
I am looking for help or suggestions on how to *correctly* (i.e., not by
having them emulate vt100's) use DEC vt200 and vt300 series terminals with a
Pyramid. Actually, the problem I have can probably be found in most UNIX
systems.
The problem is this: in native mode, the vt200 and vt300 series terminals use
an 8-bit character set (DEC Multinational). However, the UNIX tty driver
(brain-damagedly, in my opinion -- I'm sure someone will tell me if this
behaviour can be considered a "feature" :-)) generates even parity (in an
8-bit data frame) on output, which causes these terminals to display
characters from the "supplemental" character set, rather than the intended
7-bit ASCII character.
I would like the terminal driver to pass all eight bits unscathed to and from
my terminal without my having to put the driver into "raw" mode (and lose line
editing). The "even", "odd", and "litout" options to "stty" would seem to be
the ticket, but "litout" mode also turns off expansion of newline to
carriage-return plus newline on output (regardless of the setting of "nl").
Now, if the above problem has a solution, what about the fact that the
terminal driver is in its "brain-damaged" state at login time, before one has
the chance to issue an "stty" or equivalent command? Being no expert, it is
not clear to me how "gettytab," "termcap," and "stty" interact to specify the
proper treatment for a given terminal. (For example, the description of
"gettytab" indicates that it is possible to have any parity accepted on input
and have odd parity generated on output, but it says nothing about having no
parity generated on output.) In this day of "eight *data* bits, no parity"
data communications and extended character sets, why is UNIX apparently so
backwards in its terminal driver?
Finally, If anyone has other words of wisdom regarding the use of vt200 and
vt300 terminals with UNIX (especially good termcap entries and pointers on
using them with Emacs), I would like to hear them.
Any help greatly appreciated,
Greg Jumper
trwrb!jumper@trwind.TRW.COM (ARPA)
...{decvax,ihnp4,ucbvax}!trwrb!jumper (UUCP)romain@pyrnj.uucp (Romain Kang) (12/25/87)
[I followed up to comp.sys.pyramid only, since there is so much Pyramid-specific stuff here.] In article <4212@trwrb.UUCP> jumper@trwrb.UUCP (Gregory S. Jumper) writes: | I would like the terminal driver to pass all eight bits unscathed to and from | my terminal without my having to put the driver into "raw" mode (and lose line | editing). The "recommended" way to do this under OSx (3.2 and later) involves twiddling a flag in /usr/sys/conf/param.c. I quote from my param.c: /* * Support for 8-bit tty I/O. * This allows full 8-bit tty input and output in canonical mode using: * * att stty cs8 -parenb -istrip * or * ucb stty -even -odd */ int eightbitttyio = 0; I won't have a chance to try this myself before the New Year, but I suspect no one else may see your message before then, either... (For the record, those of you who *must* adb your OSx kernels with /dev/kmem need to change adb's address map: 0xff000000>1 ?m <1 <1+<t ?*m <1+<b <1+<b+<d /m 0 0xffffffff 0x1000 There is no VM simulation; if you want to look at /dev/mem or core images, you'll need to configure your system with the kernel debugger, or use the crash analyzer. If you don't know what this "adb" stuff is, you don't want to know. And naturally, you can't call RTOC if you zap your system with adb... :-) | Now, if the above problem has a solution, what about the fact that the | terminal driver is in its "brain-damaged" state at login time, before one has | the chance to issue an "stty" or equivalent command? | [...] (For example, the description of | "gettytab" indicates that it is possible to have any parity accepted on input | and have odd parity generated on output, but it says nothing about having no | parity generated on output.) getty normally operates in raw mode. Therefore it should be necessary to simply turn off even parity and odd parity: :ep@:op@: | [...] In this day of "eight *data* bits, no parity" | data communications and extended character sets, why is UNIX apparently so | backwards in its terminal driver? You actually speak of Version 7-derived line disciplines. I believe UNIX variants supported by large vendors will all have to support 8-bit tty data because of the needs of internationalization. For the time being, though, there's a lot of V7-based stuff out there that people aren't too eager to hack. All the "local mode" stuff in the BSD tty interface is esthetically displeasing to me, even though I do use it. The System V line discipline is better-designed, since it distinguishes between various line attributes more cleanly. It seems a more elegant model for UNIX tty interfaces of the future, though there are a few gotcha's that are not documented or non-obvious. And again, there's a question of inertia. See the System V man pages for termio.7. -- Romain Kang {allegra,cmcl2,mirror,pyramid,rutgers}!pyrnj!romain Pyramid Technology Corp. / 10 Woodbridge Center. Dr / Woodbridge, NJ 07095 "Eggheads unite! You have nothing to lose but your yolks!" -Adlai Stevenson