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
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.
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
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
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
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,
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
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
If not, and you really don't have time to mess with this, you
can do some tricks from the host side. Lets 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
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
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
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
If the terminal is still screwed up, check to make sure that no
other process is using the port. Try this:
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.
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
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.
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
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
If this page was useful to you, please help others find it:
More Articles by Tony Lawrence
- Find me on Google+
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. We appreciate comments and article submissions.