Aucbvax.1516 fa.info-terms utzoo!duke!decvax!ucbvax!CSVAX.mark@Berkeley Wed Jun 3 21:06:26 1981 tvi 950 comment, forwarded Since I don't have a printer on this one, I can't offer any useful suggestions on this, but perhaps someone else can? Anyway, it should serve as a warning to anyone who wants to buy a 950 with a printer on the side. Mark >From ihuxi!ihuxg!grg Wed Jun 3 16:04:45 1981 To: ihuxi!ucbvax!mark ihuxg!grg To: mark Subject: tvi pitfalls Cc: file Status: R I have had a weird problem wiht the Tvi terminal, with many long and generally unfulfilling conversations with their engineers, about a terminal printer handshake application. I enclose a description for your information, and to see if others have any related experience/thoughts. Well, it goes like this.... The tvi has a buffered output port, and should recognize two data flow protocols over the channel, 1) DTR handshake 2) X-on/off My problem is that 1) works intermittently, and then latches the terminal (engneers allude to a possible level problem, or race condition, or sunspot activity..), while 2) doesn't work at all. I can see (on a RS-232C breakout box) the printer say X-off, but Nooooo.., the terminal keeps sending. I proposed that perhaps the terminal wasn't listening because the printer didn't raise RTS or some such, but tvi claims that DTR is sufficient. Anyway, so far the most I can get them to acknowledge is that what I am trying should work. An interesting related problem is an effect of their secondary-X-on/off protocol which they use for the terminal/printer. Basically, the above description is simplified. When the printer sends X-off to the terminal, the terminal sends Secondary-X-off to the host (DC4), and then if the host keeps sending uses the terminal screen buffer (as an overflow to the terminals output port buffer) until it fills, and then sends a [primary] X-off (DC3) to the host. They explain that this allows the host by use of two levels of X-on/off protocol to maintain seperate data flows to the terminal and printer, by sending transparent print data to the printer through the terminal, alternating with normal terminal input/output modes. The turn on protocol would then be X-on (DC1). They ar not sure yet if the aborted Secondary sequence would cause a trailing Sec-X-on (DC2), although their engineer agrees that it shouldn't. Wel, anyway, the problem with this otherwise cute scheme is that the secondary codes which may be ignored by the host, will most likely also be echoed to the terminal, and cause some effect. The Sec-X-Off is OK, but the Sec-X-on would cause trouble. They are still reading ROM code in the terminal to figure out exactly what it does. Note that this is a seperate problem from my "no-throttle" situation. Summary. The tvi has some nice modes. I cannot get a seemingly simple one to work. Other usage problems may also exist. Other experience, pitfalls, successes?? Greg ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.