Drawing lines in the sand.
Async Professional provides an implementation of the standard VT100 terminal. This component emulates a VT100 even down to displaying the line draw character set available on that terminal.
However, feedback has shown us that there are a couple of points that we didn’t make as clear as we should have in the documentation. This article will attempt to clarify how the APRO terminal emulates the various VT100 charsets and displays the line draw characters. It will also explain what to look for when line draw characters are missing or are displayed as normal alphabetic characters.
Before we begin, we shall assume that we are talking about a TAdTerminal component attached to a TAdVT100Emulator component. The emulator is the component that does most of the work, parsing the data coming from the host, processing the various commands embedded in the data stream, and displaying the results on the terminal’s client window. Essentially, the terminal component is merely the window upon which the emulator displays the host’s data. From now on in this article we shall refer to this pair of components as the terminal control, and to the ‘real’ thing as the VT100 terminal.
An obvious point to make, perhaps, is that it is the host that determines what is shown on the VT100 terminal. It is the host that sends the commands that cause the VT100 terminal to start displaying the line draw characters, and then subsequently to stop. APRO’s terminal control mimics the VT100 terminal so well that the host is not aware that anything is different.
The VT100 terminal has five built in character sets, known as charsets. These charsets define the glyph that will be displayed for a given ASCII character. So for example the ASCII character #106 is displayed as ‘j’ using the US ASCII charset, whereas using the line draw charset it will be rendered as the lower left corner of a box. The charsets on a VT100 only have 95 glyphs. The ASCII characters less than a space (#32) are not rendered at all (instead they are interpreted as commands); the ASCII #127 character is parsed as a ‘delete’ command; and the VT100 does not accept characters whose top bit is set (the 128 upper ASCII characters), it merely ignores them.
The five charsets have different names or ids:
-id A: UK ASCII charset
-id B: US ASCII charset
-id 0: Line draw charset
-id 1: Alternate ROM charset 1 – same as US ASCII
-id 2: Alternate ROM charset 2 – same as line draw
Charsets A and B are identical except that ASCII #35 is rendered as a ‘£’ in charset A and as a ‘#’ in charset B. Charset 0 contains the line draw characters. Charsets 1 and 2 could vary from country to country and APRO’s terminal control merely assumes that they’re the same as charsets B and 0.
Although the VT100 terminal has five physical charsets from which it can display glyphs, it can’t use them all at the same time. Instead it has two logical charsets, known as G0 and G1, and has several commands that map a physical charset onto a logical charset. Hence, you could map charset B onto G0 and charset 0 onto G1 and then switch between the two logical charsets to draw the display.
The terminal escape sequence “Esc ( id” maps the charset given by id onto G0, whereas “Esc ) id” maps the charset given by id onto G1.
Once the host has told the VT100 terminal to perform the required charset mapping, it then sends SI or SO characters (hex 0E and 0F) in the data stream to tell the terminal to switch from one logical charset to the other. If an SO command (‘shift out’) is encountered the terminal switches to the G1 logical charset, and if an SI command (‘shift in’) is encountered, the terminal switches back to the G0 character set. All ASCII characters received after the SO are rendered using the G1 charset, until the next SI is received, after which the terminal renders characters using the G0 charset.
At start up or upon receipt of a “terminal reset” command, the terminal control maps both G0 and G1 to physical charset B (US ASCII) and ensures that G0 is selected as the default charset.
So, how does the terminal control ‘know’ which glyphs to display? For this is uses the TAdCharSetMapping class, an instance of which is stored in the VT100 emulator component. By default the charset mapping object gets the information about which glyph to display for a character/charset pair from a resource file (the ADCHSVT1.R32 file) or it can be reset and loaded from a text file (the ADCHSVT1.TXT file being an example). If the mapping object cannot find the character/charset pair in its internal table, the character is displayed using the terminal control’s font without being mapped.
Another point to realize is that the VT100 terminal only processes characters with their high bit clear. The upper ASCII characters are ignored and the terminal control replicates this behavior. Now, a lot of BBS sites assume that if they send an upper ASCII character, the terminal will display it as if it was a character from the PC OEM character set. The terminal control can be set to do this as well, by setting the DisplayUpperASCII property of the TAdVT100Emulator component (notice: the emulator not the terminal) to true.
So, let’s suppose that the terminal control in your application is not displaying line draw characters properly. In other words, you have a terminal emulation program that displays the host’s screen with line draw characters, but the terminal control either doesn’t display anything or is displaying normal alphabetic characters. What could be the problem?
The first thing to check is that you have properly attached a VT100 emulator component to the terminal component. If not, the terminal component would be using its internal TTY component and this has no built in charset support.
The next thing to find out is how the host is sending the line draw characters to display on the terminal. There are two possibilities: the VT100 standard or the ANSI standard. Let’s take these in reverse order, simpler case first. The ANSI standard is the BBS method we just saw: the host is sending characters with the eighth bit set and the terminal is supposed to display the glyph from Windows’ OEM character set. This is easy to check; just set the emulator’s DisplayUpperASCII property to true and try again. Another way is to run the application with dispatch logging and check the log for these full 8-bit characters.
For the VT100 standard, run the application with dispatch logging enabled, and then check the log for entries from the emulator. The emulator will write a user entry to the log for every command or terminal control sequence it encounters in the data stream from the host. Look for entries with a [0E] command (this is SO) or a [0F] command (this is SI)—these are the commands the host sends to switch from the G0 to the G1 charset, or vice versa. You should also be able to see an “Esc ( 0” or an “Esc ) 0” command to map the line draw charset to either the G0 or G1 logical charset.
If you have passed these two checks then the problem lies elsewhere, with the main culprit being the charset mapping object owned by the VT100 emulator object. Either the mapping object was unable to read the resource containing the mapping table from the application at start-up or it has been cleared in some way. The charset mapping object has been written to be error neutral, in other words, errors are merely ignored and no exception is raised. This fits in with the philosophy behind the terminal component: just as a real VT100 terminal couldn’t crash or stop working with an error, so does the APRO terminal. Add some test code in the application to cause the mapping object to dump its mapping table to a file:
and then check the file to see if it contains some data.
The final problem might be a missing font. For a particular character/charset pair, the charset mapping object will return the character and font required to display that pair. If the font does not exist, Windows will use a similar font instead. That font may not have the required line draw glyphs. By default, the charset mapping supplied with APRO makes use of the Terminal font for the line draw characters.
This site is not affiliated, endorsed, or otherwise associated with the
entity formerly known as
TurboPower Software. The owners and maintainers of Aprozilla.com were merely
meager employees of the aforementioned organization, providing this site out of
the pure goodness of their collective hearts.