using NS16550A UARTs with a dumb serial card (386/ix)

Mark W. Snitily mark at zok.UUCP
Fri Dec 22 19:05:05 AEST 1989


In article <10233 at june.cs.washington.edu> witold at june.cs.washington.edu (Witold Paluszynski) writes:
>In article <10231 at june.cs.washington.edu> I write:
>
>>I have an Everex EV170B IO card with 3 serial lines on it.
>>I just tried using it with the NS16550A UART chips, which
>>have FIFO queues for TX and RX and are supposed to be supported
>>by 386/ix.  No go.  It doesn't work.  What is strange is that
>
>After I received some responses to my message I realized that I
>didn't make myself clear.  The Everex EV170B IO board doesn't
>work with the NS16550A UARTs.  The board does not work, period.

That's funny.  I'm using it with 16550A's in all three ports.
Works great for me.

>But unfortunately the 16550A is not pin-compatible with the
>16450.  Two pins (24 and 29) on the 16550A have different
>functions than on the 16450 (where 29 is NC and 24 is CSOUT).
>Some boards may ignore these pins and work with the 16550A.
>The Everex EV170B is not one of them.

Never heard of pins 24 & 29 having different functionality.
Didn't read through the data sheet in detail, but once again,
I'm having no problem with 16550A's and the EV170B.

I'm the person who wrote the original article about the EV170B and
16550A's back in August.  Right now I'm running ISC 2.0.2 with Jim
Murray's PD driver.  (Had everything configured and *working* before
the X5 update came out.  Have the X5 update, but never got around to
trying the new ISC drivers.  Guess I'm following the old adage of,
"If it works, don't fix it.")

Now the EV170B card does have some *strange* pin defintions for the
2nd and 3rd ports.  The 1st port is on the card itself and works as
expected, but you have to build your own cables for the additional
ports.  Here's a repost of my original article that explains the
pin definitions for these additional ports:

-------------------------------------------------------------------------------
>From mark Sun Aug 20 23:22:47 PDT 1989
Article 583 of comp.unix.i386:
Path: zok!mark
>From: mark at zok.UUCP (Mark W. Snitily)
Newsgroups: comp.unix.i386
Subject: Everex EV-170B card with 16550A's
Keywords: 16550A, RS-232C, pin mappings
Message-ID: <349 at zok.UUCP>
Date: 21 Aug 89 06:16:25 GMT
Organization: The distant planet Zok
Lines: 62

The following is a somewhat long note about a nice three port serial I/O
card and a question about RS-232 pin orderings.

With the recent info on how to fix uucico throughput with 16550A's, I went
shopping for a new serial I/O card that would allow me to replace *all* of
the 16450 UART chips with 16550A chips.  (Typically serial I/O cards have
one 16450 (or equivalent) soldered in place and have one socket for an
additional UART for COM2.)

What I came across was the Everex EV-170B card.  Nice.  Typical inexpensive
I/O card; has parallel port, game port, but has *three* serial ports.  Each
serial port's UART is socketed and each serial port allows the selection of
independent interrupt vectors and I/O addresses.  In other words, this
card *is not* like the typical DOS configuration of forcing COM1/COM2 to
share the same interrupt vectors with COM3/COM4.

So, if you have an unused interrupt vector (either 5 or 9) then you can
configure Unix (386/ix 2.0.1 in my case) to have *three* serial lines.
And, if you're using a device driver that supports the 16550A, *all* three
lines can enjoy the super throughput that the 16550A provides.

So far, all nice and grand -- now for the real reason why I'm writing this.
To make what could be a *real* long story short, IMHO the pins on the card
that connect to the RS-232C cables are really ordered *weird*.

          RS-232C                  J Connector Pins on Card
   ---------------------           ------------------------
   9-pin  25-pin  Signal           Normal    Everex EV-170B
     1       8     DCD             1  (8)        1  (8)
     2       3     RX              2  (3)        3  (2)
     3       2     TX              3  (2)        5  (7)
     4      20     DTR             4 (20)        7  (4)
     5       7     GND             5  (7)        9 (22)
     6       6     DSR             6  (6)        2  (3)
     7       4     RST             7  (4)        4 (20)
     8       5     CTS             8  (5)        6  (6)
     9      22     RI              9 (22)        8  (5)

For example, on the card the J connector pin number 5 normally connects
to pin number 5 on the 9-pin RS-232, (or pin number 7 on the 25-pin
RS-232).  But on the EV-170B, the J connector pin number 5 needs to
connect to pin number 9 on the 9-pin RS-232, (or pin number 22 on the
25-pin RS-232).

[The above mapping was obtained only after:  exchanging the card once
thinking it was defective -- no difference;  calling Everex tech support --
it was configured correctly according to them;  buying a RS-232 breakout
box -- that's something I've avoided for over a decade;  and finally
tracing the lines on the PC card -- it now works!]

If anyone from Everex is reading this, may I suggest that you please
add the pin's signals to your manual.  There's no hint that buying a
standard cable (from someone other than Everex) won't work.

Has anyone ever seen the pin ordering that's on this card?  Is it
*weird*, or is it yet another standard used by some vendors?
-------------------------------------------------------------------------------

I only received one reply regarding my question about the pin ordering.
It came from Doug Ingraham (...!uunet!loft386!dpi) who mentioned that
Tall Tree Systems also used a different ordering from the one IBM later
used and suggested that maybe Everex got a deal on some weird connectors.

[Anyone from Everex listening?  What's the real story on this card?]

To reiterate, hardware wise the EV170B and 16550A works.  Special wiring
is required for the 2nd & 3rd ports.  Have not tried ISC's X5 update,
but know that Jim Murray's driver works.  [FYI, running a 33Mhz Micronics
motherboard with AT bus at 11Mhz.  TB+ modem connected to EV170B at
19.2K.  As I have said, works great...]

If you need more info, or need a copy of Jim Murray's driver, feel
free to email.  Hope this helps.  Good luck.

-- Mark
Mark W. Snitily                 Consulting Services:
894 Brookgrove Lane             Graphics, Operating Systems, Compilers
Cupertino, CA 95014             (408) 252-0456
mark at zok.uucp



More information about the Comp.unix.i386 mailing list