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
[email protected]. 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.
