3B2 eports hfc and modems

[Steve Friedl]

In article <268 at puzzle.UUCP>, bei at puzzle.UUCP (Bob.Izenberg) writes:
> I've got a Telebit T2500 on a lightly loaded (one other 2400 baud modem)
> eports board, and I'm weighing the merits of hardware flow control.

Oh boy.

I have worked a lot with EPORTS and can probably help with this.
This board is much more powerful than the old PORTS board (4
serial, 1 parallel) but it has a number of real problems.  They
are only recently getting the driver and/or pumpware working
right, so it mostly doesn't lock up.  We have had customers
nearly commit suicide over this, and the joke around the office
then was that the EPORTS debacle in summer 1988 was the reason
that Cassoni left :-).  This problem is the only one that they
seem to be working on.

Software flow control has real trouble at high speeds.  They use
direct UART-to-RAM transfer via a DMA channel on the board, and
it really offloads the processing on the board's and the 3B2's
CPU by having no interrupts on each character.  This is the good
news.

The problem happens when an XOFF arrives.  The EPORTS 80188[?]
CPU regularly scans all the input buffers looking for special
characters put there by the DMA (including XOFF), but the way the
board is designed means that there can be as much as a 32-
character skid before output stops (my guess is if the XOFF
arrives just after the input queue has been scanned).  This kills
an HP LaserJet at 19200bps and maybe even 9600.  I have been told
that this is largely unfixable.

[ NOTE: the specifics of the problem described above are just
  what I hear on the street and have guessed at.  I have never
  seen the code or schematics or anything.  I could also be
  wrong on everything other than there is a very large skid. ]

Hardware flow control is a mixed blessing.  If you want to
connect up a LaserJet via an lp interface, you cannot beat it:
it is reliable and it works great.  If you need it for anything
else you are really out of luck.

Problem #1: CTS/RTS and XON/XOFF are mutually-exclusive (!).  If
you want to hook up your terminal to use hardware handshake, you
have to also set -ixon -ixoff -ixany or it will not work.  The
handshake works just fine, but if you have a habit of using ^S
and ^Q for your personal flow control, it will at best not work.
When you hit the ^S, it is not a special character any more so it
is echoed right back to the terminal: on mine, it means "lock
keyboard"

Problem #2: Hardware flow control is part-time only.  This means
that it is reset when you close the port, so you have to actively
go and turn it on all the time.  Again, this is no problem if you
are putting it in an lp interface, but for outgoing uucp or cu
calls I have found no solution that are not horrible hardcoded
hacks that no self-respecting <anybody> would ever use.

These two problems make hardware flow control of very limited
use, especially if you are running a telebit.  For incoming uucp
connections, you can in fact stick a front-end program that turns
on HFC and execs the real uucico.

I find it amazing that AT&T could blow it so badly on hardware
flow control (especially the mutually exclusive stuff), and it
means that we can only really use HFC for printers.  Those of
us with Telebits wanting to use them bidirectionally are really
S.O.L. (especially since DTR doesn't work right on uugetty/cu
anyway).

If anybody has found a way to make this work right, I would love
to hear about it.

     Steve, EPORTS old-timer

P.S. - I speak for me only.  Really.

-- 
Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy
+1 714 544 6561 voice   /   friedl at vsi.com   /   {uunet,attmail}!mtndew!friedl

"Winning the Balridge Quality Award is as easy as falling off a horse." - me