Tack has a number of tools that are designed to help gather
information about the terminal. Although these functions are not
dependent on terminal type, you may wish to execute tack
with options -it. This will turn off initialization
and default the standard entries.
These tools may be reached from the main menu by selecting
the 'tools' entry.
Echo tool: All data typed from the keyboard will be echoed back
to the terminal. Control characters are not translated to the up arrow format
but are sent as control characters. This allows you to test an escape
sequence and see what it actually does. You may also elect to
enable hex output on echo tool this will echo the characters in
hexadecimal. Once the test is running you may enter the 'lines'
or 'columns' keywords which will display a pattern that will help
you determine your screen size. A complete list of keywords will
be displayed when the test starts. Type 'help' to redisplay
the list of available commands.
Reply tool: This tool acts much like the echo tool, but
control characters that are sent from the terminal more than one character
after a carriage return will be expanded to the up arrow format. For example
on a standard ANSI terminal you may type:
CR ESC [ c
and the response will be echoed as something like:
^[ [ ? 6 c
ANSI sgr display: This test assumes you have an ANSI terminal. It
goes through attribute numbers 0 to 79, displaying each in turn and using that
SGR number to write the text. This shows you which of the SGR
modes are actually implemented by the terminal. Note: some terminals (such as
Tektronix color) use the private use characters to augment the functionality of
the SGR command. These private use characters may be interjected into the
escape sequence by typing the character ( <, =, >, ? ) after the original
display has been shown.
ANSI status reports: This test queries the terminal in standard
ANSI/VT-100 fashion. The results of this test may help
determine what options are supported by your terminal.
ANSI character sets: This test displays the character sets
available on a ANSI/VT-100 style terminal.
Character sets on a real VT-100 terminal are usually defined
with smacs=\\E(0 and rmacs=\\E(B. The first character after the
escape defines the font bank. The second character defines the
character set. This test allows you to view any of the possible
combinations. Private use character sets are defined by the digits.
Standard character sets are located in the alphabetic range.
Some terminals require significant amounts of time (that is, more than one
transmitted-character interval) to do screen updates that change large
portions of the screen, such as screen clears, line insertions,
line deletions, and scrolls (including scrolls triggered by line feeds
or a write to the lowest, right-hand-most cell of the screen).
If the computer continues to send characters to the terminal while one
of these time-consuming operations is going on, the screen may be garbled.
Since the length of a character transmission time varies inversely with
transmission speed in cps, entries which function at lower speeds may
break at higher speeds.
Similar problems result if the host machine is simply sending characters at a
sustained rate faster than the terminal can buffer and process them. In either
case, when the terminal cannot process them and can't tell the host to stop
soon enough, it will just drop them. The dropped characters could be text,
escape sequences or the escape character itself, causing some really
strange-looking displays. This kind of glitch is called an overrun.
In terminfo entries, you can attach a pad time to each string capability
that is a number of milliseconds to delay after sending it. This will give
the terminal time to catch up and avoid overruns.
If you are running a software terminal emulator, or you are on an X pseudo-tty,
or your terminal is on an RS-232C line which correctly handles RTS/CTS
hardware flow control, then pads are not strictly necessary. However, some
display packages (such as ncurses(3X)) use the pad counts to calculate
the fastest way to implement certain functions.
For example: scrolling the screen may be faster than deleting the top line.
One common way to avoid overruns is with XON/XOFF handshaking.
But even this handshake may have problems at high baud rates.
This is a result of the way XON/XOFF works. The terminal tells
the host to stop with an XOFF. When the host gets this character, it stops
sending. However, there is a small amount of time between the stop request and
the actual stop. During this window, the terminal must continue to accept
characters even though it has told the host to stop. If the terminal sends
the stop request too late, then its internal buffer will overflow. If it sends
the stop character too early, then the terminal is not getting the most
efficient use out of its internal buffers. In a real application at high baud
rates, a terminal could get a dozen or more characters before the host gets
around to suspending transmission. Connecting the terminal over a network
will make the problem much worse.
(RTS/CTS handshaking does not have this problem because the UARTs are
signal-connected and the "stop flow" is done at the lowest level, without
software intervention).
In order to get accurate timings from your terminal tack
needs to know when the terminal has finished processing all the
characters that were sent. This requires a different type of handshaking
than the XON/XOFF that is supported by most terminals. Tack
needs to send a request to the terminal and wait for its reply.
Many terminals will respond with an ACK when they receive an ENQ.
This is the preferred method since the sequence is short.
ANSI/VT-100 style terminals can mimic this handshake with the
escape sequence that requests 'primary device attributes'.
ESC [ c
The terminal will respond with a sequence like:
ESC [ ? 1 ; 0 c
Tack assumes that (u9) is the enquire sequence and that (u8) is the
acknowledge string. A VT-100 style terminal could set u9=\\E[c
and u8=\\E[?1;0c.
Acknowledge strings fall into two categories.
1) Strings with a unique terminating character and,
2) strings of fixed length.
The acknowledge string for the VT-100 is of the first type since
it always ends with the letter 'c'. Some Tektronics terminals
have fixed length acknowledge strings. Tack supports both
types of strings by scanning for the terminating character until
the length of the expected acknowledge string has arrived.
(u8) should be set to some typical acknowledge that will be
returned when (u9) is sent.
Tack will test this sequence before running any of the pad
tests or the function key tests. Tack will ask you the following:
Hit lower case g to start testing...
After it sends this message it will send the enquire string.
It will then read characters from the terminal until it sees the
letter g.
The pad timings in distributed terminfo entries are often incorrect. One
major motivation for this program is to make it relatively easy to tune these
timings.
You can verify and edit the pad timings for a terminal with
the `test string capabilities'
function (this is also part of the `normal test sequence' function).
The key to determining pad times is to find out the effective baud rate of
the terminal. The effective baud rate determines the number of characters
per second that the terminal can accept without either handshaking or
losing data. This rate is frequently less than the nominal cps rate on the
RS-232 line.
Tack uses the effective baud rate to judge the duration of the test and
how much a particular escape sequence will perturb the terminal.
Each pad test has two associated variables that can be tweaked to help verify
the correctness of the pad timings. One is the pad test length. The other is
the pad multiplier, which is used if the pad prefix includes `*'. In curses
use, it is often the first parameter of the capability (if there is one).
For a capability like (dch) or (il) this will be the number of character
positions or lines affected, respectively.
Tack will run the pad tests and display the results to the terminal.
On capabilities that have multipliers tack will not tell you
if the pad needs the multiplier or not. You must make this decision
yourself by rerunning the test with a different multiplier.
If the padding changes in proportion to the multiplier than the
multiplier is required. If the multiplier has little or no effect on
the suggested padding then the multiplier is not needed.
Some capabilities will take several runs to get a good feel for
the correct values. You may wish to make the test longer
to get more accurate results. System load will also effect the
results (a heavily loaded system will not stress the
terminal as much, possibly leading to pad timings that are too short).