info-mac@uw-beaver (info-mac) (11/10/84)
From: John Clark <clark@rand-unix>
Thanks for the help re MacTerm's answerback msg. Since I posted my
original note, I've observed several different MacTerminal 1.1 responses to
the terminal id query (ESC [ c). I haven't any idea why the responses
vary, but here's what I've seen so far when I've sent the query from a
Unix login script (9600 bps, 7 bits, no parity, no flow control, printer
port [modem port occupied by hard disk]):
ESC [ E ; V
ESC [ ? 1 ; 2 c
ESC [ E { V
(nil)
The first response is what I see most of the time, but the others also
occur. As you pointed out, the second of these happens to be the standard
VT100 terminal id, and is invariably the response I get if I send out the
query AFTER I've successfully logged on to the Unix system (when I've
switched to 8 bits/char).
Is there a logical explanation for any of this weird behavior?
--John Clarkinfo-mac@uw-beaver.UUCP (11/11/84)
From: Jerry Callen <SYSTEMS.JLC@UChicago> You can get MacTerminal to send the answerback message by sending it a cntl-E (x'05'). What you are requesting with ESC [ c is the "terminal id", that is, terminal type. By the way, when I send our MacTerminal (which is also 1.1) that sequence, I get back "ESC [ ? 1 ; 2 c", which is the standard VT100 terminal id. Are you sure....... -- Jerry Callen -------
info-mac@uw-beaver.UUCP (11/11/84)
From: Charles Carvalho <CHARLES@ACC> The problem is that Unix is expecting 8 data bits (or seven plus parity) between the start and stop bits; the Macintosh is sending 7 data bits but no parity bit between the start and stop bits. Assuming no idle time between characters, the resulting shift causes "<esc>[?1;2c" to be seen as "<esc>[E;V" (possibly followed by "t"). The solution is to tel MacTerminal to send either 8 bits, no parity, or 7 bits, space parity. /Charles ------