home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / terminal / 1114 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  2.3 KB
  1. Path: sparky!uunet!stanford.edu!rutgers!igor.rutgers.edu!zodiac.rutgers.edu!leichter
  2. From: leichter@zodiac.rutgers.edu
  3. Newsgroups: comp.terminals
  4. Subject: Re: VT320 DECTSR Terminal State Report Meanings
  5. Message-ID: <1992Sep9.100642.1@zodiac.rutgers.edu>
  6. Date: 9 Sep 92 14:06:42 GMT
  7. References: <1992Sep4.214917.25679@jupiter.sun.csd.unb.ca>
  8. Sender: news@igor.rutgers.edu
  9. Organization: Rutgers University Department of Computer Science
  10. Lines: 37
  11. Nntp-Posting-Host: cancer.rutgers.edu
  12.  
  13. In article <1992Sep4.214917.25679@jupiter.sun.csd.unb.ca>, dedgar@mta.ca writes:
  14. | Hello Net
  15. | 
  16. | I am looking for the meaning of the bytes returned by the DECTSR function
  17. | on a VT320.  Does any body know these?  The VT320 reference manual does
  18. | not list them specifically.
  19.  
  20. The format of DECTSR is explicitly, and deliberately, undocumented.  It can
  21. vary between different firmware versions of the same terminal model, and will
  22. certainly differ between terminal models.  (Theoretically, it could even vary
  23. between different instances of the SAME terminal model running the SAME firm-
  24. ware version, though given the nature of the technology, this is of course
  25. pretty unlikely!)
  26.  
  27. The ONLY supported use of the DECTSR sequence is to send it back to the
  28. terminal that sent it to you, thus restoring the terminal's state to where it
  29. was.  There is a whole group of additional state queries with documented
  30. syntax that you can use if you need to do anything else.
  31.  
  32. While I originally specified this architecture, and was involved with the
  33. details of the VT330 specification (but not the coding), I have absolutely no
  34. idea what the contents of a DECTSR string are.  We left that entirely up to
  35. the firmware implementors.  My guess is that it's effectively a memory dump
  36. of one or more internal data areas.  (We suggested that a checksum also be
  37. included, partly to protect from damaged DECTSR strings, partly to prevent
  38. accidentaly use of a DECTSR string from a different firmware version - and
  39. partly to help dissuade people from mucking with the DECTSR string.)
  40.  
  41. | All help gratefully appreciated.  Please reply to me directly rather than
  42. | use up net bandwidth on this rather obscure topic.
  43.  
  44. Since you don't even offer to post a summary, I take this to mean that you
  45. don't want to be bothered to follow this group for responses.  Well, tough.
  46.  
  47.                             -- Jerry
  48.                         (One-time member of
  49.                          DEC's terminal group)
  50.