Equinox MEGAPORT multiport boards and hardware flow control

[Wolf Kozel]

Jim Dixon (among others) writes:
>Wouldn't it be nice if the [Equinox MEGAPORT]card supported CTS flow control by default.
>Regular serial ports that use UARTs and the like do it. Regardless
>of *WHAT* software you are using, if you drop CTS, the UART's transmitter
>will stop sending until you raise it again, independent of software control.
>Why the h--l can't Equinox do the same thing? The control In pin (whichever
>one is mapped to the CTS input, by mode) is internally pulled up on the card,
>so if the CTS flow was enabled, and nothing was connected to it, it would
>just operate as normal, transparently, painlessly.... it would be wonderful...

>Ahh, I feel better already...

>Jim Dixon
>jim at lambda.uucp or dixon at info.com

If you've been following this newsgroup lately, there has been several 
postings about Equinox MEGAPORTs and Hardware Flow Control (hfc). Basically,
two problems were presented:

   1) Hardware flow control under Interactive was not supported by the 
      driver.

   2) WordPerfect 5.0 disables xon/xoff when it enters PC Term mode. In
      this case, a user could use hardware flow control (except he runs into
      problem number 1). In addition to problem number 1, small buffers
      such as found on the Wyse 60 drop DTR when their buffer is 75%
      full. The Wyse 60 has 64 bytes of room left after flow controlling
      the MEGAPORT. Running at baud rates of 19.2K baud or lower there is
      no problem, but at 38.4K baud, the MEGAPORT overflows the Wyse 60's
      buffer. This presents the paradox as mentioned by Bill Dripps:
      We purchased the MEGAPORT because it's the fastest card on the market.
      Now I have to tell my users we have to run slower than the card it 
      replaced because the MEGAPORT is faster??-- Good point.


We have fixed both problems. We appreciate the suggestions--and the 
criticisms too. Both help us build a better product. If you are 
encountering either problem, please call or email. The driver version
to ask for is 2.2.0h. 

The first problem was solved by adding a +cts flag in our driver. We
also look at that port (which has the +cts flag turned on) more often.
This keeps us from overflowing Wyse 60's small buffers at 38.4K baud
(Problem #2 solved too.).

Problem number two we suspect is a WordPerfect problem (I'm not trying
to point fingers, please hear me out). Before these problems were 
reported on the net, we emphasized xon/xoff flow control because the
Equinox ASIC chip guarantees stopping data within a maximum of two
characters of receiving an xoff. Boards based on UARTS and microprocessors
typically recommend not using xon/xoff at high speeds (38.4K baud) because
they overflow the buffer before they catch the xoff. With us it was
the opposite (We overflowed with hfc). Applications like Microsoft Word,
VP/ix-- like WordPerfect that put the terminal into PC Term scancode mode,
do not have any problems with MEGAPORT and xon/xoff flow control. We have
put in a call to WordPerfect and they have agreed to list it as a "discrepancy".At first, they were going to classify it as a feature, an enhancement
to be added later.But our software engineer asked to speak
to the President of WordPerfect. I expect WordPerfect, being the great
company they are, will fix this problem in the next version.

In the meantime, we have a developed another megastty flag that  allows
xon/xoff to be used with WordPerfect at 38.4K baud (Problem #2 solved,
again). So we work at 38.4K baud with hardware flow control, and if 
you're using WordPerfect (which doesn't seem to support xon/xoff), we
work with that also (xon/xoff and hardware flow control).

So what do we need to add/fix now? Any suggestions?

--Wolf
 
_________________________________________________________________
Arf, Yipe, Grrrrrrrr          Equinox Systems (305) 255-3500 x289
Wolf Kozel                    14260 SW 119th Ave, Miami FL 33186
Me: The only living person to install modems at 3 Multiport Companies.