This README is all about extended character sets and 7/8 bit data paths
for normal or control characters on input and output.

It is NOT (yet) about extended character attributes.

The basic principle of this emulator is never to touch directly the
settings of the terminal. It is, however, quite acceptable to include
any relevant settings in the termcap file (specifically in the initialisation
sequence setting). This has the advantage that if the settings get changed
somehow they can be restored with the "master reset" (normally ^g).

By default the emulator assumes a 7-bit data path and 7-bit control
characters: this assumption is normally consistent with the settings of
the escape sequences specified in the termcap file and the map3270 file.
However, eight-bit data and controls can be handled.

The arrival of any 8-bit control character will be noticed and causes
the emulator to start to use 8-bit controls for output. Thus, for instance,
the 8-bit CSI control character (hex 9B) will be used instead of the 7-bit
ESC plus '['. This can economise on output and may slightly speed up a
terminal on a slow RS232 line. However, for the purposes of checking for
special input sequences as described in the map3270 file an input CSI is
always converted to be the ESC character followed by '['.
(Subsequently I have discovered that one can set up some terminals to
send 8-bit controls but only accept 7-bit controls!)

I assume that many terminals can enter 8-bit characters using the
Compose key. My understanding is that this key only allows itself to
input characters when there is an 8-bit data path (except if the terminal
is using a specific national character set: see remarks below).

The arrival of an 8-bit "printable" character, i.e. a character whose
value is at least 0x80 but is not an 8-bit control character, will be
taken as a signal that there is a full 8-bit data path for "extended ASCII"
characters. This will mean that such characters (either the echoing of the
character just entered or the output of an extended EBCDIC character sent
by the IBM) will become a full 8-bit byte according to the ISO 8859-1
extended ASCII character set.

While the emulator does not know about 8-bit controls or data it will
assume only a 7-bit data path. In order to get in extended ASCII characters
there is the possibility of switching to a mode whereby every 7-bit
input character (except control characters) can be forced into the
extended ASCII region by setting the most significant bit (hex 80).
This mode is set upon entry of the "extend" special sequence as defined
in the map3270 file, and is reset by the "normal" special sequence as
defined in that same file. By default I normally use ^x for "extend"
and ^n for normal.

The use of the "extend" will be flagged by a double bell and by an
indicator in the status line. It is, however, possible to get into this
mode by accident, and also to get into this mode on a terminal which
cannot display these extended ASCII characters. I therefore automatically
cancel this extended mode each time that the user sends the screen to the
IBM (since one cannot do very much in extended mode): this is the same
as cancelling "insert mode" regularly. I also allow a new 'x' option in
the on-line help menu, which will show the character input plus, if
extended, the hexadecimal value. This on-line help will also allow a
mode switch (extend/normal) but this change will only be temporary whilst
in the help dialogue.

Output of extended characters is normally done by a single shift mapping
of G2 into GL. On a VT220-style terminal this maps G2 into GL for the
next character. This, of course, assumes that G2 is the correct character
set (ISO Latin-1 if on a VT300, otherwise DEC supplemental Graphic set).
I recommend, therefore, to include in the termcap the setting of G2 as
this character set. You should also set G0, although if the default setting
is not the ASCII set things will be screwed anyway (I have seen a case where
a different program reset G0 to DEC Special Graphic and G1 to ASCII, and
then normally kept G1 mapped to GL!).

For the case of terminal emulators, including xterm, the single shift
mapping has no effect (nor any ill effect!). However, things work there
because even after sending this single shift I nonetheless try to send
the complete 8 bit character, which xterm seems to accept.

For the poor old VT100 we are in trouble, since it has no possibility
for the G2 or G3 character sets. With luck (and until the program is
made to contain something specific for them) we just rely on the VT100
ignoring these single shift mappings.

For the moment the emulator cannot handle the use of non-default National
Character Replacement Sets (NRCS). This may come in the future some time,
when I work out how to deal with it. I do know about the VT-style
sequences for setting up a particular national character set as any of
G0, G1, G2 or G3, plus how to set national or multinational character
set mode, plus how to know whether a terminal supports NRCS, plus how
to check which NRCS (keyboard language) is currently in use. I guess that
I may need to add something into the screen sizer (sizer.c) module, since
this is the one module which currently sends specific escape sequences
to the terminal and interprets the answers.

Some readers will tell me that the above is not optimal (it can look bad
on a VT100, which has neither GR nor the DEC Supplemental Graphic set).
Ideally I should have some termcap sequence to turn on and off the switch
to the DEC Supplemental Graphic set: if the sequence to turn it on is
empty then it would imply no such possibility. For future thought.
