Equinox hardware flow control

[Super user]

In article <1991Feb14.134714.5407 at nstar.rn.com> larry at nstar.rn.com (Larry Snyder) writes:
>bill at astph.UUCP (Bill Dripps) writes:
>
>>We are evaluating Equinox's 24 port Megaport. It looks like a good
>>board. Unfortunately the key tech support person is on vacation this
>>week. Sigh. 
>
>>Anybody know how to turn on hardware flow control using ISC UNIX? The
>>manual tells how for Xenix, but no hints for ISC. Did I miss it?
>
>Hardware flow control for ISC Unix is not supported (so I've been
>told) with the Equinox or stock ISC ASY driver.
>

I've checked into the ISC hardware flow control question and here is
what I've found out:

It's not quite true that ISC doesn't support hardware flow control since
the Dialer program and application software that turn hardware flow control
on work fine. It may be a question of semantics, but hardware flow control
is not supported "on the console or terminals" by ISC. For the most part,
xon/xoff works great. Because the megaport doesn't use UARTS, the megaport
can stop data transfer within two characters after receiving an XOFF--even
at 38.4K baud. That's significant, because most UART boards would not be able to
handle 38.4K baud with xon/xoff flow control because at that speed the 
buffer would overflow. Please remember, I'm talking about the need for
hardware flow with the use of terminals/printers -- not high speed modems.
For terminals/printers, use xon/xoff with MEGAPORT (why not?).

Ok, one reason why not is a problem we're working on with Bill Dripps.
WordPerfect 5.0 puts the wyse60 in PC Term mode (for keyboard compatibility
with DOS WordPerfect) and must use hardware flow control. To me, this 
sounds similar to the FoxBase 9600 baud limit that we came up with a fix
for (megastty +fb) to allow FoxBase to run at 38.4K baud with xon/xoff
handshaking (even though FoxBase disabled xon/xoff for its editor to
maintain DBASE III compatibility). We have a beta driver out with an
attempted fix for this WordPerfect problem. We're short-handed this week,
because two of our support guys are on installs, one high-level guru
who was working on these problems is on leave for a family emergency --
so the rest of us are getting support experience (which, I think, is
good -- since it really brings customer problems home to roost when you
have marketing types and kernel hacker types answering the phone.). These
problems will get solved!

wolf