flash@lehi3b15.csee.Lehigh.EDU (Stephen Corbesero) (09/23/89)
I have 12 of the AT&T Multi-Tasking Graphic terminals (MTG-630) hooked up serially to ethernet terminal servers (Bridge/3Com CS/210) and I have two distinct problems. 1) I have already discovered and verified with AT&T that the layers environment will not run across an ethernet link. They have no plans to fix this problem. 2) The terminals do need some sort of flow control. XON/XOFF to the terminal server works fine, but giving up ^S and ^Q is just not feasible. The terminal manual lists RS-232 pins 4 & 5 (RTS & CTS), and the terminal server documents it as a supported method, but apparently the terminals do not use them. With respect to the first problem, I will be trying to get the "stand-alone" graphics routines to run in a single-tasking mode. If someone has already worked around this problem, perhaps by rewriting the the sxt drivers, I'd appreciate any information. With respect to the second problem, I have found a set of LF and CR delays values that seem togive the terminal enough to time in both line-oriented mode and screen-oriented modes. I regard this as a kludge, and I would prefer a better solution. I am really stunned that such a powerful terminal (with 2 MB of memory!) requires flow control, and that there is apparently no hardware flow control. Any information or experience in this area would also be greatly appreciated.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/24/89)
In article <622@lehi3b15.csee.Lehigh.EDU> flash@lehi3b15.csee.Lehigh.EDU (Stephen Corbesero) writes: >I have 12 of the AT&T Multi-Tasking Graphic terminals (MTG-630) hooked >up serially to ethernet terminal servers (Bridge/3Com CS/210) and I >have two distinct problems. >1) I have already discovered and verified with AT&T that the layers > environment will not run across an ethernet link. They have no > plans to fix this problem. This sounds wrong. I don't have direct experience with "terminal servers" like the ones you mention. However, if they provide RS-232 connections to the terminal then you certainly should be able to run "layers" (xt packet protocol) over them. You may have to enable "hex encoding" both in the terminal (turn on via SetUp menu) and on the host (automatic, or else you have to flag it by setting e.g. HEXLOAD in the environment; it depends on your host's specific implementation of the "layers" program and the "dmdld" relocating downloader). The reason for the encoding is that some so-called terminal servers do not transmit all 8-bit (or even 7-bit) patterns transparently, so encoding must be used to ensure that all bytes sent and received lie within the range of values that are not molested by the server. >2) The terminals do need some sort of flow control. XON/XOFF to the > terminal server works fine, but giving up ^S and ^Q is just not > feasible. The terminal manual lists RS-232 pins 4 & 5 (RTS & CTS), > and the terminal server documents it as a supported method, but > apparently the terminals do not use them. The handshaking signals must be supplied for the terminal to operate properly, but they should not be used for per-character handshaking. DC3/DC1 (XOFF/XON) is supported, or in protocol (layers) mode the packet protocol itself ensures proper flow control. >With respect to the first problem, I will be trying to get the >"stand-alone" graphics routines to run in a single-tasking mode. If >someone has already worked around this problem, perhaps by >rewriting the the sxt drivers, I'd appreciate any information. A "takeover download" (standalone replacement of the default terminal emulator) works just fine. I assume you know that "dmdld" must be used to download terminal-resident applications? However, you're much better off using "layers" mode. >I am really stunned that such a powerful terminal (with 2 MB of memory!) >requires flow control, and that there is apparently no hardware flow >control. The amount of memory is irrelevant (the basic 630 has 640Kb). Any sufficiently powerful terminal will potentially require flow control, as it may take longer to perform "powerful" operations than it takes to receive the instructions to do so. In any event, the 630 is intended to support "layers" operation, not as a fancy dumb terminal. (It is a pretty nice dumb terminal, because of the mouse editing, scrolling, etc. but as you have observed it is more powerful than that use requires.) See if you can get it working in layers mode.
muller@sdcc7.ucsd.EDU (Keith Muller) (09/25/89)
In article <622@lehi3b15.csee.Lehigh.EDU>, flash@lehi3b15.csee.Lehigh.EDU (Stephen Corbesero) writes: > > I have 12 of the AT&T Multi-Tasking Graphic terminals (MTG-630) hooked > up serially to ethernet terminal servers (Bridge/3Com CS/210) and I > have two distinct problems. > > 1) I have already discovered and verified with AT&T that the layers > environment will not run across an ethernet link. They have no > plans to fix this problem. I have used 630's over the ethernet to run layers etc on a remote host. rlogin -8 (for eight bit mode) from BSD hosts (such as suns) that supports it works fine (and without lan encoding enabled in the 630). Keith Muller University of California muller@ucsd.edu
david@ms.uky.edu (David Herron -- One of the vertebrae) (10/12/89)
I have a new job ... see .signature below
I heard recently, at this job, that the 630's were to be getting
ethernet and/or starlan capabilities "soon" and would also be
able to run X in the terminal. Much like an X display. It's not
too farfetched considering what's in the terminal vs. what's in
something like an NCD terminal.
--
<- David Herron; an MMDF guy <david@ms.uky.edu>
<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- New official address: attmail!sparsdev!dsh@attunix.att.com