AT&T MTG-630 Terminals, Ethernet, Flow Control

[Doug Gwyn]

In article <622 at lehi3b15.csee.Lehigh.EDU> flash at 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.