Path: utzoo!attcan!uunet!ginosko!aplcen!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.sys.att Subject: Re: AT&T MTG-630 Terminals, Ethernet, Flow Control Message-ID: <11138@smoke.BRL.MIL> Date: 24 Sep 89 03:14:31 GMT References: <622@lehi3b15.csee.Lehigh.EDU> Reply-To: gwyn@brl.arpa (Doug Gwyn) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 56 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.