EPORTS & TB+

[Leslie Mikesell]

In article <1990Aug9.113122.8696 at nebulus.UUCP> dennis at nebulus.UUCP (Dennis S. Breckenridge) writes:

>Well the problem is obvious. The 3B2 driver is not as generic as one 
>would like. Some of the driver code lives on the 3B2 side of the world
>and most of the "low level" code lives on the ports card itself. It is
>easy to say, if I had the source I could fix it. There are many more 
>constraints than just broken software. The ports card is driven by it's 
>own heartbeat and interrupts are serviced on a hardware priority. What 
>really has to happen is the hardware has to be modified, and then a driver
>must be DESIGNED post facto.

Why would any hardware have to be modified to make software flow control
work?  Are you saying that the on-board 80186 can't see the characters
that are transfered into the 3B2 memory, or that the 3B2's ioctl's
can't pass information to the 80186 when the modes are changed?  The
obvious thing to do is to let the on-board CPU deal with both types
of flow control and unless something is really wierd it should be
possible in software.

>[...] If it was economical to repair or
>resdesign do you not think that other companies would have cloned the card
>and fixed the driver?

No.  Why should they?  But you might note that the 80386 ports expansion
almost works right.  Is this due to having to compete with equivalent
reasonable products or did the whole thing come from an outside source?

Les Mikesell
  les at chinet.chi.il.us