Digital VT320 Terminal State Reports

Paul Flo Williams, 12 November 2000

Quick introduction

Appendix E of Installing and Using the VT320 Video Terminal mentions Terminal State Reports, which allow the host to ask the VT320 for its current state. The host sends DECRQTSR (Request Terminal State Report) and the VT320 responds with DECTSR (Terminal State Report). At some later stage, the host can send this state report back to the VT320 to restore it to a known state, in the sequence DECRSTS (Restore Terminal State).

I’ve just found some old notes about the contents of this report, reproduced below. I’ll deal with the actual encoding of the report at some later time, but for now the table below shows the 56-byte content of the report, one byte of which is a checksum. I doubt that any host would want to interpret the report, because I would’ve thought that its precise contents could differ from one firmware revision to the next.

There are a number of blank bits in this table. The meaning of these is unknown; I wasn’t able to influence the setting of these bits by changing terminal modes or settings. I haven’t recorded the default state of these bits.

There are also a number of greyed-out bits, marked as ‘\\\’. I tried to set these bits in the DECRSTS sequence, but they always read back as zero. There are two possible explanations for this; either they don’t do anything, or they have some internal function that is masked out of the report. The latter case is plausible if we assume that bits that are reported together, live together in the VT320’s memory.

Random thoughts

• User-defined (soft) sets are represented in this report as the code 0x40, whatever the name of the set. The name of the set doesn’t appear in this report, but the terminal has to store the name of the set. I know this because it is quite possible to give a downloaded character set the same name as an internal font. When this happens, an SCS (Set Character Set) sequence will select the soft set. In my experience, the soft set will start to deteriorate after hours of operation, which probably means that there is a bug in the VT320. I’ve only noticed this fault when I’ve given the font the same name as an internal one, but then that’s the only time that I’d be looking at a soft font for hours.

• Bytes 7 & 8 can be derived from the data in bytes 1 to 6. I don’t know what happens if you force them to be inconsistent.

• Bytes 10 to 21 are the data saved by DECSC (Save Cursor). I can’t find the information about bytes 12 & 13 in my notes. I know that the state of DECOM (Origin Mode) is saved and restored by DECSC/DECRC, so perhaps that is in one of these two bytes. I’d have to go back and check. The contents of byte 12 might match those of byte 50.

• Bytes 22 to 38, the tab columns, just have each bit set to ‘1’ if there is a tab in that column.

• Bit 0 of byte 47 is the only way of setting CRM from the host, which the manual tells you is impossible. You can’t reset this feature from the host of course, because the VT320 will just display the DECRSTS sequence instead of interpreting it.

• Byte 50 contains the current character attributes, including two which are not normally settable from the host. Bit 1 turns characters invisible. I’d guess that this is set in screen saver mode, preventing the display of all characters apart from a flashing rectangle in the bottom right-hand corner of the display. That would certainly save memory over the alternative approach of saving the screen to somewhere else and clearing display memory during screen saver mode.

  Bit 3 switches between the glyph tables, producing some strange effects.

• Changing bytes 54 and 55 in order to place the cursor offscreen can produce some strange and not very useful effects.