If you understand something, it is probably already obsolete - James BurkeSolving 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.
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.
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.
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.
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 do (stty $i ; echo "baud is $i\r\n" > /dev/ttya07) < /dev/ttya07 done
(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* do echo "Testing $i" echo "I am $i" > $i read ak done
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.
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!
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.
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 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.
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 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.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2012-07-15 Tony Lawrence