Text-Terminal-HOWTO <author> David S. Lawyer <url url="mailto:dave@lafn.org"> -<date> v1.23, July 2001 +<date> v1.24, August 2001 <!-- Change log: +v1.24 Aug. 2001 Respawning too fast due to no such device, block mode +obsolete, troubleshooting: diplays escape sequences, detective work +for repair v1.23 July 2001: 10-cond. is not RJ45/48 ?, corrupted character attributes v1.22 May 2001 Clarity: 8-bit, ASCII, national replacement characters, CP1252=MS-ANSI @@ -166,13 +169,15 @@ url="http://linuxdoc.org/mirrors.html">. Various formats are available. If you only want to quickly check the date of the latest version look at <url url="http://linuxdoc.org/HOWTO/Text-Terminal-HOWTO.html">. The -version your are currently reading is: v1.23, July 2001 . New in recent +version your are currently reading is: v1.24, August 2001 . New in recent versions:<newline> -v1.23 July 2001: 10-cond. is not RJ45/48 ?, corrupted character - attributes<newline> -v1.22 Clarity: 8-bit, ASCII, national replacement characters, - CP1252=MS-ANSI<newline> -v1.21 More on mgetty, getty-login sequence, agetty parity +v1.24 Aug. 2001 Respawning too fast due to no such device, block mode +obsolete, troubleshooting: displays escape sequences, detective work +for repair +v1.23 July 2001: 10-cond. is not RJ45/48 ?, corrupted character attributes +v1.22 May 2001 Clarity: 8-bit, ASCII, national replacement characters, + CP1252=MS-ANSI +v1.21 April 2001 More on mgetty, getty-login sequence, agetty parity problem, types of "terminal servers", parity set shows upper 128 chars., Correction: PCTerm doesn't work with MS DOS, troubleshooting: no CD signal @@ -1690,7 +1695,19 @@ presses control-S. Much less common is the opposite case where the PC can't keep up with your typing speed and tells the terminal to stop sending. The terminal "locks" its keyboard and a message or light should inform you of this. Anything you type at a locked keyboard is -ignored. +ignored. When the PC catches up on it's work, then the keyboard +should unlock. When it doesn't, there is likely some sort of deadlock +going on. + +Another type of keyboard lock happens when a certain escape sequence +(or just the ^O control character for Wyse 60) is sent to the +terminal. While the previous type of lock is done by the serial +driver, this type of lock is done by the hardware of a real terminal. +It's a catch-22 situation if this happens since you can't type any +commands to escape out of this lock. Going into setup and resetting +might work (but it failed on my Wyse 60 and I had to cycle power to +escape). One could also send an "unlock keyboard" escape sequence +from another terminal. The term "locked" is also sometimes used for the common case of where the computer is told to stop sending to a terminal. The keyboard is @@ -1922,17 +1939,18 @@ doesn't yet (2000). <tscreen><verb> PC male DB25 Terminal DB25 +DSR Data Set Ready 6 + | +DCD Carrier Detect 8 <-- 20 DTR Data Terminal Ready TxD Transmit Data 2 --> 3 RxD Receive Data RxD Receive Data 3 <-- 2 TxD Transmit Data RTS Request To Send 4 --> 5 CTS Clear To Send CTS Clear To Send 5 <-- 4 RTS Request To Send -DSR Data Set Ready 6 - | -DCD Carrier Detect 8 <-- 20 DTR Data Terminal Ready SG Signal Ground 7 --- 7 SG Signal Ground - 6 DSR Data Set Ready - | DTR Data Terminal Ready 20 --> 8 DCD Carrier Detect + | + 6 DSR Data Set Ready + </verb></tscreen> <label id="DB_pin-out"> Alternatively, a full DB9-DB25 null modem cable (will not work @@ -1950,7 +1968,7 @@ DCD Carrier Detect 1 DSR Data Set Ready 6 <-- 20 DTR Data Terminal Ready RTS Request To Send 7 --> 5 CTS Clear To Send CTS Clear To Send 8 <-- 4 RTS Request To Send -(RI Ring Indicator 9 not needed) +(RI Ring Indicator 9 (not needed) </verb></tscreen> (Yes, the pins 2 and 3 really do have opposite meanings for DB9 and DB25 connectors!) @@ -2295,9 +2313,9 @@ Pin Signal Signal Pin 4 SG (RxD)--------------------| 5 RxD <--------------------------- TxD 3 6 DSR <--------------------------- RTS 7 - |--- DTR 4 + |--> DTR 4 |--> CD 1 - RI 9 + (no connection) RI 9 </verb></tscreen> <sect3> 8-conductors and 10-conductors <p> RJ45 and RJ48 are 8-conductor modular telephone plugs. @@ -3651,15 +3669,15 @@ In fact, you can run "setserial" and assign a purely fictitious I/O port address, any IRQ, and whatever uart type you would like to have. Then the next time you type "setserial ..." it will display these bogus values without complaint. They will also be officially -registered with the kernel as seen by the "scanport" command. -Of course the serial port driver will not work correctly (if at all) -if you attempt to use such a port. Thus when giving parameters to -"setserial" anything goes. Well almost. If you assign one port a -base address that is already assigned (such as 3e8) it will not accept -it. But if you use 3e9 it will accept it. Unfortunately 3e9 is -already assigned since it is within the range starting at base address -3e8. Thus the moral of the story is to make sure your data is correct -before assigning resources with setserial. +registered with the kernel as displayed (at the top of the screen) by +the "scanport" command. Of course the serial port driver will not +work correctly (if at all) if you attempt to use such a port. Thus +when giving parameters to "setserial" anything goes. Well almost. If +you assign one port a base address that is already assigned (such as +3e8) it will not accept it. But if you use 3e9 it will accept it. +Unfortunately 3e9 is already assigned since it is within the range +starting at base address 3e8. Thus the moral of the story is to make +sure your data is correct before assigning resources with setserial. While assignments made by setserial are lost when the PC is powered off, a configuration file may restore them (or a previous @@ -3672,7 +3690,13 @@ name="Configuration Scripts/Files"> <sect2> Probing <label id="probing_ss"> -<p> With appropriate options, <tt/setserial/ can probe (at a given I/O +<p>Prior to probing with "setserial", one may run the "scanport" +command to check all possible ports in one scan. It makes crude +guesses as to what is on some ports but doesn't determine the IRQ. But +it's a fast first start. It may hang your PC but so far it's worked +fine for me. + +With appropriate options, <tt/setserial/ can probe (at a given I/O address) for a serial port but you must guess the I/O address. If you ask it to probe for /dev/ttyS2 for example, it will only probe at the address it thinks ttyS2 is at (2F8). If you tell setserial that ttyS2 @@ -3683,11 +3707,12 @@ The purpose of this is to see if there is a uart there, and if so, what its IRQ is. Use "setserial" mainly as a last resort as there are faster ways to attempt it such as wvdialconf to detect modems, looking at very early boot-time messages, or using <tt>pnpdump ---dumpregs</tt>. To try to detect the physical hardware use the -v -(verbose) and <tt/autoconfig/ command to <tt/setserial/. If the -resulting message shows a uart type such as 16550A, then you're OK. -If instead it shows "<tt/unknown/" for the uart type, then there is -supposedly no serial port at all at that I/O address. Some cheap +--dumpregs</tt>. To try to detect the physical hardware use for +example :<newline> +<tt>setserial /dev/ttyS2 -v autoconfig</tt><newline> +If the resulting message shows a uart type such as 16550A, then you're +OK. If instead it shows "<tt/unknown/" for the uart type, then there +is supposedly no serial port at all at that I/O address. Some cheap serial ports don't identify themselves correctly so if you see "<tt/unknown/" you still might have a serial port there. @@ -3695,15 +3720,15 @@ Besides auto-probing for a uart type, setserial can auto-probe for IRQ's but this doesn't always work right either. In one case it first gave the wrong irq but when the command was repeated it found the correct irq. In versions of setserial >= 2.15, the results of your -last probe test may be saved and put into the configuration file -<tt>/etc/serial.conf</tt> which will be used next time you start -Linux. At boot-time when the serial module loads (or the like), a -probe for UARTs is made automatically and reported on the screen. But -the IRQs shown may be wrong. The second report of the same is the -result of a script which usually does no probing and thus provides no -reliable information as to how the hardware is actually set. It only -shows configuration data someone wrote into the script or data that -got saved in /etc/serial.conf. +last probe test could be automatically saved and put into the +configuration file <tt>/etc/serial.conf</tt> which will be used next +time you start Linux. At boot-time when the serial module loads (or +the like), a probe for UARTs is made automatically and reported on the +screen. But the IRQs shown may be wrong. The second report of the +same is the result of a script which usually does no probing and thus +provides no reliable information as to how the hardware is actually +set. It only shows configuration data someone wrote into the script +or data that got saved in /etc/serial.conf. It may be that two serial ports both have the same IO address set in the hardware. Of course this is not permitted but it sometimes @@ -3712,6 +3737,7 @@ are two. However if they have different IRQs, then the probe for IRQs may show IRQ = 0. For me it only did this if I first used <tt/setserial/ to give the IRQ a ficticious value. + <sect2> Boot-time Configuration <label id="sets_boot_time"> <p> When the kernel loads the serial module (or if the "module equivalent" is built into the kernel) then only <tt/ttyS{0-3}/ are @@ -4676,7 +4702,7 @@ the previous section. <sect2> Symptoms and some fixes <label id="symptoms_"> <p> When the display doesn't look right, or when what you type doesn't display correctly (if at all), or nothing happens when you type a -command, you may have a corrupted terminal interface. In rare cases +command, you may have a corrupted terminal interface. In rare cases, when the serial port hardware gets itself corrupted, the only fix may be to cycle power (turn off the PC and reboot). In some cases just cycling power for the terminal will fix it. Sometimes logging in again @@ -4713,9 +4739,10 @@ 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. +display a message telling you that they can't edit binary. But you're +likely to corrupt things if you: "cat ...." or "cp .... /dev/tty.." or +run a program which sends binary output to "standard output" (unless +you redirect such output with >, etc.). Corruption it can also happen when using a communications program where a remote computer may send binary to your screen. There are numerous @@ -5218,9 +5245,11 @@ stty rows 24 <sect> Trouble-Shooting <label id="trouble_shoot"> <p> If you suspect that the problem is a hardware problem, see the <ref -id="repair_" name="Repair and Diagnose"> section. If it's the keyboard -see <ref id="keyboards_" name="Keyboards">. If the problem involves -the serial port itself see the Serial-HOWTO. +id="repair_" name="Repair and Diagnose"> section. If it's the +keyboard see <ref id="keyboards_" name="Keyboards">. If it responds +incorrectly (if at all) to what you type. see <ref +id="corrupt_interface" name="Corrupted Terminal Interface">. If the +problem involves the serial port itself see the Serial-HOWTO. Here is a list of possible problems: <itemize> @@ -5228,12 +5257,13 @@ Here is a list of possible problems: Suspect the terminal is defective. <item><ref id="display_freezes" name="Display Freezes (hung terminal)"> -<item><ref id="displays_garbage" name="Displays Garbage"> Characters you - type or see are "foreign" letters/symbols. +<item><ref id="displays_foreign" name="Displays Foreign/Weird + Characters/Symbols"> +<item><ref id="displays_esc-seqs" name="Displays Escape Sequences"> <item><ref id="flow_ctrl_ng" name="Missing Text"> Either skips -over some text or displays some text OK and hangs. + over some text or displays some text OK and hangs. <item><ref id="keys_erratic" name="All Keys Work Erratically; Must Hit -a Key a Few Times"> + a Key a Few Times"> <item><ref id="stopped_" name="If getty run from command line: Programs get stopped"> with message "Stopped" <item><ref id="rapid_respawn" name="Getty Respawning Too Rapidly"> @@ -5255,7 +5285,7 @@ the next section. <p> When a formerly working terminal suddenly goes bad it is often easy to find the problem. That's because (except for hardware failures) the problem is likely due to something that you did (or -something the software you used did). +something the software that you used did). The problem may be obvious such as an error message when the terminal is first turned on. If it makes a strange noise it likely needs @@ -5298,20 +5328,19 @@ causes. You should deviate a little from this method based on hunches and clues. <sect1> Is the Terminal OK ? <label id="term_OK"> -<p> Many terminals will start up with some words on the -screen. If these words convey no error message, it's probably -OK. If there is no sign of power (a dark screen, etc.) re-plug in the -computer power cord at both ends. Make sure there is power at the -wall jack (or at the extension cord end). Try another power cord if -you have one. Make sure the terminal is turned on and that its fuse -is not blown. A blank (or dim) screen may sometimes be fixed by just -turning up the brightness and contrast using knobs or a keyboard key -in set-up mode. +<p> Many terminals will start up with some words on the screen. If +these words convey no error message, it's probably OK. If there is no +sign of power (a dark screen, etc.) re-plug in the computer power cord +at both ends. Make sure there is power at the wall jack (or at the +extension cord end). Try another power cord if you have one. Make +sure the terminal is turned on and that its fuse is not blown. A +blank (or dim) screen may sometimes be fixed by just turning up the +brightness and contrast using knobs or a keyboard key in set-up mode. -A terminal that's been stored for a long time may -take a while to "warm up" as the electrolytic capacitors heal -themselves under voltage. If it still won't work See <ref -id="repair_" name="Repair & Diagnose"> for tips on repairing it. +A terminal that's been stored for a long time may take a while to +"warm up" as the electrolytic capacitors heal themselves under +voltage. If it still won't work See <ref id="repair_" name="Repair & +Diagnose"> for tips on repairing it. If the terminal starts up OK, but you suspect that something may be wrong with it, go into "local mode" where is works like a typewriter @@ -5369,32 +5398,59 @@ terminal nor the gpm mouse program uses lockfiles. Since others may need to write to your terminal, it's reasonable not to use lockfiles. See Lock-Files in the Serial-HOWTO. -<sect1> Getty Respawning Too Rapidly <label id="rapid_respawn"> +<sect1> ... respawning too fast: disabled for 5 minutes + <label id="rapid_respawn"> + +<sect2>What's happening +<p>You see a message on the console like: "Getty respawning too fast: +disabled for 5 minutes". Instead of "Getty" it may display a label +(such as "S2") for the line in /etc/inittab from where from where getty +was called. + +When getty starts up, it tries to send a login message to the serial +port. But if there is something seriously wrong, getty will be +immediately killed. Since the /etc/inittab file line for getty says +to "respawn", getty is started again, only to be killed again, etc. +Thus getty respawns over and over. But the operating system +intervenes and stops this nonsense (for 5 minutes). The following +sections show possible causes and fixes. <sect2> No modem control signal -<p> If getty can't open and/or use a port because of the lack of a -positive modem control voltage on one of the pins, then getty might -be killed. Then, per the instructions in inittab, getty respawns and -tries again, only to be killed again, etc., etc. You may see an error -message like: Getty respawning too fast: disabled for 5 minutes. -Instead of "Getty" it may give the label (such as S2) of the line in -/etc/inittab from where from where getty was called. Try using -the "local" option with getty and/or check the modem control settings -and voltages. +<p> If the terminal doesn't send the PC a CD signal on one of the pins +of the serial port, getty will be killed unless the "local" option has +been used with getty. So a quick fix is to just use a "local" option +(-L for agetty, "CLOCAL" in /etc/gettydefs for ps_getty). + +Another approach is to determine why CD is not being asserted. In +many cases the cable to the terminal simply doesn't have a wire for +the CD pin so you must use the "local" option. If there is a wire for +the CD pin then there may not be any signal on it until the terminal +is powered on. Note that the CD pin signal is sometimes supplied by +the DTR pin of the terminal (or the PC) by using jumper wires inside +the connector. + +<sect2> No such serial device +<p>If the device (such as /dev/ttyS2) is bogus (doesn't physically +exist or has been disabled), then getty will be killed. You may use +"scanport" and/or "setserial" to probe for the device or try another +ttyS. Perhaps the device has been disabled in the CMOS. See +"Serial-HOWTO". <sect2> No serial support <p> Linux provides serial support either by selecting it when -compiling the kernel or by loading the serial module. This +compiling the kernel or by loading the serial module: serial.o. This "respawning" error happens if serial support has neither been built into the kernel nor provided by a serial module. You many use the -"lsmod" command to see if the serial module is loaded. +"lsmod" command to see if the serial module is loaded. To see if +serial support is built into the kernel, check a kernel configuration +file (in /boot, in the source tree, etc.) <sect2> Key shorted <label id="key_shorted_getty"> <p> Another possible cause of getty respawning too rapidly is if a -keyboard key is shorted, giving the same result as if the key was +keyboard key is shorted. This gives the same result as if the key was continuously held down. With auto-repeat enabled, this "types" thousands of characters to the login prompt. Look for a screen filled -with all the same character (in some cases with 2 or more different +with all the same character (in some cases, with 2 or more different characters). <sect1> Fails Just After Login <label id="after_login"> @@ -5536,25 +5592,68 @@ you could get a false high AC reading when looking at the idle DC of good device (such as another terminal or an external modem) to the serial port and see if it works OK. -<sect1> Displays Garbage <label id="displays_garbage"> - -<p> If what you type or see on the screen is not what's expected but -looks like a foreign alphabet, math symbols, line-drawing character, -etc. then it could be that the many of bytes that are sent to your -terminal have the high order bit set (when it shouldn't be). You are -looking at the character set (or part of a character set) which has -the high order bit set. This may happen if you have the baud rate -wrong or parity set wrong (per stty). If you have parity set per stty -but inside the terminal it's 8-bit no-parity, then the high order bit -(= parity bit) will often be erroneously set. Try stty -F /dev/ttyS? -from another terminal to check if the baud rate and parity are -correct. +<sect1> Displays Foreign/Weird Characters/Symbols +<label id="displays_foreign"> +<p> Don't confuse this with <ref id="displays_esc-seqs" name="Displays +Escape Sequences">. If what you type or see on the screen is not +what's expected but looks like a foreign alphabet, math symbols, +line-drawing character, etc. then it could be that the many of bytes +that are sent to your terminal have the high order bit set (when it +shouldn't be). You are looking at the character set (or part of a +character set) which has the high order bit set. This may happen if +you have the baud rate wrong or parity set wrong (per stty). If you +have parity set per stty but inside the terminal it's 8-bit no-parity, +then the high order bit (= parity bit) will often be erroneously set. +Try stty -F /dev/ttyS? from another terminal to check if the baud +rate and parity are correct. Perhaps the wrong character set (font) has been installed. An erroneous escape sequence sent to the terminal could have switched character sets. If you are using the mapchan program to change the keyboard mapping, it could be incorrect. +<sect1> Displays Escape Sequences <label id="displays_esc-seqs"> +<p>You may see something like "5;35H22,1" or "3;4v" or "1;24r" or +"^[[21;6H", etc., etc. Of course, the numbers and letters will be +different. They will be scattered about (either randomly or in a +strange sense of order). The display will look a mess and will likely +have other defects. Some application and commands will result in +corrupted displays. + +What you see are escape sequences (or fragments of them) that were +sent to your terminal in order to control it, but your terminal didn't +recognize them and passed them on to the screen. It's likely that the +program you're using erroneously thinks you are using another type of +terminal. Thus it sends escape sequences that your terminal doesn't +understand. This can sometimes do strange things to your display. +Check that the TERM environment variable is set correctly (type: echo +$TERM). + +<sect2>Telnet +<p>The problem of getting TERM right can be a bit more complex if you use +telnet. Telnet doesn't emulate a terminal but passes the value of +your TERM variable to the remote computer. If the remote computer +doesn't support your type of terminal, or changes the value of TERM to +a wrong value (on the remote) then there's trouble. Telnet +should initially set the value of TERM correctly on the remote. But +changes to the value of TERM (on the remote) could be caused by an +incorrect shell configuration file there. The first thing to do is to +check the value of TERM, both on your computer and on the remote. The +above is overly simplified since it's possible for your telnet client +to present the remote server with a list of possible TERM values which +your computer supports (if it can emulate more than one terminal +type). + +<sect2>Terminal set to display escape sequences +<p>Another possible cause is that your terminal happens to be in a +special mode where it displays the escape sequences instead of +executing them. Then you'll also see them on the screen but they will +display in an orderly fashion. This mode is more precisely, one that +displays control codes. But since each escape sequence starts with a +control code (the "escape" character), the whole escape sequence is +not recognized by the terminal and is passed along to the screen. See +<ref id="control_codes" name="Control Codes">. + <sect1> Slow: pauses of several seconds between bursts of characters <p> You likely have mis-set interrupts> See the Serial-HOWTO section starting with "Slow:" @@ -5670,11 +5769,11 @@ flashlight batteries first so you will know what taste to expect. <p> Repairing a terminal has much in common with repairing a monitor and/or keyboard. Sometimes the built-in diagnostics of the terminal -will tell you what is wrong on the screen. If not, then by the -symptoms, one may often isolate the trouble to one of the following: -bad keyboard, CRT dead, terminal digital electronics failure. It's -best to have a service manual, but even if you don't have one, many -terminals may still be repaired. +will display on the screen. By the symptoms, one may often isolate +the trouble to one of the following: bad keyboard, CRT dead, power +electronics failure, or digital electronics failure. It's best to +have a service manual, but even if you don't have one, you can +often still repair it. <sect1> Repair Books & Websites <label id="repair_info"> <sect2> Books @@ -5752,40 +5851,43 @@ such names: Changing linearity may change the size so that it will need to be readjusted. A terminal that has been stored for some time may have a small display rectangle on the screen surrounded by a large black -border. If it's difficult to adjust, wait a while before adjusting it -since it will likely recover some with use (the black borders will -shrink). +Before adjusting it, leave the terminal on for a while since it will +likely recover some with use (the black borders will shrink). <sect1> Diagnose -<sect2> Terminal Made a Noise +<sect2> Terminal Made a Noise or Smoked <p> If the terminal made some noise just before it failed (or when you turn it on after it failed) that noise is a clue to what is wrong. If -you hear a sparking noise or see/smell smoke, immediately turn the -terminal off to prevent further damage. The problem is likely in the -high voltage power supply of several thousand volts. Remove the cover -and if the bad spot is not evident, turn it on again for a short time -in a dimly lit room to look for arcing. The high voltage -cable (runs between the flyback transformer and the side of the -picture tube) may have broken insulation that arcs to ground. Fix it -with high-voltage insulating dope, or special electrical tape designed -say for 10,000 volts. +you hear a noise or see/smell smoke, immediately turn the terminal off +to prevent further damage. A pop noise may be a capacitor exploding +or a fuse blowing. A buzzing noise is likely due to arcing. The +problem may be in the high voltage power supply of several thousand +volts. + +Remove the cover. Look for discoloration and bulging/cracked +capacitors. If the bad spot is not evident, turn it on again for a +short time and look for smoking/arcing. For arcing, a dimly lit room +will help find it. The high voltage cable (runs between the flyback +transformer and the side of the picture tube) may have broken +insulation that arcs to ground. Fix it with high-voltage insulating +dope, or special electrical tape designed say for 10,000 volts. The flyback transformer (high voltage) may make only a faint clicking or sparking noise if it fails. You may not hear it until you turn the -terminal off for a while to rest and then turn it back on again. To -track down the noise you may use a piece of small rubber tubing (such -as used in automobiles) as a stethoscope to listen to it. But while -you are listening for the noise, the terminal is suffering more damage -so try find it fast (but not so fast as to risk getting shocked). +terminal off for a while and then turn it back on again. To track +down the noise you may use a piece of small rubber tubing (such as +used in automobiles) as a stethoscope to listen to it. But while you +are listening for the noise, the terminal is suffering more damage so +try find it fast (but not so fast as to risk getting shocked). -A short in the power supply may cause a fuse to blow with a pop. -Replacing a blown fuse may not solve the problem as the same short may -blow the fuse again. Inspect for any darkened spots due to high heat -and test those components. Shorted power transistors may cause the -fuse to blow. They may be tested with a transistor checker or even -with an ohm-meter. Use the low ohm scale on an ohm-meter so that the -voltage applied by the meter is low. This will reduce the possible -damage to good components caused by this test voltage. +A shorted power supply may cause a fuse to blow. Replacing a blown +fuse may not solve the problem as the same short may blow the fuse +again. Inspect for any darkened spots due to high heat and test those +components. Shorted power transistors may cause the fuse to blow. +They may be tested with a transistor checker or even with an +ohm-meter. Use the low ohm scale on an ohm-meter so that the voltage +applied by the meter is low. This will reduce the possible damage to +good components caused by this test voltage. If the terminal has been exposed to dampness such as being stored in a damp place or near a kitchen with steam from cooking, a fix may be to @@ -5813,20 +5915,28 @@ in local, then the problem is likely in the connection to the host computer (or incorrect interface) or in the UART chips of the terminal. -By carefully inspecting the circuitry, one may often find the cause of -the problem. Look for discoloration, cracks, etc. An intermittent +<sect1> Detective work +<p>By carefully inspecting the circuitry, one may often find the cause +of the problem. Look for discoloration, cracks, etc. An intermittent problem may sometimes be found by tapping on components with a ball-point pen (not the metal tip of course). A break in the conductor of a printed circuit board may sometimes be revealed by flexing the board. Solder that looks like it formed a drop or a solder joint with little solder may need re-soldering. Soldering may heat up transistors (and other components) and damage them so use a -heat sink if feasible. +heat sink if feasible. One failure may cause others, so unless you +find the original cause, the failure may reoccur. -If you have a common brand of terminal, you may be able to search -newsgroup postings on the Internet to find out what the most frequent -types of problems are for your terminal and perhaps information on how -to fix them. +If you have a common brand of terminal, you may be able to search the +Internet (including newsgroup postings) to find out what the most +frequent types of problems are for your terminal and perhaps +information on how to fix it. If you find that a certain component +is bad you may search for this component (for example R214 wyse) and +hopefully find a report by someone else who had the same problem. +Such a report may indicate other components that failed at the same +time. If a component is damaged so badly that its value can't be +read, then you might find it on the Internet. The manufacturer may +have on-line data that search engines don't index. To see if the digital electronics work, try (using a good keyboard) typing at the bad terminal. Try to read this typing at a @@ -5867,6 +5977,11 @@ leaving the terminal on for a while will help partially restore them. If you can, exercise any terminals you have in storage by turning them on for a while every year or two. +Note that cheap electrolytic capacitors designed for use in audio +circuits may fail if used in high frequency horizontal circuitry. For +this, you need low resistance (low ESR) capacitors. Replace +non-polarized capacitors (NP) with the same (or with "bi-polar"). + <sect1> Keyboards <label id="keyboards_"> <sect2> Interchangeability <p> The keyboards for terminals are not the same as keyboards for @@ -6584,38 +6699,42 @@ phone line. <sect1> Block Mode <label id="block"> -<sect2> Intro to Block Mode -<p> 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 (see <ref id="ibm_" name="IBM Terminals "> -so many IBM terminals are block-mode only and also synchronous (see -Section <ref id="sync" name="Synchronization & Synchronous">). +<sect2> Introduction to Block Mode +<p> Block mode is seldom used with Linux and is mainly of historical +interest. 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, must react instantly to typing certain +keys so block mode isn't feasible. Such editors and other interactive +programs can't permit the long delay in sending a keystroke to the +computer which is inherent in block mode. So they can't use block +mode. + +The old IBM mainframe interface uses block mode (see <ref id="ibm_" +name="IBM Terminals "> so many IBM terminals are block-mode only and +also synchronous (see Section <ref id="sync" name="Synchronization & +Synchronous">). <sect2> Types of Block Modes, Forms <p> 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. Many later model terminals can emulate block mode. 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. +block modes include HP2622A, Wyse60, VT130, VT131, VT330, VT340, and +Visual500. Many later model terminals can emulate block mode. But +the Linux console can't. 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. <sect2> Efficiency -<p> 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 mainframes were). In character mode every character typed is sent +<p> Block mode takes load off the host computer, especially if the +host computer's hardware is designed for block modes (as IBM +mainframes were). 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 @@ -6636,6 +6755,27 @@ 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. +<sect2> Problems with block mode +<p>While block mode is more efficient, it is nearly extinct, and for +good reason. Faster and cheaper computers made the higher efficiency +less important. For example, a 56k modem results in hundreds of +interrupts per second (every 14 characters) while typing at a terminal +only causes a few interrupts per second (one for each character +typed). So the number of interrupts caused by typing at a terminal +is not very significant (unless you have hundred of terminals +connected to the same computer). + +Another point is that the efficiency is not of much significance where +the user doesn't type in very much. Editors are a primary example of +where the user types in a lot. But if you use block mode for +editing, you must then use the crude editor built into terminal. Modern +editors like vim and emacs are much better but can't use block mode. +Even in the days of mainframes with terminals, block mode wasn't used +much except by IBM. A major reason was that software to utilize it +was not widely available (except for IBM). The terminfo data base +doesn't seem to include it and this would complicate writing software +for it. + <sect1> EIA-232 (RS-232) Books <label id="RS232_books"> <p> (Note: The first book covers much more than just EIA-232.) <itemize> @@ -6760,6 +6900,15 @@ will also lead to some FAQ's for terminal numbers under 100 (such as WY60). For the specs on more recent terminals see See <url url="http://www.wyse.com/products/gpt/index.htm" name="Wyse terminals">. +Wyse terminals were lower in cost than other brands and they captured +a major share of the market. There were concerns about the quality +of these terminals, especially the Wyse 50. One reason for the large +number of reports of Wyse failures may be because there were so many +of them out there. + +<sect2> Wyse 50 +<p>Reported not to last very long. + <sect2> Wyse 60 <p> Display adjustments (must remove cover): Brightness VR202, Height VR302, Width VR101 (also affects height). If you want to use it in @@ -6771,8 +6920,10 @@ edit /etc/inputrc so that the arrow keys will work in Bash. See <ref id="bash_bug" name="Bugs in Bash"> <sect2> Wyse 85 -<p> Can emulate VT52/VT100/VT200. Press F3 for setup. Scroll thru -setup with up/down keys. +<p> Can emulate VT52/VT100/VT200. Press F3 for setup. After moving +left/right to go the a menu "icon", press space to select it. Scroll +thru setup menus with up/down keys. Press F3 at any time to reenter +setup (without loosing any settings). <sect2> Wyse 99-GT <p> Here is the setup Menus of the Wyse99GT (late 1980's). Note that