  Text-Terminal-HOWTO
  David S. Lawyer
  v0.05, June 1998

  This document explains what text terminals are, how they work, how to
  install and configure them, and provides some info on how to repair
  them.  It may be of some use even if you don't have a terminal manual.
  While it's written for real terminals on a Linux system, some of it is
  also applicable to terminal emulation and/or other Unix-like systems.
  ______________________________________________________________________

  Table of Contents






















































  1. Introduction

     1.1 Copyright, Disclaimer, and Author
        1.1.1 Copyright
        1.1.2 Disclaimer
        1.1.3 Author Contact
     1.2 What is a Terminal ?
     1.3 Dumb Terminals
     1.4 Types of Terminals
        1.4.1 Text Terminals
        1.4.2 Graphics Terminals
        1.4.3 Serial Line Graphics Terminals
        1.4.4 Fast Graphics Terminals (often known by other names)
        1.4.5 Quasi-Terminals (= Quasi-Computers)
        1.4.6 Terminal Emulation
     1.5 Terminology

  2. Quick Install

  3. Why Use a Terminal ?

     3.1 Introduction
     3.2 Lower Hardware Costs
     3.3 Control of Software
     3.4 Hardware Upgrades
     3.5 Other Advantages of Terminals
     3.6 Major Disadvantages of Terminals
     3.7 Are Text Terminals Obsolete ?

  4. Overview of How Terminals Work (in Linux)

     4.1 Device Names
     4.2 Login/Logout
     4.3 Half/Full Duplex
     4.4 Terminal Memory
     4.5 Commands for the Terminal
     4.6 Lack of Standardization Solved by Terminfo
     4.7 The Interface
     4.8 Emulation
     4.9 The Console

  5. Terminal Special Files: /dev/tty... etc.

     5.1 Serial Port Terminals
     5.2 Pseudo Terminals
     5.3 The Controlling Terminal /dev/tty
     5.4 /dev/ttyI? "Terminals"
     5.5 The Console: /dev/tty?
     5.6 Creating a Device with mknod

  6. Some Details on How Terminals Work

     6.1 Terminal Memory
     6.2 Early Terminals
     6.3 Control Codes and Escape Sequences
        6.3.1 Control Codes
        6.3.2 Escape Sequences

  7. Special Capabilities of Some Terminals

     7.1 Color
     7.2 Dual Sessions
     7.3 Printer/Auxiliary Port
     7.4 Character-Sets
     7.5 Fonts
     7.6 Keyboards & Special Keys
     7.7 The Linux Console
        7.7.1 Make a Terminal the Console

  8. Notes by Brand Name

     8.1 CIT
     8.2 IBM
     8.3 Teletypes
     8.4 VT (DEC)

  9. Serial Communications on EIA-232 (RS-232)

     9.1 Introduction
     9.2 Voltages
        9.2.1 Voltage for a Bit
        9.2.2 Voltage Sequence for a Byte
     9.3 Parity Explained
     9.4 Forming a Byte (Framing)
     9.5 Limitations of EIA-232
        9.5.1 Low Speed & Short Distance
        9.5.2 Successors to EIA-232
        9.5.3 Line Drivers
     9.6 Synchronization & Synchronous
        9.6.1 How "Asynchronous" is Synchronized
        9.6.2 Defining Asynchronous vs Synchronous
        9.6.3 Synchronous Communication
     9.7 Block Mode
        9.7.1 Introduction
        9.7.2 Types of Block Modes, Forms
        9.7.3 Efficiency
     9.8 EIA-232 (RS-232) Books

  10. Flow Control (Handshaking)

     10.1 Why Is Flow Control Needed ?
     10.2 Overrunning a Serial Port
     10.3 Stop Sending
     10.4 Resume Sending
     10.5 Hardware Flow Control (RTS/CTS etc.)
        10.5.1 RTS/CTS and DTR Flow Control
        10.5.2 Interfacing DTR with RTS/CTS flow control
        10.5.3 Old RTS/CTS Handshaking Is Different
        10.5.4 Reverse Channel
     10.6 Is Hardware Flow Control Done by Hardware ?
     10.7 Obsolete ETX/ACK Flow Control

  11. Physical Connection

     11.1 Direct Cable Connection.
        11.1.1 Multiport I/O Cards (Adapters)
        11.1.2 Length Limitations
        11.1.3 Type of Cable
        11.1.4 A Kludge using Twisted-Pair Cable
        11.1.5 Cable Grounding
     11.2 Modem Connection
        11.2.1 Dialing Out From a Terminal
        11.2.2 Terminal Gets Dialed Into
        11.2.3 Modem Commands
     11.3 Terminal Server Connection
     11.4 Making or Modifying a Cable
        11.4.1 Buy or Make ?
        11.4.2 Connectors & Pins

  12. Set-Up (Configure) for both Computer & Terminal

     12.1 Introduction
     12.2 Terminal Set-Up
     12.3 At the Computer
        12.3.1 Inittab
        12.3.2 Stty & Setserial
        12.3.3 Setserial
        12.3.4 Where to Run Setserial ?
        12.3.5 Stty
        12.3.6 Where to Put the Stty Command ?
        12.3.7 Terminfo & Termcap (brief)
     12.4 Communication Interface Settings
        12.4.1 Speed
        12.4.2 Parity
        12.4.3 Bits/Character
        12.4.4 Which Flow Control ?
     12.5 Rarely Needed /etc/ttytype File
     12.6 Login Restrictions
     12.7 Run Command Only If TERM=my_term_type

  13. Terminfo and Termcap (detailed)

     13.1 Introduction
     13.2 Terminfo Database
        13.2.1 Terminfo Compiler (tic)
        13.2.2 Look at Your Terminfo
        13.2.3 Deleting Data Not Needed
     13.3 Initialization
     13.4 TERM Variable
     13.5 Termcap Documents

  14. Using the Terminal

     14.1 Introduction
     14.2 Starting Up the Terminal
     14.3 Terminal Device Driver
     14.4 Corrupted Terminal Interface
        14.4.1 Symptoms
        14.4.2 Sent Terminal Binary Characters
        14.4.3 Abnormally Exit a Program
     14.5 Special (Control) Characters
        14.5.1 Command-Line Editing
        14.5.2 Interrupting (& Quit, Suspend, EOF, Flush)
        14.5.3 Scrolling
        14.5.4 Take Next Character Literally
     14.6 Inspecting the Interface
     14.7 Changing the Terminal Settings
        14.7.1 setterm
        14.7.2 tput
        14.7.3 echo
        14.7.4 Saving Changes

  15. Trouble-Shooting (software)

     15.1 Terminal Was Working OK
     15.2 Terminal Newly Installed
     15.3 Is the Terminal OK ?
     15.4 Missing Text
     15.5 Getty Respawning Too Rapidly
        15.5.1 No Modem Control Voltage
        15.5.2 Key Shorted
     15.6 Fails Just After Login
     15.7 Can't Login
     15.8 Garbled Login Prompt
     15.9 No Sign of any Login Prompt
        15.9.1 Diagnose Problem from the Console
        15.9.2 Measure Voltages
     15.10 Serial Test Equipment
        15.10.1 Breakout Gadgets, etc.
        15.10.2 Measuring Voltages
        15.10.3 Taste Voltage

  16. Repair & Diagnose

     16.1 Repair Books & Websites
        16.1.1 Books
        16.1.2 Websites
     16.2 Safety
     16.3 Appearance of Display
     16.4 Diagnose
        16.4.1 Terminal Made a Noise
        16.4.2 Terminal Made No Noise
     16.5 Capacitors
     16.6 Keyboards
        16.6.1 Interchangeability
        16.6.2 How They Work
        16.6.3 One Press Types 2 Different Characters
        16.6.4 Modern vs Old Keyboards
        16.6.5 Keyboard Doesn't Work At All
        16.6.6 Typing b Displays bb, etc. (doubled)
        16.6.7 The Keyboard Types By Itself
        16.6.8 Liquid Spilled on the Keyboard
        16.6.9 Cleaning Keyboard Contacts
           16.6.9.1 Keyboards with Membranes
           16.6.9.2 Keyboards with Individual Switches

  17. Appendix

     17.1 List of Linux Terminal Commands
        17.1.1 Sending a Command to the Terminal
        17.1.2 Configuring the Terminal Device Driver
        17.1.3 Terminfo
        17.1.4 Other
     17.2 The Internet and Books
        17.2.1 Terminal Info on the Internet
        17.2.2 Books Related to Terminals
        17.2.3 Entire Books on Terminals
        17.2.4 Books with Chapters on Terminals


  ______________________________________________________________________

  1.  Introduction

  For a quick attempt to install a terminal see ``Quick Install''.


  1.1.  Copyright, Disclaimer, and Author

  1.1.1.  Copyright

  Copyright 1998 by David S. Lawyer.  Please freely copy and distribute
  this document.  Let me know (if you can locate me and if I'm alive) if
  you significantly modify it.  If certain words are trademarks, the
  context should make it clear to whom they belong.  For example "MS
  Windows NT" implies that "Windows NT" belongs to Microsoft (MS). Mac
  is by Apple Computer.


  1.1.2.  Disclaimer

  Much of the info in this HOWTO was obtained from the Internet and may
  be unreliable (although I've done some double checking in some cases).
  While I haven't intentionally tried to mislead you, there are likely a
  number of errors in this document.  Please let me know about them.  It
  should be obvious that I cannot be held legally responsible for them.


  1.1.3.  Author Contact

  My email in 1998 is bf347@lafn.org.  Please let me know of any errors
  in facts, opinions, logic, spelling, grammar, clarity, links, etc.  I
  realize that this document needs some improvement so I hope to revise
  it about once a month .  Please send me any info that you think
  belongs in this document.


  1.2.  What is a Terminal ?

  A terminal consists of a screen and keyboard that one uses to
  communicate remotely with a (host) computer.  One uses it just like it
  was a personal computer but the terminal is remote from the host
  computer (on the other side of the room or even on the other side of
  the world).  Programs execute on the host computer but the results
  display on the terminal screen.  Its computational ability is
  relatively low (otherwise it would be a computer and not a terminal).
  This computational ability is generally limited to the ability to
  display what is sent to it (possibly including full-screen graphics).

  In the days of mainframes from the mid 1970's to the mid 1980's, most
  people used terminals to communicate with computers.  They typed in
  programs, ran programs, wrote documents, issued printing commands,
  etc.  A cable connected the terminal to the computer (often
  indirectly).  It was called a terminal since it was located at the
  terminal end of this cable.

  If you've been using Linux (except for X-Window use) with a computer
  monitor and keyboard you already know what a terminal is because you
  have been using one (or more precisely a "virtual terminal").  The
  monitor (along with the keyboard) is called the console, but it
  emulates a terminal.

  A real terminal is different from a monitor because it's a different
  electronic setup.  A text terminal is often connected to a serial port
  of the computer via a long cable.  Thus, in contrast to a monitor
  which is usually located right next to the computer, a terminal may be
  quite a distance away from its host computer.  The video card inside a
  computer stores the video image seen on the monitor screen.  For a
  terminal, the equivalent of this video card is built right into the
  terminal but since text terminals are often monochrome without much
  graphics, the capabilities of its "video card" are rather weak.  Also,
  most text terminals do not have mice.

  In network terminology, one might think that the terminal is the
  client and the host computer the server.  This is not actually true
  since the only "service" the host provides is to receive every letter
  typed at the keyboard and react to this just like a computer would.
  The terminal is like a window into the computer just like a monitor
  is.  You may have already used virtual terminals in Linux (by pressing
  Alt-F2, etc.).  A real terminal is just like running such a virtual
  terminal on its own screen and keyboard.  In contrast to using a
  virtual terminal at the console (monitor), this allows another person
  to sit at the real terminal and use the computer simultaneously with
  others.


  1.3.  Dumb Terminals

  There are various conflicting definitions of "dumb terminal", but as
  time goes by, more and more terminals are called dumb.  This document
  mainly covers text terminals which display only text on the screen.
  It might be titled "Dumb-Terminal-HOWTO" but in some computer
  magazines any terminal, no matter how smart, including ones which
  present a full graphical user interface (GUI), are called dumb.  If
  all terminals are "dumb" then there is no point of prefixing the word
  "dumb" to terminal (except as a sales pitch to sell computers or the
  like in place of "smart" terminals).  Due to the ambiguous meaning of
  "dumb terminal" it is not classified here as a type of terminal.


  1.4.  Types of Terminals

  1.4.1.  Text Terminals

  For a text terminal, a 2-way flow of information between the computer
  and the terminal takes place over the cable that connects them
  together.  This flow is in ASCII bytes where each byte usually
  represents a character.  Bytes typed at the keyboard go to the
  computer and most bytes from the computer are displayed on the
  terminal screen.  Special bytes (or sequences of bytes) from the
  computer tell the terminal where to move the cursor to, what to erase,
  where to begin and end underlining and/or blinking and/or bold, etc.
  There are often hundred of such special commands and many terminals
  can even change fonts.

  The communication uses characters (letters) encoded using a code chart
  for the character set being used.  Usually, the first 128 bytes out of
  256 possible bytes use ASCII codes.  Terminals for unix-like systems,
  normally connect to computers via a cable running between the
  asynchronous serial ports (per RS-232-C = EIA-232-D) of the host
  computer and terminal.  Sometimes the connection is via modem or
  terminal server, etc.

  Other names for text terminals are "serial terminal", "character-cell
  terminal", "ASCII terminal", "ANSI terminal", "asynchronous terminal",
  "data terminal", "video terminal" and "video display terminal" (VDT).
  In olden days "video display unit" (VDU) was used for terminals but
  strictly speaking, it excludes the keyboard.

  Old IBM mainframe terminals use "block mode".  The characters you type
  are temporarily retained in the terminal memory (and may possibly be
  edited by a built-in editor at the terminal).  Then when the send key
  (or the like) is pressed, a block of characters (sometimes just a line
  of characters) is sent to the computer all at once.  Such terminals
  are not feasible to use with Linux.  They are actually block devices
  (and not character devices).  See section ``Block Mode''.


  1.4.2.  Graphics Terminals

  To a limited degree some ASCII symbols can provide graphics on text
  terminals.  One may form  arrows: <--- and draw boxes with _ and |.
  With special graphic character sets, even more is possible.  None of
  these are really graphics terminals.  However, the term "graphics
  terminal" is sometimes applied to all text-only terminals since text
  is a limited form of graphics.

  There are two basic types of graphics displays: raster and vector
  (rarely used).  Raster graphics (bit-mapped) puts dots on the screen
  by horizontal scan lines drawn by an electron beam (or by energizing
  pixels or dots on a flat screen.  Vector graphic displays use smart
  electronics to draw lines and curves with an electron beam that can
  move in any direction.  Vector graphics draws high quality lines
  without zig-zags but is both rare and expensive.  Raster graphics is
  almost universally used today.  For PC's, images encoded in vector
  graphic format are sometimes used but they are translated to raster
  graphics format for display (with a drop in image quality).


  1.4.3.  Serial Line Graphics Terminals

  Most of this document also applies to these.  Most of these can also
  function as text terminals.  The protocalls for such graphics include:
  Tektronix Vector Graphics, ReGIS (DEC), Sixel (DEC), and NAPLPS (North
  American Presentation Level Protocall Syntax).  All of these are
  monochrome ??


  1.4.4.  Fast Graphics Terminals (often known by other names)

  None of these covered in this document.  A terminal that deserves to
  be called smart is a graphics terminal which can rapidly display full-
  screen graphics just like a PC monitor.  It will also have a mouse.
  Bytes sent to it often represent bit-maps for pictures (and other
  graphics).  It will often use a high-speed connection to the computer
  using twisted pair or coax cable.  X-Window terminals are such
  devices.

  For displaying a MS-Windows GUI there are at various types of
  interfaces and terminals: Winterm using WinFrame software from Citrix
  is one.  Another (based in part on Citrix's code) is Hydra (code name)
  by Microsoft, also known as "Windows Terminal Server" which works with
  versions 4 or higher of MS Windows NT.  Citrix uses its ICA protocall,
  and has created an add-on to Hydra known as pICAsso so that WinFrame
  (ICA) based terminals can use the Hydra system.  Hydra is also
  multiuser.  There is also the "MultiConsole Personal Terminal" by
  Unbounded Technologies and Tektronix has its multi-user interface but
  will now support Hydra.  A magazine article in 1997 called Winterm a
  "dumb terminal" but it's really pretty smart.  Such terminals are
  often called "thin clients", but some thin clients are more that just
  terminals as they can execute Java code sent to them, etc.


  1.4.5.  Quasi-Terminals (= Quasi-Computers)

  "Quasi" is my terminology (not standard).  These are neither true
  computers nor terminals but are something in-between.  Network
  Computers (NC's) are computers with a CPU but no hard Disk.  They are
  full-graphics and connect to a server computer.  They are different
  from terminals since the programs they run execute on their own CPU
  chips.  Java code may be sent to them for execution.  They should work
  on IP networks and might work under a server running Linux.  Wintel
  established a "NetPC" which, unlike the NC, is almost a PC computer.
  However, it has no removable disks so users can't install their own
  software or obtain copies of anything.


  1.4.6.  Terminal Emulation

  Since a PC has a screen and keyboard (as does a terminal) but also has
  much more computing power, it's easy to use some of this computing
  power to make the PC computer behave like a text terminal.  Software
  to do this is widely available and comes built-in with recent versions
  of MS Windows.  An emulation program is often combined with a modem
  dialing program (such as Minicom for Linux) so that one may (for
  example) dial up public libraries to use their catalogs and indexes,
  (or even read magazine articles).  The terminal emulated is often the
  old VT100 (text terminal).  Sometimes the emulation is not 100%
  perfect but this usually causes few problems.

  A real terminal is often nicer to use than emulating one.  It usually
  costs less, often has better resolution for text, and has no disk
  drives to make annoying noises.  Some real terminals can emulate
  various models of terminals but it's still a real terminal.


  1.5.  Terminology

  Configuration means the same as set-up.  While Linux commands take
  options (using - symbols), options in a broader sense include various
  other types of choices.  Install in the broad sense includes setting
  up (configuring) software and hardware.  A statement that I'm
  uncertain about ends with 2 question marks: ??  Let me know if you
  know that it's correct (or in error).


  2.  Quick Install

  This is a quick procedure to install a terminal without going through
  a ``Setup'' procedure for both the terminal and the host computer.  It
  probably will not work right if the terminal happens to have been set
  up incompatible with the computer.  If you don't understand some of it
  you'll need to consult other parts of this document for more info.

  To install a terminal, first look in /etc/termcap or terminfo.src to
  find an entry for it (see ``Terminfo and Termcap (detailed)'').  You
  might try "vt100" if you can't find anything suitable.  Figure out
  what serial port you'll connect it to and what the tty designation is
  for that port (e.g. ttyS1, see ``Device Names''.  As the root user,
  edit /etc/inittab and add a getty command next to the other getty
  commands.  The format of the getty command depends on which getty
  program you use (see Serial-HOWTO 4.1 & 7.2 and/or type "man getty").
  For getty parameters use the terminfo (or termcap) name (such as
  vt100) for your terminal.  Type in a baud-rate that the terminal
  supports.  But if you set the baud too high you may need to use
  (See``Flow Control'').

  Then physically connect the serial ports of the terminal and computer
  together with a null-modem cable and turn on the terminal.  Don't
  expect most ready-made cables to be wired correctly for hardware flow
  control.  Make sure the baud-rate of the terminal is set the same as
  you gave to getty.  Then at the computer console type "init q" to
  apply the changes you made to the inittab file.  You should now see a
  login prompt at the terminal.  If you don't, tap the terminal's return
  key.  If this doesn't work read more of this document and/or see
  ``Trouble-Shooting''.


  3.  Why Use a Terminal ?

  3.1.  Introduction

  PC's are so powerful today that one such computer can often support
  several persons using it at once, especially if they are doing low-
  load tasks such as text editing, data entry, etc.  One way to do this
  is to connect a number of terminals to a single computer (host
  computer) by modems or direct cable connection.  To do this, one needs
  a multi-user operating system such as Linux.  This has been called
  "time sharing" but it's not good terminology today since "distributed"
  computing over a network is also a type of time sharing.  It might be
  better described as "centralized" computing.  But the central computer
  may be connected to the rest of the world via a network over which
  terminal users may communicate with, so it's not really "centralized"
  either.

  Terminals have seldom been used with PC's because the popular
  operating systems used for them (Windows, DOS, and Mac) were not
  multiuser until 1998 (available for MS Windows NT) and previously
  could not support terminals.  Now that Linux, a multiuser operating
  system, is freely available for PC's, the use of terminals with PC's
  becomes more feasible.  The drawback is that text terminals are not
  smart enough to support the type of graphical user interface (GUI)
  that many computer users today normally expect.


  3.2.  Lower Hardware Costs

  If several people use the same computer as the same time, there is a
  reduction in the amount of hardware needed for the same level of
  service.  One type of savings is due to code sharing.  The application
  files on hard disks are shared as well as shared libraries in memory
  (even when people are running different programs provided they use
  some of the same functions in their code).  Another type of savings is
  due to reduction of peak load.  The hardware of a single PC may be
  idle most of the time as people slowly type in information, think,
  talk, or are away from their desks.  Having several people on the same
  computer at once makes good use of much of this idle time which would
  otherwise be wasted.

  These savings are substantial.  One may roughly estimate that for 9
  persons (8 terminals & 1 console) the shared PC only needs about 3
  times as much capacity (in memory, disk storage, CPU(s), etc.) as a
  single PC in order to provide the same level of service per person (9
  times as much service overall).  Thus the computational hardware for
  such a shared system should only cost about 1/3 as much per user.
  However, the cost of the display hardware (CRT's, keyboards, video
  electronics, etc.) is about the same for both cases.  The terminals
  have the added cost of requiring additional serial ports at the host
  computer.

  For a fair comparison with PC's, the terminals should have the same
  capabilities as the PC monitors.  Unfortunately, color graphic
  terminals for Linux (X-windows) with high speed communication is a
  niche market with high prices so in this case there may not be much
  (if any) savings in hardware costs.  But for text terminals the
  savings will be substantial.


  3.3.  Control of Software

  For centralized computing, software (and the updates to software) only
  need be installed on one host computer instead of several.  The person
  in charge of this computer may control the software which is installed
  on it.  This is advantageous if the person controlling the host
  computer does an excellent job and knows about the needs and
  preferences of the other users.  Users can be prevented from playing
  games or surfing the Internet by not installing the software (or by
  otherwise restricting access to it).  Whether or not centralized
  control is desirable depends on the situation.


  3.4.  Hardware Upgrades

  With terminals, the computer hardware upgrades take place on only one
  computer instead of many.  This saves installation labor effort.
  While the cost of the hardware for the host computer upgrade will be
  more than that for a single PC (since the host needs more computing
  power than a PC), the cost will be significantly less than upgrading a
  number of PC's being used instead of terminals.





  3.5.  Other Advantages of Terminals


  1. The elimination of noise from fans and disk drives provided the
     terminals are not close to the computer.

  2. The users of the terminals can share data and files and even send
     e-mail to each other.  It's similar to a local network.


  3.6.  Major Disadvantages of Terminals



  1. For the case of a text terminal, it has no high-speed graphic
     display (or high resolution graphics) although it can sometimes use
     graphic character sets to draw lines, etc.  This lack limits the
     software that may be used on it.

  2. If the host computer goes down, then no one can use the terminals
     either (unless there is another computer to connect to).


  3.7.  Are Text Terminals Obsolete ?

  Text terminals are technologically obsolete because for a slightly
  higher cost of hardware, one could build a smart terminal (with the
  same quality of display).  This wasn't always the the case since
  around 1980 memory cost thousands of dollars per megabyte.  Today with
  low costs for memory and processors, one could make a text terminal
  smart for only about a 10% or 20% increase in cost.

  The reasons that text terminals are not yet obsolete are:

    Many people don't need full screen graphics.

    The only smart terminal for Linux is an X-Window terminal which may
     cost more than a PC running Linux.

    Used text terminals are often very low in cost, yet can give access
     to a much newer (and powerful) computer.


  4.  Overview of How Terminals Work (in Linux)

  See also section ``Some Details on How Terminals Work''


  4.1.  Device Names

  Each terminal is connected to a serial port on the host computer
  (often just a PC).  The ports have names: ttyS0, ttyS1, ttyS2 etc.
  These are represented by special files found in the /dev (device)
  directory.  /dev/ttyS0 corresponds to COM1 in DOS or Windows.  ttyS1
  is COM2, etc.  See ``Terminal Devices'' for more details.


  4.2.  Login/Logout

  When the host computer starts up it runs the program getty (see
  Serial-HOWTO 4.1 & 7.2) on each serial port which has a terminal on it
  (as specified in the file etc/inittab).  The getty program runs the
  "login" program to log people in.  A "login:" prompt appears on the
  screen.  People at the terminals log in (after giving their passwords)
  and then have access to the computer.  When it's time to shut the
  terminal down, one normally logs out and turns the terminal off.  See
  ``Login Restrictions'' regarding restricting logins (including
  allowing the root user to log in at terminal).


  4.3.  Half/Full Duplex

  If one watches someone typing at a terminal, the letters one types
  simultaneously appear on the screen.  A naive person might think that
  what one types is being sent directly from the keyboard to the screen
  with a copy going to the computer (called half-duplex).  What is
  usually going on is that what is typed at the keyboard is directly
  sent only to the host computer (called full-duplex) which in turn
  echos back to the terminal each character it receives.  In some cases
  (such as passwords or terse editor commands) the typed letters are not
  echoed back.


  4.4.  Terminal Memory

  The image on a CRT tube will fade away almost instantly unless it is
  frequently redrawn on the screen by a beam of electrons shot onto the
  face of the tube.  Since text sent to a terminal needs to stay on the
  screen, the image on the screen must be stored in the memory chips of
  the terminal and the electron beam must repeatedly scan the screen
  (say 60 times per second) to maintain the image.  See ``Terminal
  Memory'' for more details.


  4.5.  Commands for the Terminal

  The terminal is under the control of the computer.  The computer not
  only sends the terminal text to display on the screen but also sends
  the terminal commands which are acted on.  These are ``control codes''
  (bytes) and ``escape sequences''.  For example, the CR (carriage
  return) control code moves the cursor the the left hand edge of the
  screen.  A certain escape sequence (several bytes where the first byte
  is the "escape" control code) can move the cursor to the location on
  the screen specified by parameters placed inside the escape sequence.

  The ``first terminals'' had only a few such commands but modern
  terminals have hundreds of them.  The appearance of the display may be
  changed for certain regions: such as bright, dim, underline, blink,
  and reverse video.   A speaker in a terminal can "click" when any key
  is pressed or beep if a mistake has occurred.  Function keys may be
  programmed for special meanings.  Various fonts may exist.  The
  display may be scrolled up or down.  Specified parts of the screen may
  be erased.  Various types of flow control may be used to stop the flow
  of data when bytes are being sent to the terminal faster than the
  terminal can handle them.  There are many more as you will see from
  looking over a terminal manual.


  4.6.  Lack of Standardization Solved by Terminfo

  While terminals made for the US all used the same ASCII code for the
  alphabet (except for IBM terminals which used EBCDIC), they
  unfortunately did not all use the same escape sequences.  This
  happened even after various ANSI (and ISO) standards were established
  since these standards were never quite advanced enough.  Furthermore,
  older terminals often lacked the capabilities of newer terminals.
  This might cause problems.  For example, the computer might send a
  terminal an escape sequence telling it to split the screen up into two
  windows of specified size, not realizing that the terminal was
  incapable of doing this.


  To overcome these problems a database called "termcap" (now
  "terminfo") was established.  This database resides in certain files
  on the computer and has a section of it (sometimes an entire file) for
  each model of terminal.  For each model (such as VT100) a list of
  capabilities is provided including the available escape sequences to
  use, etc.  See Section ``Termcap and Terminfo (detailed)'' for more
  details.  Application programs may utilize this database by calling
  certain C-Library programs.  One large set of such programs (over 200)
  is named "ncurses" and are listed on the manual page for ncurses.


  4.7.  The Interface

  The environment variable TERM is the type of terminal Linux thinks you
  are using.  Application programs use this to look up the capabilities
  in the terminfo database so TERM needs to be set correctly.   But
  there is more to a correct interface than the computer knowing about
  the capabilities of the terminal.

  For bytes to flow from the computer to the terminal the terminal must
  be set to receive the bytes at the same baud rate (bits per second) as
  they are sent out from the terminal.  If the terminal is set to
  receive at 19,200 baud and the computer sends out characters at 9600
  baud, only garbage (or perhaps nothing) will be seen on the screen.
  One selects the baud rate for a terminal (as well as many other
  features) from the terminals "set-up" menus at the terminal.  Most
  terminals have a large number of options in their "set-up" menus.
  Computer serial port software has options also and these options must
  be set up in a compatible way.


  4.8.  Emulation

  Most terminals today have more than one personality (or emulation).
  The terminal model numbers of terminals formerly made by DEC (Digital
  Equipment Corporation) start with VT (e.g. VT100).  Many other
  terminals which are not VT100 may be set up to emulate a VT100.  Wyse
  is a major terminal manufacturer and most of their terminals can
  emulate various DEC terminals such at VT100 and VT220.  Thus if you
  want to, say, use a VT320 terminal you may either use a real VT320 in
  "native" personality or possibly use some other terminal capable of
  emulating a VT320.  The "native" personalities usually have more
  capabilities so, other things being equal, "native" is usually the
  best to use.

  The most common type of emulation is to use a PC like it was a
  terminal.  Programs loaded into the PC's memory permits this.  In
  Linux (unless you're in X-windows) the PC monitor (called the console)
  emulates a terminal.  Even certain windows within X-windows emulate
  terminals.


  4.9.  The Console

  On a PC, the monitor is known as the console.  It emulates a terminal
  of type "Linux".  One logs onto it as a virtual terminal.  See ``The
  Console: /dev/tty?''.  It receives messages from the kernel regarding
  booting and shutdown progress.  One may have the messages that
  normally go to the console, go the a terminal by patching and
  recompiling Linux. (see ``Make a Terminal the Console'').


  5.  Terminal Special Files: /dev/tty... etc.

  "tty" is an abbreviation for "Teletype".  The first terminals were
  Teletypes (like remotely controlled typewriters).  See subsection
  ``Teletypes''.


  5.1.  Serial Port Terminals

  The computer considers the terminal on a serial port to be a "device".
  For each such terminal there is a special file in the /dev (device)
  directory.  /dev/ttyS0 is the special file for the serial port known
  as COM1 in the DOS/Windows world.  To send text to a terminal you may
  redirect standard output of some command-line command to the
  appropriate special file.  For example typing "echo test > /dev/ttyS1"
  at the command prompt should send the word "test" to the terminal on
  COM2 (provided you have write permission on /dev/ttyS1).  Similarly,
  typing "cat my_file > /dev/ttyS0" will send the contents of the file
  my_file to COM1 (ttyS0).

  In addition to ttyS0 (/dev/ttyS0), ttyS1, ttyS2, etc. (the "S" stands
  for Serial port) there is also a "cua" series: cua0, cua1, cua2, etc.
  cua0 is the same port as ttyS0, etc.  The "cu" of cua stands for
  CalloUt.  The ttyS series are Posix compliant while using cua may
  permit the opening of a port that the modem control lines say is not
  ready.  It's claimed that the cua series is only included for
  backwards compatibility so you should probably use the ttyS series.


  5.2.  Pseudo Terminals

  Pseudo terminals have no unique physical connector on the computer.
  They are used to emulate a serial port.  For example, if someone
  connects via telnet to your computer over a network, they may wind up
  connected to the device /dev/ptyp2 (a pseudo terminal port).  In X-
  Windows, the terminal emulator program, xterm, uses pseudo terminals.
  Ham radio programs under Linux also use them.  Using certain
  application software it is possible to have 2 or more pseudo terminals
  attached to the same physical serial port.

  Pseudo terminals come in pairs such as ttyp3 and ptyp3.  The pty... is
  the master or controlling terminal and the tty... is the slave.  ttyq5
  is also a pseudo terminal as is ttysc (c is a hexadecimal digit).
  More precisely, pseudo master terminals are /dev/pty[p-s]n and the
  corresponding slaves are /dev/tty[p-s]n where n is a hexadecimal
  digit.


  5.3.  The Controlling Terminal /dev/tty

  /dev/tty stands for the controlling terminal (if any) for the current
  process (the process that uses "/dev/tty" in a command).  To find out
  which tty's are attached to which processes use the "ps -a" command at
  the shell prompt (command line).  Look at the "tty" column.  For the
  shell process you're in, /dev/tty is the terminal you are now using.
  Type "tty" at the shell prompt to see what it is (see manual pg.
  tty(1)).  /dev/tty is something like a link to the actually terminal
  device name with some additional features for C-programmers: see the
  manual page tty(4).


  5.4.  /dev/ttyI? "Terminals"

  ? stands for an integer.  One use of these in Linux is with the ISDN
  driver package: isdn4linux.  The ttyI? is something like ttyS?.  There
  is also a cui?  which is something like cua?.  The ttyI and cui
  emulate modems and may be given modem commands.



  5.5.  The Console: /dev/tty?

  In Linux the PC monitor is called the console and has several device
  special files associated with it: tty0, tty1, tty2, etc.  When you log
  in you are on tty1.  To go to tty2 press Alt-F2.  tty1, tty2, etc. are
  "virtual terminals" (sometimes called "virtual consoles").  You may
  log in to different virtual terminals and thus have a few different
  sessions with the computer going on at the same time.  You switch
  between them using the Alt-F?  key where "?" is the virtual-terminal
  number you want.  The console is also known as /dev/tty0 and system
  messages may go to that device and display on your console.  Only the
  system or the root user may write to /dev/tty0 to which /dev/console
  is sometimes linked.  System messages may also be written directly to
  the hardware address of the serial port card, thus bypassing
  /dev/tty0.  For more info on the console see ``The Linux Console''.


  5.6.  Creating a Device with mknod

  The /dev directory comes supplied with many device special files.  If
  you need something that's not there you may try to create it with the
  "mknod" command.  See the manual page tty(4) for how to do this for
  serial ports.  To use mknod you must know the major and minor device
  numbers.  You might be able to infer the numbers you need by using the
  "ls -l" command in the /dev directory.  It will display the major and
  minor numbers of existing special files.


  6.  Some Details on How Terminals Work

  If you know little about terminals, suggest you read the first
  section: ``Introduction'' and also read ``Overview of How Terminals
  Work''.


  6.1.  Terminal Memory

  The terminal screen refreshes itself at perhaps 60 times per second
  from an image stored in the memory of the terminal.  For a PC the
  monitor's image is stored on the video card inside the computer but
  for a terminal, the equivalent of the video card is inside the
  terminal.  For a text terminal the storage of the image uses little
  memory.  Instead of putting every dot (pixel) on the screen into
  memory and requiring the storage of about a quarter-million dots, a
  much more efficient method of storage is used.

  A screen-full of text may be represented inside the terminal memory by
  ASCII bytes, one for each character on the screen.   An entire screen
  only takes about 2K ASCII bytes.  To display these characters, the
  terminal must also know the bit-map (the shape) of each of the almost
  100 printable ASCII characters.  With a bit-map of a character using
  say 15 bytes, only about 1.5K of memory is needed for the bit-maps of
  all the ASCII characters (the font).  This ASCII text and font memory
  is scanned so that the resulting image is put on the screen about 60
  times each second.  This is a form of shared memory where a single
  bit-map of a letter such as the letter e, is shared by all of the many
  letter e's which appear on a screenfull of text.  Low memory
  requirements meant low costs to produce monitors in the early 1980's
  when the cost of memory was several thousand times higher than it is
  today (costing then several dollars per kilobyte).


  6.2.  Early Terminals

  The first terminals were something like remotely controlled
  typewriters which could only "display" (print on paper) the character
  stream sent to them from the computer.  The earliest models were
  called ``Teletypes''.  Early terminals could do a line feed and a
  carriage return just like a typewriter and ring a bell when a bell
  character was received.  Due to the lack of significant capabilities
  this was the first type of terminal to be labeled "dumb".  This type
  of terminal interface (using a terminal type called "dumb") is
  sometimes used today when the computer can't figure out what kind of a
  terminal it is communicating with.


  6.3.  Control Codes and Escape Sequences

  Terminals have many capabilities some of which are always present and
  some of which require commands from the computer to change or
  activate.  To exercise all these capabilities under the control of the
  computer requires that special codes be established so that the
  computer can tell the terminal what to do.  There are two major type
  of such codes: control codes (control characters) and escape
  sequences.


  6.3.1.  Control Codes

  The control codes (or control characters) consist of the first 32
  bytes of the ASCII alphabet.  They include the following: carriage-
  return (cursor to far left), line-feed (cursor down one line),
  backspace, escape-character, tab, and bell.  They do not normally show
  on the screen.  There is usually a command which you may give to your
  terminal which will result in them being displayed when they are
  received by the terminal.  It's called something like "Control
  Characters Visible".  If you do this then the display may look a mess
  since escape sequences, which all start with the ESC (escape) control
  character, are no longer executed.  Words which should appear at the
  top or bottom of the screen will show up in other locations.  The
  escape sequences to reposition the cursor display on the screen but
  the cursor doesn't move to where the escape sequence says.


  6.3.2.  Escape Sequences

  Since there are not nearly enough control codes to do everything, many
  escape sequences are used.  They consist of the "escape" (ESC) control
  character followed by a sequence of ordinary characters.  Upon
  receiving an escape character, the terminal examines the characters
  following it so that it may interpret the sequence and carry out the
  intended command from the computer.  Once it recognizes the end of a
  valid sequence, further characters received just display on the screen
  (unless they are control codes or more escape sequences).  Some escape
  sequences may take parameters (or arguments) such as the coordinates
  on the screen to move the cursor to.  The parameters become a part of
  the escape sequence.

  A list of the escape sequences for your terminal should be in the
  manual for the terminal.  Except for very old terminals, there may be
  two or three hundred such sequences.  If you don't have a manual it's
  not easy to find them.  For vt100, the sequences are available on the
  Internet.  By searching the Internet for one sequence (such as ESC[5m)
  you may come across a long list of them.  One way to determine some of
  them is to find the termcap (terminfo) for the terminal and mentally
  decode it.  See ``Terminfo and Termcap (detailed)'' in this document
  and/or the ``Termcap Manual'' on the Internet.  Unfortunately, the
  termcap (terminfo) for a terminal often does not list all of the
  escape sequences which the terminal has available for use, but
  fortunately, the most important ones are usually there.


  7.  Special Capabilities of Some Terminals

  7.1.  Color

  While the common monochrome terminal is not a color terminal it may
  have a fixed "color" display other than white such as green or amber.
  All terminals have black (electron beam turned off = zero brightness).
  A real color terminal can change the color of the text and background
  to many different colors while a monochrome terminal can only change
  the brightness of a fixed color.

  However, changing the brightness, etc. gives a lot of possibilities.
  For example, a black and white (monochrome) terminal can have white,
  grey, and black by varying the brightness.  Some words can be black on
  a light grey background while other are highlighted by black on white.
  In addition there is white on black, underlining, and blinking.

  Color works like the color on a computer monitor or TV screen.  The
  CRT has three colors of dots on it with each color controlled by its
  own electron beam (3 beams).  Monochrome has inherently better
  resolution since it doesn't depend on dots permanently fixed on the
  screen.  For text terminals the only use of color is to differentiate
  text and this advantage is not always worth the cost of worse
  resolution.  Thus monochrome may be better since it also costs less.


  7.2.  Dual Sessions

  For this the terminal has two serial ports.  Each port is connected to
  a serial port on a different computer.  Thus one may log in to two
  different computers with each session displaying in a split-screen
  window.   Alternatively, each session may run full-screen with a "hot"
  key (or the like) to switch between sessions.  One could also connect
  to two different serial ports on the same computer and log in twice
  (similar to "virtual terminals" at the console).


  7.3.  Printer/Auxiliary Port

  The terminal has two serial ports as above but the two ports are not
  identical in behavior.  If a printer is connected to the printer or
  auxiliary port, then pressing certain keys will print the screen.  One
  may also have everything that displays on the screen go also to the
  printer.  If the port is an auxiliary port one may connect this to
  another computer and almost have dual sessions as above.  However, the
  video memory inside the terminal may not retain both sessions so you
  may need to refresh the screen when switching to the other session.
  There will likely not be a hot key either but possibly a programmable
  function key may be programmed to do this.

  There exists various key combinations and escape sequences for
  controlling such a port.  It may be difficult to find out how to use
  this port without having a terminal manual.


  7.4.  Character-Sets

  A character-set is normally represented by a list (or table or chart)
  of characters along with the byte code assigned to each character.
  The codes for a byte range from 0 to 255 (00 to FF in hexadecimal).
  In MS-DOS, character-set tables are called "code-pages".  You should
  examine such a table if you're not familiar with them.  They are
  sometimes included in printer and terminal manuals but may be
  difficult to find.


  ASCII is one of the most common character-sets used on text terminals.
  It is a 7-bit code but can be made into 8-bit if the first bit (high
  order bit) is always set to 0.  Other character-sets are usually
  available (except on very old terminals where the only choice is
  ASCII).  The first half of most character-sets are the conventional
  ASCII characters and the second half (the characters with the high-
  order bit set to 1) belong to a wide variety of character-sets.
  Character sets are often ISO standards.  To get a non-ASCII character
  set on a terminal, you likely need to download a soft-font for that
  character-set into the memory of the terminal.

  Besides ASCII, there are some other common character-sets, all 8-bit.
  CP stands for Code Page character sets invented by IBM: CP-437 (DOS
  ECS), CP-850 (Multilingual Latin 1 --not the same as ISO Latin-1),
  ISO-8859-1 (Latin-1), ANSI (derived from Latin-1).  MS Windows uses
  ANSI while the Internet often uses Latin-1.  There are several
  ISO-8859 character sets in addition to Latin-1.  These include Greek
  (-7), Arabic (-6), Eastern European (-2), and Russian (-5).  There are
  many others.  For example, KOI8-R is more commonly used for Russian
  than IS0-8859-5.  Unicode is a very large character-set where each
  character is represented by 2 bytes instead on just one byte.

  Websites re character-sets are:

    <http://www.cc.columbia.edu/kermit/charsets.html> for a short
     listing of various character-set names.

    <http://www.pku.edu.cn/on_line/w3html/International/Overview.html>
     for info on character-sets and the Internet.

    <http://www.w3.org/International/O-charset-lang.html>

    <http://vancouver-webpages.com/multilingual/>

     Once you've found the character set name (or number) you are
     interested in, you may search for more info about it on the
     Internet.


  7.5.  Fonts

  Most terminals made after the mid 1980's can accept downloaded soft-
  font.  This means that they can display almost any character set
  provided that you can find the soft-font for it.  If you can't find
  the needed soft-font, you can always create your own.  A font editor
  for this is called BitFontEdit (written by the author of this
  document) and might be found at
  <http://www.cs.utk.edu/~shuford/terminal_index.html>


  7.6.  Keyboards & Special Keys

  Terminal keyboards often have a number of keys that one doesn't find
  on a PC keyboard.  Few (if any) actual terminals will have all of
  these keys and most will have additional keys not listed here.  Some
  have a large number of special purpose keys such as terminals made for
  use with cash registers.  There are often many more key meanings than
  shown here since these keys often have extended meanings when used in
  conjunction with other keys (such as shift and control).


    BREAK sends a very long 0 bit (+12 V) of duration 300 to 700
     milliseconds to the host.  The host may interrupt if its stty has
     set brkint or ignore it if ignbrk is set.


    NO SCROLL stops the screen from scrolling like ^S does.  Depressing
     it again resumes scrolling.  Uses flow control signals to do this.

    REPEAT if held down with an other key, forces repeated output of
     that other key even if the auto-repeat option is set to off.

    LINE FEED sends the line feed character ^J to the host.  Seldom
     used.

    SET-UP allows the manual configuration of the terminal via menus.
     Sometimes purposely disabled by putting a block under it so it
     can't be pressed down.

    LOCAL disconnects the terminal from the host.  In local, what one
     types goes directly to the screen.  Useful for testing.

    RETURN is the same as the "enter" key on a PC.  It usually sends a
     carriage return to the host which normally get translated to a new-
     line character by the host's device driver.  On some terminals it
     may be set up to send something else.

    F1, F2, ... or PF1, PF2, ... are function keys which usually may be
     programmed to send out a sequence of bytes (characters).


  7.7.  The Linux Console

  The console for a PC Linux system is the computer monitor  It emulates
  a terminal of type "Linux".  The emulation is flexible and has
  features which go well beyond those of the vt100 terminal it emulates.
  These include the ability to use custom fonts and easily remap the
  keyboard (without patching the source code and recompiling the kernel
  as is required for the case of a real terminal).  These extra features
  reside in the console driver software and not in the emulation
  software but the results are like it was part of the emulation.  Many
  commands exist (see Keyboard-and-Console-HOWTO, formerly just
  Keyboard-HOWTO) to utilize these added features.   Real terminals,
  which use neither scan codes nor VGA cards, unfortunately can't use
  most of these features.  One may recompile Linux to make a terminal
  receive the messages which normally go to the console (see ``Make a
  Terminal the Console'').


  7.7.1.  Make a Terminal the Console

  Many messages from the system are normally only sent to the console.
  While the messages generated at boot-time appear on the console, they
  may also be seen on a terminal after the boot succeeds by typing the
  command: dmesg.  If the boot fails this will not be of any use, so you
  may want to have a terminal display the messages during the booting.

  It's possible to patch the Linux kernel to do this and recompile it.
  This will send a terminal the messages which are normally sent only to
  the console.  It doesn't fully make the terminal into a console since
  one can't remap the keyboard nor change colors like most consoles can.
  The Linux Journal in April 1997 had an article on this.  To patch the
  Linux kernel add a couple of #defines at the start of
  src/linux/drivers/char/console.c:


  ______________________________________________________________________
  <item> #define CONFIG_SERIAL_ECHO
  <item> #define SERIAL_ECHO_PORT 0x2f8  /* Serial port address  */
  ______________________________________________________________________


  If you currently use the console to select which operating system to
  boot (using LILO), but would like to do this from a terminal, then you
  need to add a line to the /etc/lilo.conf file.   See the manual page
  for lilo.conf and search for "serial=".


  8.  Notes by Brand Name

  This section may eventually become so large that it will become a
  separate document (or a separate file for each terminal brand).  This
  would be of use for the many cases where one lacks manuals for their
  terminals.  You could help by writing up some info for the terminal
  you use and e-mailing it to me.  Sometimes, useful information for a
  certain model may be found in the comments of the terminfo (or
  termcap) entry in the file /etc/termcap or terminfo.src.


  8.1.  CIT

  CIT terminals were made in Japan in the 1980's for CIE Terminals.
  They ceased to be imported in the late 1980's.  The company, CIE,
  still makes CItoh printers (in 1997) but has no parts for its
  abandoned terminals.  Ernie at (714) 453-9555 in Irvine CA sells (in
  1997) some parts for models 224, 326, etc. but has nothing for the 80
  and 101.  (The document you are now reading was written mostly on the
  101e.)

  To save the Set-Up parameters press ^S when in Set-Up mode.  cit80:
  Contrast: knob on rear of terminal, cit101e: Brightness: use up/down
  arrow keys in Set-Up mode.


  8.2.  IBM

  Don't confuse IBM terminals with IBM PC monitors.  Many IBM terminals
  don't use ASCII but instead use an 8-bit EBCDIC code.  It's claimed
  that in EBCDIC the bit order of transmission is reversed from normal
  with the high-order bit going first.  The IBM mainframe communication
  standards are a type of synchronous communication in block mode (sends
  large packets of characters).  Two standards are "BISYNC" and "SNA"
  (which includes networking standards).  Many of their terminals
  connect with coax cable (RG62A/U) and naive persons may think the
  "BNC" connecter on the terminal is for ethernet (but it's not).

  While this IBM system is actually  more efficient than what is
  normally used in Linux, terminals meeting this IBM standard will not
  currently work with Linux.  However, some IBM terminals are
  asynchronous ASCII terminals and should work with Linux on PC's.  The
  numbers 31xx may work with the exception that 317x and 319x are not
  ASCII terminals.  Before getting an IBM terminal, make sure there is a
  termcap (terminfo) for it.  If their isn't, it likely will not work
  with Linux.  Even if there is a terminfo, it may not work.  For
  example, there is a termcap for 327x but the 3270 is an EBCDIC
  synchronous terminal.

  The 3270 series includes the 3278 (late 1970's), 3279 with color and
  graphics, and the 3274 terminal controller (something like the 3174).
  They may be used for both BISYNC and SNA.  The 3290 has a split screen
  (splits into quarters).

  The synchronous IBM terminals don't connect directly to the IBM
  mainframe, but connect to a "terminal controller" (sometimes called
  "cluster controller" or "communication controller").  Some of these
  controllers can convert a synchronous signal to asynchronous so that
  in this case a synchronous terminal could indirectly connect to a
  unix-like host computer via its serial port.  But there is still a
  major problem and that is block transmission.  See section ``Block
  Mode''.


  8.3.  Teletypes

  These are antiques and represent the oldest terminals.  They are like
  remotely controlled typewriters but are large and noisy.  Made by the
  Teletype Corp., the first models were made in the 1920's and predate
  the computer by over 30 years.  Early models used electro-mechanical
  relays and rotating distributors instead of electronics.  Their Baudot
  code was only 5-bits per character as compared to 7-bit ASCII.  See
  the book "Small Computer Systems Handbook" by Sol Libes, Hayden Books,
  1978: pp. 138-141 ("Teletypes").


  8.4.  VT (DEC)

  Digital Equipment Corporation made the famous VT series of terminals
  including the commonly emulated VT100.  In 1995 they sold their
  terminal business to SunRiver which is now named Boundless
  Technologies.  More information is available at Shuford's Website.
  Information on current products is available from the Boundless
  website.  See ``Terminal Info on the Internet''.

  VT220: Some have a BNC connector for video output (not for input).


  9.  Serial Communications on EIA-232 (RS-232)

  9.1.  Introduction

  Text terminals on Unix-like systems (and on PC's) are usually
  connected to an asynchronous 232 serial port of a computer.  It's
  usually a RS-232-C, EIA-232-D, or EIA-232-E.  These three are almost
  the same thing.  The original RS prefix became EIA (Electronics
  Industries Association) and later EIA/TIA after EIA merged with TIA
  (Telecommunications Industries Association).  The EIA-232 spec
  provides also for synchronous (sync) communication but the hardware to
  support sync is almost always missing on PC's.  The RS designation is
  obsolete but is still in use.  EIA will be used in this article.

  Older terminals use the 7-bit ASCII code for characters but most
  terminals made after 1990 permit other character sets which use 8-bit
  characters (256 possible characters).  In order to deal with terminals
  you should also read the relevant parts of the Serial-HOWTO and look
  at an ASCII code table.

  The serial port is more than just a physical connector on the back of
  a computer or terminal.  It includes the associated electronics which
  must produce signals conforming to the EIA-232 specification.  The
  standard connector has 25 pins, most of which are unused.  An
  alternative connector has only 9 pins.  One pin is used to send out
  data bytes and another to receive data bytes.  Another pin is a common
  signal ground.  The other "useful" pins are used mainly for signalling
  purposes with a steady negative voltage meaning "off" and a steady
  positive voltage meaning "on".

  The UART (Universal Asynchronous Receiver-Transmitter) chip does most
  of the work.  Today, the functionality of this chip is usually built
  into another chip.





  9.2.  Voltages

  9.2.1.  Voltage for a Bit

  At the EIA-232 serial port, voltages are bipolar (positive or negative
  with respect to ground) and should be about 12 volts in magnitude
  (some are 5 or 10 volts).   For the transmit and receive pins +12
  volts is a 0-bit (sometimes called "space") and -12 volts is a 1-bit
  (sometimes called "mark").  This is known as inverted logic since
  normally a 0-bit is both false and negative while a one is normally
  both true and positive.  Although the receive and transmit pins are
  inverted logic, other pins (modem control lines) are normal logic with
  a positive voltage being true (or "on" or "asserted") and a negative
  voltage being false (or "off" or "negated").  Zero voltage has no
  meaning (except that it is an error).

  A range of voltages is allowed.  The specs say the magnitude of a
  transmitted signal should be between 5 and 15 volts but must never
  exceed 25 V.  Any voltage received under 3 V is undefined (but some
  terminals will accept a lower voltage as valid).  One sometimes sees
  erroneous claims that the voltage is commonly 5 volts (or even 3
  volts) but it's usually 10-12 volts.  If you are using a EIA-422 port
  on a Mac computer as an EIA-232 (requires a special cable) or EIA-423
  then the voltage will actually be only 5 V.  The discussion here
  assumes 12 V.  There is much confusion about voltages on the Internet
  and at least one book erroneously claims that a positive voltage is a
  1-bit, unaware that EIA-232 uses inverted logic for transmitted data.

  Note that normal computer logic normally is 5 volts (often even less)
  so that if you try to use test equipment designed for testing 5 volt
  computer logic (TTL) on the 12 volts of a serial port, it may damage
  the test equipment.


  9.2.2.  Voltage Sequence for a Byte

  The transmit pin (#2) is held at -12 V (mark) at idle when nothing is
  being sent.  To start a byte it jumps to +12 V (space) for the start
  bit and remains at +12 V for the duration (period) of the bit.  Next
  comes the low-order bit of the data byte.  If it's a 0-bit nothing
  changes and the line remains at +12 V for another bit-period.  Then
  comes the next bit, etc.  Finally, a parity bit may be sent and then a
  -12 V (mark) stop bit.  The line remains at -12 V (idle) until the
  next start bit.  Note that there is no return to 0 volts and thus
  there is no simple way (except by a synchronizing signal) to tell
  where one bit ends and the next one begins for the case where 2
  consecutive bits are the same polarity (both zero or both one).

  A 2nd stop bit would also be -12 V, just the same as the first stop
  bit.  Since there is no signal to mark the boundaries between these
  bits, the only effect of the 2nd stop bit is that the line must remain
  at -12 V idle a little longer.  The receiver has no way of detecting
  the difference between a 2nd stop bit and a longer idle time between
  bytes.  Thus communications works OK if one end uses one stop bit and
  the other end uses 2 stop bits, but using only one stop bit is
  obviously faster.  In rare cases 1 1/2 stop bits are used.  This means
  that the line is kept at -12 V for 1 1/2 time periods (like a stop bit
  50% wider than normal).


  9.3.  Parity Explained

  Characters are normally transmitted with either 7 or 8 bits (of data).
  An additional parity bit may (or may not) be appended to this
  resulting in a byte length of 7, 8 or 9 bits.  Some terminal emulators
  and older terminals do not allow 9 bits.
  The parity may be set to odd, even or none (mark and space parity may
  be options on some terminals).  With odd parity, the parity bit is
  selected so that the number of 1-bits in a byte, including the parity
  bit, is odd.  If a such a byte gets corrupted by a bit being flipped,
  the result is an illegal byte of even parity.  This error will be
  detected and if it's an incoming byte to the terminal an error-
  character symbol will appear on the screen.  Even parity works in a
  similar manner with all legal bytes (including the parity bit) having
  an even number of 1-bits.  During set-up, the number of bits per
  character usually means only the number of data bits per byte (7 for
  true ASCII and 8 for various ISO character sets).

  A "mark" is a 1-bit (or logic 1) and a "space" is a 0-bit (or logic
  0).  For mark parity, the parity bit is always a one-bit.  For space
  parity it's always a zero-bit.  Mark or space parity only wastes
  bandwidth and should be avoided when feasible.  "No parity" means that
  no parity bit is added.   For terminals that don't permit 9 bit bytes,
  "no parity" must be selected when using 8 bit character sets since
  there is no room for a parity bit.


  9.4.  Forming a Byte (Framing)

  In serial transmission of bytes via EIA-232 ports, the low-order bit
  is always sent first.  Serial ports on PC's use asynchronous
  communication where there is a start bit and a stop bit to mark the
  beginning and end of a byte.  This is called framing and the framed
  byte is sometimes called a frame.  As a result a total of 9, 10, or 11
  bits are sent per byte with 10 being the most common.   8-N-1 means 8
  data bits, No parity, 1 stop bit.  This adds up to 10 bits total when
  one counts the start bit.  One stop bit is almost universally used.
  At 110 bits/sec (and sometimes at 300 bits/sec) 2 stop bits were once
  used but today the 2nd stop bit is used only in very unusual
  situations (or by mistake since it seemingly still works OK that way).


  9.5.  Limitations of EIA-232

  9.5.1.  Low Speed & Short Distance

  The conventional EIA-232 serial port is inherently low speed and is
  severely limited in distance.  Ads often read "high speed" but it can
  only work at high speed over very short distances such as to a modem
  located right next to the computer.  All of the wires use a common
  ground return so that twisted-pair technology (needed for high speeds)
  can't be used without additional hardware.  However some computers and
  terminals have more modern interfaces.  See ``Successors to EIA-232''.

  It is somewhat tragic that the RS-232 standard from 1969 did not use
  twisted pair technology which could operate about a hundred times
  faster.  Twisted pairs have been used in telephone cables since the
  late 1800's.  In 1888 (over 110 years ago) the "Cable Conference"
  reported its support of twisted-pair (for telephone systems) and
  pointed out its advantages.  But over 80 years after this approval by
  the "Cable Conference", RS-232 failed to utilize it.   Since RS-232
  was originally designed for connecting a terminal to a low speed modem
  located nearby, the need for high speed and longer distance
  transmission was apparently not recognized.


  9.5.2.  Successors to EIA-232

  A number of EIA standards have been established for higher speeds and
  longer distances using twisted-pair (balanced) technology.  Balanced
  transmission can sometimes be a hundred times faster than unbalanced
  EIA-232.  For a given speed, the distance (maximum cable length) may
  be many times longer with twisted pair.  But PC-s keep being made with
  the "obsolete" EIA-232 since it works OK with modems connected to slow
  telephone lines, and it works OK with mice.

  One exception is Apple's Mac computer with its EIA-232/EIA-422 GeoPort
  which provides twisted-pairs (balanced) for transmit and receive.  It
  uses a small round "mini-DIN" connector.  It also provides
  conventional EIA-232 but only at 5 volts (which is still legal
  EIA-232).  However, due to the fact that Macs cost more than PC's,
  they are seldom used as a host computer for terminals.  Some newer
  terminals use EIA-423 but this is just like the unbalanced EIA-232 and
  can be connected to a EIA-232 port.  This EIA-423 is only 5 volts, but
  the specs call for higher speeds than the EIA-232 (which will be of no
  help on a long run where it's the unbalance that causes interference).

  EIA-530-A (balanced but can also be used unbalanced) at 2Mbits/s
  (balanced) was intended to be a replacement for EIA-232 but few have
  been installed.  It uses the same 25-pin connector as EIA-232.  The
  High Speed Serial Interface ( HSSI = EIA-612/613) uses a 50-pin
  connector and goes up to about 50 Mbits/s but the distance is limited
  to only several meters.  The Universal Serial Bus (USB) is being built
  into PCI chips.  It is 12 Mbits/s over a twisted pair with a 4-pin
  connector (2 wires are power supply) but it also is limited to short
  distances.


  9.5.3.  Line Drivers

  For a text terminal, the EIA-232 speeds are fast enough but the
  useable cable length is often too short.  Balanced technology could
  fix this.  The common method of obtaining balanced communication with
  a text terminal is to install 2@ line drivers in the serial line to
  convert unbalanced to balanced (and conversely).  They are a specialty
  item and are expensive if purchased new.


  9.6.  Synchronization & Synchronous

  9.6.1.  How "Asynchronous" is Synchronized

  Per EIA-232 there are only two states of the transmit (or receive)
  wire: mark (-12 V) or space (+12 V).  There is no state of 0 V.  Thus
  a sequence of 1-bits is transmitted by just a steady -12 V with no
  markers of any kind between bits.  For the receiver to detect
  individual bits it must always have a clock signal which is in
  synchronization with the transmitter clock.  Such clocks generate a
  "tick" in synchronization with each transmitted (or received) bit.

  For asynchronous transmission, synchronization is achieved by framing
  each byte with a start bit and a stop bit (done by hardware).  The
  receiver listens on the line for a start bit and when it detects one
  it starts its clock ticking.  It uses this clock tick to time the
  reading of the next 7, 8 or 9 bits.  (It actually is a little more
  complex than this since several samples of a bit are often taken and
  this requires additional timing ticks.)  Then the stop bit is read,
  the clock stops and the receiver waits for the next start bit.  Thus
  async is actually synchronized during the reception of a single byte
  but there is no synchronization between one byte and the next byte.


  9.6.2.  Defining Asynchronous vs Synchronous

  Asynchronous (async) means "not synchronous".  In practice, an async
  signal is what the async serial port sends and receives which is a
  stream of bytes each delimited by a start and stop bit.  Synchronous
  (sync) is most everything else.  But this doesn't explain the basic
  concepts.

  In theory, synchronous means that bytes are sent out at a constant
  rate one after another (in step with a clock signal tick ).
  Asynchronous bytes may be sent out erratically with various time
  intervals between bytes (like someone typing characters at a
  keyboard).

  There are borderline situations that need to be classified as either
  sync or async.  The async serial port often sends out bytes in a
  steady stream which would make this a synchronous case but since they
  still have the start/stop bits (which makes it possible to send them
  out erratically) its called async.  Another case is where data bytes
  (without any start-stop bits) are put into packets with possible
  erratic spacing between one packet and the next.  This is called sync
  since the bytes within each packet must be transmitted synchronously.


  9.6.3.  Synchronous Communication

  Did you ever wonder what all the unused pins are for on a 25-pin
  connector for the serial port?  Most of them are for use in
  synchronous communication which is seldom implemented on PC's.  There
  are pins for sync timing signals as well as for a sync reverse
  channel.  The EIA-232 spec provides for both sync and async but PC's
  use a UART (Universal Asynchronous Receiver/Transmitter) chip such as
  a 16450, 16550A, or 16650 and can't deal with sync.  For sync one
  needs a USART chip or the equivalent where the "S" stands for
  Synchronous.  Since sync is a niche market, a sync serial port is
  likely to be quite expensive.

  Besides the sync part of the EIA-232, there are various other EIA
  synchronous standards.  For EIA-232, 3 pins of the connector are
  reserved for clock (or timing) signals.  Sometimes it's a modem's task
  to generate some timing signals making it impossible to use
  synchronous communications without a synchronous modem (or without a
  device called a "synchronous modem eliminator" which provides the
  timing signals).

  Although few serial ports are sync, synchronous communication does
  often take place over telephone lines using modems which use V.42
  error correction.  This strips off the start/stop bits and puts the
  date bytes in packets resulting in synchronous operation over the
  phone line.


  9.7.  Block Mode

  9.7.1.  Introduction

  Block mode is seldom used with Linux.  In block mode when one types at
  a terminal, the results are saved in the terminal memory and are not
  sent just yet to the host computer.  Such terminals often have built-
  in editing capabilities.  When the user presses certain keys (such as
  the send key) what has been saved in the terminal memory is sent to
  the host computer.  Now the Linux editors vi and emacs, react
  instantly to pressing certain keys but in the above situation such
  keys will be pressed and nothing will happen since nothing is sent
  when a key is pressed.  Thus using a block mode terminal will not
  allow the use of such interactive programs.  The old IBM mainframe
  interface uses block mode so many IBM terminals are block-mode only
  and also synchronous (see Section ``Synchronization & Synchronous'').




  9.7.2.  Types of Block Modes, Forms

  Block mode may itself have various sub-modes such as "page" (a page at
  a time) and "line" (a line at a time).  Some terminals have both block
  transmission modes and conventional character modes and may be
  switched from one mode to another.  Async terminals which have block
  modes include HP2622A, VT130, VT131, VT330, VT340, and Visual500.
  Block modes may include a forms capability where the host computer
  sends a form to the terminal.  Then the user fills it out and hits the
  send key which sends only the data in the form back to the host
  computer.  The form itself (not the data) is displayed on the screen
  in protected fields which don't get transmitted to the host.


  9.7.3.  Efficiency

  Block mode takes a great deal of load off the host computer,
  especially if the host computer's hardware is designed for block modes
  (as IBM's is/was).  In character mode every character typed is sent
  immediately to the serial port and usually causes an interrupt at the
  host computer.  The host that receives the byte must stop whatever it
  is doing and fetch that character from the port hardware.  Even with
  UART's that have larger hardware buffers the timeout may be such that
  it issues an interrupt for every character typed.

  In true block mode a long block of characters is received using only
  one interrupt.  If block mode is used with conventional async serial
  ports newer models can now get by with issuing an interrupt every 14
  bytes since they have 16-byte hardware buffers.  Thus much of the load
  and overhead of interrupt handling is eliminated and the computer has
  more time to do other tasks when block mode is used.

  A significant savings for block mode occurs if the terminal is
  connected to its host via a network.  Without block mode, every
  character (byte) typed is sent in its own packet including all the
  overhead bytes (40 in a TCP/IP packet as used on the Internet).  With
  block mode, a large number of characters are sent in a single packet.


  9.8.  EIA-232 (RS-232) Books

  (Note: The first book covers much more than just EIA-232.)

    Black, Uyless D.: Physical Layer Interfaces & Protocalls, IEEE
     Computer Society Press, Los Alamitos, CA, 1996.

    Campbell, Joe: The RS-232 Solution, 2nd ed., Sybex, 1982.

    Putnam, Byron W.: RS-232 Simplified, Prentice Hall, 1987.

    Seyer, Martin D.: RS-232 Made Easy, 2nd ed., Prentice Hall, 1991.


  10.  Flow Control (Handshaking)

  Some terminal manuals call "flow control" handshaking.  Flow control
  is to prevent too fast of a flow of bytes from overrunning a terminal,
  computer, modem or other device.  Overrunning is when a device can't
  process what it is receiving quickly enough and thus loses bytes
  and/or makes other serious errors.  What flow control does is to halt
  the flow of bytes until the terminal (for example) is ready for some
  more bytes.  Flow control sends its signal to halt the flow in a
  direction opposite to the flow of bytes it wants to stop.  Flow
  control must both be set at the terminal and at the computer.


  There are 2 types of flow control: hardware and software (Xon/Xoff).
  Hardware flow control uses a dedicated signal wire while software flow
  control signals by sending Xon or Xoff control bytes in the normal
  data wire.  For hardware flow control, the cable must be correctly
  wired.

  The flow of data bytes in the cable between 2 serial ports is bi-
  directional so there are 2 different flows to consider:

  1. Byte flow from the computer to the terminal

  2. Byte flow from the terminal keyboard to the computer.


  10.1.  Why Is Flow Control Needed ?

  You might ask: "Why not send at a speed slow enough so that the device
  will not be overrun and then flow control is not needed?"  This is
  possible but it's usually significantly slower than sending faster and
  using flow control.  One reason for this is that one can't just select
  any serial port baud rate such as 14,500.  There are only a discrete
  number of choices.  For speed, one should select a rate that is a
  little higher than the device can keep up with but then use flow
  control to make things work right.  Another reason is that the maximum
  rate that a device can cope with (without flow control) often depends
  on what is being sent.  Sending escape sequences to a terminal to get
  it to do complex things usually requires a slower baud rate at that
  time.  For a modem, the increase in effective flow by compressing the
  data sent to it depends on how much the data can be compressed.  This
  depends on the randomness of the data, so flow control is needed for
  modems too.


  10.2.  Overrunning a Serial Port

  One might wonder how overrunning is possible at a serial port since
  both the sending and receiving serial ports involved in a transmission
  of data bytes are set for the same speed (in bits/sec) such as 19,200.
  The reason is that although the receiving serial port electronics can
  handle the incoming flow rate, the hardware/software that fetches and
  processes the bytes from the serial port sometimes can't cope with the
  high flow rate.

  One cause of this is that the serial port's hardware buffer is quite
  small.  Older serial ports had a hardware buffer size of only one byte
  (inside the UART chip).  If that one received byte of data in the
  buffer is not removed (fetched) by CPU instructions before the next
  byte arrives, that byte is lost (the buffer is overrun).  Newer
  UART's, namely the 16550A, have 16-byte buffers (but may be set to
  emulate a one-byte buffer) and are less likely to overrun.  It may be
  set to issue an interrupt when the number of bytes in its buffer
  reaches 1, 4, 8, or 14 bytes.  It's the job of another computer chip
  (usually the main CPU chip for a computer) to take these incoming
  bytes out of this small hardware buffer and process them (as well as
  perform other tasks).

  When contents of this small hardware buffer reaches the specified
  limit (one byte for old UART'S) an interrupt is issued.  Then the
  computer interrupts what it was doing and software checks to find out
  what happened.  It finally determines that it needs to fetch a byte
  (or more) from the serial port's buffer.  It takes these byte(s) and
  puts them into a larger buffer (also a serial port buffer) that the
  kernel maintains in main memory.

  Terminals also have serial ports and buffers similar to the computer.
  Since the flow rate of bytes to the terminal is usually much greater
  than the flow in the reverse direction from the keyboard to the host
  computer, it's the terminal that is most likely to suffer overrunning.
  Of course, if you're using a computer as a terminal (by emulation),
  then it is likewise subject to overrunning.

  Risky situations where overrunning is more likely are:  1. When
  another process has disabled interrupts (for a computer).  2. When the
  serial port buffer in main (or terminal) memory is about to overflow.


  10.3.  Stop Sending

  When its appears that the receiver is about to be overwhelmed by
  incoming bytes, it sends a signal to the sender to stop sending.  That
  is flow control and the flow control signals are always sent in a
  direction opposite to the flow of data which they control (although
  not in the same channel or wire).  This signal may either be a control
  character (^S = DC3 = Xoff) sent as an ordinary data byte on the data
  wire (in-band signalling), or a voltage transition from positive to
  negative in the rts-cts (or other) signal wire (out-of-band
  signalling).  Using Xoff is called "software flow control" and using
  the voltage transition in a special signal wire (inside the cable) is
  called "hardware flow control".

  When a terminal is told to stop sending, the terminal "locks" its
  keyboard.  This seldom happens but when it does, a message or light
  should inform you that the keyboard is locked.  Anything you type at a
  locked keyboard is ignored.  The term "locked" is also used when the
  computer is told to stop sending to a terminal.  The keyboard is not
  locked so that whatever you type goes to the computer.  Since the
  computer can't send anything back to you, characters you type don't
  display on the screen and it may seem like the keyboard is locked but
  it's not.


  10.4.  Resume Sending

  When the receiver has caught up with its processing and is ready to
  receive more data bytes it signals the sender.  For software flow
  control this signal is the control character ^Q = DC1 = Xon which is
  sent on the regular data line.  For hardware flow control the voltage
  in a signal line goes from negative (negated) to positive (asserted).
  If a terminal is told to resume sending the keyboard is then unlocked
  and ready to use.


  10.5.  Hardware Flow Control (RTS/CTS etc.)

  Some older terminals have no hardware flow control while others use a
  wide assortment of different pins on the serial port for this.  The
  most popular seems to be the DTR pin.


  10.5.1.  RTS/CTS and DTR Flow Control

  Linux PC's use RTS/CTS, but DTR flow control (used by many terminals)
  behaves similarly (except it is only in one direction).  RTS/CTS uses
  the pins RTS and CTS on the serial (EIA-232) connector.  RTS means
  "Request To Send".  When this pin stays asserted (positive voltage) at
  the receiver it means: keep sending data to me.  If RTS is negated
  (voltage goes negative) it negates "Request To Send" which means:
  request not to send to me (stop sending).  When the receiver is ready
  for more input, it asserts RTS requesting the other side to resume
  sending.  For computers and terminals (both DTE type equipment) the
  RTS pin sends the flow control signal and the CTS pin (Clear To Send)
  receives the signal.  That is, the RTS pin on one end of the cable is
  connected to the CTS pin at the other end.

  For a modem (DCE equipment) it's a different setup since the modem's
  RTS pin receives the signal and its CTS pin sends.  While this may
  seem confusing, there are valid historical reasons for this which are
  too involved to discuss here.  For DTR flow control at a terminal the
  DTR signal is like the signal sent from the RTS pin.


  10.5.2.  Interfacing DTR with RTS/CTS flow control

  Many terminals use DTR flow control.  This is only one-way flow
  control to keep the terminal from being overrun.  It doesn't protect
  the computer from someone typing too fast for the computer to handle
  it.  How can one use this with Linux which uses RTS/CTS flow control?
  Since the DTR pin behaves like a RTS pin just treat the DTR pin at the
  terminal like it was the RTS pin and connect it to the CTS pin at the
  computer.  You will likely need to make up a special cable for this
  (or rewire a connector).  Thus one may use the DTR flow control at the
  terminal end of the cable with the RTS/CTS flow control at the
  computer end of the cable.  When using this you should "stty local"
  since the terminal DTR pin can't perform its usual function of telling
  the host computer that the terminal is turned on.


  10.5.3.  Old RTS/CTS Handshaking Is Different

  What is confusing is that there is the original use of RTS where it
  means about the opposite of the previous explanation above.  This
  original meaning is: I Request To Send to you.  This request was
  intended to be sent from a terminal (or computer) to a modem which, if
  it decided to grant the request, would send back an asserted CTS from
  its CTS pin to the CTS pin of the computer: You are Cleared To Send to
  me.  Note that in contrast to the modern RTS/CTS bi-directional flow
  control, this only protects the flow in one direction: from the
  computer (or terminal) to the modem.

  For older terminals, RTS may have this meaning and goes high when the
  terminal has data to send out.  The above use is a form of flow
  control since if the modem wants the computer to stop sending it drops
  CTS (connected to CTS at the computer) and the computer stops sending.


  10.5.4.  Reverse Channel

  Old hard-copy terminals may have a reverse channel pin (such as pin
  19) which behaves like the RTS pin in RTS/CTS flow control.  This pin
  but will also be negated if paper or ribbon runs out.  It's often
  feasible to connect this pin to the CTS pin of the host computer.
  There may be a dip switch to set the polarity of the signal.


  10.6.  Is Hardware Flow Control Done by Hardware ?

  Some think that hardware flow control is done by hardware but (unless
  you are using an intelligent serial card with several serial ports)
  it's actually done by your operating system software.  UART chips and
  associated hardware usually know nothing at all about hardware flow
  control.  When a hardware flow control signal is received, the signal
  wire flips polarity and the hardware gives an electrical interrupt
  signal to the CPU.  However, the hardware has no idea what this
  interrupt means.  The CPU stops what it was doing and jumps to a table
  in main memory that tells the CPU where to go to find a program which
  will find out what happened and what to do about it.


  It's this program (part of the serial device driver) that stops (or
  resumes) the sending.  This program checks the contents of registers
  in the UART chip to find out that a certain wire has changed polarity.
  Then the software realizes that a flow control signal has been
  received and goes about stopping (or starting) the flow.  However, if
  it's a stop signal that has been received, the flow stops almost
  instantly when the signal arrives because the interrupt has stopped
  whatever the CPU was doing (including the program that was sending the
  data and putting it in the serial ports hardware buffers for
  transmission).  However any bytes (up to 16) which were already in the
  serial port's hardware transmit buffer will still get transmitted ??
  Thus the hardware almost instantly stops the flow only because it's
  reaction to a hardware signal is to interrupt and stop everything the
  CPU was doing.


  10.7.  Obsolete ETX/ACK Flow Control

  This is also software flow control and requires a device driver that
  knows about it.  Bytes are sent in packets (via the async serial port)
  with each packet terminated by an ETX (End of Text) control character.
  When the terminal gets an ETX it waits till it is ready to receive the
  next packet and then returns an ACK (Acknowledge).  When the computer
  gets the ACK, it then send the next packet.  And so on.  This is not
  supported by Linux ??


  11.  Physical Connection

  A terminal may be connected to its host computer either by a direct
  cable connection, via a modem, or via a terminal server.


  11.1.  Direct Cable Connection.

  The simplest and cheapest way to connect a terminal to a host computer
  is via a direct connection to a serial port on the computer.  Most
  PC's come with a couple of serial ports, but one is usually used by a
  mouse.  For the EIA-232 port, you need a null modem cable that crosses
  over the transmit and receive wires.  Pin 2 at one end is wired to pin
  3 at the other end.  If you want hardware flow control, you must find
  out which pins of the terminal (if any) are used for it as different
  models of terminals use different pins.  The diagrams in Serial-HOWTO
  7.1 will not work for hardware flow control unless the RTS pin of the
  terminal is used for flow control.  It rarely is ??


  11.1.1.  Multiport I/O Cards (Adapters)

  Additional serial cards may be purchased which have several serial
  ports on them called "multiport boards" (see Serial-HOWTO 2.3 & 2.4).
  One company which has below average prices is ByteRunner
  <http://www.byterunner.com/cgi-bin/goto.cgi?FILE=iocards.html>.  For
  some other brands see Computer ESP
  <http://www.computer.esp.com/INPUT_DEVICES/PARALLEL___SERIAL_ADAPTERS/>


  11.1.2.  Length Limitations

  A cable longer than a 50 feet or so may not work properly at high
  speed.  Much longer lengths sometimes work OK, especially if the speed
  is low and/or the cable is a special low-capacitance type and/or the
  electronics of the receiving end are extra sensitive.  It is claimed
  that under ideal conditions at 9600 baud, 1000 feet works OK.  One way
  to cover long distances is to install 2@ line drivers near each serial
  port so as to convert unbalanced to balanced (and conversely) and then
  use twisted pair cabling.


  11.1.3.  Type of Cable

  If you expect to use hardware flow control (handshaking) you will
  likely need to make up your own cable (or order one made).   You will
  need to determine what pins the terminal uses for this and make up a
  compatible cable.  See ``Hardware Flow Control''.   Older terminals
  may have no provision for hardware flow control.

  If you don't use hardware flow control a ready-made cable may work OK
  (if you can find one long enough).  A null modem cable is often
  labeled as a printer cable with "null modem" in fine print.  In this
  cable certain pairs of wires are crossed-over (= flipped or cross-
  wired).  For example, pin 2 on one end goes to pin 3 on the other end,
  but not all pins are crossed-over.  Many ready-made null modem cables
  will cross over RTS and CTS (Pins 4 & 5) but these are probably not
  the pins the terminal uses for hardware flow control.

  The normal "straight thru" cable will not work unless you are using it
  as an extension cable in conjunction with either a null modem cable or
  a null modem adapter (a two-sided connector) to obtain the cross-over
  effect.  Make sure that the connectors on the cable ends will mate
  with the connectors on the hardware.  Most printer cables use a
  centronics connector on the printer end which will not connect to
  terminals.  One may use twisted-pair telephone cable.  Shielded,
  special low-capacitance cable is best.


  11.1.4.  A Kludge using Twisted-Pair Cable

  Although none of the EIA-232 signals are balanced for twisted pair one
  may attempt to use twisted-pair cable with it.  Use one pair for
  transmit and another for receive.  To do this connect signal ground to
  one wire in each of these 2 pair.  Only part of the signal ground
  current flows in the desired wire but it may help.  Due to the lower
  inductance of the twisted pair circuit, more return (ground) current
  will confine itself to the desired path than one would expect from
  only resistance calculations.  This is especially true at higher
  frequencies since inductive impedance increases with frequency.  The
  rectangular wave of the serial port contains high frequency harmonics.


  11.1.5.  Cable Grounding

  Pin 1 should be chassis ground (also earth ground) but on cheap serial
  ports it may not even be connected to anything.  The signal ground is
  pin 7 and is usually grounded to chassis ground.  This means that part
  of the signal current will flow thru the ground wires of the building
  wiring (undesirable).  Cable shields are supposed to be only grounded
  at one end of the cable, but it may be better to ground both ends
  since it's better to have current in the shield than in the building
  wiring ??


  11.2.  Modem Connection

  Using a terminal-modem combination (without a computer) one may
  connect to BBS's.  Some BBS's (such a free-nets) permit Internet
  access via the text browser lynx which will work on text terminals.
  Thus with an old terminal and external modem, one may connect to the
  Internet.  If one connects to a host computer on which one has an
  account, then one may sometimes store ones work (or downloads) on the
  host computer.  Of course one may also do this easier with a computer
  emulating a terminal using a communication program such as Minicom.
  11.2.1.  Dialing Out From a Terminal

  Instead of connecting a terminal (or computer emulating a terminal)
  directly to a host computer using a cable it may be connected to the
  host via a telephone line (or dedicated private line) with a modem at
  each end of the line.  The terminal (or computer) will usually dial
  out on a phone line to a host computer.

  This dialing out is commonly done using a PC computer with a modem to
  call a BBS or ISP where the PC emulates a terminal once it's
  connected.  If you use a real terminal for this it's more difficult
  since the real terminal isn't very intelligent and doesn't give as
  much feedback to the user.  For dialing out, many terminals can store
  one or more telephone numbers as messages which may be "set-up" into
  them and are sent out to the modem by pressing certain function keys.
  Many modems can also store phone numbers.  The modem initiation
  sequence must precede the telephone number.  The host computer may use
  "mgetty" (a getty for use with modems) to log in someone who has
  dialed in to the host.


  11.2.2.  Terminal Gets Dialed Into

  A less common situation is for the host computer to dial-out to a
  terminal.  One possible reason for doing this is to save on phone
  bills where rates are not symmetric.  To do this, your modem at your
  terminal should be set for automatic answer (Register S0 set to 2 will
  answer on the 2nd ring).  You turn on the terminal and modem before
  you expect a call and when the call comes in you get a login prompt
  and log in.

  The host computer that dials out to your terminal may do so by running
  the Linux program "callback" (not widely distributed yet) sometimes
  named "cb".  Callback is for having computer A call computer B, and
  then B hangs up and calls A back.  This is what you want if you are
  using computer A to emulate a terminal.  For the case of a real
  terminal this may be too complex a task so the host may utilize only
  the "back" part of the callback program.  The setup file for callback
  must be properly configured at the host.  Callback makes the call to
  the terminal and then has mgetty run a login on that port.  Mgetty by
  itself (as of early 1998) is only for dial-in calls but there is work
  being done to incorporate callback features into it and thus make it
  able to dial-out.  By the time you read this, mgetty may be all you
  need.


  11.2.3.  Modem Commands

  As of June 1997 there were no detailed listings of modem commands on
  the Internet for most modems.  However Hayes
  <http://www.hayes.com/support/techref/> has a list of its commands and
  many proposed initialization strings were listed.  These init strings
  may not be the best for the terminal situation where sending from the
  terminal is at very slow typing speeds but where you want the
  receiving speed as fast as feasible ??


  11.3.  Terminal Server Connection

  A terminal server is something like an intelligent switch that can
  connect a many terminals (or modems) to one or more computers.  It's
  not a mechanical switch so it may change the speeds and protocalls of
  the streams of data that go thru it.

  One use for it is to connect many terminals (or modems) to a high
  speed network which connects to host computers.  Of course the
  terminal server must have the computing power and software to run
  network protocalls so it is in some ways like a computer.  The
  terminal server may interact with the user and ask what computer to
  connect to, etc.  One may sometimes send jobs to a printer thru a
  terminal server.

  A PC today has enough computing power to act like a terminal server
  for text terminals except that each serial port should have its own
  hardware interrupt.  PC's only have a few spare interrupts for this
  purpose and since they are hard-wired you can't create more by
  software.  A solution is to use an advanced multiport serial card
  which has its own system of interrupts.

  Today real terminal servers serve more than just terminals.  They also
  serve PC's which emulate terminals, and are sometimes connected to a
  bank of modems connected to phone lines.  If a terminal is connected
  directly to a modem, the modem at the other end of the line could be
  connected to a terminal server.  In some cases the terminal server by
  default expects the callers to use PPP packets, something that text
  terminals don't generate.


  11.4.  Making or Modifying a Cable

  11.4.1.  Buy or Make ?

  If you need long cables to connect up terminals, how do you get them?
  Ready-made long cables may be difficult to find, especially if you
  want to use a minimum (say 4) of conductors.  One option is to get
  them custom made, which is likely to be fairly expensive although you
  might find someone to make them at prices not too much higher than
  ready-made cable (I did).  Another alternative is to make your own.
  This may require special tools.  If you can find it, used cable can be
  a real bargain but you will probably need to rewire the connectors.
  One advantage of making your own cable is that the skills you learn
  will come in handy if a cable breaks (or goes bad) or if you need to
  make up another cable in a hurry.


  11.4.2.  Connectors & Pins

  Unfortunately, most cables one purchases today have molded connectors
  on each end and can't be modified.  Others have connectors which
  unscrew and can be rewired.  If you are making up cable or modifying
  an existing one then you need to know about pins.  There are two
  types: soldered and crimped.

  The crimped pins require a special crimping tool and also need an
  "insertion/extraction" tool.  But once you have these tools, making up
  and modifying cable is a lot faster than soldering.  To insert pins
  just push them in with the tool.  Removing a pin with the tool
  requires some tricks.  You must insert the tool tip around the back of
  the pin.  One tool tip requires spreading a little to get it over the
  wire but for this tip the pin should be easier to remove.  Then pull
  on both the tool and the wire with a gentle jerk.  If it doesn't come
  out, the tool was likely not inserted correctly or you should use
  another tip that goes more around the pin.  Using this tool one may
  readily convert a straight-thru cable to a null-modem cable, etc.

  Don't try soldering unless you know what you're doing or have read
  about how to do it.





  12.  Set-Up (Configure) for both Computer & Terminal

  12.1.  Introduction

  Part of the set-up is setting up the physical terminal by saving (in
  its non-volatile memory) the characteristics it will have when it is
  powered on.  In addition (or as an alternative), the terminal may be
  configured by sending escape sequences to it from the computer, but
  this configuration will usually be lost when the terminal is powered
  down.  So if you know how to set up and save the configuration inside
  the terminal it's likely the best way.

  Another part of the setup is letting the computer know what kind of
  terminal you have connected it to and how the terminal has been set
  up.  The environment variable TERM stores the name of the terminal and
  makes it easy for programs to look up the terminal capabilities under
  this name in the terminfo directory.  See ``Terminfo & Termcap
  (brief)''.

  Programs called "stty" and "setserial" configure the serial port at
  the computer (including it's device driver software).  These programs
  (if needed) must be run each time the computer starts up since the
  configuration is lost each time the computer powers down.

  There are a great many options for you to choose from.  Some options
  concern only the terminal and do not need to be set at the computer.
  For example: Do you want black letters on a light background?  (This
  is easier on the eyes than a black background.)  Should a key repeat
  when held down?  Should the screen wrap when a line runs off the right
  end of the screen?

  The "communication interface" options must be set exactly the same at
  the computer and inside the terminal: speed, parity, bits/character,
  and flow control.  Until these are compatibly set up there can be no
  satisfactory serial communication (and possibly no communication at
  all) between the terminal and the computer.  One must set these by
  doing it manually at each terminal (or using some sort of special
  cartridge at each terminal).  The host computer is configured by
  adding commands to certain files on its hard disk which will be
  executed each time the computer starts (or when people log in).

  While all this may seem overly complex, to get a terminal working is
  often fairly simple.  The ``Quick Install'' section describes a simple
  way to try to do this.  But to make the display look better and
  perform better more work may be needed.


  12.2.  Terminal Set-Up

  Once the communication interface is established, the rest of the
  configuration of the terminals may sometimes be done by sending
  commands to the terminals from the computer.  If you have a large
  number of terminals, it may be worthwhile to write (or locate) a shell
  script to automatically do this.  There may (or may not) be a command
  you can send to a terminal to tell it to save its current set-up in
  its non-volatile memory so that it will be present the next time the
  terminal is powered on.

  If you have a manual for your terminal, you should also consult it.
  You may send commands to configure the terminal using the programs
  "tput" and "setterm".  See ``Changing the Terminal Settings''.  You
  could just send the terminal an init string from the terminfo entry if
  the init string sets up the terminal the way want it.  Unless you plan
  to send these sequences from the computer to the terminal each time
  the terminal is powered on, you must somehow save the settings in the
  non-volatile memory of the terminal.
  To set up a terminal you usually need to enter set-up mode by
  depressing the "set-up" key (or the like).  This will display a menu
  from which you may go to other menus.  How to go to other menus may
  (or may not) be inferred from the display.  Look at the keyboard for
  labels just above the top row of numeric keys.  If they exist, these
  labels may be what these keys do in set-up mode.  Older terminals may
  only have only one "set-up" menu.  Still older ones have physical
  switches.  In some cases not all the switches are well labeled.  They
  may even be DIP switches hidden in obscure locations with no labels.

  Unless you set up the terminal by throwing switches, your set-up must
  be saved in the non-volatile memory of the terminal so that it will be
  effective the next time you turn on the terminal.  If you fail to save
  it, then the new settings will be lost when you turn off the terminal.
  Before you go to the trouble of setting up a terminal, make sure that
  you know how to save the settings.  In some older terminals, only the
  manual tells how to save them.


  12.3.  At the Computer

  (Of course you might do this from any working terminal connected to
  the computer.)


  12.3.1.  Inittab

  There are various files to edit to set up the computer for terminals.
  With luck, only one file on the computer needs to be changed:
  /etc/inittab.  Add a new getty command(s) to this file next to the
  existing getty command(s).  Getty will start a login process on the
  serial port(s) of your choice and tell the computer what kind of
  terminal you have via the TERM environment variable (see Serial-HOWTO
  4.1 & 7.2 and/or type "man getty").

  If you are not using modem control lines (for example if you only use
  the minimum number of 3 conductors: transmit, receive, and common
  signal ground) you must let getty know this by using a "local" flag.
  The format of this depends on which getty you use.


  12.3.2.  Stty & Setserial

  There is both a "stty" command and a "setserial" command for setting
  up the serial ports.   Some (or all) of the needed stty settings can
  be done via getty and there may be no need to use setserial so you may
  not need to use either command.  These two commands (stty and
  setserial) set up different aspects of the serial port.  Stty does the
  most while setserial configures the low-level stuff such as interrupts
  and port addresses.  To "save" the settings, these commands must be
  written in certain files (shell scripts) which run each time the
  computer starts up.  You may also use the stty and setserial commands
  on the command line, but such settings will be lost as soon at you
  turn off the computer.


  12.3.3.  Setserial

  Setserial can change both the interrupt (IRQ) number and the port
  address.  It can tell you what type of UART chips you have.  It can
  set the time that the port will keep operating after it's closed (in
  order to output any characters still in its buffer in main RAM).  This
  is needed at slow baud rates of 1200 or lower.  For setserial to work,
  the serial module (for the Linux kernel) must be loaded.  If you use
  more than 2 serial ports you need to use setserial to assign unique
  IRQ numbers.
  12.3.4.  Where to Run Setserial ?

  To modify (or add) a setserial command, edit the shell script that
  runs setserial.  Where it resides depends on your distribution.  It
  might be in /etc/rc.d in a "rc.local" or "rc.serial" file.  In the
  Debian distribution it was the 0setserial file in /etc/rc.boot but
  this eventually should change to a file in /etc/init.d.


  12.3.5.  Stty

  Stty does most of the configuration of the serial port.  To see how
  it's now set for the terminal (or console) you're now at type at the
  shell prompt: stty -a.  For other terminals (such as ttyS1) type: stty
  -a < /dev/ttyS1.  Here are some of the items stty configures: speed
  (bits/sec), parity, bits/byte, # of stop bits, strip 8th bit?, modem
  control signals, flow control, break signal, end-of-line markers,
  change case, padding, beep if buffer overrun?, echo, allow background
  tasks to write to terminal?, define special (control) characters (such
  as what keys to press for interrupt).  See the manual (type: man stty)
  for more details.  For use of some special characters see ``Special
  (Control) Characters''

  With some implementations of getty, the commands that one would
  normally give to stty are typed into a getty configuration file:
  /etc/gettydefs.  Even without this configuration file, the getty
  command line may be sufficient to set things up so that you don't need
  stty.

  One may write C programs which change the stty configuration, etc.
  Looking at the documentation for this may help one better understand
  the use of the stty command (and its many possible arguments).
  Serial-Programming-HOWTO is useful.  The manual page: termios contains
  a description of the C-language structure (of type termios) which
  stores the stty configuration in computer memory.  Many of the flag
  names in this C-structure are almost the same (and do the same thing)
  as the arguments to the stty command.


  12.3.6.  Where to Put the Stty Command ?

  To have stty set up the terminal each time the computer starts up you
  need to put the stty command in a file that will be executed each time
  the computer is started up (Linux booted).  This file should be run
  before getty starts.  There are many possible places to put it.  If it
  gets put in more than one place and you only know about (or remember)
  one of those places, then a conflict is likely.  So make sure to
  document (perhaps in your terminal manual) where it's put.

  One good place to put it would be in the same file that runs setserial
  when the system is booted.  See ``Where to Run Setserial?''.  It would
  seem best to put it after the setserial command so that the low level
  stuff is done first.  In the Debian distribution there is an
  /etc/init.d/bootmisc.sh script but it currently runs before 0setserial
  does.  Example line: stty crtscts < /dev/ttyS1.


  12.3.7.  Terminfo & Termcap (brief)

  See ``Terminfo and Termcap (detailed)'' for a more detailed discussion
  of termcap.  Many application programs that you run use the terminfo
  (formerly termcap) data base.  This has an entry for each model or
  type (such as vt100) of terminal and tells what the terminal can do,
  what codes to send for various actions, and what codes to send to the
  terminal to initialize it.

  Since many terminals (and PC's also) can emulate other terminals and
  have various "modes" of operation, there may be several terminfo
  entries from which to choose for a given physical terminal.  They
  usually will have similar names.  The last parameter of getty should
  be the terminfo name of the terminal (or terminal emulation) that you
  are using (such as vt100).

  The terminfo does more than just specify what the terminal is capable
  of doing and disclose what codes to send to the terminal to get it to
  do those things.  It also specifies what "bold" will look like, what
  the cursor will look like, if the letters will be black, white, or
  some other color, etc.  In PC terminology these are called
  "preferences".  It also specifies initialization codes to send to the
  terminal (analogous to the init strings sent to modems).  If you don't
  like the way the display on the screen looks and behaves you may need
  to edit (and then install) the terminfo (or termcap) file.


  12.4.  Communication Interface Settings

  These settings are:

    ``Speed (bits/second) ''

    ``Parity ''

    ``Bits per Character ''

    ``Flow Control ''

  The above settings must be set the same at both the terminal and
  computer.  At the computer these may often set by using parameters to
  the getty command in the /etc/inittab file.  All of them may be set at
  the computer with the "stty" command which you might put in a shell
  script.  The script must be run each time the computer starts up.  You
  could put the stty command in an existing script file which is run at
  boot-time.  See ``Where to Put the Stty Command ?''


  12.4.1.  Speed

  These must be set the same on both the terminal and the computer.  The
  speed is the bits/sec (bps or baud rate).  9,600 is often fast enough,
  but if a faster speed improves performance without errors, use it.
  There may be two speeds to set at the terminal: Transmit and Receive,
  sometimes abbreviated T and R.  Usually they are both set the same.
  Common speeds are 300, 600, 1200, 2400, 4800, 9600, 19200, ...  An old
  terminal may even have a speed of 2 to be compatible with teletypes of
  the 1920's that formed serial bytes by mechanical means without
  electronics.


  12.4.2.  Parity

  For a definition see ``Parity Explained''.  Parity disabled is often
  the default.  To enable parity, you must both enable it and then
  select either even or odd parity.  It probably makes no difference
  which one you choose.  For terminals there are sometimes settings for
  both transmit and receive parity.  You should set both of these the
  same since stty at the computer doesn't permit setting them
  differently.

  Should you use parity  at all?  Parity, while not really necessary, is
  nice to have.  If you don't have parity, then you may get an incorrect
  letter here and there and wind up correcting spelling errors that
  don't really exist.  However parity comes at a cost.  First, it's a
  little more complicated to set up since the default is usually no
  parity.  Secondly, parity will slow down the speed with which bytes
  travel over the serial cable since there will be one more bit per
  byte.  This may or may not slow down the effective speed.

  For example, a hard-copy terminal is usually limited by the mechanics
  of the printing process.  Increasing the bytes/sec when the computer
  (its UART chip) is transmitting only results in more flow-control
  "halt" signals to allow the mechanical printing to catch up.  Due to
  more flow-control waits the effective speed is no better without
  parity than with it.  The situation is similar for some terminals.

  One option is to install terminals with no parity.  Then if parity
  errors are noticed, it can be implemented later.  To spot possible
  errors with no parity, look for any spelling errors you don't think
  you made.  If you spot such an error, refresh the screen (retransmit
  from the computer).  If the error goes away, then it's likely a parity
  error.  If too many such errors happen (such as more than one ever
  hundred screens) then corrective action is needed such as:  Enable
  parity and/or reduce speed, and/or use a shorter/better cable.
  Enabling parity will not reduce the number of errors but it will tell
  you when an error has happened.

  Just the opposite policy is to initially enable parity.  Then if no
  parity errors (error symbols on the CRT) are ever seen (over a
  reasonable period of time, say a month or two) it may be safely
  disabled.


  12.4.3.  Bits/Character

  This is the character size (the number of data bits per character).
  For ASCII it's 7,  but it's 8 for ISO character sets.  If you are only
  going to use ASCII characters, then select 7-bits since it's faster to
  transmit 7 bits than 8.  Some older terminals will only display 7-bit
  characters.


  12.4.4.  Which Flow Control ?

  The choice is between "hardware" (for example rts/cts + dtr/dsr) or
  "software" (Xon/Xoff) flow control.  While hardware may be faster (if
  the two extra wires for it are available in the cable and if the
  terminal supports it) in most cases Xon/Xoff should work OK.  Some
  people report that they solved disturbing problems by converting to
  hardware flow control but software flow control has worked fine at
  other installations (and for me personally).

  If you use software (Xon/Xoff) flow control and have users who don't
  know about it, then they may accidentally send an Xoff to the host and
  lock up their terminal.  While it's locked, they may type frantically
  in a vain attempt to unlock it.  Then when Xon is finally sent to
  restore communication, all that was typed in haste gets executed,
  perhaps with unexpected results.  They can't do this with hardware
  flow control.  See ``Flow Control'' for an explanation of flow
  control.


  12.5.  Rarely Needed /etc/ttytype File

  The configuration file /etc/ttytype is used to map /dev/ttySn's to
  terminal names per terminfo.  tset uses it, but if the TERM
  environment variable is already set correctly, then this file is not
  needed.  Since the Linux getty sets TERM for each tty, you don't need
  this file.  In other Unix-like systems such as FreeBSD, the file
  /etc/ttys maps ttys to much more, such as the appropriate getty
  command, and the category of connection (such as "dialup").  An
  example line of Linux ttytype: vt220 ttyS1


  12.6.  Login Restrictions

  By default, the root user may not login from a terminal.  To permit
  this you must create (or edit) the file /etc/securetty per the manual
  page "securetty".  To restrict logins of certain users and/or certain
  terminals, etc. edit /etc/login.access (this replaces the old
  /etc/usertty file ??).  /etc/login.def determines if /etc/securetty is
  to be used and could be edited so as to make /etc/securetty not needed
  (or not used).  /etc/porttime restricts the times at which certain
  ttys and users may use the computer.  If there are too many failed
  login attempt by a user, that user may be prohibited from ever logging
  in again.  See the man page "faillog" for how to control this.


  12.7.  Run Command Only If TERM=my_term_type

  Sometimes there are commands that one wants to execute at start-up
  only for a certain type of terminal.  To do this for the stty command
  is no problem since one uses the redirection operator < to specify
  which terminal the command is for.  But what about shell aliases or
  functions?  You may want to make a function for the ls command so it
  will color-code the listing of directories only on color terminals or
  consoles.  For monochrome terminals you want the same function name
  (but a different function body) which will use symbols as a substitute
  for color-coding.  Where to put such function definitions that are to
  be different for different terminal?

  You may put them inside an "if" statement in /etc/profile which runs
  at startup each time one logs on.  The conditional "if" statement
  defines certain functions, etc. only if the terminal is of a specified
  type.  While much of what this if statement does could be done in the
  configuration file for dircolors, here's an example:


  ______________________________________________________________________
  if [ $TERM = linux ]; then
      eval `dircolors`;
  elif [ $TERM = vt220 ]; then
      ls () { command ls -F $* }
      declare -xf ls
  else echo "From /etc/profile: Unknown terminal type $TERM"
  fi
  ______________________________________________________________________




  13.  Terminfo and Termcap (detailed)

  13.1.  Introduction

  Terminfo (formerly Termcap) is a database of terminal capabilities and
  more.  For every (well almost) model of terminal it tells application
  programs what the terminal is capable of doing.  It tells what escape
  sequences (or control characters) to send to the terminal in order to
  do things such as move the cursor to a new location, erase part of the
  screen, scroll the screen, change modes, change appearance (colors,
  brightness, blinking, underlining, reverse video etc.).  After about
  1980, many terminals supported over a hundred such commands.



  13.2.  Terminfo Database

  The terminfo database is compiled and thus has a source part and a
  compiled part.  The old termcap database has only a source part but
  this source can be both converted to terminfo source and then compiled
  by a single command.  To see if your terminal (say vt100) is in the
  terminfo data base type "locate vt100".  It may show
  /usr/lib/terminfo/v/vt100 or /usr/share/terminfo/v/vt100 which are
  possible locations of the compiled terminfo files.  Some older
  programs may expect it to be in the /etc/terminfo directory.

  The source code you use may reside in /etc/termcap and/or in
  terminfo.src.  See the man pages: terminfo(5) or termcap(5) for the
  format required to create (or modify) these files.  The file
  terminfo.src may be in various locations or it may not be included
  with your linux distribution.  Use the locate command to try to find
  it.  It is available for downloading (under the name termtypes.ti)
  from  <locke.ccil.org/~esr/terminfo>


  13.2.1.  Terminfo Compiler (tic)

  The data in the source files is compiled with the "tic" program which
  is capable of converting between termcap format and terminfo format.
  Thus you can create a compiled terminfo data base from termcap source.
  The installation program which was used to install Linux probably
  installed the compiled files on your hard disk so you don't need to
  compile anything unless you modify /etc/termcap (or terminfo.src ).
  "tic" will automatically install the resulting compiled files into a
  terminfo directory ready to be used by application programs.


  13.2.2.  Look at Your Terminfo

  It's a good idea to take a look at your termcap/terminfo entry (source
  code of course) and read the comments.  A quick way to inspect it
  without comments is to just type "infocmp".  But the comments may tell
  you something special about the terminal such as how you need to set
  it up so that it will work correctly with the terminfo database.


  13.2.3.  Deleting Data Not Needed

  In order to save disk space, one may delete all of the database except
  for the terminals types that you have.  Don't delete any of the Linux
  termcaps or the xterm ones if you use X-Windows.  The terminal type
  "dumb" is used when an application program can't figure out what type
  of terminal you are using.  It would save disk space if install
  programs only installed the terminfo for the terminals that you have
  and if you could get a termcap for a newly installed terminal over the
  Internet in a fraction of a second.


  13.3.  Initialization

  Included in the terminfo are often a couple of initialization strings
  which may be sent to the terminal to initialize it.  This may change
  the appearance of the screen, change what mode the terminal is in,
  and/or make the terminal emulate another terminal.  The initialization
  strings are not automatically sent to the terminal to initialize it.
  You must use a command given on the command line (or in a shell
  script) to do it such as: "tset", "tput init", or "setterm
  -initialize".  Sometimes there is no need to send the init string
  since the terminal may set itself up correctly when it is powered on
  (using options/preferences one has set up and saved in non-volatile
  memory of the terminal).
  13.4.  TERM Variable

  The Environment variable TERM should be set to the type of terminal
  which you are using.  It is normally set by the terminal_type
  parameter passed to the getty program (look at it in the /etc/inittab
  file).  This name must be in the Terminfo data base.  Just type "set"
  at the command line to see what TERM is set to (or type: tset -q).  At
  a console (monitor) TERM is set to "linux" which is the PC monitor
  emulating a fictitious terminal model named "linux".  Since "linux" is
  close to a vt100 terminal and many text terminals are also, the
  "linux" designation will sometimes work as a temporary expedient with
  a text terminal.

  If more than one type of terminal may be connected to the same port
  (/dev/tty...) (for example, if there is a switch to permit different
  terminal types to use the same serial port, or if the port is
  connected to a modem to which people call in from different types of
  terminals) then TERM needs to be set each time someone connects to the
  serial port.  There is often a query escape sequence so that the
  computer may ask the terminal what type it is.  Another way is to ask
  the user to type in (or select) the type of terminal s/he is using.
  You may need to use tset of write a short shell script to handle this.


  One way to do this is to use "tset" (see the manual page).  tset tries
  to determine the terminal name of the terminal you are using.  Then it
  looks up the data in terminfo and sends your terminal an init string.
  It can also set the value of TERM.  For example, a user dials in and
  logs in.  The .profile login script is executed which contains within
  it the following statement: eval `tset -s ?vt100`.  This results in:
  The user is asked if s/he is using a vt100.  The user either responds
  yes or types in the actual terminal type s/he is using.  Then tset
  sends the init string and sets TERM to this terminal name (type).


  13.5.  Termcap Documents



    The Termcap Manual
     <http://www.delorie.com/gnu/docs/termcap/termcap_toc.html> by
     Richard M. Stallman is a GNU manual.

    manual pages for terminfo(5) and/or termcap(5).

    /etc/termcap (a file) or terminfo.src has info about various
     versions of termcap files, naming conventions for terminals, and
     special capabilities code named u6-u9

    "Termcap and Terminfo" is a book published by O'Reilly in 1988.


  14.  Using the Terminal

  14.1.  Introduction

  This section is about the controlling the terminal-computer interface
  and/or changing the terminal set-up while using the terminal.  It
  explains (or points to explanations of) how the user of a terminal can
  control and inspect the interface and how to use various commands
  provided by the device driver.  It does not explain how to use the
  many application programs, shells or most Linux utilities.  Two
  commands commonly used at the terminal are:

    clear (to clear the screen)

    reset (to reset the terminal)


  14.2.  Starting Up the Terminal

  You should be able to turn on the power to the terminal, hit the
  "return" (or "enter") key and then get a login prompt.  Then type your
  account name and your password when prompted for it.  If nothing
  happens, make sure the host computer is OK.  If the host computer is
  shut down (no power) what you type at the terminal keyboard may appear
  on the screen since the transmit and receive pins at the computer may
  be connected together resulting in echoing of characters by an "off"
  computer.  If you can't log in when the host computer is running, see
  ``Trouble-Shooting''.


  14.3.  Terminal Device Driver

  When typing at the command line, the shell (such as the Bash shell) is
  reading what you type and reacting to it.  What you type first passes
  thru the terminal driver part of your operating system.  This driver
  may translate certain characters (such as changing the "return"
  character generated by the "return" key into a "new-line" character
  for Linux files).  It also recognizes certain control codes which you
  may type at the keyboard such as ^C to interrupt the execution of a
  program.  It also normally echos what you type back to the display.
  ``Stty'' may be used to configure how this terminal driver behaves,
  including disabling some (or all) of its functionality.


  14.4.  Corrupted Terminal Interface

  14.4.1.  Symptoms

  When the display doesn't look right or what you type doesn't display
  correctly, you may have a corrupted terminal interface.  It could also
  be a bug in the program you're using, a hardware failure, or possibly
  an incorrect configuration.  If everything was working normally but it
  suddenly goes bad, it may be that the interface got corrupted by
  something you did.  Two ways to corrupt the interface are to send a
  binary file to the terminal or to abnormally exit an application
  program.


  14.4.2.  Sent Terminal Binary Characters

  Your terminal will change its characteristics if sent certain escape
  sequences or control characters.  It you inadvertently try to display
  a binary file, it might contain such sequences which may put your
  terminal into some strange mode of operation or even make it unusable.
  Always view or edit a binary file with programs designed for that
  purpose so that this doesn't happen.  Most editors and pagers will
  handle binary OK so as not to corrupt the interface.  Some may display
  a message telling you that they can't edit binary.  But using "cat
  ...." or "cp .... /dev/tty.." where .... is a binary file, will send
  the binary to the terminal and likely corrupt things.

  Corruption it can also happen when using a communications program
  where a remote computer may send binary to your screen.  There are
  numerous other ways it can happen so be prepared for it.  Even a
  supposed ASCII file may contain unwanted control codes.

  To fix this problem reset the terminal.  There may be a key which does
  this directly at the terminal (perhaps in setup mode) or you may try
  typing either "reset" or "setterm -reset" (although you may not be
  able to see what you're typing).  This will send the reset string from
  the terminfo entry to the terminal.


  14.4.3.  Abnormally Exit a Program

  Large application programs (such as editors) often use the stty
  command (or the like) in their code to temporarily change the stty
  configuration when you are running the program.  This may put the
  device driver into "raw" mode so that every character you type goes
  directly thru to the application program.  Echoing by the driver is
  disabled so that everything you see on the screen comes directly from
  the application program.  Thus many control commands (such as ^C) may
  not work within such applications.

  When you tell such an application to quit, the application program
  first restores the stty settings to what they were before the
  application program started.  If you abnormally exit the program (you
  may guess this has happened when what you type no longer displays on
  the screen) then you may still be in "raw mode" on the command line.

  To get out of raw mode and restore the normal stty settings type "stty
  sane".  However, you must type this just after a "return" and end it
  with a "return".   But hitting the "return" key doesn't do the job
  since the "return" code no longer gets translated to the new-lines
  that the shell is waiting for.  So just type new-line (^J) instead of
  "return".  The "sane" terminal interface may not be exactly the same
  as the normal one but it usually works.  "stty sane" may also useful
  to get out of a corrupted interface due to other causes.


  14.5.  Special (Control) Characters

  A number of control characters which you may type at the keyboard are
  "caught" by the terminal driver and perform various tasks.  To see
  these control commands type: stty -a and look at lines 2-4.  They are
  tersely explained in the stty manual pages.  They may be changed to
  different control characters or disabled using the stty command.  Thus
  your control characters might be different than those described below.
  They are used for command-line editing, interrupting, scrolling, and
  to pass the next character thru transparently.


  14.5.1.  Command-Line Editing

  While the terminal driver has a few commands for command-line editing,
  some shells have a built-in real editor (such as "readline" in the
  Bash shell).  Such an editor is normally on by default so you don't
  need to do anything to enable it.  If it's available you don't need to
  learn many of the following commands although they often still work
  along with the command-line editor.  The most important to learn are
  ^C (interrupt), ^D, and scrolling.


    Delete-key (shown by stty as ^?) erases the last character

    ^U kills (deletes) the line

    ^W deletes a word backwards

    ^R reprints the line.  Useful mainly on hard copy terminals ??


  14.5.2.  Interrupting (& Quit, Suspend, EOF, Flush)



    ^C interrupts.  Exits the program and returns you to the command-
     line prompt.

    ^/ quits.  Same as interrupt ^C but weaker.  Also dumps a "core"
     file (which you likely have no use for) into your working
     directory.

    ^Z suspends.  Stops the program and puts it in the background.
     Type fg to restart it.

    ^D end of file.  If typed at the command-line prompt, exits the
     shell and goes to where you were before the shell started.

    ^O flush.  Not implemented in Linux.  Sends output to /dev/null.


  14.5.3.  Scrolling

  If what you want to see scrolls off the bottom of the screen, you may
  prevent this by sending a "stop" signal (^S or Xoff) to the host
  (provided Xon-Xoff ``Flow Control'' is enabled).  Send a "start signal
  to resume (^Q or Xon).  Some terminals have a "No Scroll" key which
  will alternately send Xoff and Xon.  If you have hardware flow control


    ^S stops scrolling (Xoff)

    ^Q resume scrolling (Xon)

  If you want to both stop scrolling and quit, use ^C.  If you want to
  stop scrolling to do something else but want to keep the program in
  memory so you can resume scrolling later, use ^Z suspend.

  An alternative scrolling method is to pipe the output thru a pager
  such as more, less, or most.  However, the output might not be
  standard output but could be error output which the pager doesn't
  recognize.  To fix this you may need to use redirection "2>&1" to get
  the pager to work OK.  It is often simpler to just use ^S and ^Q
  unless you need to scroll backwards.

  At a PC console (emulating a terminal) you may scroll backwards by
  using Shift-PageUp.  This is frequently needed since the scrolling is
  too fast to stop it where you want using ^S.  Once you've scrolled
  backwards Shift-PageDown will scroll forward again.


  14.5.4.  Take Next Character Literally

  ^V sends the next character typed (usually a control character)
  directly  thru the device driver with no action or interpretation.
  Echoed back are two ASCII characters such as ^C.


  14.6.  Inspecting the Interface

  These utility programs will provide information about the terminal
  interface:

    gitkeys: shows what byte(s) each key sends to the host.

    tty: shows what tty port you are connected to.

    set: shows the value of TERM (the terminfo entry name)

    stty -a: shows all stty settings.

    setserial -g /dev/tty?? (you fill in ??) shows UART type, port
     address and IRQ number.

    infocmp: shows the current terminfo entry (less comments)


  14.7.  Changing the Terminal Settings

  The terminal settings are normally set once when the terminal is
  installed using the setup procedures in the terminal manual.  However,
  some settings may be changed when the terminal is in use.  You
  normally would not give any "stty" of "setserial" commands when the
  terminal is in use as they are likely to corrupt the terminal
  interface.  However, there are changes you may make to the appearance
  of the terminal screen or to its behavior without destroying the
  integrity of the interface.  Sometimes these changes are made
  automatically by application programs so you may not need to deal with
  them.

  One direct method of making such changes is to use the setup key at
  the terminal and then use menus or the like to make the changes.  To
  do this you may need to be familiar with the terminal.


  The other 3 methods send an escape sequence from the computer to the
  terminal to make the changes.  These 3 examples show different methods
  of doing this to set reverse video:


  1. setterm -reverse

  2. tput -rev

  3. echo ^[[7m


  14.7.1.  setterm

  This is the easiest command to use.  It uses long options (but doesn't
  use the -- before them) and consults the terminfo database to
  determine what code to send.  You may change the color, brightness,
  linewrap, keyboard repeat, cursor appearance, etc.


  14.7.2.  tput

  The "tput" command is similar to "setterm" but instead of using
  ordinary words as arguments, you must use the abbreviations used by
  terminfo.  Many of the abbreviations are quite terse and hard to
  remember.


  14.7.3.  echo

  In the example "echo ^[[7m" to set reverse video, the ^[ is the escape
  character.  To type it type ^V^[ (or ^V followed by the escape key).
  To use this "echo" method you must find out what code to use from your
  terminal manual or from terminfo or termcap.  It's simpler to use
  setterm or tput although echo will execute a little faster.  So you
  might use echo ... in shell scripts which deal with only one type of
  terminal.





  14.7.4.  Saving Changes

  When you turn off the terminal the changes you made will be lost
  (unless you saved them in non-volatile terminal memory by pressing
  certain keys at the terminal).  If you want to use them again without
  having to retype them, put the commands in a shell script or make it a
  shell function.  Then run it when you want to make the changes.  One
  way to make the changes semi-permanent is to put the commands in a
  file that runs each time you login or start up the computer.


  15.  Trouble-Shooting (software)

  If you suspect that the problem is a hardware problem, see the Repair
  and Diagnose section ``Repair & Diagnose''.

  Here is a list of possible problems:

    ``Is the Terminal OK ?''  Suspect the terminal is defective.

    ``Missing Text'' Either skips over some text or displays some text
     OK and hangs.

    ``Getty Respawning Too Rapidly'' (console error message)

    ``Fails Just After Login''

    ``Can't Login'' but login prompt is OK.

    ``Garbled Login Prompt''

    ``No Sign of any Login Prompt''

  There are two cases where the terminal goes bad.  One is when it's
  been recently working OK and suddenly goes bad.  This is discussed in
  the next section.  The other case is where things don't work right
  when you install a terminal.  For this case you may skip over the next
  section.


  15.1.  Terminal Was Working OK

  When a formerly working terminal suddenly goes bad it is often easy to
  find the problem.  The problem may be obvious such as an error message
  when the terminal is first turned on.  If it makes a noise it likely
  needs repair.  See ``Repair & Diagnose''.  First, think about what has
  been done or changed recently as it's likely the cause of the problem.
  Did the problem happen just after new system software was installed or
  after a change in the configuration?


  15.2.  Terminal Newly Installed

  If you've just connected up a terminal to a computer per instructions
  and it doesn't work this section is for you.  If a terminal that
  formerly worked OK doesn't work now then see ``Terminal Was Working
  OK'' If you suspect that the serial port on your computer may be
  defective you might try running a diagnostic test program on it,
  possibly from MS DOS.

  One approach is to first see if the the terminal will work by trying
  to copy a file to the terminal (cp my_file /dev/ttyS?) under the most
  simple situation.  This means with the modem control lines disabled
  and at a show speed that doesn't need flow control (make sure that any
  hardware flow control is disabled).  If this copy works, then make the
  situation a little more complicated and see if it still works, etc.,
  etc.  When the trouble appears just after you made a change, then that
  change is likely the source of the trouble.  Actually, its more
  efficient (but more complex) to jump from the simple situation to
  about half way to the final configuration so that the test eliminates
  about half of the remaining possible causes of the problem.  Then
  repeat this methodology for the next test.  This way it would only
  take about 10 tests to find the cause out of a thousand possible
  causes.  You should deviate a little from this method based on hunches
  and clues.



  15.3.  Is the Terminal OK ?

  A good terminal will usually start up with some words on the screen.
  If these words convey no error message, its probably OK.  If there is
  no sign of power (no lights on, etc.) re-plug in the computer power
  cord at both ends.  Make sure there is power at the wall jack (or at
  the extension cord end).  Try another power cord if you have one.
  Make sure the terminal is turned on and that it's fuse is not blown.
  A blank (or dim) screen may sometimes be fixed by just turning up the
  brightness and contrast using knobs or a key in set-up mode.  Put the
  terminal into local mode if possible and try typing.  If it still
  won't work See ``Repair & Diagnose'' for tips on repairing it.


  15.4.  Missing Text

  If some text displays on the terminal OK and then it stops without
  finishing (in the middle of a word, etc.) or if chunks of text are
  missing, you likely have a problem with flow control.  If you can't
  figure out right away what's causing it, decrease the speed.  If that
  fixes it, it's likely a flow control problem.  It may be that flow
  control is not working at all due to failure to configure it
  correctly, or due to incorrect cable wiring (for hardware flow
  control).  See ``Flow Control''

  If single characters are missing, perhaps the serial port is being
  overrun by too fast a speed.  Try a slower baud rate.

  If you are using a baud rate under 1200 (very slow, mostly used for
  old hard-copy terminals and printers) and the text gets truncated,
  then the problem is likely in the serial device driver.  See Printing-
  HOWTO under "Serial devices" on how to fix this.


  15.5.  Getty Respawning Too Rapidly

  15.5.1.  No Modem Control Voltage

  If getty can't open and/or use a port because of the lack of a
  positive modem control voltage on one of the pins, then getty might be
  killed.  Then, per the instructions in inittab, getty respawns and
  tries again, only to be killed again, etc., etc.  Try using the
  "local" option with getty and/or check the modem control settings and
  voltages.


  15.5.2.  Key Shorted

  Another possible cause of getty respawning is if a keyboard key is
  shorted, giving the same result as if the key was continuously held
  down.  With auto-repeat enabled, this "types" thousands characters to
  the login prompt.  Look for a screen filled with all the same
  character (in some cases with 2 or more different characters).

  15.6.  Fails Just After Login

  If you can login OK but then you can't use the terminal it may be
  because the starting of the login shell has reconfigured the terminal
  (to an incorrect setting) by a command which someone put into one of
  the files that are run when you login and a shell starts.  These files
  include /etc/profile and  /.bashrc.  Look for a command starting with
  "stty" or "setserial" and make sure that it's correct.  Even if it's
  done OK in one initialization file, it may be reset incorrectly in
  another initialization file that you are not aware of.  You may need
  to boot from a rescue diskette to be able to get into the system for
  fixing things.


  15.7.  Can't Login

  If you get a login prompt but get no response (or perhaps a garbled
  response) to your login attempts a possible cause is that the
  communication is bad one-way from the terminal to the computer.  If
  you're not already using the "local" option with getty, do so to
  disable the modem control lines.  You might also disable hardware flow
  control (stty -crtscts) if it was enabled.  If things now works then
  your modem control lines are likely either not wired or set up
  correctly.  Some terminals allow setting different values (such as
  baud rate) for send and receive so the receive could be OK but the
  send bad.

  If you get a message saying something like "login failed" then if
  there is no error in typing or the password there may be some
  restrictions on logins in effect.  See ``Login Restrictions''


  15.8.  Garbled Login Prompt

  This may be due to using the wrong character set, transmission errors
  due to too high of a baud rate, incompatible baud rates or
  incompatible parity.  If it's a variety of strange characters you have
  the wrong character set or a high order bit is being set by mistake.
  If words are misspelled, try a lower baud rate.  For baud or parity
  incompatibilities you see a lot of the same "error character" which
  represents a real character that can't be displayed correctly due to
  an error in parity or baud rate.

  If you are using agetty (often just named getty), the agetty program
  will detect and set parity if you type something.   Try it with a
  return to see if it fixes possible parity errors.


  15.9.  No Sign of any Login Prompt

  If nothing at all happens at the terminal, then the worst has
  occurred.  One of the first things to do is to make sure that all
  cable connections are tight and connected correctly.  Other problems
  could be: A baud rate mismatch, broken hardware, or Getty not running.
  At this point two different avenues of approach are (you may pursue
  more than one at a time).


    ``Diagnose Problem from the Console''

    Measure Voltages I ``Measure  Voltages''





  15.9.1.  Diagnose Problem from the Console

  At the console (or another working terminal), use "top" or "ps -al" to
  see if getty is running on the port.  Don't confuse it with getty
  programs running on other ports or on the virtual consoles.  You will
  not get a login prompt unless getty runs.  If it's running then you
  may disable it so that you can try to copy a file to the terminal as a
  test.

  To disable getty, edit /etc/inittab and comment out the getty command
  with an initial # so that it will not respawn after you kill it.  Then
  kill the old getty using the k key while in "top".

  To copy a short file to the terminal (It might be a good idea to try
  this near the start of the installation process before setting up
  getty) use the Linux copy command such as: cp file_name  /dev/ttyS1.
  If it doesn't work, use stty to make the interface as simple as
  possible with everything disabled (such as hardware flow control:
  -crtscts; parity, and modem control signals: clocal).  Be sure the
  baud rates and the bits/byte are the same.  If nothing happens verify
  that the port is alive with a voltmeter per the next section.


  15.9.2.  Measure Voltages

  If you have a voltmeter handy check for -12 V (-5 to -15) at pin 3
  (receive data) at the terminal side of the null modem cable.  The
  positive lead of the meter should be connected to a good ground (the
  metal connectors on the ends of cables are often not grounded).  If
  there is no such negative voltage then check for it at pin 2 on the
  computer.  If it's present there but not at pin 3 to at the terminal,
  then the cable is bad (loose connection, broken wire, or not a null
  modem with pin 2 feeding thru to pin 3).  If voltage is absent, then
  the serial port on the computer is dead.  Test it with software
  diagnostics or replace it.

  If the serial port is alive, you may want to send a file to it (with
  modem controls disabled) and see if anything gets to it.  To check for
  a transmitted signal, look at the voltmeter needle at -12 V when the
  line is idle.  Then start sending a file (or start getty).  You should
  see the needle dropping to 0 and fluttering about 0 as it measures
  short-run averages of the bit stream.  You can see this also on the AC
  scale provided that your meter has a capacitor to block out DC
  voltages when on the AC scale.  If it doesn't, then the idle DC of -12
  V will cause a high false AC reading.  Without a meter, you could
  connect a good device (such as another terminal or an external  modem)
  to the serial port and see if it works OK.


  15.10.  Serial Test Equipment

  15.10.1.  Breakout Gadgets, etc.

  While a multimeter (used as a voltmeter) may be all that you need for
  just a few terminals, special test equipment has been made for testing
  serial port lines.  Some are called "breakout ... " where breakout
  means to break out conductors from a cable.  These gadgets have a
  couple of connectors on them and insert into the serial cable.  Some
  have test points for connecting a voltmeter.  Others have LED lamps
  which light when certain modem control lines are asserted (turned on).
  Still others have jumpers so that you can connect any wire to any
  wire.  Some have switches.  Radio Shack sells a "RS-232
  troubleshooter" and a "RS-232 serial jumper box".



  15.10.2.  Measuring Voltages

  Any voltmeter or multimeter, even the cheapest that sells for about
  $10, should work fine.  Trying to use other methods for checking
  voltage is tricky.  Don't use a LED unless it has a series resistor to
  reduce the voltage across the LED.  A 470 ohm resistor is used for a
  20 ma LED (but not all LED's are 20 ma).  The LED will only light for
  a certain polarity so you may test for + or - voltages.  Does anyone
  make such a gadget for automotive circuit testing??  Logic probes may
  be damaged if you try to use them since the TTL voltages for which
  they are designed are only 5 volts.  Trying to use a 12 V incandescent
  light bulb is not a good idea.  It won't show polarity and due to
  limited output current of the UART it probably will not even light up.

  To measure voltage on a female connector you may plug in a bent paper
  clip.  Its diameter should be no larger than the pins so that it
  doesn't damage the contact.


  15.10.3.  Taste Voltage

  As a last resort, if you have no test equipment and are willing to
  risk getting shocked (or even electrocuted) you can always taste the
  voltage.  Before touching one of the test leads with your tongue, test
  them to make sure that there is no high voltage on them.  Touch both
  leads (at the same time) to one hand to see if they shock you.  Then
  if no shock, wet the skin contact points by licking and repeat.  If
  this test gives you a shock, you certainly don't want to use your
  tongue.

  For the test for 12 V, Lick a finger and hold one test lead in it.
  Put the other test lead on your tongue.  If the lead on your tongue is
  positive, there will be a noticeable taste.  You might try this with
  flashlight batteries first so you will know what taste to expect.


  16.  Repair & Diagnose

  Repairing a terminal has much in common with repairing a monitor
  and/or keyboard.  Sometimes the built-in diagnostics of the terminal
  will tell you what is wrong on the screen.  If not, then by the
  symptoms, one may often isolate the trouble to one of the following:
  bad keyboard, CRT dead, terminal digital electronics failure.  It's
  best to have a service manual, but even if you don't have one, many
  terminals may still be repaired.


  16.1.  Repair Books & Websites

  16.1.1.  Books

  Bigelow, Stephen J.: Troubleshooting & Repairing Computer Monitors,
  2nd edition, McGraw-Hill, 1997.  Doesn't cover the character
  generation electronics nor the keyboard.


  16.1.2.  Websites

  The FAQ  <http://www.repairfaq.org> for the newsgroup:
  sci.electronics.repair is long and comprehensive, although it doesn't
  cover terminals per se.  See the section "Computer and Video
  Monitors".  Much of this information is applicable to terminals as are
  the sections: "Testing Capacitors", "Testing Flyback Transformers",
  etc.  Perhaps in the future, the "info" on repair in this HOWTO will
  consist mainly of links to the above FAQ (or the like).

  16.2.  Safety

  CRT's use high voltage of up to 30,000 volts for color (less for
  monochrome).  Be careful not to touch this voltage if the set is on
  and the cover off.  It probably won't kill you even if you do since
  the amount of current it can supply is limited.  But it is likely to
  badly burn and shock you, etc.  High voltage can jump across air gaps
  and go thru cracked insulation so keep your hands a safe distance from
  it.  You should notice the well-insulated high voltage cable connected
  to one side of the picture tube.  Even when the set is off, there is
  still enough residual voltage on the picture tube cable connection to
  give you quite a shock.  To discharge this voltage when the set is
  unplugged use a screwdriver (insulated handle) with the metal blade
  grounded to the chassis with a jumper wire.

  The lower voltages (of hundreds of volts) can be even more dangerous,
  especially if your hands are wet or if you are wearing a metal
  watchband, ring or the like.  In rare cases people have been killed by
  it so be careful.  The lowest voltages of only several volts on
  digital circuitry are fairly safe but don't touch anything (except
  with a well insulated tool) unless you know for sure.


  16.3.  Appearance of Display

  If the display is too dim, turn up the brightness and/or contrast.
  using knobs on the exterior of the unit (if they exist).  If the
  width, height or centering is incorrect, there are often control knobs
  for these.  For some older terminals one must press an arrow key (or
  the like) in set-up mode.

  You may need to remove the cover to make adjustments, especially on
  older models.  You could arrange things so that a large mirror is in
  front of the terminal so as to view the display in the mirror while
  making adjustments.  The adjustments to turn may be on a printed
  circuit board.  While a screwdriver (possibly Phillips-head) may be
  all that's needed, inductors may require special TV alignment tools
  (plastic hex wrenches, etc.).  The abbreviated name of the adjustment
  should be printed on the circuit board.  For example, here are some
  such names:


    V-Size adjusts the Vertical height (Size)

    H-Size adjusts the Horizontal width (Size).  It may be an inductor.

    V-Pos adjusts the Vertical Position

    H-Pos adjusts the Horizontal Position

    V-Lin adjusts Vertical Linearity (Use if width of scan lines
     differs at the top and bottom of the screen)

    V-Hold adjusts Vertical Hold (Use if screen is uncontrollable
     scrolling)

    Bright adjusts brightness (an external knob may also exist)

    Sub-Bright adjusts brightness of subdued intensity mode (often the
     normal mode: dimmer than bold or bright mode).

  Changing linearity may change the size so that it will need to be
  readjusted.  A terminal that has been stored for some time may have a
  small display rectangle on the screen surrounded by a large black
  border.  If it's difficult to adjust, wait a while before adjusting it
  since it will likely recover some with use (the black borders will
  shrink).  Just being turned on for a while improves it.


  16.4.  Diagnose

  16.4.1.  Terminal Made a Noise

  If the terminal made some noise just before it failed (or when you
  turn it on after it failed) that noise is a clue to what is wrong.  If
  you hear a sparking noise or see/smell smoke, immediately turn the
  terminal off to prevent further damage.  The problem is likely in the
  high voltage power supply of several thousand volts.  Remove the cover
  and if the bad spot is not evident, turn it on again for a short time
  in a dimly lit room to look for arcing.  The high voltage cable (runs
  between the flyback transformer and the side of the picture tube) may
  have broken insulation that arcs to ground.  Fix it with high-voltage
  insulating dope, or special electrical tape designed say for 10,000
  volts.

  The flyback transformer (high voltage) may make only a faint clicking
  or sparking noise if it fails.  You may not hear it until you turn the
  terminal off for a while to rest and then turn it back on again.  To
  track down the noise you may use a piece of small rubber tubing (such
  as used in automobiles) as a stethoscope  to listen to it.  But while
  you are listening for the noise, the terminal is suffering more damage
  so try find it fast (but not so fast as to risk getting shocked).

  The noise might be due to a short in the power supply.  This may cause
  a fuse to blow with a pop.  Replacing a blown fuse may not solve the
  problem as the same short may blow the fuse again.  Inspect for any
  darkened spots due to high heat and test those components.  Shorted
  power transistors may cause the fuse to blow.  They may be tested with
  a transistor checker or even with an ohm-meter.  Use the low ohm scale
  on an ohm-meter so that the voltage applied by the meter is low.  This
  will reduce the possible damage to good components caused by this test
  voltage.

  If the terminal has been exposed to dampness such as being stored in a
  damp place or near a kitchen with steam from cooking, a fix may be to
  dry out the unit.  Heating a "failed" flyback transformer with a blow
  dryer for several minutes may restore it.


  16.4.2.  Terminal Made No Noise

  A blank screen may be due to someone turning the brightness control to
  the lowest level or to aging.  The next thing to do is to check the
  cables for loose or broken connections.  If there is no sign of power,
  substitute a new power cord after making sure that the power outlet on
  the wall is "hot".

  If the keyboard is suspected, try it on another terminal of the same
  type or substitute a good keyboard.  Wiggle the keyboard cable ends
  and the plug.  Wires inside cables may break, especially near their
  ends.  If the break is verified by wiggling it (having the problem go
  on and off in synchronization with the wiggles), then one may either
  get a new cable or cut into the cable and re-solder the breaks, etc.

  One of the first things to do if the keyboard works is to put the
  terminal into local mode (where it works like a typewriter and is
  disconnected from the computer).  If it works OK in local, then the
  problem is likely in the connection to the host computer (or incorrect
  interface) or in the UART chips of the terminal.

  By carefully inspecting the circuitry, one may often find the cause of
  the problem.  Look for discoloration, cracks, etc.  An intermittent
  problem may sometimes be found by tapping on components with a ball-
  point pen (not the metal tip of course).  A break in the conductor of
  a printed circuit board may sometimes be revealed by flexing the
  board.  Solder that looks like it formed a drop or a solder joint with
  little solder may need re-soldering.  Soldering may heat up
  transistors (and other components) and damage them so use a heat sink
  if feasible.

  If you have a common brand of terminal, you may be able to search
  newsgroup postings on the Internet to find out what the most frequent
  types of problems are for your terminal and perhaps information on how
  to fix them.

  To see if the digital electronics work, try (using a good keyboard)
  typing at the bad terminal.   Try to read this typing at a good
  terminal (or the console) using the copy command or with a terminal
  communication program such as Minicom.  You may need to hit the return
  key at the terminal in order to send a line.  One may ask the bad
  terminal for its identity etc. from another terminal.  This will show
  if two-way communication works.


  16.5.  Capacitors

  Electrolytic capacitors have a metal shell and are may become weak or
  fail if they set for years without being used.  Sometimes just leaving
  the terminal on for a while will help partially restore them.  If you
  can, exercise any terminals you have in storage by turning them on for
  a while every year or two.


  16.6.  Keyboards

  16.6.1.  Interchangeability

  The keyboards for terminals are not the same as keyboards for PC's.
  The difference is not only in the key layout but in the codes
  generated when a key is pressed.  Also, keyboards for various brands
  and models of terminals are not always interchangeable with each
  other.  Sometimes one get an "incompatible" keyboard to partially work
  on a terminal.  All the ASCII keys will work OK, but special keys such
  as set-up and break will not work correctly.


  16.6.2.  How They Work

  Most keyboards just make a simple contact between two conductors when
  you press a key.  Electronics inside a chip in the keyboard converts
  this contact closure into a code sent over the keyboard's external
  cable.  Instead of having a separate wire (or conductor) going from
  each key to the chip, the following type scheme is used.  Number the
  conductors say from 1-10 and A-J.  For example: conductor 3 goes to
  several keys and conductor B goes to several keys, but only one key
  has both conductors 3 and B going to it.  When that key is pressed, a
  short circuit is established between 3 and B.  The chip senses this
  short and knows what key has been pressed.  Such a scheme reduces the
  number of conductors needed (and  reduces the number of pins needed on
  the chip).  It's similar to what is called a crossbar switch.


  16.6.3.  One Press Types 2 Different Characters

  If, due to a defect, conductors 3 and 4 become shorted together then
  pressing the 3-B key will also short 4 and B and the chip will think
  that both keys 3-B and 4-B have been pressed.  This is likely to type
  2 different characters when all you wanted was one character.
  16.6.4.  Modern vs Old Keyboards

  While the modern keyboard and the old fashioned type look about the
  same, the mechanics of operation are different.  The old ones have
  individual key switches under the key-caps with each switch enclosed
  in a hard plastic case.  The modern ones use large flexible plastic
  sheets (membrane) the size of the keyboard.  A plastic sheet with
  holes in it is sandwiched between two other plastic sheets containing
  printed circuits (including contact points).  When you press a key,
  the two "printed" sheets are pressed together at a certain point,
  closing the contacts printed on the sheets at that point.


  16.6.5.  Keyboard Doesn't Work At All

  If none of the keys work try another keyboard (if you have one) to
  verify that the keyboard is the problem.  The most likely cause is a
  broken wire inside the cord (cable) that connects it to the terminal.
  The most likely location of the break is at either end of the cord.
  Try wigging the ends of the cord while tapping on a key to see if it
  works intermittently.  You may carefully cut into the cord with a
  knife at the bad spot and splice the broken conductor.  Sometimes just
  a drop of solder will splice it.  Seal up the cord with electrical
  tape, glue, or caulk.


  16.6.6.  Typing b Displays bb, etc. (doubled)

  If all characters appear double there is likely nothing wrong with the
  keyboard.  Instead, your terminal has likely been incorrectly set up
  for half-duplex (local echo on) and every character you type is echoed
  back both from the electronics inside your terminal and from your host
  computer.  If the two characters are not the same, there may be a
  short circuit inside your keyboard.  See ``One Press Types 2 Different
  Characters''


  16.6.7.  The Keyboard Types By Itself

  If a key is shorted out it is likely to type out a large number of the
  same character if auto-repeat is enabled.  If more than one key is
  shorted out then repeating sequences of a few characters will be
  typed.  This may cause getty to respawn too fast if it happens at the
  login prompt.  See ``Key Shorted''.  The fix is to clean the contacts
  per ``Cleaning Keyboard Contacts''.


  16.6.8.  Liquid Spilled on the Keyboard

  If water or watery liquid has been spilled on the keyboard (or if it
  was exposed to rain, heavy dew, or dampness) some keys may not work
  right.  The dampness may cause a key to short out (like it was pressed
  down all the time) and you may see the screen fill up with that letter
  if auto-repeat is enabled.  If it's gotten wet and then partially (or
  fully) dried out, certain keys may not work due to deposits on the
  contact surfaces.  For the modern type of keyboard, one may readily
  take apart the plastic sheets inside and dry/clean them.  For the old
  type one may let it dry out in the sun or oven (low temp.).  When it's
  dry it may still need contact cleaner on some keys as explained below.


  16.6.9.  Cleaning Keyboard Contacts




  16.6.9.1.  Keyboards with Membranes

  On some newer keyboards, the plastic sheets (membranes) are easy to
  remove for inspection and cleaning if needed.  You only need to remove
  several screws to take apart the keyboard and get to the sheets.  On
  some old IBM keyboards the sheets can't be removed without breaking
  off many plastic tabs which will need to be repaired with glue to put
  back (probably not worthwhile to repair).  Such a keyboard may
  sometimes be made to work by flexing, twisting, and/or pounding the
  assembly containing the plastic sheets.


  16.6.9.2.  Keyboards with Individual Switches

  What follows is for older keyboards that have separate hard plastic
  switches for each key.  Before going to all the work of cleaning
  electrical contacts first try turning the keyboard upside-down and
  working the bad keys.  This may help dislodge dirt, especially if you
  press the key hard and fast to set up vibration.

  Often the key-caps may be removed by prying them upward using a small
  screwdriver as a lever while preventing excessive tilting with a
  finger.  (Warning: Key-caps on modern keyboards don't pry up.)  The
  key-cap may tilt a bit and wobble as it comes loose.  It may even fly
  up and onto the floor.  Then you have two choices on how to clean the
  contacts: Use contact cleaner spray directly on top of the key switch,
  or take the key switch apart and clean it.  Still another choice is to
  replace the key switch with a new or used one.

  Directly spraying contact cleaner or the like (obtained at an
  electronics store) into the top of the key switch is the fastest
  method but may not work and it also might damage the plastic.  With
  the keyboard live (or with the key contacts connected to an ohm-meter)
  use the tube which came with the spray to squirt cleaner inside the
  key switch.  Tilt the keyboard so that the cleaner flows into the
  contacts.  For the CIT101e terminal with an Alps keyboard, this means
  tilting the digit row up toward the ceiling.  Work the key switch up
  and down with a pen or small screwdriver handle to avoid getting the
  toxic cleaner liquid on your skin (or wear gloves).  Finally turn the
  keyboard upside-down while working the key to drain off remaining
  cleaner.  The more cleaner you squirt in the more likely it will fix
  it but it is also more likely to do more damage to the plastic, so use
  what you think is just enough to do the job.  Once the key works OK,
  work it up and down a little more and test it a half minute later,
  etc. to make sure it will still work OK.

  Sometimes a key works fine when the contacts inside are saturated with
  contact cleaner liquid, but when the liquid dries a few minutes later
  then the resulting scale on the contacts prevents good contact and the
  key works erratically (if at all).  Operating the key when the liquid
  is drying inside may help.  Some switches have the contacts nearly
  sealed inside so little if any contact cleaner reaches the contacts.
  The cleaner that does get to the contacts may carry contamination with
  it.

  If you need to disassemble the key switch, first inspect it to see how
  it is installed and comes apart.  Sometimes one may remove the cover
  of the switch without removing the switch from the keyboard.  To do
  this pry up (or pull up) the top of the key switch after prying apart
  thin plastic tabs that retain it.  Don't pry too hard or you may break
  the thin plastic.  If this can't be done, you may have to unsolder the
  switch and remove it in order to take it apart (or replace it).  Once
  the switch has been taken apart you still may not be able to see the
  contacts if the contact surfaces are sandwiched together (nearly
  touching).  You may get contact cleaner on the contacts by slightly
  prying apart the conducting surfaces and squirting cleaner between
  them.  There may be some kind of clip holding the contact surfaces
  together which needs to be removed before prying these surfaces apart.
  With cleaner on the contacts, work them.  Tilting the keyboard or
  inverting it may help.  Take care not to loose small parts as they may
  fly up into the air when taking apart a key switch.


  17.  Appendix

  17.1.  List of Linux Terminal Commands

  17.1.1.  Sending a Command to the Terminal


    ``setterm'': long options

    ``tput'': terse options

    tset: initializes only

    clear: clears screen

    reset: sends reset string


  17.1.2.  Configuring the Terminal Device Driver


    ``setserial'':

    ``stty''


  17.1.3.  Terminfo


    ``tic'' terminfo compiler & translator

    toe: shows list of terminals for which you have terminfo (termcaps)

    ``infocmp'' compares or displays terminfo entries


  17.1.4.  Other


    gitkeys: shows what bytes each key sends to the host.

    tty: shows what tty port you are connected to.

    set (or tset -q): shows the value of TERM, the terminfo entry name

    ``tset'': sets TERM interactively and initializes


  17.2.  The Internet and Books

  17.2.1.  Terminal Info on the Internet



    Shuford's Website
     <http://www.cs.utk.edu/~shuford/terminal_index.html> at the
     University of Tennessee has a great deal of useful information
     about text terminals.

    Boundless <http://www.boundless.com/textterm/> purchased the VT and
     Dorio terminal business from DEC.

    Wyse <http://www.wyse.com/terminal/> is a major manufacturer of
     terminals.

    comp.terminals is the newsgroup for terminals


  17.2.2.  Books Related to Terminals



    EIA-232 serial port see ``EIA-232 (RS-232) Books''.

    Repair see ``Repair Books &  Websites''.

    Terminfo database see ``Termcap Documents''


  17.2.3.  Entire Books on Terminals

  As far as I know, there is no satisfactory book on text terminals
  (unless you are interested in antique terminals of the 1970's).

    Handbook of Interactive Computer Terminals by Duane E. Sharp;
     Reston Publishing Co. 1977. (mostly obsolete)

    Communicating with Display Terminals by Roger K. deBry; McGraw-Hill
     1985.  (mostly on IBM synchronous terminals)

  The "HANDBOOK ... " presents brief specification of over 100 different
  models of antique terminals made in the early 1970's by over 60
  different companies.  It also explains how they work physically but
  incorrectly shows a diagram for a CRT which uses electrostatic
  deflection of the electron beam (p. 36).  Terminals actually used
  magnetic deflection (even in the 1970's).  This book explains a number
  of advanced technical concepts such as "random scan" and "color
  penetration principle".

  The "COMMUNICATING ... " book in contrast to the "Handbook ... "
  ignores the physical and electronic details of terminals.  It has an
  entire chapter explaining binary numbers (which is not needed in a
  book on terminals since this information is widely available
  elsewhere).  It seems to mostly cover old IBM terminals (mainly the
  3270) in block and synchronous modes of operation.  It's of little use
  for the commonly used ANSI terminals used today on Unix-like systems.
  Although it does discuss them a little it doesn't show the various
  wiring schemes used to connect them to serial ports.


  17.2.4.  Books with Chapters on Terminals

  These chapters cover almost nothing about the terminals themselves and
  their capabilities.  Rather, these chapters are mostly about how to
  set up the computer (and its terminal driver) to work with terminals.
  Due to the differences of different Unix-like systems, much of the
  information does not not apply to Linux.


    Unix Power Tools by Jerry Peck et. al.  O'Reilly 1998.  Ch. 5
     Setting Up Your Terminal, Ch. 41: Terminal and Serial Line
     Settings, Ch. 42: Problems With Terminals

    Advanced Programming in the Unix Environment by W. Richard Stevens
     Addison-Wesley, 1993.  Ch. 11: Terminal I/O, Ch. 19: Pseudo
     Terminals

    Essential System Administration by Aleen Frisch, 2nd ed.  O'Reilly,
     1998.  Ch. 11: Terminals and Modems.

  The "UNIX POWER TOOLS" book has 3 short chapters on text terminals.
  It covers less ground than this HOWTO but gives more examples to help
  you.

  The "ADVANCED PROGRAMMING ... " Chapter 11 covers only the device
  driver (or terminal driver) aspect of terminals (the software which is
  included in the operating system to deal with terminals).  It explains
  the parameters one gives to the stty command to configure the
  terminal.

  The "ESSENTIAL SYSTEM ..." book's chapter has more about terminals
  than modems.  It seems well written.

















































