APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Dumb Terminals

© December 1998 Tony Lawrence
December 1998

If you understand something, it is probably already obsolete - James Burke

Solving today's problems with yesterday's technology,someday - Kevin Brooks Clark

Yeah, but people still use this stuff - Tony Lawrence

It is certainly true that hundreds, maybe even thousands of dumb CRT terminals are being replaced every day by personal computers. Yet, it is also true that the market for these devices, both new and used, is still pretty strong, because there still are many hundreds of thousands still being used, and many of them probably will continue to be used for years to come.

Update: this article was originally written in 1998. Today, fifteen years later, I still sometimes find these old serial terminals in use, although most are now attached to devices convert them to be used on a TCP/IP network.

And why not? If the application being used doesn't need anything more than a dumb terminal, why have the expense and complication of a PC? Dumb terninals are simple, have no moving parts, are relatively rugged, easy to diagnose (usually it's broken or it isn't), and easy to replace when needed.

So you are apt to find these still kicking about here and there. For those of us who started out when these were completely ubiquitous, dumb terminals create no fear and are not particularly challenging. But there is a whole new breed of consultant out there, young folks who don't have the advantage of having cut their teeth on these critters, and I have noticed that some of them find our comfortable old green screens a little confusing and maybe a little intimidating.

We can't have that, so this article is designed as "Serial Terminals 101", and includes some troubleshooting help too. If serial devices in general are a mystery to you, you'll also want to read Serial Wiring.

What does this thing do?

Dumb terminals are RS232 display devices. A host Unix machine can support many of these through dumb or intelligent serial ports. The terminals are connected to the serial ports by at least three wires: Transmit, Send, and Ground (RS232 pins 2,3 and 7 respectively). Terminals are DTE (Date Terminal Equipment) devices, and so are the standard (COM1 and COM2) devices in a PC. Don't panic! All DTE means is that the device sends data on a specific pin (pin 2 for DB25, 3 for DB9) and expects to recieve it on another pin (pin 3 for DB25 and -you guessed it!- 2 for DB9). By the way, if you don't know: DB25 is the 25 pin connector, DB9 is the smaller, 9 pin version.

Therefore, since both of these (the terminal and the computer) want to send characters on pin 2 and receive on pin 3 for (DB25 connections), it is necessary to use a null modem, or a crossed cable (at least 2 and 3 swapped) for the computer and the terminal to be able to communicate. Note that modems are DCE devices: these transmit on pin 3 and receive on 2, so they are ready to "talk" with a straight-through cable, but that cable would NOT work for connecting a terminal. Also note that since 9 pin serial ports transmit on pin 3 and receive on 2, a "normal" straight through 9 to 25 cable really isn't straight through, even though it probably is labelled as such.

However, not all serial ports are DTE. A number of manufacturers make dumb or smart serial cards (the distinction between dumb and smart is usually at least who is handling the port(s) interrupts: the main CPU or the card itself. The built in COM ports rely on the CPU; therefore they are "dumb"). These cards may provide either a DTE or a DCE interface, or may have RJ-12 or RJ-45 ports. You can find out whether or not a port is DTE by sticking a line analyzer onto (or into) it. A line analyzer is just a box that plugs into an RS232 line and has LED's to show which lines are active. Radio Shack sells one (Part # 276-1401) for around $15.00, but you can probably get them for less than $10.00 if you shop around. If the thing you've plugged into is DTE, you'll have a red TD light, and RD will be off.

Will these things talk?

You can use the line analyzer to solve all kinds of problems. Unplug the cable coming to the terminal, and stick the analyzer in it. Got a TD lit? Now plug the analyzer into the port on the terminal that you just took that cable off. Got TD again? The devices cannot talk to each other (some terminals have multiple ports, usually marked "Modem" and "Aux"- the Modem port is DTE, the Aux is usually DCE- watch out for that).

Got no lights coming from the cable? That isn't going to work either. Got both TD and RD lit? Wiring problem, or it could be that the port itself is blown. RD red and TD green? Wiring problem again.

Andrew Smallshaw warns:

On /Unixart/terminals.html I read: > Unplug the cable coming to the terminal, and stick the > analyzer in it. Oh no you don't. You unplug the cable coming into the host: a long serial cable acts as an aerial and on a dumb serial port, this can cause the machine to run rather slowly as it deals with all those spurious interrupts...

While this may be a valid point, you still have to check at the terminal: otherwise you can't tell what's happened to the wires before it got there. In a case where you can't even see the wiring (in the wall), the end you have may not even originate where you think it does. So heed Andrews advice and don't leave it unplugged like this, but it is necessary for testing.

If you don't have a line analyzer, you can use a volt-meter instead. It's a little less handy, of course, but you are looking for voltage between pins 2 and 7 (DB-25) and 3 and 7. Same idea, different tool.

Baud Rate

If the wiring is right, that's still not enough. The two devices need to speak the same language, and for RS232, that's baud rate, data bits,parity, and stop bits. Let's start with some basics: the SCO box is going to assume 8 data bits, no parity, and one stop bit. We''ll get to the baud rate in a minute, but first:

If your terminal is otherwise set correctly but is set for EVEN parity, you'll be able to type lower case "a"'s and "b"'s, but not upper case, and upper case "C"'s, but not lower case.

If it's set ODD, it will be the other way around.

Why? Because the characters themselves are 7 bits, and the eighth (paity) bit will be set or unset depending on whether the number of bits set (in 7 bits) is even or odd. So an "a" is decimal 65, which is 2 bits set (64 and 1), while a "b" is decimal 66, which is still 2 bits (64 and 2), while "c" is 3 bits (64, 2 and 1). So if "even" parity is set, the "c" needs a parity bit added, which the terminal would set, but the Unix box, expecting no parity, would see that as decimal 193 (65 + 128) and can't display it.

Note that the terminal doesn't display the character when you type it: the Unix machine echoes back the character.

If the terminal is set 7/even/1, you can type just about anything, but nothing happens.

If the baud rate is wrong, you'll get "garbage": wrong characters, no characters, characters with umlauts, etc.

So how do you set this stuff?

Good question, and I don't have a clue.

That is, how you get the terminal to do what you want depends on the terminal. An awful lot of the terminals you'll see connected to SCO machines have a key in the upper right hand corner marked "Select" or "Setup". Try pressing it. If that doesn't work, try holding one of the shift keys (usually the left) and pressing it. No? Try Control and that key. Still no luck? How about ALT and Select? Shift-Control-CapsLock? No? I hope you can find a manual!

If not, and you really don't have time to mess with this, you can do some tricks from the host side. Let's say that you know this is /dev/ttya07 (and knowing that can be quite a trick in itself, because it isn't always easy to figure out). You could do:

for i in 1200 2400 4800 9600 19200 38400
(stty $i ; echo "baud is $i\r\n" > /dev/ttya07) < /dev/ttya07

(you'll need to be logged in as root)

One and only one of these "baud is" lines will appear legibly on the screen. The rest will be garbage.

This sort of thing is also useful if you don't know what device this is. You'll annoy any legitimate terminal users, but you can do (assuming your devices are named ttya-something):

for i in /dev/ttya*
echo "Testing $i"
echo "I am $i" > $i
read ak

If you are successful in getting into the terminal's setup screen, there is usually some way to "default" the settings. If you have a non-working terminal, default settings may be a good place to start, but be sure you know what the settings were before you do that. There is at least one thing not set by default that you will need, and that's flow control. For terminals, that should be XON/XOFF, or "Software" flow control. That's usually set in the same place that the baud rate is set. Flow control is critical to use of the terminal, though (again) not for initially logging in.

Quite a few terminals have non-intuitive methods for saving the settings. Read the screens carefully if you aren't lucky enough to have a manual.

Some terminals will do diagnostics when they are turned on. Wyse models, for exampple, will display "K" in the upper left corner of the screen if the keyboard doesn't pass muster (by the way, you can't just use any old keyboard with any old terminal, even they are both the same manufacturer: different models take different keyboards). Other codes are possible.

There is also usually a key or keys that will perform a hard reset of the terminal, putting everything back to default values. For some Wyse terminals, you can press and hold "G" while turning the unit on; this resets everything to factory values.

Some terminals have a status line that indicates communications mode: you want to see FDX (not BLK). If you see something like PRTX or BSY, it might mean that the terminal thinks it has been sent a screen print command, and that it trying to print out of its AUX or (some models) parallel port.

Intelligent multiport cards usually have a better way to do local pass-through printing. They do the same sequences, but they send only small bursts of data and they buffer your terminal keystrokes so that effectively the printing appears to happen in the background. Digiboard, for example. provides transparent print devices that match the terminals- just send your data to the appropriate device, the Digiboard driver handles the rest.

Pass-through printing (sometimes called "local printing", "transparent printing") is always accomplished by sending some special string to the terminal that tells it to send the next data it gets out some other port- auxiliary or parallel. Usually there's some support in the OS for this- SCO has used "local" and "lprint" - but it's usually pretty bad, because it's just a lousy way to print. Your keyboard is unusable while the data prints, and it's possible that just touching a key will screw everything up.

But there are conditions where this will not work- for example, a terminal emulator running on a Windows machine can do local printing, but it usually will not work if the printer is a "Windows only" printer because of the way that the emulator sends the data. Even if it does work, you may have to try different Windows drivers configurations. You generally can't print graphics through a terminal- often certain bytes won't be passed at all, and of course there's always the magic sequence that tells it to stop doing transparent print: that definitely can't be in the data. So, this is really a bad way to print. Use an LPD server if you can ( AlphaCom 3 Terminal Emulator and LPD server ).

Some terminals (Wyse370 is a good example) have extra features like color and the ability to connect to two different hosts, and switch between them. Many Wyse models have built in calculators, schedulers and alarm clocks (WyseWorks). Almost all terminals have some degree of flexibility with regard to key clicks, scrolling speed, etc. Most will let you control the speed at which function keys send escape sequences, will let you redefine function and other special keys (DELETE is a key that SCO users often want defined to work as the "interrupt" key), etc.

All of these special features and functions mean that you really need the manuals!

The Unix Side

On the Unix side, the baud rate and other settings for each terminal is controlled by /etc/inittab. That is, therefore, the first place to look if you have an otherwise working system but one or more terminals acting up. The inittab ifile can tell you what the device names are, and what the baud rate is.

The actual control is by /etc/inittab, but there is another file involved too: let's say the port you want is ttya07. Type "disable ttya07" and you will see a message about "/etc/inittab updated" and then "/etc/conf/init.d/??? updated". Note the name, because to change baud rate, you need to edit BOTH files (the second one, and others in /etc/conf/init.d, are used to rebuild inittab when the kernel environment is rebuilt).

If you saw "Already disabled", then try "enable ttya07" before you mess with anything else. A terminal must be enabled before a login prompt will appear.

If you'd like to make copies of these before editing, that's a great idea, but DO NOT make copies in /etc/conf/init.d ! Make copies elsewhere, or you'll have a really confused mess later. Also, if you see backups in here (files named sio.bak or anything like that), get rid of them: they could well be the source of your problem. If that's the case, you'll have an inittab with multiple entries in it: you can either clean up /etc/conf/init.d, and relink and rebuild, or manually correct /etc/inittab: let's hope you don't have that mess, but believe me, I've seen it more than once.

Assuming you don't have that, you'll find ONE line referencing ttya07 in each file. You'll find that line ends with either a letter or a number. It should end with a letter, but I've seen people screw this up. The letter is a lookup reference to the /etc/gettydefs file. Every line in that file begins with a letter or a number, and then sets the baud rate (and some other characteristics) for the terminal. So, for example, if you want 19200, you want "n" at the end of your line in inittab.

Here's a sample line:

Se2a:234:respawn:/etc/getty tty2a m

That's COM2, it is enabled for logins (the "respawn" tells us that) and the speed is "m" or 9600 baud. The "m" line from gettydefs is:

m # B9600 HUPCL # B9600 CS8 SANE HUPCL TAB3 ECHOE IXANY #\r\nlogin: # m

After you make these changes, type "enable ttya07" (or whatever it is) and then, just to be safe, "disable ttyA07" (note the upper case A). You'll probably get a "Already disabled" message, and that's OK.

If the terminal is still screwed up, check to make sure that no other process is using the port. Try this:

disable ttya07
fuser /dev/ttya07
fuser /dev/ttyA07

Both of those "fuser" commands should return NOTHING. If they do spit back numbers, then some other process is using your port, and it is messing you up. You can kill it, of course, but you need to figure out what starts it, and correct the problem. The most likely situation is that the line was once used for a printer, and there is a "hold-open" script setting baud rate and flow control. That will be somewhere in the rc directories, but since some other administrator added it, it could be anywhere.

How fast can it go?

Almost any terminal should be able to present an ungarbled login prompt at 19200, but not all terminals are going to actually work well at that speed. It depends on distance, the state of the wiring, the device at the host end, and the state of health of the terminal. Many terminals can work at 38400 with good serial boards, but it is also true that many of those can really only display characters at around 18K baud, so the 38400 setting may not actually give any more speed than 19200.

What type?

A common misconception is that setting the wrong terminal type (defined to Unix in /etc/ttytype and of course within the terminal itself) will prevent a login prompt. It will not. Until someone logs in, the Unix box doesn't know or care what type is being used.

However, after logging in is a completely different story. The terminal type becomes very important once you are logged in and trying to run an application.

The reason is simple: there is very little standardization between terminals. A wyse60 is very different from a vt100, and they are both unlike a Texas Instruments ti950. Function keys send different codes, arrow keys do also, and the sequences to clear the screen, position the cursor or draw boxes are different. Therefore, if the Unix box thinks you are using a Tandy DT-100 terminal, but it is actually a Wyse 370, you'll get quite a mess on your screen the moment you try to do much of anything.

Worse, many terminals "emulate" other terminals, but they don't necessarily do so accurately. So your terminal may have a vt100 mode, but not the vt100 mode that your program is expecting. Again, things may not work well or at all.

On the Unix side, there is more confusion. Older programs (and some simple applications) use "termcap" to find out how a particular terminal type is supposed to work, while newer ones use "terminfo". Unfortunately, there are quite a few programs that use neither of those, but have their own information about terminals. Wherever the information comes from, if your terminal doesn't behave the way the program expects it to, then things are not going to work well. These problems don't just affect dumb terminals; PC emulation programs can and will have the same problems (note that "ansi" and "vt100" are among the most troublesome types).

There is no easy way to tell which method a particular program will use. The "captoinfo" program can be used for creating terminfo files from termcap entries, "infocmp" compares or prints out terminfo entries, and "tic" compiles entries. If you have to get into this heavily, there are books available: Termcap & Terminfo, and the online manual pages, of course.

Function keys

Debugging this sort of incompatibility can be difficult and frustrating. One thing you do need to see is what your terminal actually is sending. For example, if function or arrow keys are not working, you need to see what sequences they really are generating and compare those to what the program expects. The "hd" command is helpful here: type "hd <ENTER>, and then press the keys you are debugging, concluding with a newline and a control-D.

The ESC key problem

The ESC key is often a problem for Unix apps. The problem is that many terminals use ESC as the lead in for other sequences: for example, F1 might generate ESC-[-M. So, when the application sees ESC, it has to wait to see what comes next. In a poorly written program, that can slow things down or even cause function keys not to work at all (5.0.6 users can see What can I do about function keys not working?).

Some terminals can be put into a "scan-code" mode, where the keys work like PC keyboards do: sending a unique code both when pressed and when released. If the terminal can do it, and the application can handle that mode, this can be much smoother.

See also Termcap and Terminfo.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Serial Terminals

1 comment

Inexpensive and informative Apple related e-books:

Take control of Apple TV, Second Edition

Take Control of the Mac Command Line with Terminal, Second Edition

Take Control of OS X Server

Take Control of Parallels Desktop 12

Take Control of Automating Your Mac

More Articles by © Tony Lawrence

Well, it is the end of an era. After some 17 years of production, Wyse Technology has retired the king of ASCII terminals, the venerable WY-60, officially EOLed in November 2004.

The WY-60 is an all time best seller, exceeding the sales of all of the DEC VT models combined. I can't recall how many 60's I have installed (and repaired) over the years, but it has to be in excess of a thousand or so (one installation alone had over 30 of the suckers hooked up to a SCO UNIX 3.2v4.2 box powered by a single 200 MHz AMD K6 -- it ran plenty fast for the times). Even as Wyse developed newer models, the WY-60 continued to be the weapon of choice due to its features, easy-on-the-eyes display and reliability. In fact it was just before they EOLed the 60 that I sold one to a client who is still processing on terminals.

The funny thing is that even though everyone is enamored with GUI's, mice, PC's, etc., terminals are still the preferred "human interface device" in applications where reliability is paramount (e.g., airline reservations systems). There's little to go wrong in a terminal and once the firmware has been debugged (as was the case with the WY-60 long ago), the system stability is limited only by the host machine. The three WY-60's I have here (which are still in use -- I prefer them for editing source code and performing admin on our UNIX boxes) have been in service for close to 11 years, two of which still have the original CRT.

Anyhow, time marches on and I imagine a time will come when terminals will take their place in computer museums alongside Tele-Type machines, Osborne "luggables" and eight inch floppy drives. So, as the old saying goes, the king is dead. Long live the king!


Mon Apr 18 14:18:25 2005: 352   richlove

Wyse 60 emulation is still popular with my clients using MacWise.


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

Be respectful to your superiors, if you have any. (Mark Twain)

Linux posts

Troubleshooting posts

This post tagged:



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode