usenet@carssdf.UUCP (UseNet Id.) (09/06/89)
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 *********************************
larry@nstar.UUCP (Larry Snyder) (03/15/90)
More information here ... I removed the 4.40 drivers for the intelliport
and re-installed the 4.31 drivers - and now my bi-directional communications
with hardware handshaking is working just dandy - except no VP/ix access to
the serial ports (real Unix users don't use DOS/VPix :)) at high baud
rates (> 9600).
I am still using the 3.14 firmware -
--
The Northern Star Public Access Unix Site, Notre Dame, Indiana USA
uucp: iuvax!ndmath!nstar!larry internet: larry@nstar
USR HST 219-287-9020 * PEP 219-289-3745 * Hayes V9600 219-289-0286chip@tct.uucp (Chip Salzenberg) (03/22/90)
According to larry@nstar.UUCP (Larry Snyder): >More information here ... I removed the 4.40 drivers for the intelliport >and re-installed the 4.31 drivers - and now my bi-directional communications >with hardware handshaking is working just dandy - except no VP/ix access to >the serial ports (real Unix users don't use DOS/VPix :)) at high baud >rates (> 9600). I'd just like to add a personal testimonial to Larry's story. After supporting forty Xenix/386 installations with Computone IntelliPort [sic] boards, and having more than half -- that's right, HALF -- of them come back as failures, let me say this: Computone's so-called "programmers" have Q-Tips Cotton Swabs[tm] for brains. Their drivers have never failed to be entertaining just when I needed boring success. Computone may clean up their act someday. I don't care. I'll never buy a Computone product again. -- Chip Salzenberg at ComDev/TCT <chip%tct@ateng.com>, <uunet!ateng!tct!chip> "The Usenet, in a very real sense, does not exist."
mark@promark.UUCP (Mark J. DeFilippis) (03/25/90)
In article <2607C48F.30CF@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: > > Computone's so-called "programmers" > have Q-Tips Cotton Swabs[tm] for brains. > Well, I don't know if this is true, but we have used many Computone boards, and migrated up from the older AT-vantage X boards, $ boards, and intelliport boards, and they all hae one thing in common. 1. uugetty has problems with re-initializing a port that is used as an in-out port after you make a call out with cu. Last time I spoke with Tech Support they blamed it on SCO. 2. The boards get "confused" at times, requiring a re-boot. It happens on every system we have them in, and it don't matter if they have 2.45 proms with older drivers, or 3.00 proms with 2.28 or whatever drivers, or 3.14 proms with 2.35 drivers. From Day one, they have both of these problems. We now use Arnet boards, and all is calm, and we are no longer entertained, threw out all the popcorn, and our hair is starting to grow back now. Also, that Consensys board which is polled as opposed to interrupt driven, anyone tried out that board? It has been around for a while now, there must be some guinea pigs out there with some performance reports. -- Mark J. DeFilippis SA @ Department of Mathematics and Computer Science Adelphi University, Garden City, NY 11530 (516) 663-1170 UUCP: philabs!sbcs!bnlux0!adelphi!markd
larry@nstar.UUCP (Larry Snyder) (03/28/90)
> 1. uugetty has problems with re-initializing a port that is used as an > in-out port after you make a call out with cu. Last time I spoke with > Tech Support they blamed it on SCO. > > 2. The boards get "confused" at times, requiring a re-boot. It happens on > every system we have them in, and it don't matter if they have 2.45 proms > with older drivers, or 3.00 proms with 2.28 or whatever drivers, or > 3.14 proms with 2.35 drivers. From Day one, they have both of these > problems. I don't use uugetty - only the getty supplied with the X5 upgrade from ISC - and I can honestly say thay my machine is running fine with bi-directionalcommunications and complete hardware flow control as long as I don't try to "upgrade" my drivers.. I've never noticed the second problem you mention here at nstar - I did notice that the 3.14 proms allowed me to run my motherboard buss at 12.5 mhz while the older 3.00 firmwarw limited me to a buss speed of 8 mhz.
tim@comcon.UUCP (Tim Brown) (03/29/90)
In article <2326@promark.UUCP>, mark@promark.UUCP (Mark J. DeFilippis) writes: > > Also, that Consensys board which is polled as opposed to interrupt driven, > anyone tried out that board? It has been around for a while now, there > must be some guinea pigs out there with some performance reports. > Guinea pig is right! I have been using the consensys board for about a year now in two different systems. Ths older ones were better than the one they offer now. After tech support and such I finally got the old ones working, wish I could say the same for the new ones. They do most things well and I really like the multiple sessions but they fall down on telecomunications. I have to implement hardware handshaking and run at max speed of 2400 baud or uucp throws up errors. I have been waiting to post this untill thier tech support got back to me but alas, no call. I was told by a very rude individual there to put my problems in writing or put up! I finally convinced him to give me a usenet address and an individual to respond to and I wrote a lengthy discription of the problem. I heard nothing. There tech support used to be good, don't know what happened to them. They have always had a problem with modem communications in my view and shouldn't be used for that application. The first time I purchased one of these boards it took months to get it worked out, guess I am out of patience. Tim Brown | Computer Connection | uunet!iuvax.cs.indiana.edu!ndmath!nstar!comcon!tim |
mikej@lilink.com (Michael R. Johnston) (03/30/90)
In article <2326@promark.UUCP> mark@promark.UUCP (Mark J. DeFilippis) writes: >1. uugetty has problems with re-initializing a port that is used as an > in-out port after you make a call out with cu. Last time I spoke with > Tech Support they blamed it on SCO. This is FIXED if you get prom rev 3.14 and ask them for the driver version 3.54. We are were a beta site for that driver and I can honestly say that it cured ALL the problems ESPECIALLY the hangup problem. >2. The boards get "confused" at times, requiring a re-boot. It happens on > every system we have them in, and it don't matter if they have 2.45 proms > with older drivers, or 3.00 proms with 2.28 or whatever drivers, or > 3.14 proms with 2.35 drivers. From Day one, they have both of these > problems. Again, try the new proms and drivers. You may be surprised. It is my understanding that they sent their device driver guru down to SCO to learn how to write one properly for Xenix. Since then they've released the new drivers and my problems have been solved. -- Michael R. Johnston mikej@lilink.com Lilink Communications rutgers!lilink!mikej "Affordable Unix Solutions" (516) 285-4148