Thread View: comp.terminals
2 messages
2 total messages
Started by dedgar
Fri, 04 Sep 1992 21:49
VT320 DECTSR Terminal State Report Meanings
Author: dedgar
Date: Fri, 04 Sep 1992 21:49
Date: Fri, 04 Sep 1992 21:49
12 lines
781 bytes
781 bytes
Hello Net I am looking for the meaning of the bytes returned by the DECTSR function on a VT320. Does any body know these? The VT320 reference manual does not list them specifically. All help gratefully appreciated. Please reply to me directly rather than use up net bandwidth on this rather obscure topic. Dale Edgar Cybernetic Control Inc. DEDGAR@MTA.CA
Re: VT320 DECTSR Terminal State Report Meanings
Author: leichter
Date: Wed, 09 Sep 1992 14:06
Date: Wed, 09 Sep 1992 14:06
37 lines
2447 bytes
2447 bytes
In article <1992Sep4.214917.25679@jupiter.sun.csd.unb.ca>, dedgar@mta.ca writes: | Hello Net | | I am looking for the meaning of the bytes returned by the DECTSR function | on a VT320. Does any body know these? The VT320 reference manual does | not list them specifically. The format of DECTSR is explicitly, and deliberately, undocumented. It can vary between different firmware versions of the same terminal model, and will certainly differ between terminal models. (Theoretically, it could even vary between different instances of the SAME terminal model running the SAME firm- ware version, though given the nature of the technology, this is of course pretty unlikely!) The ONLY supported use of the DECTSR sequence is to send it back to the terminal that sent it to you, thus restoring the terminal's state to where it was. There is a whole group of additional state queries with documented syntax that you can use if you need to do anything else. While I originally specified this architecture, and was involved with the details of the VT330 specification (but not the coding), I have absolutely no idea what the contents of a DECTSR string are. We left that entirely up to the firmware implementors. My guess is that it's effectively a memory dump of one or more internal data areas. (We suggested that a checksum also be included, partly to protect from damaged DECTSR strings, partly to prevent accidentaly use of a DECTSR string from a different firmware version - and partly to help dissuade people from mucking with the DECTSR string.) | All help gratefully appreciated. Please reply to me directly rather than | use up net bandwidth on this rather obscure topic. Since you don't even offer to post a summary, I take this to mean that you don't want to be bothered to follow this group for responses. Well, tough. -- Jerry (One-time member of DEC's terminal group)
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads