Text-Terminal-HOWTO David S. Lawyer v0.05, June 1998 This document explains what text terminals are, how they work, how to install and configure them, and provides some info on how to repair them. It may be of some use even if you don't have a terminal manual. While it's written for real terminals on a Linux system, some of it is also applicable to terminal emulation and/or other Unix-like systems. ______________________________________________________________________ Table of Contents 1. Introduction 1.1 Copyright, Disclaimer, and Author 1.1.1 Copyright 1.1.2 Disclaimer 1.1.3 Author Contact 1.2 What is a Terminal ? 1.3 Dumb Terminals 1.4 Types of Terminals 1.4.1 Text Terminals 1.4.2 Graphics Terminals 1.4.3 Serial Line Graphics Terminals 1.4.4 Fast Graphics Terminals (often known by other names) 1.4.5 Quasi-Terminals (= Quasi-Computers) 1.4.6 Terminal Emulation 1.5 Terminology 2. Quick Install 3. Why Use a Terminal ? 3.1 Introduction 3.2 Lower Hardware Costs 3.3 Control of Software 3.4 Hardware Upgrades 3.5 Other Advantages of Terminals 3.6 Major Disadvantages of Terminals 3.7 Are Text Terminals Obsolete ? 4. Overview of How Terminals Work (in Linux) 4.1 Device Names 4.2 Login/Logout 4.3 Half/Full Duplex 4.4 Terminal Memory 4.5 Commands for the Terminal 4.6 Lack of Standardization Solved by Terminfo 4.7 The Interface 4.8 Emulation 4.9 The Console 5. Terminal Special Files: /dev/tty... etc. 5.1 Serial Port Terminals 5.2 Pseudo Terminals 5.3 The Controlling Terminal /dev/tty 5.4 /dev/ttyI? "Terminals" 5.5 The Console: /dev/tty? 5.6 Creating a Device with mknod 6. Some Details on How Terminals Work 6.1 Terminal Memory 6.2 Early Terminals 6.3 Control Codes and Escape Sequences 6.3.1 Control Codes 6.3.2 Escape Sequences 7. Special Capabilities of Some Terminals 7.1 Color 7.2 Dual Sessions 7.3 Printer/Auxiliary Port 7.4 Character-Sets 7.5 Fonts 7.6 Keyboards & Special Keys 7.7 The Linux Console 7.7.1 Make a Terminal the Console 8. Notes by Brand Name 8.1 CIT 8.2 IBM 8.3 Teletypes 8.4 VT (DEC) 9. Serial Communications on EIA-232 (RS-232) 9.1 Introduction 9.2 Voltages 9.2.1 Voltage for a Bit 9.2.2 Voltage Sequence for a Byte 9.3 Parity Explained 9.4 Forming a Byte (Framing) 9.5 Limitations of EIA-232 9.5.1 Low Speed & Short Distance 9.5.2 Successors to EIA-232 9.5.3 Line Drivers 9.6 Synchronization & Synchronous 9.6.1 How "Asynchronous" is Synchronized 9.6.2 Defining Asynchronous vs Synchronous 9.6.3 Synchronous Communication 9.7 Block Mode 9.7.1 Introduction 9.7.2 Types of Block Modes, Forms 9.7.3 Efficiency 9.8 EIA-232 (RS-232) Books 10. Flow Control (Handshaking) 10.1 Why Is Flow Control Needed ? 10.2 Overrunning a Serial Port 10.3 Stop Sending 10.4 Resume Sending 10.5 Hardware Flow Control (RTS/CTS etc.) 10.5.1 RTS/CTS and DTR Flow Control 10.5.2 Interfacing DTR with RTS/CTS flow control 10.5.3 Old RTS/CTS Handshaking Is Different 10.5.4 Reverse Channel 10.6 Is Hardware Flow Control Done by Hardware ? 10.7 Obsolete ETX/ACK Flow Control 11. Physical Connection 11.1 Direct Cable Connection. 11.1.1 Multiport I/O Cards (Adapters) 11.1.2 Length Limitations 11.1.3 Type of Cable 11.1.4 A Kludge using Twisted-Pair Cable 11.1.5 Cable Grounding 11.2 Modem Connection 11.2.1 Dialing Out From a Terminal 11.2.2 Terminal Gets Dialed Into 11.2.3 Modem Commands 11.3 Terminal Server Connection 11.4 Making or Modifying a Cable 11.4.1 Buy or Make ? 11.4.2 Connectors & Pins 12. Set-Up (Configure) for both Computer & Terminal 12.1 Introduction 12.2 Terminal Set-Up 12.3 At the Computer 12.3.1 Inittab 12.3.2 Stty & Setserial 12.3.3 Setserial 12.3.4 Where to Run Setserial ? 12.3.5 Stty 12.3.6 Where to Put the Stty Command ? 12.3.7 Terminfo & Termcap (brief) 12.4 Communication Interface Settings 12.4.1 Speed 12.4.2 Parity 12.4.3 Bits/Character 12.4.4 Which Flow Control ? 12.5 Rarely Needed /etc/ttytype File 12.6 Login Restrictions 12.7 Run Command Only If TERM=my_term_type 13. Terminfo and Termcap (detailed) 13.1 Introduction 13.2 Terminfo Database 13.2.1 Terminfo Compiler (tic) 13.2.2 Look at Your Terminfo 13.2.3 Deleting Data Not Needed 13.3 Initialization 13.4 TERM Variable 13.5 Termcap Documents 14. Using the Terminal 14.1 Introduction 14.2 Starting Up the Terminal 14.3 Terminal Device Driver 14.4 Corrupted Terminal Interface 14.4.1 Symptoms 14.4.2 Sent Terminal Binary Characters 14.4.3 Abnormally Exit a Program 14.5 Special (Control) Characters 14.5.1 Command-Line Editing 14.5.2 Interrupting (& Quit, Suspend, EOF, Flush) 14.5.3 Scrolling 14.5.4 Take Next Character Literally 14.6 Inspecting the Interface 14.7 Changing the Terminal Settings 14.7.1 setterm 14.7.2 tput 14.7.3 echo 14.7.4 Saving Changes 15. Trouble-Shooting (software) 15.1 Terminal Was Working OK 15.2 Terminal Newly Installed 15.3 Is the Terminal OK ? 15.4 Missing Text 15.5 Getty Respawning Too Rapidly 15.5.1 No Modem Control Voltage 15.5.2 Key Shorted 15.6 Fails Just After Login 15.7 Can't Login 15.8 Garbled Login Prompt 15.9 No Sign of any Login Prompt 15.9.1 Diagnose Problem from the Console 15.9.2 Measure Voltages 15.10 Serial Test Equipment 15.10.1 Breakout Gadgets, etc. 15.10.2 Measuring Voltages 15.10.3 Taste Voltage 16. Repair & Diagnose 16.1 Repair Books & Websites 16.1.1 Books 16.1.2 Websites 16.2 Safety 16.3 Appearance of Display 16.4 Diagnose 16.4.1 Terminal Made a Noise 16.4.2 Terminal Made No Noise 16.5 Capacitors 16.6 Keyboards 16.6.1 Interchangeability 16.6.2 How They Work 16.6.3 One Press Types 2 Different Characters 16.6.4 Modern vs Old Keyboards 16.6.5 Keyboard Doesn't Work At All 16.6.6 Typing b Displays bb, etc. (doubled) 16.6.7 The Keyboard Types By Itself 16.6.8 Liquid Spilled on the Keyboard 16.6.9 Cleaning Keyboard Contacts 16.6.9.1 Keyboards with Membranes 16.6.9.2 Keyboards with Individual Switches 17. Appendix 17.1 List of Linux Terminal Commands 17.1.1 Sending a Command to the Terminal 17.1.2 Configuring the Terminal Device Driver 17.1.3 Terminfo 17.1.4 Other 17.2 The Internet and Books 17.2.1 Terminal Info on the Internet 17.2.2 Books Related to Terminals 17.2.3 Entire Books on Terminals 17.2.4 Books with Chapters on Terminals ______________________________________________________________________ 1. Introduction For a quick attempt to install a terminal see ``Quick Install''. 1.1. Copyright, Disclaimer, and Author 1.1.1. Copyright Copyright 1998 by David S. Lawyer. Please freely copy and distribute this document. Let me know (if you can locate me and if I'm alive) if you significantly modify it. If certain words are trademarks, the context should make it clear to whom they belong. For example "MS Windows NT" implies that "Windows NT" belongs to Microsoft (MS). Mac is by Apple Computer. 1.1.2. Disclaimer Much of the info in this HOWTO was obtained from the Internet and may be unreliable (although I've done some double checking in some cases). While I haven't intentionally tried to mislead you, there are likely a number of errors in this document. Please let me know about them. It should be obvious that I cannot be held legally responsible for them. 1.1.3. Author Contact My email in 1998 is bf347@lafn.org. Please let me know of any errors in facts, opinions, logic, spelling, grammar, clarity, links, etc. I realize that this document needs some improvement so I hope to revise it about once a month . Please send me any info that you think belongs in this document. 1.2. What is a Terminal ? A terminal consists of a screen and keyboard that one uses to communicate remotely with a (host) computer. One uses it just like it was a personal computer but the terminal is remote from the host computer (on the other side of the room or even on the other side of the world). Programs execute on the host computer but the results display on the terminal screen. Its computational ability is relatively low (otherwise it would be a computer and not a terminal). This computational ability is generally limited to the ability to display what is sent to it (possibly including full-screen graphics). In the days of mainframes from the mid 1970's to the mid 1980's, most people used terminals to communicate with computers. They typed in programs, ran programs, wrote documents, issued printing commands, etc. A cable connected the terminal to the computer (often indirectly). It was called a terminal since it was located at the terminal end of this cable. If you've been using Linux (except for X-Window use) with a computer monitor and keyboard you already know what a terminal is because you have been using one (or more precisely a "virtual terminal"). The monitor (along with the keyboard) is called the console, but it emulates a terminal. A real terminal is different from a monitor because it's a different electronic setup. A text terminal is often connected to a serial port of the computer via a long cable. Thus, in contrast to a monitor which is usually located right next to the computer, a terminal may be quite a distance away from its host computer. The video card inside a computer stores the video image seen on the monitor screen. For a terminal, the equivalent of this video card is built right into the terminal but since text terminals are often monochrome without much graphics, the capabilities of its "video card" are rather weak. Also, most text terminals do not have mice. In network terminology, one might think that the terminal is the client and the host computer the server. This is not actually true since the only "service" the host provides is to receive every letter typed at the keyboard and react to this just like a computer would. The terminal is like a window into the computer just like a monitor is. You may have already used virtual terminals in Linux (by pressing Alt-F2, etc.). A real terminal is just like running such a virtual terminal on its own screen and keyboard. In contrast to using a virtual terminal at the console (monitor), this allows another person to sit at the real terminal and use the computer simultaneously with others. 1.3. Dumb Terminals There are various conflicting definitions of "dumb terminal", but as time goes by, more and more terminals are called dumb. This document mainly covers text terminals which display only text on the screen. It might be titled "Dumb-Terminal-HOWTO" but in some computer magazines any terminal, no matter how smart, including ones which present a full graphical user interface (GUI), are called dumb. If all terminals are "dumb" then there is no point of prefixing the word "dumb" to terminal (except as a sales pitch to sell computers or the like in place of "smart" terminals). Due to the ambiguous meaning of "dumb terminal" it is not classified here as a type of terminal. 1.4. Types of Terminals 1.4.1. Text Terminals For a text terminal, a 2-way flow of information between the computer and the terminal takes place over the cable that connects them together. This flow is in ASCII bytes where each byte usually represents a character. Bytes typed at the keyboard go to the computer and most bytes from the computer are displayed on the terminal screen. Special bytes (or sequences of bytes) from the computer tell the terminal where to move the cursor to, what to erase, where to begin and end underlining and/or blinking and/or bold, etc. There are often hundred of such special commands and many terminals can even change fonts. The communication uses characters (letters) encoded using a code chart for the character set being used. Usually, the first 128 bytes out of 256 possible bytes use ASCII codes. Terminals for unix-like systems, normally connect to computers via a cable running between the asynchronous serial ports (per RS-232-C = EIA-232-D) of the host computer and terminal. Sometimes the connection is via modem or terminal server, etc. Other names for text terminals are "serial terminal", "character-cell terminal", "ASCII terminal", "ANSI terminal", "asynchronous terminal", "data terminal", "video terminal" and "video display terminal" (VDT). In olden days "video display unit" (VDU) was used for terminals but strictly speaking, it excludes the keyboard. Old IBM mainframe terminals use "block mode". The characters you type are temporarily retained in the terminal memory (and may possibly be edited by a built-in editor at the terminal). Then when the send key (or the like) is pressed, a block of characters (sometimes just a line of characters) is sent to the computer all at once. Such terminals are not feasible to use with Linux. They are actually block devices (and not character devices). See section ``Block Mode''. 1.4.2. Graphics Terminals To a limited degree some ASCII symbols can provide graphics on text terminals. One may form arrows: <--- and draw boxes with _ and |. With special graphic character sets, even more is possible. None of these are really graphics terminals. However, the term "graphics terminal" is sometimes applied to all text-only terminals since text is a limited form of graphics. There are two basic types of graphics displays: raster and vector (rarely used). Raster graphics (bit-mapped) puts dots on the screen by horizontal scan lines drawn by an electron beam (or by energizing pixels or dots on a flat screen. Vector graphic displays use smart electronics to draw lines and curves with an electron beam that can move in any direction. Vector graphics draws high quality lines without zig-zags but is both rare and expensive. Raster graphics is almost universally used today. For PC's, images encoded in vector graphic format are sometimes used but they are translated to raster graphics format for display (with a drop in image quality). 1.4.3. Serial Line Graphics Terminals Most of this document also applies to these. Most of these can also function as text terminals. The protocalls for such graphics include: Tektronix Vector Graphics, ReGIS (DEC), Sixel (DEC), and NAPLPS (North American Presentation Level Protocall Syntax). All of these are monochrome ?? 1.4.4. Fast Graphics Terminals (often known by other names) None of these covered in this document. A terminal that deserves to be called smart is a graphics terminal which can rapidly display full- screen graphics just like a PC monitor. It will also have a mouse. Bytes sent to it often represent bit-maps for pictures (and other graphics). It will often use a high-speed connection to the computer using twisted pair or coax cable. X-Window terminals are such devices. For displaying a MS-Windows GUI there are at various types of interfaces and terminals: Winterm using WinFrame software from Citrix is one. Another (based in part on Citrix's code) is Hydra (code name) by Microsoft, also known as "Windows Terminal Server" which works with versions 4 or higher of MS Windows NT. Citrix uses its ICA protocall, and has created an add-on to Hydra known as pICAsso so that WinFrame (ICA) based terminals can use the Hydra system. Hydra is also multiuser. There is also the "MultiConsole Personal Terminal" by Unbounded Technologies and Tektronix has its multi-user interface but will now support Hydra. A magazine article in 1997 called Winterm a "dumb terminal" but it's really pretty smart. Such terminals are often called "thin clients", but some thin clients are more that just terminals as they can execute Java code sent to them, etc. 1.4.5. Quasi-Terminals (= Quasi-Computers) "Quasi" is my terminology (not standard). These are neither true computers nor terminals but are something in-between. Network Computers (NC's) are computers with a CPU but no hard Disk. They are full-graphics and connect to a server computer. They are different from terminals since the programs they run execute on their own CPU chips. Java code may be sent to them for execution. They should work on IP networks and might work under a server running Linux. Wintel established a "NetPC" which, unlike the NC, is almost a PC computer. However, it has no removable disks so users can't install their own software or obtain copies of anything. 1.4.6. Terminal Emulation Since a PC has a screen and keyboard (as does a terminal) but also has much more computing power, it's easy to use some of this computing power to make the PC computer behave like a text terminal. Software to do this is widely available and comes built-in with recent versions of MS Windows. An emulation program is often combined with a modem dialing program (such as Minicom for Linux) so that one may (for example) dial up public libraries to use their catalogs and indexes, (or even read magazine articles). The terminal emulated is often the old VT100 (text terminal). Sometimes the emulation is not 100% perfect but this usually causes few problems. A real terminal is often nicer to use than emulating one. It usually costs less, often has better resolution for text, and has no disk drives to make annoying noises. Some real terminals can emulate various models of terminals but it's still a real terminal. 1.5. Terminology Configuration means the same as set-up. While Linux commands take options (using - symbols), options in a broader sense include various other types of choices. Install in the broad sense includes setting up (configuring) software and hardware. A statement that I'm uncertain about ends with 2 question marks: ?? Let me know if you know that it's correct (or in error). 2. Quick Install This is a quick procedure to install a terminal without going through a ``Setup'' procedure for both the terminal and the host computer. It probably will not work right if the terminal happens to have been set up incompatible with the computer. If you don't understand some of it you'll need to consult other parts of this document for more info. To install a terminal, first look in /etc/termcap or terminfo.src to find an entry for it (see ``Terminfo and Termcap (detailed)''). You might try "vt100" if you can't find anything suitable. Figure out what serial port you'll connect it to and what the tty designation is for that port (e.g. ttyS1, see ``Device Names''. As the root user, edit /etc/inittab and add a getty command next to the other getty commands. The format of the getty command depends on which getty program you use (see Serial-HOWTO 4.1 & 7.2 and/or type "man getty"). For getty parameters use the terminfo (or termcap) name (such as vt100) for your terminal. Type in a baud-rate that the terminal supports. But if you set the baud too high you may need to use (See``Flow Control''). Then physically connect the serial ports of the terminal and computer together with a null-modem cable and turn on the terminal. Don't expect most ready-made cables to be wired correctly for hardware flow control. Make sure the baud-rate of the terminal is set the same as you gave to getty. Then at the computer console type "init q" to apply the changes you made to the inittab file. You should now see a login prompt at the terminal. If you don't, tap the terminal's return key. If this doesn't work read more of this document and/or see ``Trouble-Shooting''. 3. Why Use a Terminal ? 3.1. Introduction PC's are so powerful today that one such computer can often support several persons using it at once, especially if they are doing low- load tasks such as text editing, data entry, etc. One way to do this is to connect a number of terminals to a single computer (host computer) by modems or direct cable connection. To do this, one needs a multi-user operating system such as Linux. This has been called "time sharing" but it's not good terminology today since "distributed" computing over a network is also a type of time sharing. It might be better described as "centralized" computing. But the central computer may be connected to the rest of the world via a network over which terminal users may communicate with, so it's not really "centralized" either. Terminals have seldom been used with PC's because the popular operating systems used for them (Windows, DOS, and Mac) were not multiuser until 1998 (available for MS Windows NT) and previously could not support terminals. Now that Linux, a multiuser operating system, is freely available for PC's, the use of terminals with PC's becomes more feasible. The drawback is that text terminals are not smart enough to support the type of graphical user interface (GUI) that many computer users today normally expect. 3.2. Lower Hardware Costs If several people use the same computer as the same time, there is a reduction in the amount of hardware needed for the same level of service. One type of savings is due to code sharing. The application files on hard disks are shared as well as shared libraries in memory (even when people are running different programs provided they use some of the same functions in their code). Another type of savings is due to reduction of peak load. The hardware of a single PC may be idle most of the time as people slowly type in information, think, talk, or are away from their desks. Having several people on the same computer at once makes good use of much of this idle time which would otherwise be wasted. These savings are substantial. One may roughly estimate that for 9 persons (8 terminals & 1 console) the shared PC only needs about 3 times as much capacity (in memory, disk storage, CPU(s), etc.) as a single PC in order to provide the same level of service per person (9 times as much service overall). Thus the computational hardware for such a shared system should only cost about 1/3 as much per user. However, the cost of the display hardware (CRT's, keyboards, video electronics, etc.) is about the same for both cases. The terminals have the added cost of requiring additional serial ports at the host computer. For a fair comparison with PC's, the terminals should have the same capabilities as the PC monitors. Unfortunately, color graphic terminals for Linux (X-windows) with high speed communication is a niche market with high prices so in this case there may not be much (if any) savings in hardware costs. But for text terminals the savings will be substantial. 3.3. Control of Software For centralized computing, software (and the updates to software) only need be installed on one host computer instead of several. The person in charge of this computer may control the software which is installed on it. This is advantageous if the person controlling the host computer does an excellent job and knows about the needs and preferences of the other users. Users can be prevented from playing games or surfing the Internet by not installing the software (or by otherwise restricting access to it). Whether or not centralized control is desirable depends on the situation. 3.4. Hardware Upgrades With terminals, the computer hardware upgrades take place on only one computer instead of many. This saves installation labor effort. While the cost of the hardware for the host computer upgrade will be more than that for a single PC (since the host needs more computing power than a PC), the cost will be significantly less than upgrading a number of PC's being used instead of terminals. 3.5. Other Advantages of Terminals 1. The elimination of noise from fans and disk drives provided the terminals are not close to the computer. 2. The users of the terminals can share data and files and even send e-mail to each other. It's similar to a local network. 3.6. Major Disadvantages of Terminals 1. For the case of a text terminal, it has no high-speed graphic display (or high resolution graphics) although it can sometimes use graphic character sets to draw lines, etc. This lack limits the software that may be used on it. 2. If the host computer goes down, then no one can use the terminals either (unless there is another computer to connect to). 3.7. Are Text Terminals Obsolete ? Text terminals are technologically obsolete because for a slightly higher cost of hardware, one could build a smart terminal (with the same quality of display). This wasn't always the the case since around 1980 memory cost thousands of dollars per megabyte. Today with low costs for memory and processors, one could make a text terminal smart for only about a 10% or 20% increase in cost. The reasons that text terminals are not yet obsolete are: · Many people don't need full screen graphics. · The only smart terminal for Linux is an X-Window terminal which may cost more than a PC running Linux. · Used text terminals are often very low in cost, yet can give access to a much newer (and powerful) computer. 4. Overview of How Terminals Work (in Linux) See also section ``Some Details on How Terminals Work'' 4.1. Device Names Each terminal is connected to a serial port on the host computer (often just a PC). The ports have names: ttyS0, ttyS1, ttyS2 etc. These are represented by special files found in the /dev (device) directory. /dev/ttyS0 corresponds to COM1 in DOS or Windows. ttyS1 is COM2, etc. See ``Terminal Devices'' for more details. 4.2. Login/Logout When the host computer starts up it runs the program getty (see Serial-HOWTO 4.1 & 7.2) on each serial port which has a terminal on it (as specified in the file etc/inittab). The getty program runs the "login" program to log people in. A "login:" prompt appears on the screen. People at the terminals log in (after giving their passwords) and then have access to the computer. When it's time to shut the terminal down, one normally logs out and turns the terminal off. See ``Login Restrictions'' regarding restricting logins (including allowing the root user to log in at terminal). 4.3. Half/Full Duplex If one watches someone typing at a terminal, the letters one types simultaneously appear on the screen. A naive person might think that what one types is being sent directly from the keyboard to the screen with a copy going to the computer (called half-duplex). What is usually going on is that what is typed at the keyboard is directly sent only to the host computer (called full-duplex) which in turn echos back to the terminal each character it receives. In some cases (such as passwords or terse editor commands) the typed letters are not echoed back. 4.4. Terminal Memory The image on a CRT tube will fade away almost instantly unless it is frequently redrawn on the screen by a beam of electrons shot onto the face of the tube. Since text sent to a terminal needs to stay on the screen, the image on the screen must be stored in the memory chips of the terminal and the electron beam must repeatedly scan the screen (say 60 times per second) to maintain the image. See ``Terminal Memory'' for more details. 4.5. Commands for the Terminal The terminal is under the control of the computer. The computer not only sends the terminal text to display on the screen but also sends the terminal commands which are acted on. These are ``control codes'' (bytes) and ``escape sequences''. For example, the CR (carriage return) control code moves the cursor the the left hand edge of the screen. A certain escape sequence (several bytes where the first byte is the "escape" control code) can move the cursor to the location on the screen specified by parameters placed inside the escape sequence. The ``first terminals'' had only a few such commands but modern terminals have hundreds of them. The appearance of the display may be changed for certain regions: such as bright, dim, underline, blink, and reverse video. A speaker in a terminal can "click" when any key is pressed or beep if a mistake has occurred. Function keys may be programmed for special meanings. Various fonts may exist. The display may be scrolled up or down. Specified parts of the screen may be erased. Various types of flow control may be used to stop the flow of data when bytes are being sent to the terminal faster than the terminal can handle them. There are many more as you will see from looking over a terminal manual. 4.6. Lack of Standardization Solved by Terminfo While terminals made for the US all used the same ASCII code for the alphabet (except for IBM terminals which used EBCDIC), they unfortunately did not all use the same escape sequences. This happened even after various ANSI (and ISO) standards were established since these standards were never quite advanced enough. Furthermore, older terminals often lacked the capabilities of newer terminals. This might cause problems. For example, the computer might send a terminal an escape sequence telling it to split the screen up into two windows of specified size, not realizing that the terminal was incapable of doing this. To overcome these problems a database called "termcap" (now "terminfo") was established. This database resides in certain files on the computer and has a section of it (sometimes an entire file) for each model of terminal. For each model (such as VT100) a list of capabilities is provided including the available escape sequences to use, etc. See Section ``Termcap and Terminfo (detailed)'' for more details. Application programs may utilize this database by calling certain C-Library programs. One large set of such programs (over 200) is named "ncurses" and are listed on the manual page for ncurses. 4.7. The Interface The environment variable TERM is the type of terminal Linux thinks you are using. Application programs use this to look up the capabilities in the terminfo database so TERM needs to be set correctly. But there is more to a correct interface than the computer knowing about the capabilities of the terminal. For bytes to flow from the computer to the terminal the terminal must be set to receive the bytes at the same baud rate (bits per second) as they are sent out from the terminal. If the terminal is set to receive at 19,200 baud and the computer sends out characters at 9600 baud, only garbage (or perhaps nothing) will be seen on the screen. One selects the baud rate for a terminal (as well as many other features) from the terminals "set-up" menus at the terminal. Most terminals have a large number of options in their "set-up" menus. Computer serial port software has options also and these options must be set up in a compatible way. 4.8. Emulation Most terminals today have more than one personality (or emulation). The terminal model numbers of terminals formerly made by DEC (Digital Equipment Corporation) start with VT (e.g. VT100). Many other terminals which are not VT100 may be set up to emulate a VT100. Wyse is a major terminal manufacturer and most of their terminals can emulate various DEC terminals such at VT100 and VT220. Thus if you want to, say, use a VT320 terminal you may either use a real VT320 in "native" personality or possibly use some other terminal capable of emulating a VT320. The "native" personalities usually have more capabilities so, other things being equal, "native" is usually the best to use. The most common type of emulation is to use a PC like it was a terminal. Programs loaded into the PC's memory permits this. In Linux (unless you're in X-windows) the PC monitor (called the console) emulates a terminal. Even certain windows within X-windows emulate terminals. 4.9. The Console On a PC, the monitor is known as the console. It emulates a terminal of type "Linux". One logs onto it as a virtual terminal. See ``The Console: /dev/tty?''. It receives messages from the kernel regarding booting and shutdown progress. One may have the messages that normally go to the console, go the a terminal by patching and recompiling Linux. (see ``Make a Terminal the Console''). 5. Terminal Special Files: /dev/tty... etc. "tty" is an abbreviation for "Teletype". The first terminals were Teletypes (like remotely controlled typewriters). See subsection ``Teletypes''. 5.1. Serial Port Terminals The computer considers the terminal on a serial port to be a "device". For each such terminal there is a special file in the /dev (device) directory. /dev/ttyS0 is the special file for the serial port known as COM1 in the DOS/Windows world. To send text to a terminal you may redirect standard output of some command-line command to the appropriate special file. For example typing "echo test > /dev/ttyS1" at the command prompt should send the word "test" to the terminal on COM2 (provided you have write permission on /dev/ttyS1). Similarly, typing "cat my_file > /dev/ttyS0" will send the contents of the file my_file to COM1 (ttyS0). In addition to ttyS0 (/dev/ttyS0), ttyS1, ttyS2, etc. (the "S" stands for Serial port) there is also a "cua" series: cua0, cua1, cua2, etc. cua0 is the same port as ttyS0, etc. The "cu" of cua stands for CalloUt. The ttyS series are Posix compliant while using cua may permit the opening of a port that the modem control lines say is not ready. It's claimed that the cua series is only included for backwards compatibility so you should probably use the ttyS series. 5.2. Pseudo Terminals Pseudo terminals have no unique physical connector on the computer. They are used to emulate a serial port. For example, if someone connects via telnet to your computer over a network, they may wind up connected to the device /dev/ptyp2 (a pseudo terminal port). In X- Windows, the terminal emulator program, xterm, uses pseudo terminals. Ham radio programs under Linux also use them. Using certain application software it is possible to have 2 or more pseudo terminals attached to the same physical serial port. Pseudo terminals come in pairs such as ttyp3 and ptyp3. The pty... is the master or controlling terminal and the tty... is the slave. ttyq5 is also a pseudo terminal as is ttysc (c is a hexadecimal digit). More precisely, pseudo master terminals are /dev/pty[p-s]n and the corresponding slaves are /dev/tty[p-s]n where n is a hexadecimal digit. 5.3. The Controlling Terminal /dev/tty /dev/tty stands for the controlling terminal (if any) for the current process (the process that uses "/dev/tty" in a command). To find out which tty's are attached to which processes use the "ps -a" command at the shell prompt (command line). Look at the "tty" column. For the shell process you're in, /dev/tty is the terminal you are now using. Type "tty" at the shell prompt to see what it is (see manual pg. tty(1)). /dev/tty is something like a link to the actually terminal device name with some additional features for C-programmers: see the manual page tty(4). 5.4. /dev/ttyI? "Terminals" ? stands for an integer. One use of these in Linux is with the ISDN driver package: isdn4linux. The ttyI? is something like ttyS?. There is also a cui? which is something like cua?. The ttyI and cui emulate modems and may be given modem commands. 5.5. The Console: /dev/tty? In Linux the PC monitor is called the console and has several device special files associated with it: tty0, tty1, tty2, etc. When you log in you are on tty1. To go to tty2 press Alt-F2. tty1, tty2, etc. are "virtual terminals" (sometimes called "virtual consoles"). You may log in to different virtual terminals and thus have a few different sessions with the computer going on at the same time. You switch between them using the Alt-F? key where "?" is the virtual-terminal number you want. The console is also known as /dev/tty0 and system messages may go to that device and display on your console. Only the system or the root user may write to /dev/tty0 to which /dev/console is sometimes linked. System messages may also be written directly to the hardware address of the serial port card, thus bypassing /dev/tty0. For more info on the console see ``The Linux Console''. 5.6. Creating a Device with mknod The /dev directory comes supplied with many device special files. If you need something that's not there you may try to create it with the "mknod" command. See the manual page tty(4) for how to do this for serial ports. To use mknod you must know the major and minor device numbers. You might be able to infer the numbers you need by using the "ls -l" command in the /dev directory. It will display the major and minor numbers of existing special files. 6. Some Details on How Terminals Work If you know little about terminals, suggest you read the first section: ``Introduction'' and also read ``Overview of How Terminals Work''. 6.1. Terminal Memory The terminal screen refreshes itself at perhaps 60 times per second from an image stored in the memory of the terminal. For a PC the monitor's image is stored on the video card inside the computer but for a terminal, the equivalent of the video card is inside the terminal. For a text terminal the storage of the image uses little memory. Instead of putting every dot (pixel) on the screen into memory and requiring the storage of about a quarter-million dots, a much more efficient method of storage is used. A screen-full of text may be represented inside the terminal memory by ASCII bytes, one for each character on the screen. An entire screen only takes about 2K ASCII bytes. To display these characters, the terminal must also know the bit-map (the shape) of each of the almost 100 printable ASCII characters. With a bit-map of a character using say 15 bytes, only about 1.5K of memory is needed for the bit-maps of all the ASCII characters (the font). This ASCII text and font memory is scanned so that the resulting image is put on the screen about 60 times each second. This is a form of shared memory where a single bit-map of a letter such as the letter e, is shared by all of the many letter e's which appear on a screenfull of text. Low memory requirements meant low costs to produce monitors in the early 1980's when the cost of memory was several thousand times higher than it is today (costing then several dollars per kilobyte). 6.2. Early Terminals The first terminals were something like remotely controlled typewriters which could only "display" (print on paper) the character stream sent to them from the computer. The earliest models were called ``Teletypes''. Early terminals could do a line feed and a carriage return just like a typewriter and ring a bell when a bell character was received. Due to the lack of significant capabilities this was the first type of terminal to be labeled "dumb". This type of terminal interface (using a terminal type called "dumb") is sometimes used today when the computer can't figure out what kind of a terminal it is communicating with. 6.3. Control Codes and Escape Sequences Terminals have many capabilities some of which are always present and some of which require commands from the computer to change or activate. To exercise all these capabilities under the control of the computer requires that special codes be established so that the computer can tell the terminal what to do. There are two major type of such codes: control codes (control characters) and escape sequences. 6.3.1. Control Codes The control codes (or control characters) consist of the first 32 bytes of the ASCII alphabet. They include the following: carriage- return (cursor to far left), line-feed (cursor down one line), backspace, escape-character, tab, and bell. They do not normally show on the screen. There is usually a command which you may give to your terminal which will result in them being displayed when they are received by the terminal. It's called something like "Control Characters Visible". If you do this then the display may look a mess since escape sequences, which all start with the ESC (escape) control character, are no longer executed. Words which should appear at the top or bottom of the screen will show up in other locations. The escape sequences to reposition the cursor display on the screen but the cursor doesn't move to where the escape sequence says. 6.3.2. Escape Sequences Since there are not nearly enough control codes to do everything, many escape sequences are used. They consist of the "escape" (ESC) control character followed by a sequence of ordinary characters. Upon receiving an escape character, the terminal examines the characters following it so that it may interpret the sequence and carry out the intended command from the computer. Once it recognizes the end of a valid sequence, further characters received just display on the screen (unless they are control codes or more escape sequences). Some escape sequences may take parameters (or arguments) such as the coordinates on the screen to move the cursor to. The parameters become a part of the escape sequence. A list of the escape sequences for your terminal should be in the manual for the terminal. Except for very old terminals, there may be two or three hundred such sequences. If you don't have a manual it's not easy to find them. For vt100, the sequences are available on the Internet. By searching the Internet for one sequence (such as ESC[5m) you may come across a long list of them. One way to determine some of them is to find the termcap (terminfo) for the terminal and mentally decode it. See ``Terminfo and Termcap (detailed)'' in this document and/or the ``Termcap Manual'' on the Internet. Unfortunately, the termcap (terminfo) for a terminal often does not list all of the escape sequences which the terminal has available for use, but fortunately, the most important ones are usually there. 7. Special Capabilities of Some Terminals 7.1. Color While the common monochrome terminal is not a color terminal it may have a fixed "color" display other than white such as green or amber. All terminals have black (electron beam turned off = zero brightness). A real color terminal can change the color of the text and background to many different colors while a monochrome terminal can only change the brightness of a fixed color. However, changing the brightness, etc. gives a lot of possibilities. For example, a black and white (monochrome) terminal can have white, grey, and black by varying the brightness. Some words can be black on a light grey background while other are highlighted by black on white. In addition there is white on black, underlining, and blinking. Color works like the color on a computer monitor or TV screen. The CRT has three colors of dots on it with each color controlled by its own electron beam (3 beams). Monochrome has inherently better resolution since it doesn't depend on dots permanently fixed on the screen. For text terminals the only use of color is to differentiate text and this advantage is not always worth the cost of worse resolution. Thus monochrome may be better since it also costs less. 7.2. Dual Sessions For this the terminal has two serial ports. Each port is connected to a serial port on a different computer. Thus one may log in to two different computers with each session displaying in a split-screen window. Alternatively, each session may run full-screen with a "hot" key (or the like) to switch between sessions. One could also connect to two different serial ports on the same computer and log in twice (similar to "virtual terminals" at the console). 7.3. Printer/Auxiliary Port The terminal has two serial ports as above but the two ports are not identical in behavior. If a printer is connected to the printer or auxiliary port, then pressing certain keys will print the screen. One may also have everything that displays on the screen go also to the printer. If the port is an auxiliary port one may connect this to another computer and almost have dual sessions as above. However, the video memory inside the terminal may not retain both sessions so you may need to refresh the screen when switching to the other session. There will likely not be a hot key either but possibly a programmable function key may be programmed to do this. There exists various key combinations and escape sequences for controlling such a port. It may be difficult to find out how to use this port without having a terminal manual. 7.4. Character-Sets A character-set is normally represented by a list (or table or chart) of characters along with the byte code assigned to each character. The codes for a byte range from 0 to 255 (00 to FF in hexadecimal). In MS-DOS, character-set tables are called "code-pages". You should examine such a table if you're not familiar with them. They are sometimes included in printer and terminal manuals but may be difficult to find. ASCII is one of the most common character-sets used on text terminals. It is a 7-bit code but can be made into 8-bit if the first bit (high order bit) is always set to 0. Other character-sets are usually available (except on very old terminals where the only choice is ASCII). The first half of most character-sets are the conventional ASCII characters and the second half (the characters with the high- order bit set to 1) belong to a wide variety of character-sets. Character sets are often ISO standards. To get a non-ASCII character set on a terminal, you likely need to download a soft-font for that character-set into the memory of the terminal. Besides ASCII, there are some other common character-sets, all 8-bit. CP stands for Code Page character sets invented by IBM: CP-437 (DOS ECS), CP-850 (Multilingual Latin 1 --not the same as ISO Latin-1), ISO-8859-1 (Latin-1), ANSI (derived from Latin-1). MS Windows uses ANSI while the Internet often uses Latin-1. There are several ISO-8859 character sets in addition to Latin-1. These include Greek (-7), Arabic (-6), Eastern European (-2), and Russian (-5). There are many others. For example, KOI8-R is more commonly used for Russian than IS0-8859-5. Unicode is a very large character-set where each character is represented by 2 bytes instead on just one byte. Websites re character-sets are: · for a short listing of various character-set names. · for info on character-sets and the Internet. · · 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 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: ______________________________________________________________________ #define CONFIG_SERIAL_ECHO #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 . For some other brands see Computer ESP 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 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 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 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 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 at the University of Tennessee has a great deal of useful information about text terminals. · Boundless purchased the VT and Dorio terminal business from DEC. · Wyse 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.