Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!carssdf!usenet
From: usenet@carssdf.UUCP (UseNet Id.)
Newsgroups: comp.unix.xenix
Subject: Computone
Keywords: Computone,Intelliport,ATvantage,Wyse60
Message-ID: <190@carssdf.UUCP>
Date: 6 Sep 89 01:40:44 GMT
Distribution: usa
Organization: C.A.R.S.,Middlesex,NJ
Lines: 47

I am looking for someone who knows as much about Computone as I do
so we can figure out what is realy happening here with the changes
between ATX, ic_control, cc_control as they apply to BUSY/READY &
XON/XOFF.   For instance:
  When in raw mode for keyboard input, the AT$ & C16(Cluster) devices
pass a recvd XOFF to the application for handling, instead of halting
output to wait for an XON.  This is not unreasonable when you think
about it, but it is not what the ATX boards used to do.  If you are
using raw mode to decipher cursor movement controls, F-keys etc, while
you have streamed out screens full of data to the tube, it leaves you
wondering what to do with the xon/xoff chars in your receive buffer.
The old ATX boards used to handle it, and I never noticed a problem.

Note: Intelliport & ATvantage roms prior to 3.41 had problems,
especially with XON/XOFF, ask your dealer for an upgrade.

An obvious solution is to use BUSY-READY.  First, the Wyse 60 is much
more sensitive about how much more data you send it after it signals
full with DTR than if you watched for an XOFF.  How many characters
I don't know.  It is usually not noticable at 9600, but at 19200 it is
very critical.

Recent experience with the Cluster Controller revealed two ways to
get busy ready "hardware control".   The read me file suggests that
for Intelliport boards, the user may select ic_control, device:,
"auto" to get hardware control of flow and make it more responsive,
but this is not available for the Cluster box.  For the cluster box,
you can either select CTSFLOW in the gettydefs file, or select cc_control,
device:, "busyready".  The later making the handshake protocal un-
changeable by stty.  Here is the rub, the latter works, the former,
CTSFLOW, does not.  At least not reliably.  Of course if your customer
will tolerate 9600 you can get away with anything, even for a time,
no flow control at all.   

Don't get me wrong, I am still buying these things.  If anyone from
COMPUTONE is reading, please defend yourself from all the bad comments
I have been reading lately, these problems are resolvable.

Any ideas or further clarification would be appreciated.  Post or
e-mail response, but I would appreciate e-mail because it is more
reliable at my location.

*********************************
*   John Watson                   
*   ...!rutgers!carssdf!usenet
*   Middlesex, New Jersey
*********************************