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 (su