 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Serial Communication News
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

What most people call the "RS-232" interconnection scheme is a
standard published by the Electronic Industries Association (EIA).
The formal name is now EIA-232-E, but most sources still use the older
"RS-232" name, or sometimes "RS-232-C".

(RS just meant "recommended standard".  To order a copy from the EIA,
ask for document "EIA/TIA-232-E Interface Between Data Terminal
Equipment and Data Circuit-Terminating Equipment Employing Serial
Binary Data Interchange", ANSI/EIA/TIA-232-E-91, July, 1991.)

RS-232 was invented to describe how to connect a simple dumb terminal
to a simple dumb modem, but it has been made to work (with various warps
and stretches) in vast numbers of other types of connections.

In the early part of the 21st Century, the Universal Serial Bus (USB)
is supplanting RS-232 in many uses, but it is still widely deployed.
Converter boxes and adapters have been invented to permit interoperation;
there are available from companies such as KeySpan, Black Box, and LanTronix.

 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A classical RS-232 serial connection has two ends.  One end is the DTE
end, where "DTE" is "data terminal equipment".  Most video terminals
and most IBM-PC-type computers are set up to be the DTE end.

The other end of the wire is the DCE end, where the "data communications
equipment" is attached.  This is usually a modem, although devices such
as statistical multiplexers are also DCE.  Sometimes "DCE" is said to
mean "data circuit-terminating equipment", but in practice there is no
detectable difference.

The DTE end generally has a male connector (with 25 pins inside the shell),
and the DCE end generally has the female connector.  Exceptions to this
custom, however, are frequent.

Here are the traditional pinouts.

CIRCUIT V.24 NAME               DIRECTION DB-25 DE-9  COMMENTS
------- ---- ----------         --------- ----- ----  -------------
FG           Frame Ground           n/a     1    n/a  Electrical safety
TD      103  Transmitted Data    to DCE     2     3   Data from computer
RD      104  Received Data       To DTE     3     2   Data to computer
RTS     105  Request to Send     to DCE     4     7   Hardware flow control
CTS     106  Clear to Send       To DTE     5     8   Hardware flow control
DSR     107  Data Set Ready      To DTE     6     6   DCE on and in data mode
SG      102  Signal Ground          n/a     7     5   Signal voltage reference
CD      109  Carrier Detect      To DTE     8     1   Modems are communicating
DTR     108  Data Terminal Ready to DCE    20     4   DTE on and in data mode
RI      125  Ring Indicator      To DTE    22     9   Phone is ringing


If you wish to directly connect together two computers, or a computer and
a terminal, you have to compensate for the fact that they are both DTE
devices.  The wiring in between must somehow contain, or behave as, a
"null modem" to make the two DTEs both believe they are talking to a DCE.

A good practical discussion of RS-232 data communication appears in
Appendix II of the following book:

  Frank da Cruz and Christine M. Gianone, "Using C-Kermit", Digital Press/
  Butterworth-Heinemann, Woburn, MA, 1993, 514 pages, ISBN 1-55558-108-0
  US single-copy price: $36.95; quantity discounts available.  Available in
  computer bookstores or directly from Columbia University: +1 212 854-3703.

Two good books with in-depth technical detail are "Technical Aspects of Data
Communication" by John McNamara (also published by Digital Press) and "Data
and Computer Communications" by William Stallings (4th ed., Prentice-Hall,
1994).  A beginner's book is "RS-232 Made Easy" 2nd.ed., by Martin D. Seyer
(unknown publisher).

Two standards published by the EIA to define high-speed serial communication
are TIA/EIA-422-B (RS-422) and EIA-423-A (RS-423).  The Macintosh computers'
serial ports are actually a variant form of RS-422, although with proper 
wiring they are interoperable with RS-232.


 //////////////////////////////////////////////////////////////////////////////

If you'd like a kinder, gentler explanation of RS-232, you can try the
"Mr. Rogers" version:

    http://www.routergod.com/misterrogers/

 //////////////////////////////////////////////////////////////////////////////

If your PC computer has three DB-25 connectors on the back, two of them with
pins (male) and one of them with sockets (female), then do *not* try connecting
an RS-232 serial device to the female connector.  It's a parallel printer
interface, *not* a serial port.


 //////////////////////////////////////////////////////////////////////////////
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Newsgroups: comp.terminals
Path: cs.utk.edu!news.msfc.nasa.gov!newsfeed.internetmci.com
      !news.sprintlink.net!howland.reston.ans.net!nntp.crl.com!pacbell.com
      !amdahl.com!netcomsv!uucp3.netcom.com!lia!glenn
From: glenn@ia-us.com (Glenn Herteg)
Subject: Re: PINOUTs for NULL modem CABLE
Message-ID: <1995Aug4.190253.894@ia-us.com>
Reply-To: glenn@ia-us.com (Glenn Herteg)
Organization: IA Corporation, Emeryville, CA
References: <3vmd2s$adt@murphy.servtech.com> <3vmivr$jrd@spectre.sc.intel.com>
            <1995Aug3.041320.8502@ia-us.com>
Date: Fri, 4 Aug 1995 19:02:53 GMT
Lines: 48

In article <1995Aug3.041320.8502@ia-us.com>,
 glenn@ia-us.com (Glenn Herteg) writes:
>
> In article <3vmivr$jrd@spectre.sc.intel.com>,
> Bennet Wong <bennet_wong@ccm.sc.intel.com> writes:
>>
>>There are actually a lot of different kind of NULL cable. It all 
>>depanded on what are you trying to do. Most "Standard" no-handshake Null 
>>cable is as follow
>>2-3
>>3-2
>>7-7
>>This will work for most device that does not require DTR/DSR or CTS/RTS
>>(in other word, no H/W handshake).

I've been advised that my previous posting is subject to some
misinterpretation as to which wires are connected.  So I'll rearrange
the diagram here and add the comment that all of the crossed wires
shown are not connected; the only connections are at the pins.

The standard null-modem pinout I use is:

    1    2    3    4    5    6    8    20   7
    o    o    o    o    o    o    o    o    o
    |     \  /      \  /      \__/ \  /     |
    |      \/        \/             \/      |
    |      /\        /\        __   /\      |
    |     /  \      /  \      /  \ /  \     |
    o    o    o    o    o    o    o    o    o
    1    2    3    4    5    6    8    20   7

This has rarely failed to do the job, in my limited experience.

Note that I avoid commercial null modems like the plague.  Essentially
all of them have a criminally stupid design -- they fail to apply a
sticker that tells you what the wiring connections are inside!  That
means you have to spend far more in your time than the thing supposedly
cost you, in buzzing the cable or box to figure out what's inside.

On all the null modems I build, I attach a small sticker with a drawn
wiring diagram, much like that above, so there's never any question
about whether it's appropriate for a given situation.  If I need a
special converter, that gets its own sticker, with an extra notation
about what devices it's built to cope with, and it's impossible to
confuse with another box.  If the presence of all the extra information
on the label is confusing, you probably don't understand your wiring
situation well enough, and you need to go back and look at the manuals
of the devices you're trying to connect.

Glenn Herteg
<glenn@ia-us.com>

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.dcom.modems
Path: utkcs2!darwin.sura.net!wupost!uunet!ralvm29.VNET.IBM.COM
Message-ID: <19920720.113021.40@almaden.ibm.com>
News-Software: UReply 3.0
References: <5680.2a473a8f@hayes.com> <o14ymB3w164w@wolferts.ka.sub.org>
            <1992Jul11.214141.23489@qiclab.scn.rain.com>
Date: Mon, 20 Jul 1992 10:28:37 EDT
From: Petty@ralvm29.VNET.IBM.COM (Jack Petty)
Subject: Re: RTS/CTS flow control


Please don't bash CCITT V.24 about RTS/CTS flow control.  Circuit 133,
which is defined in the 1988 version of V.24, is called "Ready for
Receiving" and is exactly RTS flow control.  Since V.24 does not
assign pin numbers on an interface, a person specifying a modem need
only stipulate that circuit 133 from V.24 must be available as an
optional behavior for pin 4 of the 25 pin connector (or whatever pin
of a nine pin connector).

Jack Petty

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
Path: cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com
      !cyclone.swbell.net!cyclone-sf.pbi.net!63.208.208.143!feed2.onemain.com
      !feed1.onemain.com!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net
      !newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net
      !newsread1.prod.itd.earthlink.net.POSTED!not-for-mail
Message-ID: <3AA5941D.6805C2AC@EarthLink.Net>
NNTP-Posting-Host: 165.247.156.205
Organization: Hall Communications
X-Mailer: Mozilla 4.76 [en] (Win98; U)
From: "Scott G. Hall" <ScottGHall@EarthLink.Net>
Date: Wed, 07 Mar 2001 01:53:31 GMT
Subject: Re: HELP !! Cables for dumb terminals

Konstantinos Makaronas wrote:
>
> Hello Scott and thank you very much, the problem is that at least in my
> country the people in the shops are too stupid and they dont know what null
> modem is and they don't know what kind of cables are the ones for the
> terminals and I'm asking from me to give them a drawing of the every pin of
> the cable and what pin will be the input and what pin will be the output
> so they can construct it for me, but I dont have any drawing or design like
> that, and I couldnt find it on the net either; these people asked for a
> drawing of BOTH ends of the cable all the pins ands their numbers in one
> side and what will be their role and the pins on the other end and their
> role

Being forwarded is a copy of a website that maintains this stuff for every
possible connector on the PC.

 
> Where can i find such a specification drawing ?

Every few years this question comes up.  I usually go even beyond the
information contained on the website, because the true EIA RS-232C standard
also specifies synchronous as well as asynchronous connections:

Given the following:

	  DTE     DTE
	25-pin   9-pin  name            direction
	------   -----  --------------  ---------
	 1 - Shld ----  chassis ground   (frame) 
	 2 - TX  - 3 -  transmit           -->   
	 3 - RX  - 2 -  receive           <--    
	 4 - RTS - 7 -  ready to send      -->    
	 5 - CTS - 8 -  clear to send     <--     
	 6 - DSR - 6 -  data set ready    <--     
	 7 - Gnd - 5 -  signal ground     <-->    
	 8 - CD  - 1 -  carrier detect    <--     
	20 - DTR - 4 -  data term. ready   -->    
	22 - RI  - 9 -  ring indicate     <--     

and for synchronous serial connections (like X.25):
	15 - TXC ----- transmit clock out -->
	17 - RXC ----- receive clock out <--
	24 - TC  ----- transmit clock in  -->

A true null-modem cable is constructed with the following wiring diagram:

  DTE End-1               -- Null-Modem-Cable --             DTE End-2
25-pin   9-pin  name            direction  name            9-pin   25-pin
------   -----  --------------  ---------  --------------  -----   ------
 1 - Shld ----  chassis ground   (frame)   chassis ground  ---- Shld -  1
 2 - TX  - 3 -  transmit           -->     receive         - 2 - RX  -  3
 3 - RX  - 2 -  receive           <--      transmit        - 3 - TX  -  2
 4 - RTS - 7 -  ready to send      -->     clear to send   - 8 - CTS -  5
 5 - CTS - 8 -  clear to send     <--      ready to send   - 7 - RTS -  4
 6 - DSR - 6 -  data set ready    <-+-     data term. ready- 4 - DTR - 20
 8 - CD  - 1 -  carrier detect    <-+      
 7 - Gnd - 5 -  signal ground     <-->     signal ground   - 5 - Gnd -  7
20 - DTR - 4 -  data term. ready  -+->     data set ready  - 6 - DSR -  6
                                   +->     carrier detect  - 1 - CD  -  8

22 - RI  - 9 -  ring indicate     <--   ..not connected..

and for synchronous serial connections (like X.25):

15 - TXC -----  transmit clock out -+->  +-  receive clock out --- RXC - 17
17 - RXC -----  receive clock out <-+    +-  transmit clock out--- TXC - 15
24 - TC  -----  transmit clock in  -+

	-- this says that one side determines the clock for both sides

Note that this takes 4-pairs of wires:

	 TX/RX  pair
	RTS/CTS pair
	DTR/DSR pair  (the DSR and CD pins are connected together in plug)
	CLK/Gnd pair  (the single clock wire drives both sides)

-- 
H A L L   C O M U N I C A T I O N S           | Scott G. Hall, Sherri D. Hall
       HallComm-Online.Com                    |   ScottGHall@EarthLink.Net
       DataSpan-Online.Com                    |   SherriDHall@EarthLink.Net
      Technotions-Online.Com                  |    HallComm@EarthLink.Net

    [ Part 2: "Included Message" ]

 ..............................................................................

Message-id: <37138C06.DCBA19FC@GSC.GTE.Com>
Organization: GTE Government Systems
Date: Tue, 13 Apr 1999 14:25:10 -0400
From: "Scott G. Hall" <Scott.Hall@GSC.GTE.Com>
Subject: Pinouts for various PC Connectors

http://www.randomc.com/~dperr/pcpinout.txt

    [ Part 2.2: "Attached Text" ]

          This information may be shared freely but not sold for profit!

          This data is provided in a text format to allow greater ease
          of cutting and pasting into various technical documents.
         
                     This information compiled and provided by
                         Dick Perron   dperr@randomc.com

                     Standard PC Cabling Pin-out Diagrams

                      Standard motherboard power connectors
                        ATX motherboard power connector
                          CGA/EGA/VGA Video connectors
                      DB13W3 Mono and Color video connectors
                        AT and PS/2 keyboard connectors
                            PS2/Serial mouse adaptor
                          PS2/Serial mouse connectors
                   IBM and EVEREX serial ribbon cable pinout
                             Serial I/O connectors
                              Game Port Connector
                    Reset/keylock/battery/speaker/HDD/turbo MB connectors
                            Parallel I/O connectors
                          Serial Loopback Plug Wiring
                         Parallel Loopback Plug Wiring
                      Win95/98 Direct Cable Connection (Serial and Parallel)
                           Null modem cable PC to PC
                     Null modem cable PC to serial device
                           Parallel Centronics cable
                          MIDI In and Out connectors
                              IR module connector
                              USB Canle Connector
                       10baseT/100baseT crossover cable 
                           100baseT4 crossover cable
                                                      
 ******************************************************************************

                     CENTRONICS/DB STYLE CONNECTOR PIN NUMBERING

   Rule of thumb for pin numbering for standard and mini Centronics/DB style
   connectors is:
                              Male Connectors        
   Pin #1 is the first pin, top row, LEFT side when looking at the connector.
                             Female Connectors 
   Pin #1 is the first pin, top row, RIGHT side when looking at the connector.

                           DIN/MINI-DIN CONNECTORS 
   DIN and Mini-Din connectors have an alternating pin numbering scheme.  See
   diagrams in this document for correct pin orientation. 

 ******************************************************************************

                      STANDARD PC MOTHERBOARD CONNECTORS

              Main Board (System PCB) Standard DC Power Connector(s)

                          O   Y
                          r   e   B B   B B W 
                          a   l B l l   l l h 
                          n R l l a a   a a i R R R
                          g e o u c c   c c t e e e
                          e d w e k k   k k e d d d
                          ___________   ____________
                          |          |  |          |
                          |    P8    |  |    P9    |
                          |          |  |          |
                          -----------   -----------
               Wire Color                              Assignment

                 Black -------------------------------  Ground
                 Orange -------------------------- Power Good (+5V DC)
                  Red ---------------------------------- +5 VDC
                 White --------------------------------- -5 VDC
                 Yellow ------------------------------- +12 VDC
                  Blue -------------------------------- -12 VDC

    Note!! When installing the P8/P9 connector be sure that the four
    black wires are adjacent to each other in the center of the connector.

    The Red and Orange wires are on the outside edge of the connector.

                         ATX 20 pin power connector
                              Pin#     Pin#
                        ----------------------- 
                       | 3.3V  11       1* 3.3V |
                       | -12V  12       2  3.3V |
                       |  COM  13*(Gnd) 3  COM  |
                       | PS-ON 14*      4  +5V  |
                       |  COM  15       5  COM  |
                       |  COM  16       6  +5V  |
                       |  COM  17       7  COM  |
                       |  -5V  18       8  PW-OK|
                       |  +5V  19       9  5VSB |
                       |  +5V  20      10  +12V |
                       --------------------------
* NOTE!! On ATX supplies the power supply on/off functions are controlled
  thru the motherboard connector.   See pins 1, 13 and 14 for 3.3V, GND
  and Power-on signal.

                         Peripheral DC Power Connector

                                         Y
                                     B B e
                                     l l l
                                   R a a l
                                   e c c o
                                   d k k w

               Wire Color                          Assignment

                  Red ------------------------------- +5 VDC
                 Black ------------------------------ Ground
                 Yellow ----------------------------- +12 VDC

              IBM AT 101 KEY (ENHANCED) KEYBOARD 5 PIN DIN CONNECTOR

   Male End        PIN                                   SIGNAL                Female End
                    1 ---------------------------------- KBDCLK (clock)          
 1         3        2 ---------------------------------- KBDAT  (data)           3         1
   4     5          3 ---------------------------------- KBRST  (reset,not used)   5     4
      2             4 ---------------------------------- GND                          2
                    5 ---------------------------------- VCC    (+5V)

                  IBM PS/2 KEYBOARD 6 PIN MINI-DIN CONNECTOR
   Male End        PIN                                 SIGNAL                 
 
    5 H 6           1 -------------------------------- KBDAT (data)
   3     4          2 -------------------------------- not used    
     1 2            3 -------------------------------- GND         
                    4 -------------------------------- VCC (+5v)
                    5 -------------------------------- KBCLK (clock)
                    6 -------------------------------- not used

                   IBM PS/2 MOUSE 6 PIN MINI-DIN CONNECTOR
                   PIN                                SIGNAL

     6 H 5          1 ------------------------------- MOUSEDATA: 110
    4     3         2 ------------------------------- not used
      2 1           3 ------------------------------- GND
                    4 ------------------------------- +5V
   Female end       5 ------------------------------- MOUSECLK:  110
                    6 ------------------------------- not used

          PS/2 MOUSE ADAPTOR CABLE TO MOTHERBOARD 10 PIN DIL CONN
                Mouse port                           DIL Conn

                    1 ------------------------------- 1 Data
                    2 ------------------------------- 2 N/C
                    3 ------------------------------- 3 Gnd
                    4 ------------------------------- 4 VCC +5V
                    5 ------------------------------- 5 Clk
       
 NOTE!! This pinout is from a Biostar MB with PS2 mouse option.
        This PS2 to DIL connector cable IS NOT STANDARD 
        across all MB mfg's. There are some 4 pin , 5 pin and
        10 pin DIL connectors on various MB's.

                 SERIAL MOTHERBOARD CABLE 10 PIN DIL TO DB-9
                             (IBM WIRING SCHEME)
                  This is the ribbon cable from the MB serial
                     connector to the DB-9/DB-25 COM connector
                  DIL               DB-9            DB-25
                   1 -------------- 1  DCD __________ 8
                   6 -------------- 2  RX ___________ 3
                   2 -------------- 3  TX ___________ 2
                   7 -------------- 4  DTR __________ 20
                   3 -------------- 5  GND __________ 7
                   8 -------------- 6  DSR __________ 6
                   4 -------------- 7  RTS __________ 4
                   9 -------------- 8  CTS __________ 5
                   5 -------------- 9  RI ___________ 22
                   10 ------------- 10  N/C OR KEY

                 SERIAL MOTHERBOARD CABLE 10 PIN DIL TO DB-9
                             (EVEREX WIRING SCHEME)
                  This is the ribbon cable from the MB serial
                     connector to the DB-9/DB-25 COM connector
                  DIL               DB-9            DB-25
                   1 -------------- 1  DCD __________ 8
                   2 -------------- 2  RX  __________ 3
                   3 -------------- 3  TX  __________ 2
                   4 -------------- 4  DTR __________ 20
                   5 -------------- 5  GND __________ 7
                   6 -------------- 6  DSR __________ 6
                   7 -------------- 7  RTS __________ 4
                   8 -------------- 8  CTS __________ 5
                   9 -------------- 9  RI  __________ 22
                   10 ------------- 10  N/C OR KEY

 
                     MICROSOFT SERIAL MOUSE DB-9 CONNECTOR

                   PIN                                SIGNAL
                    1 -------------------------------- MOUSEDATA
                    5 -------------------------------- Gnd
                    8 -------------------------------- +5V
                    9 -------------------------------- MOUSECLOCK
             
                           PS2/SERIAL MOUSE ADAPTOR CABLE
              MINI DIN CONN                      DB-9 SERIAL CONN 
       
                    1 ---------------------------------- 1
                    3 ---------------------------------- 5
                    4 ---------------------------------- 8
                    5 ---------------------------------- 9                    

                             GAME PORT DB-15 FEMALE

                   PIN                                 SIGNAL

                    1 -------------------------------- +5V DC
                    2 -------------------------------- Button 4 (A_PB1)
                    3 -------------------------------- Pos'n 0  (A_X)
                    4 -------------------------------- GND
                    5 -------------------------------- GND
                    6 -------------------------------- Pos'n 1  (A_Y)
                    7 -------------------------------- Button 5 (A_PB2)
                    8 -------------------------------- +5V DC
                    9 -------------------------------- +5V DC
                   10 -------------------------------- Button 6 (B_PB1)
                   11 -------------------------------- Pos'n 2  (B_X)
                   12 -------------------------------- GND
                   13 -------------------------------- Pos'n 3  (B_Y)
                   14 -------------------------------- Button 7 (B_PB2)
                   15 -------------------------------- +5V DC

                        KEYLOCK AND POWER LED CONNECTOR
                  PIN                                  SIGNAL

                    1 -------------------------------- +5 VDC
                    2 -------------------------------- not used (key)
                    3 and 5 -------------------------- GND
                    4 -------------------------------- KEYBD DIS (key lock)

                       EXTERNAL BATTERY CONNECTOR (6 VDC)
                  PIN                                  SIGNAL

                    1 -------------------------------- +6 VDC
                    2 -------------------------------- not used (key)
                    3 -------------------------------- GND
                    4 -------------------------------- GND

                               SPEAKER CONNECTOR
                  PIN                                  SIGNAL

                    1 -------------------------------- SPEAKER
                    2 -------------------------------- not used (key)
                    3 -------------------------------- GND
                    4 -------------------------------- +5 VDC
                              
                              TURBO LED CONNECTOR
                  PIN                                  SIGNAL

                    1 -------------------------------- +TURBO (+5 VDC)
                    2 -------------------------------- GND

                           DISK ACCESS LED CONNECTOR
                  PIN                                  SIGNAL

                    1 -------------------------------- +DISK (+5 VDC)
                    2 -------------------------------- -DISK
                    3 -------------------------------- -DISK
                    4 -------------------------------- +DISK (+5VDC)

             ENHANCED GRAPHICS ADAPTOR (EGA) VIDEO CONNECTOR DB-9
            DB-9 PIN female                            SIGNAL

  DB-9 MALE CONN    1 -------------------------------- GND              DB-9 FEMALE CONN
    1       5       2 -------------------------------- SECONDARY RED       5       1
    o o o o o       3 -------------------------------- RED                 o o o o o  
     o o o o        4 -------------------------------- GREEN                o o o o 
     6     9        5 -------------------------------- BLUE                 9     6
                    6 ---------------------- SECONDARY GREEN/INTENSITY
                    7 ---------------------- SECONDARY BLUE/MONO VIDEO
                    8 -------------------------------- HORIZ RETRACE
                    9 -------------------------------- VERT RETRACE

                  VIDEO GRAPHICS ARRAY (VGA) HDD-15 CONNECTOR
            HDD-15 PIN female                          SIGNAL

  HDD 15 MALE CONN  1 -------------------------------- RED           HDD 15 FEMALE CONN
   1       5        2 -------------------------------- GREEN            5       1
   o o o o o        3 -------------------------------- BLUE             o o o o o
  6 o o o o o 10    4 ------------------------- MONITOR ID BIT 2      10 o o o o o 6
   o o o o o        5 -------------------------------- DIGITAL GND      o o o o o 
   11      15       6 --------------------------- RED ANALOG GND        15      11
                    7 --------------------------- GREEN ANALOG GND
                    8 --------------------------- BLUE ANALOG GND
                    9 ------------------------------ not used
                    10 -----------------------------SYNC RETURN (GND)
                    11 ------------------------ MONITOR ID BIT 0 (not usually used)
                    12 ------------------------ MONITOR ID BIT 1 (not usually used)
                    13 ----------------------------- HORIZ SYNC
                    14 ----------------------------- VERT  SYNC
                    15 ----------------------------- not used

               WORKSTATION VIDEO GRAPHICS DB13W3 CONNECTOR
              DB13W3 female                      COLOR SIGNAL

  DB13W3 MALE CONN  1 -------------------------------- N/C              DB13W3 FEMALE CONN
    1       5       2 -------------------------------- N/C                 5       1
    o o o o o       3 -------------------------------- SENSE2              o o o o o
@  o o o o o  @  @  4 ------------------------- -------SRTN           @ @   o o o o o  @ 
A1 6      10  A2 A3 5 -------------------------------- CSYNC         A3 A2  10      6  A1
                    6 -------------------------------- N/C        
                    7 -------------------------------- N/C
                    8 -------------------------------- SENSE1
                    9 -------------------------------- SENS0
                    10 ------------------------------- CRTN
                    A1 ------------------------------- RED
                    A2 ------------------------------- GREEN
                    A3 ------------------------------- BLUE
                    
              DB13W3 female                GREYSCALE (MONO) SIGNAL

                    1 -------------------------------- N/C
                    2 -------------------------------- N/C
                    3 -------------------------------- SENSE2
                    4 -------------------------------- SRTN
                    5 -------------------------------- CSYNC
                    6 -------------------------------- N/C        
                    7 -------------------------------- N/C
                    8 -------------------------------- SENSE1
                    9 -------------------------------- SENS0
                    10 ------------------------------- CRTN
                    A1 ------------------------------- N/C
                    A2 ------------------------------- GREEN
                    A3 ------------------------------- N/C

NOTE!! Most workstation monitors using DB13W3 connectors are FIXED FREQUENCY or are 
       sync on green monitors and cannot be used as standard VGA monitors on a PC
       without a special GRFX card to match the horiz/vert frequency requirements
       of the monitor. 

               COLOR GRAPHICS ADAPTER (CGA) VIDEO CONNECTOR DB-9
            DB-9 PIN Female                            SIGNAL

                    1 --------------------------------- GND
                    2 --------------------------------- GND
                    3 --------------------------------- RED
                    4 --------------------------------- GREEN
                    5 --------------------------------- BLUE
                    6 ------------------------------- INTENSITY
                    7 -------------------------------- not used
                    8 ------------------------------ HORIZ SYNC
                    9 ------------------------------ VERT SYNC

                            MONOCHROME ADAPTOR DB-9
            DB-9 PIN Female                            SIGNAL

                    1 --------------------------------- GND
                    2 --------------------------------- GND
                    3 ------------------------------- not used
                    4 ------------------------------- not used
                    5 ------------------------------- not used
                    6 ----------------------------- +INTENSITY
                    7 ------------------------------- +VIDEO
                    8 ------------------------------ +HORIZ SYNC
                    9 ------------------------------- -VERT SYNC
                                       
                       PARALLEL PRINTER CONNECTOR DB-25
              DB-25 PIN (Female)                       SIGNAL

  DB-25 MALE CONN   1 ------------------------------- > STROBE *      DB-25 FEMALE CONN
  1           13    2 ------------------------------- > DATA 0        13           1
  ooooooooooooo     3 ------------------------------- > DATA 1         ooooooooooooo
   ooooooooooo      4 ------------------------------- > DATA 2          ooooooooooo
  14         25     5 ------------------------------- > DATA 3         25         14
                    6 ------------------------------- > DATA 4
                    7 ------------------------------- > DATA 5
                    8 ------------------------------- > DATA 6
                    9 ------------------------------- > DATA 7
                    10< ------------------------------ ACK *
                    11< ------------------------------ BUSY
                    12< ------------------------------ PAPER END
                    13  ------------------------------ SLCT (select)
                    14  ------------------------------ >AUTOFEED *
                    15< ------------------------------ ERROR *
                    16 --------------------------->INITIALIZE PRINTER *
                    17 ------------------------------- SLCTIN (select in)
                    18 thru 25 ----------------------- GND
                    Note!!  * denotes an active low signal.
                              
               DB-25 MALE PARALLEL LOOPBACK CONNECTOR WIRING
               1 to 13     Strobe to select
               2 to 15     Data o to ERROR
               10 to 16    ACK to INIT
               11 to 17    BUSY to SLCTIN
               12 to 14    PAPER END to AUTOFEED
                                       
                                  SERIAL I/O PIN OUTS

                  RS-232 SERIAL (COM) PC PORT CONNECTOR DB-9
  DB-9 PIN (Male)                             FUNCTION       ABBREVIATION

          1 --------------------------- Data Carrier Detect   CD or DCD
          2 ------------------------------ Receive Data        RD or RX
          3 ---------------------------- Transmitted Data      TX or TD
          4 ---------------------------- Data Terminal Ready     DTR
          5 ------------------------------ Signal Ground         GND
          6 ------------------------------ Data Set Ready        DSR
          7 ------------------------------ Request To Send       RTS
          8 ------------------------------ Clear To Send         CTS
          9 ------------------------------ Ring Indicator         RI
          Transmitted and receive data are referenced from the data device and
          not the modem.

                  RS-232 SERIAL (COM) PC PORT CONNECTOR DB-25
  DB-25 PIN (Male)                            FUNCTION       ABBREVIATION

         1 ---------------------------- Chassis/Frame Ground      GND
         2 ------------------------------ Transmitted Data     TX or TD
         3 -------------------------------- Receive Data       RX or RD
         4 ------------------------------ Request To Send        RTS
         5 ------------------------------- Clear To Send         CTS
         6 ------------------------------- Data Set Ready        DSR
         7 ------------------------------- Signal Ground         GND
         8 ---------------------------- Data Carrier Detect   DCD or CD
         9 ------------------------- Transmit + (Current loop)   TD+
         11 ------------------------ Transmit - (Current Loop)   TD-
         18 ------------------------- Receive + (Current Loop)   RD+
         20 --------------------------- Data Terminal Ready      DTR
         22 ----------------------------- Ring Indicator         RI
         25 ------------------------- Receive - (Current Loop)   RD-
          NOTE!! Current loop technology was supported in the PC and XT interfaces.
                Current loop was discontinued when the AT interface was introduced.
                Transmitted and receive data are referenced from the data
                device and not the modem.

                        DB-25 FEMALE SERIAL LOOPBACK PLUG WIRING
                        2 to 3          Xmit to Rec data
                        4 to 5 to 22    RTS to CTS to RI
                        6 to 8 to 20    DSR to CD to DTR
                        
                        DB-9 FEMALE SERIAL LOOPBACK PLUG WIRING
                        2 to 3          Xmit to Rec data
                        7 to 8 to 9     RTS to CTS to RI
                        6 to 1 to 4     DSR to CD to DTR
     
                  SERIAL PORT LOOPBACK DIAGNOSTIC TESTING RULES 
    
     When the diagnostic asserts RTS (output) it then tests for the presence
     of CTS and Ring Indicator (input).  If CTS and RI are detected the RTS driver and
     CTS/RI receivers are considered operational.  When DTR is asserted (output) the
     diagnostic tests for the presence of CD and DSR (input).  If CD/DSR are detected
     the DTR driver and CD/DSR receivers are considered operational.  Data is Xmitted
     and received on the data lines and the data is compared in the diagnostic buffer.
     If any status's are not detected an error message is displayed.    

                  RS-232 SERIAL DB-9 to RS-232 DB-25 ADAPTOR
           DB-9 PIN (Female)                        DB-25 PIN (Male)

                    1 ------------------------------------- 8    DCD
                    2 ------------------------------------- 3    TXD
                    3 ------------------------------------- 2    RXD
                    4 ------------------------------------- 20   DTR
                    5 ------------------------------------- 7    GND
                    6 ------------------------------------- 6    DSR
                    7 ------------------------------------- 4    RTS
                    8 ------------------------------------- 5    CTS
                    9 ------------------------------------- 22   RI
                 Use this pin out to adapt between the two serial connector
                 types.

                 RS-232 SERIAL DB-25 to DB-25 NULL MODEM CABLE
                DB-25 PIN (Female) PC                   DB-25 PIN (Female) PC

                    2 ------------------------------------- 3
                    3 ------------------------------------- 2
                    7 ------------------------------------- 7
                    4 ------------------------------------- 5
                    5 ------------------------------------- 4
                    6 ------------------------------------- 20
                    20 ------------------------------------ 6
     Note!!    All other pins are unused.  Use this cable pinout for direct
               connection between two IBM compatible computers.  (LAPLINK)

            RS-232 SERIAL DB-25 to SERIAL PRINTER NULL MODEM CABLE
   DB-9 Female PC DB-25 PIN Female PC                     DB-25 PIN Male printer

   2 < RD --------- 3 <------------------------------------- 2 Transmitted data
   3 > TD --------->2 -------------------------------------> 3  Receive data
   5 < GND -------- 7 <------------------------------------> 7  Ground
   8 < CTS -------- 5 ------------------------------------ 6 to 8 to 20
 1 to 4 to 6    6 to 8 to 20                               4 to 5 
 DTR/DSR/DCD    DTR/DSR/DCD                              RTS to CTS

          Note!! Use this cable pinout for direct connection between a PC
                 serial port and a serial printer.  The 1/4/6 and 6/8/20
                 loopbacks are to enable the interface as if a modem was attached.


                 Win95/98 Direct Cable Connection Interlink Cable (Serial port)
  
                 DB-9---DB-25 (Female)                    DB-25---DB-9 (Female)

                   5      7 <------------------------------> 7      5 Gnd-Gnd
                   3      2 <------------------------------> 3      2 Xmit-Recv data
                   7      4 <------------------------------> 5      8 RTS-CTS
                  1&6     6 <------------------------------> 20     4 DSR-DTR
                   2      3 <------------------------------> 2      3 Recv-Xmit data
                   8      5 <------------------------------> 4      7 CTS-RTS
                   4      20<------------------------------> 6     1&6 DTR-DSR

            Win95/98 Direct Cable Connection Interlink Cable Parallel port (4 bit)

                 DB-25(Male)                              DB-25(Male)

                   2    <------------------------------>    15   N/A
                   3    <------------------------------>    13   N/A
                   4    <------------------------------>    12   N/A
                   5    <------------------------------>    10   N/A
                   6    <------------------------------>    11   N/A
                   15   <------------------------------>    2    N/A
                   13   <------------------------------>    3    N/A
                   12   <------------------------------>    4    N/A
                   10   <------------------------------>    5    N/A
                   11   <------------------------------>    6    N/A
                   25   <------------------------------>    25   Ground-Ground
                      

                ECP Direct Cable Connection (8 bit) Untested, For the experts only!
                This pinout was listed for testing two parallel ports and is thought
                to be correct for running two computers via ECP Direct Cable Connection.
                     DB-25 Male                            DB-25 Male
        
               nStrobe 1 <---------------------------------> 10 nACK
               Data 0  2 <---------------------------------> 2  Data 0
               Data 1  3 <---------------------------------> 3  Data 1
               Data 2  4 <---------------------------------> 4  Data 2
               Data 3  5 <---------------------------------> 5  Data 3
               Data 4  6 <---------------------------------> 6  Data 4
               Data 5  7 <---------------------------------> 7  Data 5
               Data 6  8 <---------------------------------> 8  Data 6
               Data 7  9 <---------------------------------> 9  Data 7
               nACK   10 <---------------------------------> 1  nStrobe
               Busy   11 <---------------------------------> 14 nAutoFwd
               PError 12 <---------------------------------> 16 nInit
               Select 13 <---------------------------------> 13,17 Select, nSelectIn
               nFault 14 <---------------------------------> 17 nSelectIn
             nAutofwd 15 <---------------------------------> 11 Busy
               nInit  16 <---------------------------------> 12 PError
            nSelectIn 17 <---------------------------------> 15 nFault
               Gnd    18-25 <------------------------------> 18-25 Gnd
                       
               STANDARD CENTRONICS PARALLEL CABLE DB-25 TO CENTRONICS 36
                 DB-25 PIN Male (PC)                     Centronics 36 Male

  CENTRONICS 36 MALE   1 --------------------------------------> 1  Strobe *       CENTRONICS 36 FEMALE
  1  CONNECTOR    18   2 <-------------------------------------> 2  Data bit 0 +    18  CONNECTOR    1
\ ------------------ / 3 <-------------------------------------> 3  Data bit 1 +   \ ------------------ /
 \------------------/  4 <-------------------------------------> 4  Data bit 2 +    \------------------/
  19              36   5 <-------------------------------------> 5  Data bit 3 +     36              19
                       6 <-------------------------------------> 6  Data bit 4+
                       7 <-------------------------------------> 7  Data bit 5 +
                       8 <-------------------------------------> 8  Data bit 6 +
                       9 <-------------------------------------> 9  Data bit 7 +
                       10 <------------------------------------- 10 Acknowledge *
                       11 <------------------------------------- 11 Busy +
                       12 <------------------------------------- 12 Paper out +
                       13 <------------------------------------- 13 Select (in) *
                       14 -------------------------------------> 14  Auto Feed *
                       15 <------------------------------------- 32 Error *
                       16 -------------------------------------> 31  Initialize printer *
                       17 -------------------------------------> 36  Select (out) *
                       18 thru 25 Gnd                    16, 19 thru 30, 33  Ground
                                                  15, 17, 18, 34, 35  No connection

     Note!! * denotes and active low signal.  This pin out depicts the newer bi-directional parallel
              port with input and output capabilities often used with external tape drives and
              accessory devices. If pins 31 or 32 are grounded on a cable the printer will fail to
              come ready when attached to the PC.  This is common on low cost parallel printer cables.
		
                                 MIDI 5 PIN DIN IN AND OUT CONNECTORS

                               MIDI In                        MIDI Out
                                pin     Signal                 pin     Signal

                                 1       N/C                    1       N/C
                                 2       N/C                    2       GND
                                 3       N/C                    3       N/C
                                 4       Current Src            4       Current Sink
                                 5       Current Sink           5       Current Src

                                          IR Module Connector
                                Pin                            Signal
                                 1 ----------------------------- IRTX
                                 2 ----------------------------- GND
                                 3 ----------------------------- IRRX
                                 4 ----------------------------- N/C
                                 5 ----------------------------- Vcc

                                          USB Cable Connector
                                Pin                             Signal
                                 A1 ------------------------------ Vcc
                                 A2 ------------------------------ Port0 data-
                                 A3 ------------------------------ Port0 data+
                                 A4 ------------------------------ Gnd
                                 B1 ------------------------------ Vcc
                                 B2 ------------------------------ Port1 data-
                                 B3 ------------------------------ Port1 data+
                                 B4 ------------------------------ Gnd

                            10baseT and 100baseTX crossover cable diagram
                          For direct connection from NIC to NIC with no hub
                            RJ45 Pin#                           RJ45 pin#

                              TD+ 1 <-----------------------------> 3 RD+
                              TD- 2 <-----------------------------> 6 RD-
                              RD+ 3 <-----------------------------> 1 TD+
                              RD- 6 <-----------------------------> 2 TD-

                     The receive data pair (the two wires designated RD) must be a twisted       
                     pair, and the transmit data pair (designated TD) must be a twisted pair.
                     When using 10 Megabit (10baseT), category 3, 4 or 5 cable may be
                     used. When using 100 Megabit (100baseTX), the cable must be category 5.

                                  100baseT4 crossover cable diagram 
                         For direct connection from NIC to NIC with no hub
                             RJ45 pin#                            RJ45 pin#
                      
                           TX_D1+ 1 <--------------------------> RX_D2+ 3
                           TX_D1- 2 <--------------------------> RX_D2- 6
                           RX_D2+ 3 <--------------------------> TX_D1+ 1
                           BI_D3+ 4 <--------------------------> BI_D4+ 7
                           BI_D3- 5 <--------------------------> BI_D4- 8
                           RX_D2- 6 <--------------------------> TX_D1- 2
                           BI_D4+ 7 <--------------------------> BI_D3+ 4
                           BI_D4- 8 <--------------------------> BI_D3- 5

                     The receive data pair (the two wires designated RX_D2) must be a
                     twisted pair, the transmit data pair (designated TX_D1) must be a twisted
                     pair, the first bi-directional pair (designated BI_D3) must be a twisted pair
                     and the second bi-directional pair (designated BI_D4) must be a twisted
                     pair. Category 3, 4 or 5 cable may be used.  
                          
            Note: These are not IEEE supported configurations and as such, these pinouts 
            are only supported for test purposes. (they do work in practice)

 ..............................................................................


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.dcom.modems
Path: utkcs2!darwin.sura.net!mips!zaphod.mps.ohio-state.edu!rpi
      !newsserver.pixel.kodak.com!laidbak!tellab5!vpnet!serveme!n5ial!jim
Distribution: world
Message-ID: <712027154snx@n5ial.chi.il.us>
References: <uD4DoB4w164w@zswamp.UUCP>
Date: Sat, 25 Jul 1992 01:19:14 GMT
Organization: Me? Organized? Hah! :-)
From: jim@n5ial.chi.il.us (Jim Graham)
Subject: Help on upgrade to 16550A UART

I wrote:

>> of course, good
>> luck getting UART identifying software to know the difference....from
>> the programs I've seen, a visual of the chip is the only truly reliable
>> way to know what you've got.

geoff@zswamp.UUCP writes:

>    To the contrary, in my experience... there are chips labelled
> "8250" which are functionally identical to the 16450 (including such
> trivia as the scratch register).  I suspect - but have no proof - that
> NS doesn't make 'real' 8250s anymore, but ships 16450s labelled 8250
> because that's what people order.

8250?  or 8250A?  in the post where I listed the different types, I
did mention the 8250A, which was grouped right in with the 16450.  on
the other hand, you may well have a point --- NS might very well have
improved on the 8250 design in recent years, and either not announced
it as such, or perhaps, it didn't make the publication date for the
specs I've got (which was 1990, and shipped to me in the last 6 months
from NS themselves).

interesting question --- who's right?  beats me....  but then, I'm sold
on the 16550 these days, so to me, it's purely an academic question
(still, very interesting!).

and now to get on with the other followup.....

In article <uD4DoB4w164w@zswamp.UUCP> geoff@zswamp.UUCP writes:

> jim@n5ial.chi.il.us (Jim Graham) writes:
>
> > first, the old 8250 UART I once had installed most certainly refused to
> > be programmed higher than 9600 bps.
>
>    I don't get it.  You mean to say that it refused to register divider
> values that would result in speeds higher than 9600 bps?  How long ago
> was that?

the chip was in a serial board I bought around, oh, 1986 or so.  don't
know how old the board and chip were at the time....  and yes, it flatly
refused to be programmed higher than 9600 bps.

> > NS16550AF:                            DC to 256k      page 4-36
>
>    That last figure must be with a non-standard crystal, right?

well, let's see (now pulling out the NS data sheets again...hang on)....

yuck....3 different tables....if anyone's interested, I'll type up the
tables.  otherwise, I'll only hit a couple of entries from each (the
top 2 speeds).

All tables are from NS data sheets on NS16550AF, pages 4-50 to 4-51:

Table III. Baud Rates Using 1.8432 MHz Crystal
           |   Decimal Divisor
Desired    |   Used to Generate
Baud Rate  |   16 x Clock
-----------|----------------------
38400      |  3
56000      |  2


Table IV. Baud Rates Using 3.072 MHz Crystal
           |   Decimal Divisor
Desired    |   Used to Generate
Baud Rate  |   16 x Clock
-----------|----------------------
19200      |  10
38400      |  5


Table V. Baud Rates Using 8 MHz Crystal
           |   Decimal Divisor
Desired    |   Used to Generate
Baud Rate  |   16 x Clock
-----------|----------------------
128000     |  4          [42?  The Answer?  hmmm...the speed before
256000     |  2           128 was 56 kb, which is 6*9....perhaps NS
                          has some Hitchhiker's fans?  :-)     ]

is this helpful?
   --jim

--
Standard disclaimer....Ever since my cat learned to type, there's no telling
whose thoughts these really are....         73 DE N5IAL (/9)
------------------------------------------------------------------------------
INTERNET:  jim@n5ial.chi.il.us  |  grahj@gagme.chi.il.us  |  j.graham@ieee.org
UUCP:  gagme!n5ial!jim@clout.chi.il.us
AMATEUR RADIO: n5ial@n9hsi (Chicago.IL.US.Earth)
------------------------------------------------------------------------------

 //////////////////////////////////////////////////////////////////////////////



Newsgroups: comp.dcom.lans.misc,comp.protocols.misc,comp.sources.wanted,
            comp.sys.misc
Path: cs.utk.edu!emory!sol.ctr.columbia.edu!usc!cs.utexas.edu!uunet!olivea
      !sgigate!sgi!rigden.wpd.sgi.com!rpw3
Message-ID: <v7kns3g@sgi.sgi.com>
Date: 23 Jan 1993 06:02:32 GMT
Sender: rpw3@rigden.wpd.sgi.com
Organization: Silicon Graphics, Inc.  Mountain View, CA
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: Multi-drop Serial Protocol Wanted (RS-232)


jdc@isis.cs.wayne.edu (Jon Cardwell) writes:
+---------------
| We're looking for sources or references for a "multi-drop serial protocol"
| i.e. one that allows multiple devices to be attached to the same serial line.
| Our goal is to have data exchanged between a host cpu and any number of
| ( well ok, 8 :) attached slave devices. ... Any help (even remote references
| from 15 years ago) would be most welcome.
+---------------

Well, 15-year-old stuff (or 20-yr-old) is indeed where you should look! ;-}

Many "ancient" serial protocols allowed multi-drop: BSC ("BiSync"), SDLC,
DDCMP, to name just a few. And the phone company provided leased lines
in multi-dropped configurations. It was quite common to have a central
location in, say, Chicago, with a multi-drop line that hit Kansas City,
Dallas, Abilene, and another one that hit Atlanta, Jacksonville, Miami, &c.

As far back as 1973 or -4, at Dig. Comm. Assoc. we were shipping statistical
multiplexers that could multi-drop off a single sync phone line (e.g., using
Bell 208 or 209 modems). That is, each multi-dropped mux could have multiple
local terminals, all running to the same host via a "head end" mux. The muxes
used our own implementation of DEC's DDCMP as the link-layer protocol (as
we'd call it today), but if I did it again today, I'd probably use HDLC (only
because so few current programmers are familiar with DDCMP, which is really
quite nice).

-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043


 ..............................................................................


Newsgroups: comp.dcom.lans.misc,comp.protocols.misc,comp.sources.wanted,
            comp.sys.misc
Path: cs.utk.edu!gatech!usenet.ins.cwru.edu!agate!spool.mu.edu!uunet!rosevax
      !texan!bill
Message-ID: <1993Jan24.181433.26225@rosevax.rosemount.com>
Sender: news@rosevax.rosemount.com (USENET News administrator)
Nntp-Posting-Host: texan
Organization: Rosemount, Inc. Mpls, MN
References: <v7kns3g@sgi.sgi.com>
Date: Sun, 24 Jan 1993 18:14:33 GMT
From: bill@texan.rosemount.com (William Hawkins)
Subject: Re: Multi-drop Serial Protocol Wanted (RS-232)


>jdc@isis.cs.wayne.edu (Jon Cardwell) writes:
>+---------------
>| We're looking for sources or references for a "multi-drop serial protocol"
>| i.e. one that allows multiple devices to be attached to the same serial line.

RS-232 is not a multi-drop protocol *electrically* because it holds
the line at the mark (or space) state.  You need the RS-485 protocol
to multi-drop devices, because it lets the line float if a device
has nothing to say.  There are 232 to 485 converters available (or
there were 7 years ago).  Then you can implement a master-slave
software protocol for the universe of devices attached to the line.

In ISO terms, RS-232/485 is barely a physical layer specification.
You get to do anything you want with the rest of the layers.

Bill Hawkins

 ..............................................................................

Newsgroups: comp.dcom.lans.misc,comp.protocols.misc,comp.sources.wanted,
            comp.sys.misc
Path: cs.utk.edu!emory!swrinde!sdd.hp.com!spool.mu.edu!olivea!sgigate!odin
      !twilight!zola!anchor!olson
Message-ID: <v9rgooc@zola.esd.sgi.com>
References: <v7kns3g@sgi.sgi.com><1993Jan24.181433.26225@rosevax.rosemount.com>
Sender: news@zola.esd.sgi.com (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: 24 Jan 1993 22:18:25 GMT
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: Multi-drop Serial Protocol Wanted (RS-232)


In <1993Jan24.181433.26225@rosevax.rosemount.com>,
 bill@texan.rosemount.com (William Hawkins) writes:

| >jdc@isis.cs.wayne.edu (Jon Cardwell) writes:
| >+---------------
| >| We're looking for sources or references for a "multi-drop serial protocol"
| >| i.e. one that allows multiple devices to be attached to the same serial
| >| line.
| 
| RS-232 is not a multi-drop protocol *electrically* because it holds
| the line at the mark (or space) state.  You need the RS-485 protocol
| to multi-drop devices, because it lets the line float if a device
| has nothing to say.  There are 232 to 485 converters available (or
| there were 7 years ago).  Then you can implement a master-slave
| software protocol for the universe of devices attached to the line.
| 
| In ISO terms, RS-232/485 is barely a physical layer specification.
| You get to do anything you want with the rest of the layers.


Wyse makes (made?) both 485 terminals, and 485 drops to rs232 protocol
boxes (2 and 8 232 ports per box).  I don't remember if they ever made
the controller boards.  This was done about 5 years back, originally as
a joint project with Altos.  I did a lot of the driver work, and it
worked pretty well (we ran 64 terminals at full speed both directions
off a 286 box).  As I recall, the datarate was about 1.4 Mbits/sec on
the multidrop wire. 

-- 
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com

 ..............................................................................


Newsgroups: comp.dcom.lans.misc,comp.protocols.misc,comp.sources.wanted,
            comp.sys.misc
Path: cs.utk.edu!gatech!swrinde!zaphod.mps.ohio-state.edu!uunet.ca!seachg!burke
Message-ID: <1993Jan28.142838.26423@seachg.uucp>
Organization: Sea Change Corporation, Mississauga, Ontario, Canada
References: <v7kns3g@sgi.sgi.com><1993Jan24.181433.26225@rosevax.rosemount.com>
Date: Thu, 28 Jan 93 14:28:38 GMT
From: burke@seachg.uucp (Michael Burke)
Subject: Re: Multi-drop Serial Protocol Wanted (RS-232)


In article <1993Jan24.181433.26225@rosevax.rosemount.com>,
 bill@texan.rosemount.com (William Hawkins) writes:
>>
>>jdc@isis.cs.wayne.edu (Jon Cardwell) writes:
>>+---------------
>>| We're looking for sources or references for a "multi-drop serial protocol"
>>| i.e. one that allows multiple devices to be attached to the same serial
>>| line.
>
>RS-232 is not a multi-drop protocol *electrically* because it holds
>the line at the mark (or space) state.  

Hogwash...

RS232 has been used for years with BSC 3270 multi-drop circuits. Generally,
the trick is to use the fastest modem turn around time possible to get best
results. The "poll-ack" protocols are above this physical standard.

Remember, multi-drop does not mean a "bus architecture" in the strictest
sense. One orders a multi-drop circuit from the Telco. I have not been
involved with BSC 3270 circuits for many years (about 15) so I have no idea
how one would go about building an in-house multi-drop circuit....

-- 
Michael Burke

Sea Change Corporation
6695 Millcreek Drive, Unit 8 
Mississauga, Ontario, Canada L5N 5R8
Tel: 416-542-9484  Fax: 416-542-9479
UUCP: ...!uunet!uunet.ca!seachg!burke

 ..............................................................................


Newsgroups: comp.dcom.lans.misc,comp.protocols.misc,comp.sources.wanted,
            comp.sys.misc
Path: cs.utk.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!sdd.hp.com
      !network.ucsd.edu!ucsbcsl!spectrum.CMC.COM!fennel.acc.com!art
Message-ID: <1993Jan29.182524.20570@acc.com>
Date: 29 Jan 93 18:25:24 GMT
References: <v7kns3g@sgi.sgi.com> <1993Jan24.181433.26225@rosevax.rosemount.com> <1993Jan28.142838.26423@seachg.uucp>
Organization: ACC, Advanced Computer Communications
From: art@acc.com (Art Berggreen)
Subject: Re: Multi-drop Serial Protocol Wanted (RS-232)


In article <1993Jan28.142838.26423@seachg.uucp>,
 burke@seachg.UUCP (Michael Burke) writes:
>
>In article <1993Jan24.181433.26225@rosevax.rosemount.com>,
>  bill@texan.rosemount.com (William Hawkins) writes:
>>
>>RS-232 is not a multi-drop protocol *electrically* because it holds
>>the line at the mark (or space) state.  
>
>Hogwash...
>
>RS232 has been used for years with BSC 3270 multi-drop circuits. Generally,
>the trick is to use the fastest modem turn around time possible to get best
>results. The "poll-ack" protocols are above this physical standard.
>
>Remember, multi-drop does not mean a "bus architecture" in the strictest
>sense. One orders a multi-drop circuit from the Telco. I have not been
>involved with BSC 3270 circuits for many years (about 15) so I have no idea
>how one would go about building an in-house multi-drop circuit....


Typical multi-drop modems use the modem control leads to arbitrate access
to the communications channel.  When a node wishes to transmit, it
raises RTS (Request-to-send) and the modem contends for the channel.
When the modem acquires the channel, it asserts CTS (Clear-to-Send) to
let the equiptment begin transmission.  Because there may be times when
there are no valid transmissions on the communication channel, the
modem asserts CD (Carrier-Detect) to indicate to the equiptment when
it should try to receive data.

If one were going to build a bus interconnection using RS-232 or other
electrical standard, one needs to insure that only one device is driving
the bus at one time.  This might be done in the device, or in an
external device emulating what multi-drop modems do.

Art

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!gatech!howland.reston.ans.net!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!teal.csn.org!rjn
Message-ID: <C4EqD5.HI@csn.org>
Sender: news@csn.org (news)
Nntp-Posting-Host: teal.csn.org
Organization: Colorado SuperNet, Inc.
X-Newsreader: Tin 1.1 PL4
References: <1oplmpINNp49@escargot.xx.rmit.OZ.AU>
Date: Wed, 24 Mar 1993 19:05:27 GMT
From: rjn@teal.csn.org (Robert J. Niland)
Subject: Re: 16550 buffer and hi speed modems

s923257@minyos.xx.rmit.OZ.AU (Ming Ean Chew) writes:

: but what has the 16550 chip have to do with high speed modems? 
: 14.4k bps??   Are there any advantages in having it?

Here's the latest revised: "FAQ: Ns16550AFN & TurboCOM"

re: What to do after the high speed modem arrives.       Edition 24 Mar 1993 

One of the unadvertised limitations of most current Windows PCs is that
their RS-232C (serial, COM) performance is seriously deficient.  Almost
everyone who purchases a high-speed modem (V.32bis, V.32, PEP or HST)
discovers the problem the first time they try to download a file after
upgrading the modem.  Overrun and retry errors abound, even when the only
active application is your datacomm program.  If the transfer completes
at all, it may take even longer than with the old V.22bis 2400bps modem.


There are three reasons for the problem:

1. The Universal Asynchronous Receiver/Transmitters (UARTs) used in most
   PCs are primitive Ns8250 UARTs with single-byte FIFO buffers and no
   on-board hardware CTS/RTS flow control.  If the operating system/driver
   cannot read and flush each character at high interrupt rates, the next
   incoming character overwrites the FIFO and the previous one is lost.
   DOS, being a fairly single-minded environment during datacomm, can
   usually keep up. Windows can't.

2. Windows has more operating system overhead than plain DOS, and
   interrupts often take longer to service.  Overruns are much more likely 
   than under DOS.  As soon as you report to your PC/modem vendor that you
   are losing data, you may be advised that "you need to upgrade to a
   16550". More likely, since there seems to be a conspiracy of ignorance
   about this issue,  you'll get no useful advice at all.  Most of the
   store-front and mail-order sources I spoke with attempting to solve my
   own problem had never heard the term "16550" and many didn't even know
   what a UART was.

3. Even your PC has Ns16550A UARTs (and PS/2's do), or if you can upgrade
   your mother/COM board or add a new COM board, you may STILL experience
   errors and overruns because the standard MicroSoft Windows COM drivers
   don't take full advantage of the 16550.  Windows 3.1 is improved in this
   regard over 3.0, but I still recommend a driver upgrade.  Applications
   like ProComm+/Win (which is what I use) cannot get around this problem
   by themselves.

If you have a modem CARD, you may not have a problem, as the modem part of
the card can be designed to be aware of the state of the UART, and avoid
overrunning it; however, I wouldn't want to bet that the card designers
were that clever, and will insist on a 16550 UART if I ever buy a modem
card.


The Hardware Situation.

The UARTs on most PC COM ports are based on National Semiconductor Ns8250
or Ns16450 chips (or megacells inside VLSI chips where you can't replace
them).  You can ID the UART type on your system by running the MicroSoft
diagnostic program \WINDOWS\MSD.EXE.  Be sure to run it in DOS *before*
bringing up Windows.   The Windows serial API may prevent MSD from
accurately identifying a 16550 if you run it from a Windows DOS prompt.

The Ns16550 UART has 16-byte transmit and receive FIFOs with configurable
trigger levels, and can do CTS/RTS flow control on-chip (so the FIFOs don't
fill up while the host has to respond to an interrupt to drop RTS).  The
16550 can also run reliably at clock rates over 400K bps.

Try to locate the UART on your mother board, multi-function I/O card, COM
board or ISA/MCA modem card.  If you can't find a socketed component with
the numbers "8250" or "16450", your COM ports are probably buried in VLSI,
and you won't be able to perform a chip replacement.  If you can DISABLE
your VLSI COM ports (as I had to do), you can at least add an aftermarket
COM board.

If you have one or more socketed 8250 or 16450 chips, you can buy plug-in
Ns16550AFN or PC16C550CN (low power CMOS version) ICs from several
suppliers typically for about $15 each.  The "N" chip is the normal
dual-in-line package.  Other styles are available, but avoid any Ns16550
chips without the "A" (the 16C550C are presumably all OK).

Early Ns chips have bugs, although National will reportedly exchange those 
of their own manufacture for free.  Clone chips are available from various
IC makers other than National, and some of these may have problems, with
the possible exception of those from TI and Silicon Systems.  I will
incorporate any responses along those lines in future versions of this FAQ.

If you DON'T have socketed 8250/16450 chips, you'll need to buy an after-
market COM or multi-function board. If this is a modem card situation, you
may be hosed. To add a new COM or multi-function card, you'll need to
either disable the COM1/2 port(s) you are replacing, or re-assign them to
COM3/4 (although watch out for IRQ conflicts without TurboCOM).

Although cheaper cards are available, in the interest of getting the
problem solved quickly I elected buy the Modular Circuit Technology
MCT-AIO+ card from:

JDR Microdevices
2233 Samaritan Drive
San Jose  CA  95124
(800) 538-5000 voice US
(408) 559-1200 voice other
(800) 538-5005 FAX US

The MCT-AIO+ (and the "+" is important) sells for $89.95.  It is an 8-bit
ISA card providing:

Port Type  Connector  Address and IRQ        Comments
COM        DB9M       COM 1,2,3 IRQ 2,3,4,5  Ns16550AFN in socket
COM        ribbon     COM 2,3,4 IRQ 2,3,4,5  Ns16550AFN in socket
Parallel   DB25F      LPT1,2,3  IRQ 5,7
Game       ribbon

The kit includes a ribbon cable and DB25F connector for the secondary COM
port, a ribbon cable/connector for the game port, two bulkhead plates for
the ribbon-based connectors and a 9F-to-25F adaptor cable.  Each port can
be individually disabled, and the COM ports have TX, RX, RTS, CTS, DTR,
DCD, and DSR jumpers.

JDR also sells a Super-I/O m-f card that also has IDE.

I have since heard from several people about less expensive m-f I/O cards
with 16550s:

TSD Systems
(407) 331-9130
$19.95 plus $9.95 per 16550.

Greenfield Trading and Distributors
(518) 271-2473 (voice), (518) 271-7811(FAX).
Their card is $33 w/one 16550, $45 w/2, and they sell 16550AFNs for $13.

R&S DATA SYSTEMS, INC.
820 East Highway 434
Longwood, FL  32750
PHONE: (407) 331-1424
FAX: (407) 331-8606
2COM/LPT/Game card w/2 16550s for $39

I have no personal experience with any of these firms.

Meanwhile, back at the MCT card from JDR... I only needed two serial ports,
and am running out of IRQs, so I disabled my built-in VLSI 8250 ports.
However, with the TurboCOM driver (below), I could have set the internals
as COM3 and 4, using IRQ sharing.


The Software Situation

Simply upgrading to 16550 UARTs will not completely solve common overrun
problems.  The standard MS serial drivers don't take full advantage of the
16550. The Windows 3.0 drivers are even less capable, and the Windows 3.1
drivers have the following limitations:
 - They enable only the receive FIFO, and not the transmit FIFO, which
   results in higher system overhead during uploads.
 - They set the trigger level at 12 bytes (too high - it's easy for 4
   more bytes to arrive before the driver can read the FIFO).
 - They limit max bps to 38,400 (19,200 in 3.0). With a V.32bis modem,
   sparse data and text can easily compress 3:1 or more, suggesting
   that a host DTE connect rate of 57,600 bps would be effective.
 - The API won't let DOS programs know there is a 16550 there.
 - The BIOS doesn't initialize COM3,4 properly in many systems.
 - They don't allow IRQ sharing for COM3,4.
 - They may not enable on-chip CTS/RTS flow control in the UART.

These problems are reportedly NOT solved in Windows NT or DOS 6.0, and may
or may not be addressed in any Windows releases after 3.1 (but before 4.0).
Rumors suggest they "may" be solved in Windows "4.0".

You can get replacement drivers that solve all of those problems by buying
a copy of "TurboCOM", current version 1.2, from:

Bio-Engineering Research
180 Beacon Hill Lane
Ashland  OR   97520
(503) 482-2744

Price was around $50 as I recall.  Bio-Eng is not set up to accept credit
cards, so I had to send a check.  Egghead and 1-800-Software list TurboCOM
but as far as I know, they don't stock it.  Bio is not a software company
per se.  They apparently needed reliable hi-speed serial connections for
an in-house instrument application, wrote their own driver, discovered a
market for it, revised it to be a general purpose COM driver suite and
recently upgraded it for Windows 3.1.

I now have my host (DTE) connect rate set to 38,400 bps on all my datacomm
apps, and I am having ZERO problems with downloads. I routinely see transfer
rates that exceed 2,000 bps.  Uploads are another matter, because many hosts
are still using antique UARTs and drivers.

Note that 38400 is still the highest rate that Windows 3.1 will allow in
configuring a COM port.  TurboCOM gets around this by allowing you to
specify, on each port, a factor that will set the real UART rate to a
multiple of the rate passed through by Windows.

I also have CTS/RTS hardware flow control enabled, and I suggest that you
do the same.  Even if you only ever transfer 7-bit ASCII data, Xon/XOff is
not a sufficiently reliable method of flow control.  The informal (DEC)
standard for Xon/Xoff hysteresis is that the sender may transmit another
16 (yes, sixteen) bytes after receipt of the Xoff from the receiving
system or device.  The 16 byte FIFO in the 16550 is clearly not big enough
to let us rely exclusively on Xon/Xoff.

Even with hardware flow control, a 16550 with TurboCOM can still
experience overruns in very busy systems, with lots of apps running and
serious swapping in progress. If this is your situation, you may need to
buy a co-processed COM board, but this will cost you more than a
16550/TurboCOM upgrade.  A review of two such boards, and a review of
TurboCOM, can be found in the Feb'93 issue of "Windows Sources" magazine.


Closing Soapbox Comments

The state of RS-232C serial datacomm support is an embarrassment across
the computer industry.  Because it is the oldest standard I/O interface,
the job of designing hardware and writing software often seems to be
assigned to the least senior or lowest ranked engineers at computer
companies.  The design of the average serial port is at least ten years
behind the state of the art.

You may as well learn what you can about serial I/O, because this situation
shows no sign of improving soon.  When V.FAST arrives, I expect cries of
outrage from Windows users world-wide whose 8250 PCs "sort of" work today
with V.32, but will fail miserably with V.FAST.  Without a hardware-buffered
UART (like the 16550) and without software drivers that use that UART to
best advantage, a V.FAST modem will be a waste of money.

Regards,                                            1001-A East Harmony Road
Bob Niland                                          Suite 503
Internet:  rjn@csn.org                              Fort Collins CO 80525
CompuServe: 71044,2124                              (303) 223-5209

                     Copyright 1993 Robert J. Niland
                           All Rights Reserved

    Permission is granted for automatic redistribution of this article, via
    electronic, magnetic and optical media, in an unedited form, through any
    Usenet newsgroup where the article is posted by the author.  Permission
    is granted for each Usenet reader subscriber and each person who received
    this article from an ftp site authorized by the author or via electronic
    mail from the author, to retain one electronic copy and to make hardcopy
    reproductions of this edition of this article for personal non-commercial
    use, provided that no material changes are made to the article or this
    copyright statement. All other copying, storage, reproduction or
    redistribution of this article, in any form, is prohibited without the
    express written consent of the author, Robert J. Niland.

EOF


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!darwin.sura.net!haven.umd.edu!uunet!valinor.mythical.com!n5ial!jim
Message-ID: <1993Mar24.162139.2929@n5ial.mythical.com>
Date: Wed, 24 Mar 1993 16:21:39 GMT
References: <1993Mar23.170454.23272@wam.umd.edu>
Lines: 258
From: jim@n5ial.mythical.com (Jim Graham)
Subject: Re: UART 16550,  Do I really need one?

I was going to e-mail this reply, but then I read the followup to it
from bas@argon.gas.uug.arizona.edu.   this followup is, in fact, to
*BOTH* articles....

In article <1993Mar23.170454.23272@wam.umd.edu> nicknac@wam.umd.edu
writes:

>I just got a Ext. USR Sportster 14.4/V.32. I need to know is if
>I need to get a new I/O card i.e one with a UART 16550.  I have the I/O
>that came w/ a 286/12 system that I got in '89.  It has two 8250 UART 
>(1 socketed) on it.

the answer to your question is:  you might.  :-)  seriously, if you aren't
having any problems now, you may not *NEED* to upgrade....  btw, you should
be setting your serial port at 38.4 or better...keep this in mind when
deciding if you have any problems.  now, regardless of this, you'll
probably *WANT* to upgrade.

>Mainly I'll like to know three things;
>1)  Does a 16550 UART really make that much of a difference on a 386/40,
>  one modem, one serial mouse, non-multitasking system?

yes, it can make a difference.  I'd explain here, but I'll be including
some text from National Semiconductor toward the end that explains things
very nicely (taken from Application Note 491, ``The NS16550A:  UART Design
and Application Considerations'').

basically, though, because of the improved performance, you should see
an improvement in throughput (if the computer takes less time to process
the incoming data, that's less overhead, and less overhead means better
throughput).

of course, considering the fact that the 16550 only costs about $10 (US),
and since you have a socketed 8250 (read on...you need to double-check
this), you really can't go wrong.

>2)  Can someone please explain to me all the different UART chips, i.e
>  16550,16450,16550NFA...etc?
                    ^^^
that's AFN.  :-)

the following descriptions are from Application Note 493, from National
Semiconductor (``A comparison of the INS8250, NS16450 and NS16550AF Series
of UARTs''):

 ---------------------------  CUT HERE ---------------------------

1. INS8250:  This is the original version produced by National.  It is the
   same part as the INS8250-B, but with faster CPU bus timings.

2. INS8250-B:  This is the slower speed (CPU bus timing) version of the
   INS8250.  It is used by many popular 8088-based microcomputers.

3. INS8250A:  This is a revision of the INS8250 using the more advanced
   XMOS process.  The INS8250A is better than the aforementioned parts due
   to the redesign [...] and the following process characteristics---closer
   threshold voltage control, more reliably implemented process topography
   and finer control over the active area critical dimensions.  XMOS and
   CMOS parts should be used for all new designs.  This part is used in
   many popular 8086-based microcomputers.

4. NS16450:  This is the faster speed (CPU bus timing) version of the
   INS8250A.  It is used by manu popular 80286-based microcomputers.

5. NS16550AF:  This is the newest member of the UART family.  It powers-up
   in the NS16450 mode and is completely compatible with all software
   written for the 16450.  [note:  the 16450 data sheets state that the
   16450 is compatible with the 8250A.  --jdg]  It has advanced features
   such as on-board FIFOs, a DMA interface, faster CPU bus timings and a
   much higher maximum baud rate than the NS16450.  The NS16550AF should be
   used for all new non-CMOS designs, including those that were originally
   done with the NS16550.  It is used in recent versions of popular
   80286-based, 80386-based and ROMP-based microcomputers.  Software
   written for the NS16550 is completely compatible with the NS16550AF.
   [....]

6. NS16550:  This part powers-up in the NS16450 mode and is completely
   compatible with all software written for the NS16450.  It has advanced
   features, such as a DMA interface.  The on-board FIFOs are essentially
   non-functional.  This part was issued on a limited bases.  Any users
   that wants this part should order the NS16550AF.  [....]

 ---------------------------  CUT HERE ---------------------------

the part they don't mention is the NS16550A.  this chip isn't really
documented anywhere, apparently including at National Semiconductor
(unless you dig around a lot, which someone did, in fact, do for me).

when I asked about this issue, the systems engineer that I talked to
did a lot of digging, and talked with the folks who have been with the
16550 design since it was just an idea, and found a set of specs sheets
for the NS16550A.  he then compared them line-by-line, and the only
difference he found was the lack of 1 parameter in the NS16550A:  t_RXI
(that's t sub RXI), which appears on page 4-39 of the specs for the
NS16550AF (pin descriptions).  essentially, they are the same chip.

>3)  Is the above mentioned chips all 32 pin?  That is,can I just replace
>  the socketed 8250 UART w/ a 16550 UART?  

the 16550 is pin-compatible with the 8250 and 16450, but, uhh, they're
40 pin DIPs, not 32 pin.  either you mis-counted, or there is something
really odd about this so-called ``8250'' in your machine.  count the pins
again.  :-)


Then, bas@argon.gas.uug.arizona.edu (basuki a sugiarto) writes:

>sorry for my stupidity, but what is that "UART 16650"? 
>Do all the modem owners have to have that thing? 

that's 16550, not 16650 (typo?).  see the above for part of your answer.

the 16550 is God's gift (via National Semiconductor) to modem users.  if
you're running a high-speed (V.32 and up) modem, it's a chip you should
not only know about, but one you should have installed in your serial
board.

before getting into the 16550 itself, let's take care of a little
background.  as we all know, you need to set the port speed high enough to
allow for increases in throughput from both the async-to-sync conversion
provided by error control and for data compression (in the case of V.42bis,
at least).  with a V.32 or V.32bis modem using V.42/V.42bis, that means
38.4 kb or better.  the problem is, even fast computers (e.g., 386, 486,
64030, etc) can have troubles at this speed.

you see, with a regular UART (Universal Asynchronous Receiver
Transmitter), every incoming character causes the UART to issue an
interrupt to the CPU, meaning it has to stop everything, service the
interrupt (receive the character), and then go back to what it was
doing before.  all of this takes time, and at high enough speeds, it
might take too much time, meaning another character (or worse, several
characters) comes in while the last character is still being received.
the old UARTs provide a one-character FIFO (First In First Out) buffer
to ``help'' in this case, but it can only do so much good....

for the majority of the info on the 16550 itself, I'm going to quote
from National Semiconductor's Application Note 491 (AN-491, ``The
16550A:  UART Design and Application Considerations'').  the following
is copied w/o permission, but I'm assuming it's probably ok, since
they'll gladly send out data sheets for free (might be only to select
individuals, though...don't know).....


----------------------------  CUT HERE  ----------------------------
1.0 Design Considerations and Operation of the New UART Features

In order to optimize CPU/UART data transactions, the UART design takes
into consideration the following constraints:

1. The CPU is usually much faster than the UART at transferring data.
   [....]

2. There is a finite amount of wasted CPU time due to software overhead
   when stopping its current task to service the UART (context switching
   overhead).

3. The CPU may be required to complete a certain portion of its current
   task in a multitasking environment before servicing the UART.  This
   delay is the CPU latency time associated with servicing the interrupt.
   The amount of time that the receiver can accept continuous data after
   it requests service from the CPU constrains CPU latency time.

The design constraints listed above are met by adding two FIFOs and a
specialized transmitter/receiver support circuitry to the existing
NS16450 design.  The FIFOs are 16 bytes deep---one holds data for the
transmitter, the other for the receiver[....]

The NS16550A receiver optimizes the CPU/UART data transaction via the
following features:

1. The depth of the Receiver (Rx) FIFO ensures that as many as 16
   characters will be ready to transfer when the CPU services the Rx
   interrupt.  Therefore, the CPU transfer rate is effectively buffered
   from the serial data rate.

2. The program can select the number of bytes required in the Rx FIFO
   (1, 4, 8, or 14) before the UART issues an interrupt.  This allows
   the software to modify the interrupt trigger levels depending on its
   current task or loading.  It also ensures that the CPU doesn't
   continually waste time switching context for only a few characters.

3. The Rx FIFO will hold 16 bytes regardless of which trigger level the
   CPU selects.  This makes allowances for a variety of CPU latency
   times, as the FIFO continues to fill after the interrupt is issued.

[....]

SYSTEM OPERATION:  THE NS16550A VS THE NS16450

[....]

The greatest advantages of the NS16550A over the NS16450 are seen when
considering the CPU/UART interface.  Some characteristics of the
transactions occurring between the CPU and the UART were previously
cited.  However, optimizing these transactions involves two issues:

1. Decreasing the amount of time the CPU interacts with the UART.

2. Increasing the amount of data transferred between the CPU and UART
   during their interaction time.

These optimization criteria are directly opposed to each other, but
various features on the NS16550A have improved both.

One of the more obvious ways to decrease the CPU/UART interaction time
is to decrease the time it takes for the transaction to occur.  The
NS16550A has an access cycle time that is almost 25% shorter than the
NS16450.  In addition, other timing parameters were made faster to
simplify high speed CPU interactions.

The actual software required to transfer the data between the CPU and
the UART is a small percentage of that required to support this
transfer.  However, each time a transfer occurs in the NS16450, this
support software (overhead) must also be executed.  With the NS16550A
each time the UART needs service the CPU can theoretically transfer 16
bytes while only running through its overhead once.  Tests have shown
that this will increase the performance by a factor of 5 at the system
level over the NS16450.

Another time savings for the CPU is a new feature of the UART interrupt
structure.  Unlike most other UARTs with Rx FIFOs, the NS16550A will
issue an interrupt when there are characters below the interrupt trigger
level after a preset time delay.  This saves the extra time spent by the
CPU to check for bytes that are at the end of a block, but won't reach
the interrupt level.

Since the NS16550A register set is identical to the NS16450 on power-up,
all existing NS16450 software will run on it.  The FIFOs are only
enabled under program control.

[....]
----------------------------  CUT HERE  ----------------------------

ok, now you're an expert on the 16550, right?  :-)  yeah, that is a lot
of reading to do (looks so short on the page, too!), but AN-491 is very
well-written and easy to read, and I'd rather give you the text directly
from National Semiconductor than water it down myself.

oh, whatever you do, make certain that the chip you get is either the
NS16550AN or the NS16550AFN, and don't get anything but a true National
Semiconductor chip (I've heard bad things about some others).  btw, the
N in 16550AN and 16550AFN just means the chip is a DIP (40 pin DIP, to
be exact), which is almost certainly the type you'll need.

did that answer everyone's questions?  :-)  I didn't have the bits from
AN-493 typed in yet, so this was a fun post....good thing I do type fast!

e-mail if you still have questions.
   --jim

--
#include <std_disclaimer.h>                                 73 DE N5IAL (/4)
------------------------------------------------------------------------------
INTERNET: jim@n5ial.mythical.com  |  j.graham@ieee.org     ICBM: 30.23N 86.32W
AMATEUR RADIO: n5ial@w4zbb (Ft. Walton Beach, FL)          AMTOR SELCAL: NIAL
------------------------------------------------------------------------------
E-mail me for information about KAMterm (host mode for Kantronics TNCs).


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.os.rsts
Path: cs.utk.edu!gatech!rutgers!spcvxb!terry
Message-ID: <1993May30.143245.6119@spcvxb.spc.edu>
References: <1993May28.183311.6107@spcvxb.spc.edu> <C7tqr9.CLp@msage.com>
Organization: St. Peter's College, US
Date: 30 May 93 18:32:45 GMT
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Subject: Re: CTS/RTS flow control


In article <C7tqr9.CLp@msage.com>, gerry@msage.com (Gerry Duprey) writes:
> 	I'm glad you've got some source to look at and could fill us in in
> on the details.  While I'm surprised to see that RSTS does toggle the CTS
> line (I've got to look into it myself), because it doesn't support the RTS
> line, it means, effectively, that RSTS doesn't do hardware flow control
> (like if RSTS only sent XON/XOFF, but didn't do anything when receiving
> them). 

  I believe you're confused about the RS-232 nomenclature used on DEC systems.
CTS is an input which RSTS monitors, and RTS is an output which RSTS sets high
and doesn't toggle.

> 	Setting your buffers up high on V10.1 does allow you better
> throughput, but when you've got a 14.4K modem w/compression dumping at
> it, you need some kind of throttle.  Also, we've noticed that if you spit
> characters into a port at a high enough speed (>9600 from a PC), RSTS
> starts racking up terminal handler errors (after the 1st 50-60K).

  Most folks need outbound flow control (speed-buffering modems) more than
they need inbound flow control. Inbound would probably be under the control
of some sort of protocol (Kermit, XMODEM, etc.) where there is a need to
process a *limited* number of characters rapidly. In most other cases (like
PBX call logging) the data comes out in brief bursts at a slow overall rate.

  Regarding the error log events, there are a few things to consider - the
most likely culprit is a DEC DHV11 multiplexor - this board uses a pair of
Intel microcontrollers that really aren't up to the task. The second thing
is that if you are transmitting true back-to-back frames (the start bit of
frame N+1 starts in the bit time right after the stop bit for frame N, any
problem which causes the mux to lose track of which bit is the start bit
will cause lots of framing errors to be logged. Most muxes don't get 19200
right - for some reason they run at more like 19860. Over a period of time,
when using back-to-back characters, this will cause the start bit window to
slip, causing the behavior you've seen.

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!darwin.sura.net!howland.reston.ans.net!xlink.net
      !subnet.sub.net!ppcnet.ppc.sub.org!sks!mcd.ruessel.sub.org
      !mips.ruessel.sub.org!naddy
From: naddy@mips.ruessel.sub.org (Christian Weisgerber)
Message-ID: <H.eg.Rgxt&sybvnY@mips.ruessel.sub.org>
Organization: My Individual Private Site
Subject: Braindead 6551 (was: Re: DIP vs. NVRAM)
References: <288tk6$pk7@agate.berkeley.edu> <kLmRac4w165w@zswamp.UUCP>
Reply-To: naddy@mips.ruessel.sub.org
X-Software: HERMES GUS 1.10 Rev. May  3 1993
Date: Thu, 07 Oct 1993 21:46:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 21

In <kLmRac4w165w@zswamp.UUCP>, Geoffrey Welsh writes:

> > I've personally used a terminal that wouldn't transmit unless there's DSR,
> > and the modem (a cheapo brand 2400) wouldn't assert DSR until it connects.
> > I had to jumper it with a piece of wire.
> 
>    Hmm, let me guess: the terminal used a 6551 ACIA.

Possibly so, but not necessarily. Seems there are terminals out there
that require DCD/DSR/strange signals for receiving/transmitting. Choose
any combination you like.

Now, the ACIA 6551 is an especially braindead beast. It requires both
DCD and DSR, and pulling CTS low for flow control will make it stop
sending immediately, without finishing the character, resulting in a
junked character. (Not all versions of the chip have this bug. Most do.)
The Archimedes people who were struck with the 6551 usually wired DCD
and CTS to high, DSR to modem CTS, RI to modem DCD.

-- 
Christian 'naddy' Weisgerber, Germany               naddy@ruessel.sub.org


 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.dcom.modems
Path: cs.utk.edu!emory!europa.eng.gtefsd.com!uunet!pipex!sunic!trane.uninett.no!news.eunet.no!nuug!dkuug!eskimo.CPH.CMC.COM!lars
From: lars@spectrum.CMC.COM (Lars Poulsen)
Subject: Re: 2-Wire leased line options
Message-ID: <1993Nov25.095217.178@spectrum.CMC.COM>
Organization: CMC Network Products, Copenhagen DENMARK
References: <CH0L52.Cw5@actrix.gen.nz>
Date: Thu, 25 Nov 93 09:52:17 GMT
Lines: 50

In article <CH0L52.Cw5@actrix.gen.nz>
   smart@actrix.gen.nz (Quentin Smart) writes:
>
>Can anyone suggest the "best" options for a two wire leased line (over
>about 7km).
>I'd thought about Zyxel 1496E+ to get 19k2 but these aren't "leased line"
>aware so I guess I may have problems? 
>Is it possible to run a sync connection as opposed to async? You don't see
>many sync cards for PCs around.

(1) Over a distance of 7 km (about 23000 feet) it should be eminently
    possible to run 56 kbps on a metallic 4-wire circuit. If the telco
    won't give you a metallic circuit, or it isn't good enough for this,
    you could get digital data service. In NZ, I would expect the telco
    to provide CSU/DSUs (and charge an installation fee high enough for
    them to purchase those units!) This would give you a 64kbps
    synchronous circuit.

(2) You could get a 2-wire, 2-way voice-grade circuit, which the ZyXEL
    could operate over, but it would be almost as expensive, and a lot
    slower. You might be able to run 19k2 but then you might only make
    it to 14k4. You'd have compression on top of that, but at the price
    of about 200 ms of latency on the round-trip times. If you are
    planning on running SLIP/PPP, that latency is going to make you
    unhappy.

(3) Sync cards for PCs come in two classes:

    a) Inexpensive cards with dumb SCCs. All different (so there's not
       much good software support floating around for them). These are okay
       for half duplex protocols like SNA or BSC, but cannot handle
       full-duplex HDLC protocols with back-to-back frames. While they
       do have hardware to connect to motherboard DMA channels, that
       feature is about as useless as the DMA hardware on the async ports.

    b) Intelligent cards. Great, but more expensive.
       IBM's ARTIC.
       Adax's semi-smart MK5025 card.
       I have used a wonderful card made by Sangoma Technologies in
       Ontario, Canada. Quantity 1 list price about $600, I think.
       Comes with a TSR driver that lets you write X.25 applications
       in an afternoon. (Really!!)

At Rockwell/CMC's office in Santa Barbara, the Internet connection runs
over a 56kbps DDS line with a pair of our NetHopper routers equipped
with Sangoma sync cards. We are VERY happy with the service. (And we would
even sell you a pair, if TCP/IP is your application.)

I have no relation with Sangoma, other than as a very happy OEM customer.
-- 
/ Lars Poulsen			Internet E-mail: lars@CMC.COM
  CMC Network Products		Phone: (011-) +45-31 49 81 08
  Hvidovre Strandvej 72 B	Telefax:      +45-31 49 83 08
  DK-2650 Hvidovre, DENMARK	Internets: designed and built while you wait


 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.dcom.modems
Path: cs.utk.edu!emory!sol.ctr.columbia.edu!usc!elroy.jpl.nasa.gov!swrinde!menudo.uh.edu!nuchat!steve
Message-ID: <1994Feb6.221541.4306@nuchat.sccsi.com>
Sender: usenet@nuchat.sccsi.com (Netnews Administrator)
Nntp-Posting-Host: nuchat.sccsi.com
Organization: South Coast Computing Services, Inc.  Houston
References: <2iom6p$q2@nuscc.nus.sg> <1N0BHc4w165w@zswamp.UUCP>
Date: Sun, 6 Feb 1994 22:15:41 GMT
From: steve@sccsi.com (Steve Nuchia)
Subject: Re: 16550DC and 16550DN

In article <1N0BHc4w165w@zswamp.UUCP> geoff@zswamp.UUCP (Geoffrey Welsh) writes:
>   Good God, National's gone through three revisions (B, C, and D) overnight!

Actually the CMOS version has been marked with a C revision letter
since it came out.  The D is probably the faster version, which was
promised in the data sheet for the C.

The C's shipped double-marked as a direct replacement for the
NS16550AFN.  In their revised number scheme that chip is the
PC16550CN.  If you've bought one recently that's what you probably
have -- they haven't made any of the NMOS parts for a long time now.

-- 
Steve Nuchia      South Coast Computing Services, Inc.      (713) 661-3301

 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.dcom.modems
Path: cs.utk.edu!emory!swrinde!nic.hookup.net!xenitec!zswamp!geoff
Message-ID: <XR9BHc1w165w@zswamp.UUCP>
References: <1994Jan28.055830.22982@emba.uvm.edu>
Organization: Izot's Swamp
Date: Sun, 06 Feb 1994 13:19:56 EST
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Subject: Re: programming for Multi node BBS's

jsolomon@moose.uvm.edu (Jonathan K. Solomon) writes:

> Hi I was wondering if any one here could help me out.  I'm writting some 
> hard ware interupts and some of the mode control stuff for a multi node 
> BBS.  We're probably going to use those cards that make 8 com ports out of
> one.  If they share one IRQ then how can I identify which modem is recieving
> the byte and how do I address the individual com ports?  Does anyone know 
> of any good brands of boards that do this slitting thing.
> Any help would be appriciated.

   I think that you have a fundamental misunderstanding of what these boards 
do; I have never seen them referred to as making "8 com ports out of one".  
You'll make your software simpler - and more compatible - by using the drivers 
provided by the OS (or a FOSSIL, if you're writing for DOS) and let the serial 
I/O driver gurus sweat the details. 

   Basically, the simple ('dumb') multiport cards are nothing more than a 
number of UARTs - usually four or eight - addressed as you would a regular COM 
port's UART but at different addresses and a single 'vector port' which 
identifies which UART(s) are requesting an interrupt (in first requested, 
first serviced order).  This means that all of the ports on the board should 
be serviced by a single driver, and each task should communicate with the 
driver (e.g., /dev/tty under UNIX).

   There is also a class of 'intelligent' multiport cards offering dozens or 
even hundreds of serial ports and using a block of shared memory for mailbox-
style communication between the serial card and the operating system.

   Lastly, there are 'terminal servers', which have many serial ports and 
communicate with the operating system on one or most host systems through 
Ethernet or SCSI.

Geoffrey Welsh geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff
"Communism is an intellectual idea by not-very-good intellectuals"
 - former British Prime Minister Margaret Thatcher


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!xlink.net
      !subnet.sub.net!phoenix.ppc.sub.org!mips.ruessel.sub.org!not-for-mail
Lines: 15
Message-ID: <2lshlk$qrm@mips.ruessel.sub.org>
References: <2ln6rl$o27@taloa.unice.fr> <rbbrownCMGnLH.52z@netcom.com>
NNTP-Posting-Host: mips.ruessel.sub.org
Date: 12 Mar 1994 12:56:04 +0100
From: naddy@mips.ruessel.sub.org (Christian Weisgerber)
Subject: Re: RTS/CTS on SUN Sparc 1+ / Sparc 10

rbbrown@netcom.com (Randolph B. Brown) writes:

> : But what is the signal saying to modem that the Sparc is ready or not
> : to accept character in input ? How can I manage to avoid the buffer to
> : be full, and suspend the transfer if it is ?
> According to RS-232, there is no such signal. V.24 defines "Ready to
> Receive," which is usually found (surprise!) on the pin used in RS-232
> for "Request to Send," whixh is really only used for half-duplex.

It has been mentioned in this group that EIA-232E includes RTR as an
alternative function on the RTS pin, too.

-- 
Christian 'naddy' Weisgerber, Germany         naddy@mips.ruessel.sub.org
## CrossPoint v3.0/Win ##

 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.dcom.modems
Path: cs.utk.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net
      !usenet.ins.cwru.edu!neoucom.edu!wtm
Message-ID: <1994Mar14.145441.29126@uhura.neoucom.edu>
Organization: Northeastern Ohio Universities College of Medicine
References: <2lu03c$i7q@papaioea.manawatu.gen.nz>
            <1994Mar14.064527.28471@zcon.com>
Date: Mon, 14 Mar 1994 14:54:41 GMT
From: wtm@uhura.neoucom.edu (Bill Mayhew)
Subject: Re: Zyxel plans


Section 2 of EIA RS-232-C (July 1969) defines the electrical signal
characteristcs of the the interchange circuit:  the transmitter,
cable and termination.

1.  The transmitter is limited to an open-circuit peak amplitude
of 25 volts.  The series resistance of the transmitter is to such
that no more than 1/2 amp can flow (!).

2.  The transmitter has to assure that a minimum of 5 volt
magnitude can be delivered to the reciever at the distant end.  The
receiver is permitted to have an effective load resistance between
3000 and 7000 ohms.  The shunt capacitance of the reciever is not
allowed to be more than 2500 pF.

3.  The maximum voltage slew rate permitted is less than 30 volts
per microsecond.  There is a transitiion region defined between +3
and -3 volts where the signal is considered to be in an
indeterminate state.  Within the transition region, the singal is
not allowed to change sign of its rate of change.

RS-232-C never really discusses bit rate per se, but does define
the slew rate and minimum acceptable voltage levels and capacitance
of the reciever.  If you use low capacitance cable, you can extend
the operable range, provided you don't exceed the maximum lump sum
of 2500 pF permitted to be presented to the transmitting end.

Section three says:

"The interface between the data terminal equipment and data
communication equipment is located at a pluggable connector signal
interface point between the two eqipments.  The female connector
shall be associated with, but not necesarily attached to the data
communication equipment and should be mounted in a fixed position
near the data terminal equipment.  The use of an extension cable on
the data communication equipment is permitted.  An extension cable
with a male connector shall be provided with the data terminal
equipment.  The use of short cables (each less than approximately
50 feet or 15 meters) is recommended; however, longer cables are
permissible, provided that the resulting load capacitance (CL of
Fig. 2.1), measured at the interface point and including the signal
terminator, does not exceed 2500 picofarads.  (See section 2.4 and
6.5)"

Note that RS-232 never requires a D-shell mini connector, but it
does require a 25 pin connector of unspecified type.  Some of the
later standards do specify the exact connector.


-- 
Bill Mayhew        NEOUCOM Computer Services Department
Rootstown, OH  44272-0095  USA      phone: 216-325-2511
wtm@uhura.neoucom.edu       amateur radio 146.58: N8WED

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: alt.folklore.computers
Path: utkcs2!stc06.ctd.ornl.gov!news.he.net!newsfeed.nacamar.de
      !news-feed.inet.tele.dk!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com
      !newsxfer3.itd.umich.edu!news1.best.com!nntp2.ba.best.com!not-for-mail
Date: 18 Apr 1997 17:50:44 -0700
Organization: codewright
Message-ID: <x74td3omxn.fsf@dumbcat.codewright.com>
References: <slrn5l1k99.guk.pekangas@sci.fi>
From: Marco S Hyman <marc@dumbcat.codewright.com>
Subject: Re: MicroVaxII Terminal

bbreynolds@aol.com (BBReynolds) writes:
>
> RS-232 voltages were +/- 12VDC; RS-232B (c. 1976) were +/- 5VDC; RS-232C
> (c. 1980, and the most common in use, even now) are +/- 3VDC; there is a
> RS-232D standard, but I'm only guessing at the voltages being +/-  1.5
> VDC; if your old equipment has big enough sinks, it should work with

Minor nits:

I'm looking at "Industrial Electronics Bulletin No. 9, Application Notes
for EIA Standard RS-232-C" dated May 1971, a bit earlier than the
1980s date you suggest.

The "RS" was dropped from the name before version D.

I've a copy of the "Final Draft, EIA Standard EIA-232-D (Revision
of RS-232-C) dated December 1985.  Some of the draft specs were:

        The voltage at the "interface point" must be between
        5-15 volts when the open circuit receiver voltage is
        0 volts.

        The open circuit generator voltage must be < 25 volts

        The load impedance must be >= 3 K ohms @ 25 volts
        and <= 7 K ohms @ 3 to 25 volts

It is possible that these values changed before the standard
was published.

// marc


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.protocols.time.ntp
Message-ID: <bec993c8.0307180600.4fbece0c@posting.google.com>
References: <bf46vi$2rs$1@newsmaster.ldgo.columbia.edu>
    <vhbdasbiaib48f@corp.supernews.com>
    <slrnbhcjii.gk4.ptrojane@mion.elka.pw.edu.pl>
Organization: http://groups.google.com/
Date: 18 Jul 2003 07:00:59 -0700
From: Tim Shoppa <shoppa@trailing-edge.com>
Subject: Re: Designing an NTP network for a research ships at sea...

ptrojane@mion.elka.pw.edu.pl (Piotr Trojanek) wrote in message
news:<slrnbhcjii.gk4.ptrojane@mion.elka.pw.edu.pl>...
>
> In article <vhbdasbiaib48f@corp.supernews.com>, Hal Murray wrote:
> >
> >Some GPS setups will automatically send info at a preselected
> >rate.  So you don't have to poke it to send you stuff each time.
> >If you wire up a Y cable, you can plug it into 2 PCs.
> 
> does anyone tested this on-wire trick?
> will it work (from electrical point of view)?
> can we Y-split PPS signal -- TTL or RS232 levels --
> in this way?


Yes, you can.  RS-232 doesn't technically allow multiple receivers but
it does work.  TTL is rated for fanout, but you'll be dominated by cable
capacitance for any but the shortest cable runs.  Cable capacitance is a
limit for RS-232 too.

TTL is good to several feet, but is very bad if there's even the
slightest change in ground potential.  RS-232 is OK to several dozen or
hundred feet, allows 3V of ground potential difference, but even then
you will notice jitter from induced noise if you are looking at the
microsecond level.

Differential is good to tens of thousands of feet (at which point the
propagation delay completely dominates).

Tim.



 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.os.vms
Path: cs.utk.edu!gatech!concert!hearst.acc.Virginia.EDU!gems.vcu.edu!agnew
Message-ID: <1994May18.141404.1423@gems.vcu.edu>
Organization: Medical College of Virginia
Date: 18 May 1994 14:14:04 -0400
From: agnew@gems.vcu.edu (Brainwave Surfer)
Lines: 22
Subject: DTR Dropper Summary

Thanks for all the respondents to my DTR dropper request.  Harry Flowers
was the clear winner with:

$ SET TERMINAL/PERMANENT/NOMODEM TTA2:

	and

$ SET TERMINAL/PERMANENT/MODEM TTA2:


This got put into a batch job that will turn it on and off nightly.

Many Thanks, guys for all the code.  This was one of the times that one
slaps his head and moans "Oh that simple.."

Jim

         /^^^\   \ /   Jim Agnew         | AGNEW@RUBY.VCU.EDU  (Internet)
        /      >  ||   Neurosurgery,     | AGNEW@VCUVAX        (Bitnet)
   /\_/     '   \  /   MCV-VCU           | This disc will self destruct in
 /________________>    Richmond, VA, USA | five seconds.  Good luck, Jim..."



 //////////////////////////////////////////////////////////////////////////////


Path: cs.utk.edu!stc06r.CTD.ORNL.GOV!fnnews.fnal.gov!uwm.edu!lll-winken.llnl.gov!koriel!rutgers!spcuna!spcvxb!terry
Newsgroups: comp.sys.dec
Message-ID: <1994May28.130105.1@spcvxb.spc.edu>
References: <KILCUP.94May25200821@einstein.mps.ohio-state.edu> <CASTOR.94May28075810@hassle.Stanford.EDU>
Sender: news@spcuna.spc.edu (Network News)
Nntp-Posting-Host: spcvxa.spc.edu
Organization: St. Peter's College, US
Distribution: na
Lines: 25
Date: 28 May 1994 17:01:05 GMT
From: "Terry Kennedy, Operations Mgr." <terry@spcvxb.spc.edu>
Subject: Re: DEC 3000-300 serial port speed?

In article <CASTOR.94May28075810@hassle.Stanford.EDU>, castor@hassle.Stanford.EDU (Castor Fu) writes:
>
> Is it clear that the problem isn't just the serial port driver?  
> 
> I  seem to remember people complaining that the default Sun serial drivers 
> are just as lame  as DEC's, and that one that works at high baud rates were 
> an extra cost item  which for which sun wanted about $1K 
> (Probably a comparable cost to the DEC terminal server. . .).   


  Well, for about the same money ($1045, last I looked), you can get BSDI's
BSD/386, which will happily run 2 serial ports at 115200 using your garden
variety 16550-based serial card on a 486/33 PC.

  The Telebit NetBlazer's Asyn/8 (I think that's the option name) card will
happily run 16 serial ports simultaneously at 115200 on a 386SX/20 using only
a lowly Z80 CPU.

  I think this pretty much proves that inexpensive hardware can do an excel-
ent job at high data rates if it's supported by good software. While the 
Asyn/8 can claim to have hardware assistance, the BSDI example shows that it
can be done on a hardware design (the PC's serial port) that many consider
brain-dead.

	Terry Kennedy		  Operations Manager, Academic Computing
	terry@spcvxa.spc.edu	  St. Peter's College, Jersey City, NJ USA
        +1 201 915 9381 (voice)   +1 201 435-3662 (FAX)

 ..............................................................................

Newsgroups: comp.sys.dec
Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!noc.near.net!usenet.elf.com!rpi!wilsonj
Message-ID: <2se49g$b7b@usenet.rpi.edu>
References: <2sbdut$4mc@uuneo.neosoft.com> <2sck63$nkb@lyra.csx.cam.ac.uk> 
 <akfullfo.770317544@awful> <2sdrdd$7cj@lyra.csx.cam.ac.uk>
Organization: Rensselaer Polytechnic Institute, Troy NY
NNTP-Posting-Host: alum01.its.rpi.edu
Date: 31 May 1994 01:35:44 GMT
From: wilsonj@alum01.its.rpi.edu (John Wilson)
Subject: Re: DEC 3000-300 serial port speed?


In article <2sdrdd$7cj@lyra.csx.cam.ac.uk>,
Rupert Moss-Eccardt <rwgm1@cus.cam.ac.uk> wrote:
>
>I still maintain that if you blast huge rates of data at a PC serial port
>it won't be able to take it.  Mind you if you hide it in some protocol
>such as SLIP, PPP etc then it won't show.

What on earth are you talking about?  Burying your data under SLIP or PPP
makes the effective data rate (slightly) worse, not better.

I don't see what's so hard to accept here.  115200bps is a pathetically
slow data rate, supposing character-at-a-time interrupts in both directions
that gives you 23,040 interrupts/second, which coincidentally is about the
same interrupt rate commonly used to produce digitized sound over the
built-in speaker, which people have been doing since long before the current
crop of fast machines.  Now divide by 16 if you're using the FIFOs on a
16550A, and we're talking under 1500 interrupts/second, for SUSTAINED
115.2kbps in both directions, which could potentially be cut in half if
the ISR were sneaky about polling the "other" FIFO while servicing a FIFO
interrupt.  It's no wonder a Z80 is up to the job!  Of course Z80 interrupt
latency (starting an ISR as compared to executing any normal instruction)
is a lot better than an 80x86 (where the INT instruction from the 8259A
takes dozens of cycles to execute), but the current machines are so much
faster than the Z80s ever were that in terms of absolute speed, you'd need
to have a REALLY badly-written ISR to soak up all the time between interrupts.

People keep describing the backwards-compatible PC serial ports as if they're
a brain-damaged design.  It's a perfectly straightforward interrupt-driven
SLU, just like the DL-11 or the console port on a VAX.  DMA would have been
nice, but in almost all cases it would be overkill, the line rate maxes out
at 1/40th the data rate of Ethernet (1/80th *2 since it's bidirectional),
and most low-end Ethernet boards do just fine using a dual-ported SRAM
buffer instead of DMA, it's really the same thing as a FIFO anyway.

John Wilson

 ..............................................................................


 [state of serial technology in 1994]


Newsgroups: comp.sys.dec
Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!swrinde
      !ihnp4.ucsd.edu!news.cerf.net!nic.cerf.net!magma
Message-ID: <2sgbah$3m5@news.cerf.net>
References: <KILCUP.94May25200821@einstein.mps.ohio-state.edu>
           <CqHD1p.Ey9@wlbr.iipo.gtegsc.com> <2s62k6$f4c@news.CCIT.Arizona.EDU>
           <1994May28.104510.196@macro.demon.co.uk>
Date: 31 May 1994 21:48:00 GMT
From: magma@nic.cerf.net (Ed Romascan)
Subject: Re: DEC 3000-300 serial port speed?


   Perhaps I can clear up a few things regarding serial ports, drivers
and UNIX.  I work for an outfit that manufactures serial boards, both
for DEC (TURBOchannel line) and SUN (SBus) workstations, I write the
drivers for them.  

  First thing to keep in mind;  The serial I/O paradigm for UNIX
was developed about 25 years ago.  Termio(s) allows speeds of 50, 110,
300 ... bps (notice the lack of a *K* before the bps).  I believe the
default for ULTRIX is still 300 bps.  OSF/1, SunOS and Solaris default
to the blinding speed of 9600.  Other than the advent of STREAMS, I do
not believe that there has since been any work/thought/consideration
to improve serial I/O.  I guess the vendors still believe that the only
devices useful at the end of a serial port are paper tapes and teletypes.
So much for head space.

  The nitty gritty:  Currently there are two frameworks for serial
drivers,  STREAMS drivers and berkeley clist drivers.  SUN went
to the STREAMS approach some time ago.  DEC is just now offering
STREAMS in OSF/1.  STREAMS is better in two regards (IMHO), it 
separates the receive character processing (ie, line discipline)
from interrupt context, and it provides better buffering of receive
characters.  Hopefully this will become clear, but we need to look
at hardware for a bit.

  SUN has used the Z8530 SCC on their workstations, I'm not
sure about DEC.  The 8530 is about as flexible as they come,
sync, bisync, monosync, async, you name it, this chip can do it.
It also supports DMA.  It is a *bugger* to program but once you
get it, there is nothing it won't do.  I have run the thing
at speeds exceeding 1 Mbps, synchronous with DMA.  Great chip,
but old technology.  The receive fifo is all of one character long,
and here is where the many problems begin.  Running this guy in async
and not interfacing it to a DMA controller means that for every receive
character you field an interrupt, if you are lucky, you can get two 
characters per interrupt (the 8530 has a receive shift and hold register).
Obviously, cranking up the speed cranks up the interrupt rate.  Well,
the ability to efficiently field interrupts is not on the rather long
list of UNIX strengths.  You can read that as "high interrupt rate
seriously degrades your system performance".  Gee, there is news.  
This also applies to the transmit side, it is pretty symmetric
up to this point.

  The good news is that the SCC (serial communications controller)
vendors started putting larger fifo's on the chips.  Most of our
boards use the Cirrus Logic CD1400 async chips which provide 12
byte fifo's with programmable threshholds (eg, interrupt me when, say,
8 bytes are in the receive fifo).  This can reduce the interrupt rate
by a factor of 8 (or 12 if you let the fifo fill), a big help.  Zilog
has done essentially the same thing with the 85C30 and 85130 chips.
Anyway, now for 100 received characters we have fielded somewhere
between 8 and 13 interrupts, something less than 100.  I am
not going to worry about stale data timeouts for this discussion.
The cirrus chips are also capable of performing most of the line
discipline processing, eg, CRLF, ISTRIP, XOFF/XON detection/generation,
etc.  Im not sure if this is true of the 85{c1}30's, it's been
awhile.  The cirrus chips also do automatic hardware flow control
(rts/cts).  Of course there are many SCC choices out there, I am
limiting this to the ones I have had familiarity with.  I hope
this gives you some idea as to what the hardware can provide.

  Click. Back to software, start with berkeley style drivers and
an SCC programmed to interrupt when the recieve fifo level gets 
to 8.  I will only address the recieve side, as it is the most 
limiting.  Enter the interrupt service routine, do what needs to
be done to determine board/port/type of interrupt, discover that
it is a receive character(s) available interrupt.  First check the
receive fifo count register to determine how many characters are 
available.  The traditional (berkeley) thing to do now is pull
each character out of the fifo and pass them (one at a time)
to the line discipline receive character interrupt routine (ttyin).
ttyin does the full line discipline thing for that character and
then (hopefully) sticks it on the appropriate (raw or canonical)
clist.  You would not even believe how much work needs to be done
to "line discipline" that character.  Remember, all of this is
being done at interrupt context, further interrupts at this
level (spltty) are blocked.  Now, I am hanging out in this interrupt
routine for 8 character processing times.  In the mean time more
characters are streaming in and the receive fifo is filling on
one end while the isr is draining them on the other.  It should
not be difficult to see that at some line speed the arrival rate 
will exceed the drain rate.  Hah! the infamous "silo overflow"
message appears, in tech speak, this is a receive overrun. You have
lost a character (or more).  Bummer.  Well, for some reason, the
UNIX system vendors (in this case, specifically, DEC and SUN) have
been very slow to discover out-of-band (aka, hardware or rts/cts)
flow control.  This certainly is a good way to prevent overruns.

  I hear someone asking, "at what line speeds?".  DECstation 5000/200
starts puking at as low as 19200.  More dismaying is that a flamingo
(3000/500 AXP) will begin to overrun at 38400.  Don't blame it on DEC,
blame the fossil relic of the line discipline, which POSIX has adopted
and cast in stone.  Even worse, the problem does not stop here, but
let me digress.

 SUN adopted the STREAMS approach, this has the big advantage of
moving the line discipline receive processing out of interrupt
context.  The driver isr just needs to empty the fifo and queue
the characters.  The streams scheduler will get around to processing
them eventually.  This, and the fact that STREAMS is willing to buffer
more characters, is probably the reason SUNS don't crap out until
around 56000 bps.  SUN still has to supply the cpu cycles to push
each character through the line discipline, which is still POSIX
and still sucks.  sigh.

  DEC has maintained their disadvantage in the serial speed
race by maintaining the very ugly "ttyhog" limit of 255 characters
max on a character queue (clist).  Yup, you got it, the ttyin
routine will flush the clists when ttyhog is exceeded.  It is
amazing how quietly 256 characters can hit the floor.  If you
want it will ring a bell to muffle the lack of sound.  (Anyone
notice that my level of disgust is rising?).  The point is, even 
if you prevent the loss of characters from receive overruns, the 
tty subsystem will still trash you.  

  Well, there are ways around these problems, and I have used a lot 
of them.  I can run our CD1400 based boards at 115200 bps per port
without character loss (that is as fast as the CD1400 goes).  
Naturally the effective throughput is slightly less due to hardware
flow control and buffer management.  Our CD2400 based boards can do
twice that speed with *very few* interrupts.  The wonders of DMA
makes this chip very attractive for packet oriented data streams
(slip, ppp).  

  Now I am going to flame DEC and their knee-jerk (emphasis on
the jerk) "terminal servers are the only solution" reaction to
serial comm.   What they fail to disclose (or have yet to open
their eyes and discover) is that high telnet traffic to/from
a host via a TS can also bring the host to its knees, as bad,
sometimes worse than that lousy little rs232 device.  TCP/IP
traffic into and out of a host is not for free.  I have already 
used up my bandwith for the month, so I am not going to go into
nauseating detail on why this is true.  But, for supporting
evidence, look at the success Livingston is having with some
of their (fine) products.

  Hope this helps clear (as opposed to muddying) up some
of the issues.

bruce schoenleber
bruce@magma.com

 ..............................................................................

Newsgroups: comp.sys.dec
Path: cs.utk.edu!emory!swrinde!sgiblab!gatekeeper.us.oracle.com!decwrl
      !pa.dec.com!chmist.zso.dec.com!cja
Organization: Digital Equipment Corporation
Message-ID: <2sipu8$a1@usenet.pa.dec.com>
References: <2s62k6$f4c@news.CCIT.Arizona.EDU> 
            <1994May28.104510.196@macro.demon.co.uk> <2sgbah$3m5@news.cerf.net>
Date: 1 Jun 1994 20:09:44 GMT
From: cja@chmist.zso.dec.com (Carl J Appellof)
Subject: Re: DEC 3000-300 serial port speed?

In article <2sgbah$3m5@news.cerf.net> magma@nic.cerf.net (Ed Romascan) writes:

    [...stuff deleted...]

Thanks for the good discussion of more modern async interface chips.
I have a few biased comments on some of your discussion.

>  DEC has maintained their disadvantage in the serial speed
> race by maintaining the very ugly "ttyhog" limit of 255 characters
> max on a character queue (clist).  Yup, you got it, the ttyin
> routine will flush the clists when ttyhog is exceeded.

I worked on the OSF/1 STREAMS line discipline module at one time,
and put in this ttyhog limit to mimic the old BSD line discipline.
The theory was that on a timesharing system, you wouldn't want any
individual user to hog too much memory.  What would be a better way
of limiting global system resource usage?

>
>  Well, there are ways around these problems, and I have used a lot 
> of them.

The easiest way around this problem with STREAMS is not to push
the line discipline module onto your STREAMS stack if all you want
to do is suck characters in.  Your complaints about the amount of
processing it takes to discipline a character are all true.  Those
chars are incorrigible!  But if you wants POSIX or SYSV behavior
(and many programs do), you pays the price.

Ideally, running SLIP or PPP would push a totally different "line
discipline" module onto the STREAMS stack, and would avoid all that
character-by-character processing.

>  Now I am going to flame DEC and their knee-jerk (emphasis on
> the jerk) "terminal servers are the only solution" reaction to
> serial comm.   What they fail to disclose (or have yet to open
> their eyes and discover) is that high telnet traffic to/from
> a host via a TS can also bring the host to its knees, as bad,
> sometimes worse than that lousy little rs232 device.

I also used to be one of those kneeling jerks who worked on DEC
terminal servers.  In those days (5 years ago now), we had a similar
knee-jerk reaction about telnet.  Back then, our terminal servers used
only the LAT protocol, which is very network-efficient and
host-interrupt-efficient.  But customer demand required telnet, so we
finally relented.  It's still true that a telnet session is a pretty
heavy host load.  I'll still go for LAT on my terminal server if
minimizing host load was the goal.

I see the real benefit of terminal servers as reduced wiring costs,
and the flexibility to connect to multiple systems.  Of course that
only applies to hooking up lots of real terminals or modems.  SLIP
lines are probably another story.

Just my 2 cents.
-- 
Carl J. Appellof (cja@chmist.zso.dec.com)
Storage Management Group
POLYCENTER NetWorker Save and Restore
Digital Equipment Corporation


   [Subsequently, Compaq bought Digital, then HP absorbed Compaq.]

 //////////////////////////////////////////////////////////////////////////////


Newsgroups: alt.sys.pc-clone.micron,alt.sys.pc-clone.dell,comp.sys.intel
Path: cs.utk.edu!gatech!howland.reston.ans.net!pipex!peernews.demon.co.uk!genesis.demon.co.uk!fred
References: <3f1at9$7t0@news.acns.nwu.edu> <9501131819.AA22548@fossil.ecte.uswc.uswest.com> <Pine.SUN.3.90.950113132215.4416A-100000@galadriel>
Organization: none
Reply-To: fred@genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
Lines: 39
X-Posting-Host: genesis.demon.co.uk
Message-ID: <790221120snz@genesis.demon.co.uk>
Sender: usenet@demon.co.uk
Date: Mon, 16 Jan 1995 01:52:00 +0000
From: fred@genesis.demon.co.uk (Lawrence Kirby)
Subject: Re: Which of these is better? Dell vs. Micron

In article <Pine.SUN.3.90.950113132215.4416A-100000@galadriel>
           karpens@ncssm-server.ncssm.edu "------Simon------" writes:

>The 16550 can handle speeds up to 57,600baud (v32bis+compress) without 
>problems, the 16550A can handle 115,200 and the 16550AF can handle 230,400.
>The difference is the amount of buffer and the speed of the chip itself.

Most of this is incorrect.

The 16550 was superceded several years ago and there haven't been any in the
supply channels for a long time. It has 16 character FIFOs but they are
buggy so you have to use it with them turned off which makes effectively
a 16450/8250A. Max speed is 115200bps but in practice will be limited
by what the software environment can cope with at 1 interrupt/char.

The 16550A has the 16 character FIFOs fixed. It too has a maximum settable
speed of 115200bps but can usually be run at this speed reliably.

The 16550AF is just a minor revision which makes no functional difference
to the 16550A in a standard PC serial port (though it may make some difference
in more demanding environments). The 16550AF uses the same clock divider
as the earlier chips so in a PC it remains limited to 115200bps. To go
higher you would need to change the I/O interface or the meaning of the
normal divider values (which would makes the speeds that comms programs
report incorrect).

>Note that under messy-dos or to some degree windoze, the chips are forced
>to emulate 8250s. Under Linux, they are detected as 16550As.

Comms programs under DOS take over the driving of the UART completely and
nearly all handle the 16550A fully these days. Under Windows it is down to the
Windows driver and even this can be made to drive the 16550A fully either by
configuring it correctly or using a 3rd party driver.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


Newsgroups: comp.dcom.modems
Path: cs.utk.edu!gatech!swrinde!cs.utexas.edu!news.sprintlink.net!pipex!peernews.demon.co.uk!purdy.demon.co.uk!Andy
References: <3fe5skE51j@uni-erlangen.de>
Organization: home!
Reply-To: Andy@purdy.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.29
Lines: 21
X-Posting-Host: purdy.demon.co.uk
Message-ID: <790606682snz@purdy.demon.co.uk>
Date: Fri, 20 Jan 1995 12:58:02 +0000
From: Andy@purdy.demon.co.uk (Andy Thomas)
Subject: Re: General FAQ about standards--is there any?


In article <3fe5skE51j@uni-erlangen.de>
           uhschreg@cip.informatik.uni-erlangen.de "Ulrich Schreglmann" writes:

> I don't mean one of these sales pitches for modems of a special company,
> just about protocols/baud-rates/etc. in general.  I can never find any,
> no matter how often I browse through here.
>
> Could anybody tell me whether there is one, when to look for it, or
> e-mail the FAQ or a hint on where to get it?  Thank you very much.
>
>
> May the Cool Be with You!

Have a look at Christian Blum's excellent FAQ called
'The_Serial_Port' whcih you can get by ftp from
pfsparc02.phil15.uni-sb.de in the directory /pub/E-Technik/afd.

Auf weidersehn,

--
Andy Thomas


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
Path: cs.utk.edu!stc06.CTD.ORNL.GOV!rsg1.er.usgs.gov!jobone!newsxfer.itd.umich.edu!zip.eecs.umich.edu!newshost.marcam.com!news.mathworks.com!uunet!world!aml
Message-ID: <D3y3rx.CvB@world.std.com>
Organization: The World @ Software Tool & Die
References: <3hlr74$hsg@central.server.swt.edu>
Date: Mon, 13 Feb 1995 15:45:32 GMT
From: aml@world.std.com (Andrew M. Langmead)
Subject: Re: Need info on MaXpeed SS-8

Rodney Muras <rm15876@swt.edu> writes:

>I have a MaXpeed SS-8 multiport serial card but have no info on it.
>This card was used in a PC-MOS based multiuser environment.  Any 
>information on this card would be greatly appreciated...

For MS-DOS, maxspeed included a device driver that responded to the
standard INT14 comm interrupts, with maybe some extentions. The
default switch settings are switches one through eight, "11110100"
which sets the board at memory address D000:0000. It seems that the
switches are the binary coded values for the top eight bits, but
inverted (and you might think of them as reversed since switch 8 is
the MSB, but read last.)

The back is a six wire RJ-14 connector. The pins are wired:

1 = DTR
2 = RD
3 = SHG
4 = GND
5 = TD
6 = DCD

They had a BBS at (415)345-8512, but I haven't checked it lately so I
don't know if it is still active.
-- 
Andrew Langmead

 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.terminals,comp.unix.misc
Path: cs.utk.edu!cssun.mathcs.emory.edu!hobbes.cc.uga.edu!news-feed-1.peachnet.edu
      !gatech!howland.reston.ans.net!pipex!sunic!sunic.sunet.se!news.funet.fi
      !news.csc.fi!kronos.fmi.fi!dionysos.fmi.fi!hurtta
Message-ID: <3mmfcs$16f@kronos.fmi.fi>
References: <3l6tkp$cot@umd5.umd.edu> <3ltohv$38g@kronos.fmi.fi> <3lv9tn$e3l@vixen.cso.uiuc.edu>
NNTP-Posting-Host: dionysos.fmi.fi
In-Reply-To: Article <3lv9tn$e3l@vixen.cso.uiuc.edu> of Owens-Nicholson
X-Newsreader: NN version 6.5(beta3).0 #6 (NOV)
Organization: Finnish Meteorological Institute (FMI)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Lines: 23
Date: 14 Apr 1995 18:37:16 GMT
From: hurtta@dionysos.fmi.fi (Kari E. Hurtta)
Subject: Re: vt220 term with vt100 set


[ Adding comp.unix.misc as receiver. ]

dawn@uxh.cso.uiuc.edu (Dawn Owens-Nicholson) writes in comp.terminals:
|
| hurtta@dionysos.fmi.fi (Kari E. Hurtta) writes:
| > His have wrong settings in terminal triver -- Terminal driver _should_
| > do mapping LF -> CR LF (and this is true also for VT100).
|
| I'm not sure what you mean by a terminal driver, but this problem
| might be solved by typing "stty cooked" or placing this command in
| »your login file.

Yes. With stty you can change behauviour of unix's terminal driver. 
Terminal driver is that part of unix's kernel which does special processing
for tty connections.

Command 'stty -a' gives all fields. For more details, look manual page of
termios.

--
- Kari E. Hurtta                             /  Elämä on monimutkaista
  Kari.Hurtta@FMI.FI			     puh. (90) 1929 658
  {hurtta,root,Postmaster}@dionysos.FMI.FI

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.arch.embedded,comp.terminals
Message-ID: <D9yxt2.HMK@stepeng.com>
Followup-To: comp.terminals
References: <ojpRULq00iV5Q3CJ1y@andrew.cmu.edu>
 <7JUN199512355584@erich.triumf.ca>
Organization: Step Engineering
Keywords: VT-100
Date: Sat, 10 Jun 1995 17:55:49 GMT
From: dan@stepeng.com (Daniel Weaver)
Subject: Re: VT-100 Commands


In article <7JUN199512355584@erich.triumf.ca>,
 bennett@erich.triumf.ca (P.Bennett) writes:
>
>   void gotoxy( int x, int y )
>   {
>      printf( "\033[%d;%dH\000\000", y, x );
>   }
>
>   /* \033 = Escape */
>
>   the \000 chars seem to be needed to give the terminal time to do
>   its thing...

I've got some bad news for you, Peter.  The \000 character gets swallowed by 
printf() and never makes it to the terminal.  If you want to send NULLs to
the terminal, you need to use putc(), or write().  Another way to do this
is to send \200 (0x80 hex).

printf() stops parsing when it sees the first NULL.

Follow-ups should be redirected to comp.terminals.

Dan Weaver
<dan@stepeng.com>


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.os.vms
Path: cs.utk.edu!nntp.memphis.edu!netnews.wku.edu!mvb.saic.com!news.mathworks.com
      !uunet!in1.uu.net!ulowell.uml.edu!willow.uml.edu!welchb
Message-ID: <1995Jul10.135133.1@willow.uml.edu>
References: <0099303C.509D7DC0.5@earth.oscs.montana.edu>
 <1995Jul9.163800.5770@cmkrnl>
Organization: University of Massachusetts Lowell
NNTP-Posting-Host: willow.uml.edu
Lines: 18
Date: 10 Jul 95 13:51:33 -0500
From: welchb@willow.uml.edu (Brendan Welch, W1LPG)
Subject: Re: DB25 --> DB9 RS232

> Ok, for future reference: (1) It hasn't been "RS232" for years; it's
> now the EIA-232-E standard.  (2) The 9-pin D-subminiature connectors
> are not DB-9, but rather DE-9.  (Says so in the manufacturer's
> catalogs.)  So many people get both of these points wrong that I doubt
> that this little post will help, but I can only hope.  
> 
> 	--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
> Internet: jeh@cmkrnl.com (JH645)  CompuServe: 74140,2055  

Think of how many people mispronounce "modem".  They use a long o
sound, as in Kernel _Mode_, instead of the short o sound, as in
_modulate-demodulate_.


-- 
Brendan Welch, system analyst, UMass/Lowell, W1LPG,  welchb@woods.uml.edu
working on being as perfect as Ehud


 //////////////////////////////////////////////////////////////////////////////

Article 4945 of comp.terminals:
Path: cs.utk.edu!gatech!news.mathworks.com!uunet!in1.uu.net!nwnews.wa.com
      !news1.halcyon.com!coho!dagon
Newsgroups: comp.terminals
Organization: Northwest Nexus, Inc. - Professional Internet Services
Message-ID: <45m0b8$5ic@news1.halcyon.com>
References: <45konr$e9u@uceng.uc.edu>
NNTP-Posting-Host: coho.halcyon.com
Lines: 13
Date: 13 Oct 1995 15:24:24 GMT
From: dagon@coho.halcyon.com (Mark Rafn)
Subject: Re: vt220 through modem ?

Abraham George <ageorge@babyhuey.uc.edu> wrote:
>
>I have a vt220 terminal at my residence. I wish to connect via an
>external modem to the college net.  Since I haven't purchased a modem,
>I would like to know if any of the current external modems in the market
>would do the job.

Almost any external modem will do the job.  Given that you'll only be
able to use text applications, there's not much reason to pay for a
super-fast modem.  9600bps would do fine, but you probably can't find one.
As I recall, the maximum DTE rate on those is 19200, so even if you use
a 28.8 modem, you'll only be able to use it as a 14.4.

-- 
Mark Rafn   dagon@halcyon.com   http://www.halcyon.com/dagon/

 //////////////////////////////////////////////////////////////////////////////

Path: cs.utk.edu!gatech!newsfeed.internetmci.com!news1.erols.com!news2.cais.net
      !news.cais.net!news.vbc.net!samba.rahul.net!rahul.net!a2i!dold.a2i!dold
Newsgroups: comp.protocols.kermit.misc
Organization: a2i network
Lines: 50
Message-ID: <4kf2v8$89p@samba.rahul.net>
References: <spw91g9mkrt.fsf@julie.teleport.com> <spwag0lq1pc.fsf@linda.teleport.com>
NNTP-Posting-Host: foxtrot.rahul.net
NNTP-Posting-User: dold
X-Newsreader: TIN [version 1.2 PL2]
Date: 10 Apr 1996 01:30:16 GMT
From: Clarence Dold <dold@rahul.net>
Subject: Re: modem won't respond to mskermit

: >>>>> "fdc" == Frank da Cruz <fdc@watsun.cc.columbia.edu> writes:

: fdc> If Kermit were set to an interface speed that is not supported by the
: fdc> modem, this would explain why the modem is ignoring your commands.  But i

Frank, I don't think the modem cares as much as the serial port does.


Mark McConnell (mkmcconn@teleport.com) wrote:
: Your description of the symptoms associated with a mismatched speed points
: in the direction of the solution, apparently.  I am using a ZOOM VFX V.32bis
: modem.  I had attempted to SET SPE 28800.  When I changed to 38400, the 
: modem responded.  Also works at 57600 and 14400, but not 28.8.

: Anyway, although I'm not happy with the ambiguous fix, I AM connected.


Mark, this isn't an ambiguous fix.  Many serial ports will not operate
at the new, odd speeds that modems have chosen.  Standard serial port
speeds have always been multiples of the lower speeds.  
300 1200 2400 4800 9600 19200 38400 57600 115200 have all been standard
speeds, with the ones above 19200 being rare in older systems.  Modems
that operate at 12000, 14400, 21600, 26400, 28800 are based on the
technology of the analog phone line, and do not correspond directly to
the serial port interface speeds.

I have several Intel 144I and 144E, all have run or are running
MS-Kermit, and all have been quite happy, at standard serial port
interface speeds.

I run 38400 on a DOS machine, and 19200 on my UNIX machine to Intel
modems currently.  Neither machine will recognize a setting of 14400 (I
never tried 28800).  Kermit will set the proper bits to set the speed
to that rate, but the serial port is likely sending _no_ intelligible
data to the modem.  The echo that you see is not an intelligent
response from the modem.  If an Intel (GVC) modem won't give you a
status display with AT&V, it isn't working.

With compressing modems (14.4 or 28.8), you want your serial port set
faster than the connect speed.  How much higher will produce any
effective results depends on your environment, and the data being
transferred.  If you transfer primarily .zip files, there is probably
no value to be seen with a speed greater than 19.2, which is enough to
keep a 14.4 modem running at its maximum transfer speed of 1660
characters per second.

-- 
---
Clarence A Dold - dold@rahul.net
                - Pope Valley & Napa CA.

 ..............................................................................

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!news.msfc.nasa.gov!sgigate.sgi.com!rutgers!news.columbia.edu!watsun.cc.columbia.edu!fdc
Organization: Columbia University
Message-ID: <4khbd5$44f@apakabar.cc.columbia.edu>
References: <spw91g9mkrt.fsf@julie.teleport.com> <spwag0lq1pc.fsf@linda.teleport.com> <4kf2v8$89p@samba.rahul.net>
NNTP-Posting-Host: watsun.cc.columbia.edu
Lines: 41
Date: 10 Apr 1996 22:06:29 GMT
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: modem won't respond to mskermit

In article <4kf2v8$89p@samba.rahul.net>, Clarence Dold  <dold@rahul.net> wrote:
: : >>>>> "fdc" == Frank da Cruz <fdc@watsun.cc.columbia.edu> writes:
: 
: : fdc> If Kermit were set to an interface speed that is not supported by the
: : fdc> modem, this would explain why the modem is ignoring your commands. .. 
: 
: Frank, I don't think the modem cares as much as the serial port does.
: 

Right -- I should have prefaced all that with "assuming your serial port
supports 28800 (or 14400) as a speed..."

However, in theory, and I believe also in practice, Kermit won't let you
set the serial port to a speed it does not support.  MS-DOS Kermit 3.14
handles 14400 and 28800 bps just fine, as far as I know, by setting the
UART's hardware "baud rate divisor" register to the appropriate value.

C-Kermit depends on the underlying operating system, hardware, and drivers
to do the same, and to report back accurately whether they have, in fact,
done so.  I grant you, there are cases where the underlying services fail
to do these things properly so, yes, this too can be a consideration.

: With compressing modems (14.4 or 28.8), you want your serial port set
: faster than the connect speed.  How much higher will produce any
: effective results depends on your environment, and the data being
: transferred.
:

Right, this is standard advice.  I should not take it for granted that
everybody knows this by now.  Plus all the rest regarding flow-control,
etc etc etc.

: If you transfer primarily .zip files, there is probably
: no value to be seen with a speed greater than 19.2, which is enough to
: keep a 14.4 modem running at its maximum transfer speed of 1660
: characters per second.
: 

True, but people who also use Kermit for terminal emulation will want to
use the highest possible serial speed, because V.42bis compression tends 
to be very effective for plain text, which is generally what goes back and
forth in terminal mode.

- Frank

 ..............................................................................
 

Newsgroups: comp.dcom.modems 
Path: cs.utk.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!menudo.uh.edu
      !uuneo!sugar!ficc!peter
Message-ID: <id.PAPY.476@ferranti.com> 
Organization: Xenix Support, FICC
References: <1oplmpINNp49@escargot.xx.rmit.OZ.AU> <C4EqD5.HI@csn.org>
Date: Thu, 25 Mar 1993 17:54:53 GMT
From: peter@ferranti.com (peter da silva)
Subject: Re: 16550 buffer and hi speed modems


The best prices I found for 16550s were from BG Micro in Dallas TX. They're
also pretty savvy people. I don't have the number at hand, try directory
assistance.

-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
12808 West Airport Blvd.  Sugar Land, TX  77478  USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: alt.folklore.computers
Path: utkcs2!stc06.ctd.ornl.gov!news.er.usgs.gov!news1.radix.net
      !news1.chicago.agis.net!agis!news4.agis.net!newspeer2.dearborn.agis.net
      !agis!newspeer.santaclara.agis.net!agis!su-news-hub1.bbnplanet.com
      !cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!dispatch.news.demon.net
      !demon!mail2news.demon.co.uk!tnglwood.demon.co.uk!unclebob
Date: Sun, 13 Apr 97 20:24:53 GMT
Message-ID: <860963093snz@tnglwood.demon.co.uk>
References: <4ikpi5.l6n.ln@mercury.user-rwaid.es.co.nz>
            <lfischerE8KEyr.Bn6@netcom.com> <slrn5l1k99.guk.pekangas@sci.fi>
From: Robert Billing <unclebob@tnglwood.demon.co.uk>
Subject: Re: MicroVaxII Terminal

In article <slrn5l1k99.guk.pekangas@sci.fi>
           pekangas@sci.fi "Petteri Kangaslampi" writes:

> One trick that I have found useful is to use a voltmeter to determine
> which end a given device thinks it is.

 True, but you *can* do it with a LED.

> Of course, the cable itself might be correct, but one end might be
> expecting CTS/RTS handshaking, while the other doesn't.

 DEC kit in general doesn't need the RTS/CTS but your terminal might.
Assuming your terminal has a 25-way D then short 2 and 3 at the
terminal with a paper clip, and see if you get a local echo. If you do,
all well and good, if not try shorting combinations of 4, 5, 8 and 20
until the terminal kicks in and (with the 2-3 short still on) goes
local echo (that means what you type something it comes up on the
screen).

 Then wire a cable with whatever shorts you need at the terminal end,
and 2, 3 and 7 only wired to the DEC end. If that doesn't go then swap
2&3 in the cable.

 2 & 3 are the data in the two directions, 7 is the ground.

 BTW a box with a male connector should be a DTE, a box with a female
connector should be a DCE. A cable with the same gender of connector
should be wired crossover, with different genders should be wired
straight. Nobody (except DEC) ever seems to do this right.

 The DEC MMJ connectors on some VAXEN are logically equivalent, and
work in the same way, all MMJ cables have 2 male connectors and are
crossovers.

> Petteri, whose biggest achievement is getting a strange DEC terminal talk
> to his PC :) It turned out that I needed a null-modem cable with a 9-pin
> male connector in one end (PC) and 25-pin female in the other. Go
> figure...

 This isn't too difficult. I've been threatening to have some little
cards printed with the rules for doing it on one side, and an advert
for my firm on the other.

-- 
I am Robert Billing, Christian, inventor, traveller, cook and animal
lover, I live near 0:46W 51:22N. http://www.tnglwood.demon.co.uk/
  "might there be some celestial tribunal at which a crafty advocate
  could get a sinner off hell? ...my heart sank at the thought of
  eternal work before a jury of prejudiced saints."


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: alt.folklore.computers
Path: utkcs2!stc06.ctd.ornl.gov!news.he.net!news.enteract.com
      !feed1.news.erols.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com
      !ix.netcom.com!netcom.net.uk!nntpfeed.doc.ic.ac.uk!sunsite.doc.ic.ac.uk
      !lyra.csx.cam.ac.uk!bjh21
Date: 13 Apr 1997 13:37:11 GMT
Message-ID: <5iqni7$mj6@lyra.csx.cam.ac.uk>
References: <4ikpi5.l6n.ln@mercury.user-rwaid.es.co.nz>
            <lfischerE8KEyr.Bn6@netcom.com> <slrn5l1k99.guk.pekangas@sci.fi>
From: bjh21@thor.cam.ac.uk (Ben Harris)
Subject: Re: MicorVaxII Terminal

In article <slrn5l1k99.guk.pekangas@sci.fi>,
Petteri Kangaslampi <pekangas@sci.fi> wrote:
>
> I have somewhere around lying a photocopy of a page from some electronics
> book (can't remember what) that contains the connections for a bunch of
> "RS-232 cables that actually work". It has proved extremely useful,
> especially as the same book section contains some general tips on "how to
> become a RS-232 cable guru" or something.

The book in question is the second edition of Horowitz and Hill's 'The
Art of Electronics', published by Cambridge University Press.

-- 
Ben Harris
Undergrad Computer Rep, Corpus Christi College, Cambridge.

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
Path: transfer.stratus.com!bigboote.WPI.EDU!nntprelay.mathworks.com!fci-se!fci
      !newsfeed.sunet.se!news99.sunet.se!news01.sunet.se!130.237.72.211.MISMATCH
      !news.kth.se!acheron.fusion.kth.se!johanc
Message-ID: <Pine.SOL.3.96.971212191612.16758B-100000@acheron.fusion.kth.se>
NNTP-Posting-Host: acheron.fusion.kth.se
Date: Fri, 12 Dec 1997 19:21:49 +0100
To: SPHudson <sphudsonX*hotmail.com>
From: Johan Carlsson <johanc@fusion.kth.se>
Subject: Re: mark/space parity: what is it?

> Could anyone please tell me what mark/space parity is?  I'm
> building a terminal emulator and need to support no, even, odd,
> mark, and space parity.


Hi,

mark parity means the parity bit is always set and space parity means the
bit is never set. Good luck w/ the terminal emulator.

/Johan


 //////////////////////////////////////////////////////////////////////////////

>Date: Mon, 20 Apr 1998 11:24:53 +0800
>From: Kenneth Xu <xu_dong%irel.com.sg> 
>To: Richard Shuford
>
>...we are providing a solution to connect 50 over terminals to a
>host, these terminals are all far from host and located in different area.
>That's way we look into RS422 or RS485.
>
>Our customer does not like external converters because it need extra power
>supply and etc for each terminal, they think it will make system maintenance
>more difficult.


I have seen advertisements for RS-485/RS-422 adapters that are very
small and seem to require no external power.  (They siphon a tiny
amount of power from the RS-232 status signals to operate.)

Most recently I saw such things advertised in the back of the magazine
called \Circuit Cellar Ink/, published by Steve Ciarcia:

    http://www.circellar.com/

    +1 860-875-2751

I really think that would be the best way to go.

 ---------------------------

OK.  I dug around in my office and found an October 1997 issue of this
magazine.  In it is an ad from a company in Minnesota that sells such
items:

    Integrity Instruments
    Division of Cogito Software
    PO Box 451
    Pine River, MN  56474 USA
 
    +1 218-587-3414
    http://www.integrityusa.com/

You could also inquire at Jameco Electronics:   http://www.jameco.com/
 
 ---------------------------

One more thing to try:  contact Wyse Technology and see if that company
still sells terminals with RS-485 interfaces.  Wyse did, long ago...

    http://www.wyse.com/ 
    http://www.wyse.co.uk/support/

 ...RSS

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.dcom.telecom.tech
NNTP-Posting-Host: 32.100.59.159
Message-ID: <354fcfa3.0@news1.ibm.net>
References: <3545BB01.32A2635B@netas.com.tr>
Date: Mon, 4 May 1998 23:01:26 -0500
From: <bbyrd@ibm.net>
Subject: Re: What happened to V.35

Yeah, the company I work for manufactures, among ther things, V.35
interfaces to SONET/SDH.  I was on the compliance team for testing it to
specs, along with our V.11 interface.  We had a hell of a time getting the
V.35 spec.  The ITU finally faxed it to us free of charge since it's now
been obsoleted.  The ITU says now to build interfaces that are compatible
with V.11 for balanced circuits or V.10 for unbalanced circuits.  It seems
the 100ohm impedence on the  twisted pair V.35 transmitter will draw excess
current when exposed to moderate voltages.  This is most likely the reason
for it being obsoleted.  Then again DS-1 (which is also balanced twisted
pair) has 100ohm TX/RCV impedences, and CEPT-1's(E-1's) balanced twisted
pair interface is 120 ohms, although the unbalanced E-1 is 75ohm coax.   I'd
like to see someone try to obsolete T-1 or E-1.  That would go over like a
lead zeppelin all right.  Anyways:

 
RS-422 is ASYNC V.11 with unbalanced controls
RS-232 is unbalanced ASYNC V.24 with unbalanced controls

Someone correct me if I'm wrong, but I think   RS449 is SYNC V.11 with
unbalanced controls
 
EIA-530 is SYNC V.11 with balanced controls
 
RS-423 is ASYNC V.10 with ????? controls
Any experts out there who can verify the last 3 for me?  Thanks.

--  
Bo Byrd
Systems Technician
Intelect Network Technologies
<rbyrd@intelectinc.com>


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
References: <01bdefa0$673256c0$63636363@laptop-brc> 
            <361be1ba.16306079@netbsd.haeb.demon.org>
            <01bdf20c$bd653da0$63636363@laptop-brc>
Organization: C.I.C. Ltd
Date: Thu, 08 Oct 1998 00:34:01 GMT
From: Harry Broomhall <haeb@pc60.demon.co.uk>
Subject: Re: Sending break with Wyse 50 emulator

On 7 Oct 1998 16:04:26 GMT, "Bill Creager" <creager@norfolk.infi.net>
wrote:

> My original question was obviously written poorly. I have written the
> emulator, and need to know what my program must sent to simulate pressing
> the break key.
>
> My Wyse-50 display terminal reference manual does not specify what a break
> signal is. My program is communicating with another computer which does not
> send breaks, although it expects them for some functions.


   In the serial comms world (for example RS-232)  a BREAK signal is
where the line is held at SPACE for longer than a normal character
frame.  Other rules apply for other media.

   Regards,
          Harry.


 //////////////////////////////////////////////////////////////////////////////


Message-ID: <3638EDEB.43891189@GSC.GTE.Com>
References: <3638DF3B.C7B3766E@timesystem.de>
Organization: GTE Government Systems
Date: Thu, 29 Oct 1998 22:36:27 GMT
From: "Scott G. Hall" <Scott.Hall@GSC.GTE.Com>
To: Tobias Galitzien <gal@timesystem.de>
Newsgroups: comp.terminals
Subject: Re: RS232 connector on Nixdorf BA80

Tobias Galitzien wrote:
> I have a Nixdorf BA80 terminal here with a RS232 connector on its
> backside (at least this is written above it) but it has 15 pins and I
> have never seen such a RS232.
>
> Can anybody tell me how the pins are connected in order to make a cable?

A number of the older terminal manufacturers did something like this.  The
original EIA standard for serial ports included two ports in the DB-25
connector, both either synchronous or asynchronous.  Some vendors did not
want folks mixing up the two-port versus one-port variety, so they used a
DB-15 connector.


Usually the top row (pins 1-8) are the same as for their DB-25 counterparts
(1=chassis gnd, 2=TX, 3=RX, 4=RTS, 5=CTS, 6=DSR, 7=sGnd, 8=CD), and the DTR
pin was in the same relative position (under pins 6 & 7) -- or pin 10 on a
DB-15.  The rest of the pins are usually the sychronous clock and timing
pins of a synchronous connector.  Which ones are which is anybody's guess.

--
Scott G. Hall
GTE Government Systems
North Carolina Systems Center
email: Scott.Hall@GSC.GTE.Com

 //////////////////////////////////////////////////////////////////////////////

Date: Wed, 16 Jul 2003 15:59:46 -0400 (EDT)
From: der Mouse
Subject: Re: SS10 serial Y-cable

Zoltan HERPAI writes ...
>
> i'm searching an Y-cable for my SparcStation10
> [by implication, for the serial ports].

While I don't know of any source for pre-built cables, they are fairly
easy to make if you're not afraid of a soldering iron.  Just look at
the RS-232 pin names; serial port B is all the "Secondary <foo>"
signals.  (For example, pin 13, Secondary Clear To Send, is the ttyb
version of pin 5, Clear To Send.)

Since it's small, here is the full table, typed in back when I actually
dug out a copy of the EIA RS-232 spec.  A few of the pins have multiple
uses; the only one that's relevant to what you want is pin 12, which
you should treat as secondary DCD.

Pin     Source  Type    What

 1              Ground  Shield, protective ground
 2      DTE     Data    Transmitted Data
 3      DCE     Data    Received Data
 4      DTE     Ctl     Request To Send
 5      DCE     Ctl     Clear To Send
 6      DCE     Ctl     DCE Ready
 7              Ground  Signal ground
 8      DCE     Ctl     Received Line Signal Detector
 9                      (Reserved for testing)
10                      (Reserved for testing)
11                      (Unassigned)
12      DCE     Ctl     Secondary Received Line Signal Detector
        DCE     Ctl     Data Signal Rate Selector (DCE)
13      DCE     Ctl     Secondary Clear To Send
14      DTE     Data    Secondary Transmitted Data
15      DCE     Timing  Transmitter Signal Element Timing (DCE)
16      DCE     Data    Secondary Received Data
17      DCE     Timing  Receiver Signal Element Timing (DCE)
18      DTE     Ctl     Local Loopback
19      DTE     Ctl     Secondary Request To Send
20      DTE     Ctl     DTE Ready
21      DTE     Ctl     Remote Loopback
        DCE     Ctl     Signal Quality Detector
22      DCE     Ctl     Ring Indicator
23      DTE     Ctl     Data Signal Rate Selector (DTE)
        DCE     Ctl     Data Signal Rate Selector (DCE)
24      DTE     Timing  Transmitter Signal Element Timing (DTE)
25      DCE     Ctl     Test Mode

-- 
/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B



[See also
  http://www.stokely.com/unix.serial.port.resources/A-B-Ycablepinout.html
  http://lib1.store.vip.sc5.yahoo.com/lib/anysystem/SunCables.pdf
]

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.sys.palmtops.pilot
Organization: Road Runner
Message-ID: <o_BX4.29304$Ft1.1320371@typhoon.ne.mediaone.net>
Date: Fri, 26 May 2000 21:26:44 GMT
From: richard f lansing <rlansing@mediaone.net>
Subject: Star Tac serial cable pin assignment

Motorola Star Tac serial cable for star tac digital cdma dual mode cell:

pin 1: blue
pin 2: orange   TD    (to pin 3   RD    of 10-pin palm platform device
hot-sync cable)
pin 3: red         RD   (to pin 5   TD
.........................................................................)
pin 4: brown    DSR (to pin 1   DTR
.........................................................................)
pin 5: green      SG   (to pin 10 SG
.........................................................................)
pin 6: yellow
pin 7: black      CTS (to pin 4   RTS
.........................................................................)
pin 8: purple     RTS(to pin 6   CTS
.........................................................................)
pin 9: white


 //////////////////////////////////////////////////////////////////////////////


Organization: University of Cambridge, England
References: <Pine.LNX.4.21.0007031503030.17695-100000@itdcaa.hants.gov.uk>
Message-ID: <8jq6ng$ji2$1@pegasus.csx.cam.ac.uk>
Newsgroups: comp.terminals
Date: 3 Jul 2000 14:07:44 GMT
From: Ben Harris <bjh21@cus.cam.ac.uk>
Subject: Re: Break signal??? to Sun box

In article <Pine.LNX.4.21.0007031503030.17695-100000@itdcaa.hants.gov.uk>,
Tony Singleton  <itdcaa@hants.gov.uk> wrote:
>
>     Does anyone understand what happens when a terminal sends a Break
> signal? I think that the TD line from the terminal to the DTE is held at
> zero volts for a period of time,

It's a continuous MARK, which in RS-232 is a continuous -12V-ish.  If your
receiver decides that 0V is closer to -12V than to +12V, it'll consider
ground to be MARK.

> I believe that this can occur either from
> pressing the break key or powering off the terminal. What's the proper
> meaning of a break signal (my Sun server running Solaris drops to a
> firmware prompt)?

I don't think it generally has a defined one.  On Unix systems, it's
traditional for it to generate a SIGINT.  On many systems, it's used as a
signal to break out of the current process into some kind of supervisor (or
into a ROM monitor as on Suns).

> Can software like minicomm generate these break signals?

Yes.  On POSIX systems, tcsendbreak() sends a break.  I expect minicom has
some way to request this.


--
Ben Harris
Unix Support, University of Cambridge Computing Service.
  If I wanted to speak for the University, I'd be in ucam.comp-serv.announce.

 ..............................................................................

      [Solaris 8 (and newer) allows configuration of an "Alternate Break"
       sequence to avoid problems from serial disruption; see "man kbd".]

 ..............................................................................

Newsgroups: comp.terminals
References: <Pine.LNX.4.21.0007031503030.17695-100000@itdcaa.hants.gov.uk>
    <8jq6ng$ji2$1@pegasus.csx.cam.ac.uk>
NNTP-Posting-Host: phorcys.east.sun.com
Organization: Sun Microsystems Inc. - BDC
Message-ID: <xoavvgykyhna.fsf@sun.com>
From: James Carlson <james.d.carlson@sun.com>
Subject: Re: Break signal??? to Sun box

bjh21@cus.cam.ac.uk (Ben Harris) writes:
> In article <Pine.LNX.4.21.0007031503030.17695-100000@itdcaa.hants.gov.uk>,
> Tony Singleton  <itdcaa@hants.gov.uk> wrote:
> >     Does anyone understand what happens when a terminal sends a break
> >signal? I think that the TD line from the terminal to the DTE is held at
> >zero volts for a period of time,
>
> It's a continuous MARK, which in RS-232 is a continuous -12V-ish.  If your
> receiver decides that 0V is closer to -12V than to +12V, it'll consider
> ground to be MARK.

That's close but backwards.  An idle asynchronous line is held in MARK
(-12V) condition.  A break is a SPACE (+12V) condition that lasts
longer than a valid character time (typically, it's set for at least
100 milliseconds).

This is a glitch that terminal server vendors have had to live with
for many years.  For one example, see:

http://www.cisco.com/warp/public/770/fn-tsbreak.html

--
James Carlson, Internet Engineering       <james.d.carlson@east.sun.com>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.unix.admin,comp.sys.sun.admin,comp.unix.solaris,
    comp.sys.sun.hardware
References: <3A2B5320.59BC2419@cisco.com> <90gnk5$71f$2@news.panix.com>
    <3A2C61C4.66A0DE5F@cisco.com> <90ht70$hvv$1@news.panix.com>
Date: Mon, 04 Dec 2000 23:24:03 -0800
Organization: Cisco Systems
Message-ID: <3A2C9813.83BBC4BE@cisco.com>
From: Francis <franciso@cisco.com>
Subject: Re: Null Modem Cable fr RJ45-to-DB25 Modem Adapter.

Hi Greg,
    Here's the pinout for RJ45:

    1 - RTS
    2 - DTR
    3 - TXD
    4 - GND
    5 - GND
    6 - RXD
    7 - DSR
    8 - CTS
    Actually, this pinout is referring to the console port at Cisco
Access Server (which is of type RJ45)

     Appreciate your help.

Regards,
Francis.

Greg Andrews wrote:

> franciso@cisco.com writes:
> >Hi Greg,
> >    The pinout for RJ45-to-DB25 modem adapter is as follow:
> >
> >      4 (RTS)
> >     20 (DTR)
> >      3 (TXD)
> >      7 (GND)
> >      2 (RXD)

> >      8 (DCD)
> >      5 (CTS)
> >
>
> You have listed the pinout for the DB25 connector on a modem.
>
> That's not what I asked for, and it doesn't help me answer your
> original question.
>
> Please post the pinout of the Cisco RJ45 jack.  Not a diagram of
> any cable, just the pinout of the RJ45 jack.
>
>   -Greg
> --
> +++++ Greg Andrews +++ gerg@panix.com +++++

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.admin,comp.sys.sun.admin,comp.unix.solaris,
            comp.sys.sun.hardware
Message-ID: <90jedp$173$1@news.panix.com>
References: <3A2B5320.59BC2419@cisco.com> <3A2C61C4.66A0DE5F@cisco.com>
    <90ht70$hvv$1@news.panix.com> <3A2C9813.83BBC4BE@cisco.com>
Date: 5 Dec 2000 19:07:37 GMT
Organization: I have a map of the United States that's actual size
From: Greg Andrews <gerg@panix.com>
Subject: Re: Null Modem Cable fr RJ45-to-DB25 Modem Adapter.

franciso@cisco.com writes:
>
>    Actually, this pinout is referring to the console port at Cisco
>Access Server (which is of type RJ45)
>

You're trying to connect your Sun to the *console* port of your Cisco?
I thought you had a terminal server and wanted to connect the sun to
one of the regular ports instead of the console port.

At any rate, here's the proper wiring for of null modem cable for
the console port you posted:

   Cisco RJ45    Sun DB25
   ----------------------
    1 - RTS  ---  CTS - 5
    2 - DTR  ---  DCD - 8
    3 - TXD  ---  RXD - 3
    4 - GND  ---  GND - 7
    5 - GND
    6 - RXD  ---  TXD - 2
    7 - DSR  ---  DTR - 20
    8 - CTS  ---  RTS - 4

Note that you can connect the DB25 ground pin (7) to either of the
ground pins on the RJ45 (4 or 5).

  -Greg
--
+++++ Greg Andrews +++ gerg@panix.com +++++
I have a map of the United States that's actual size.  -- Steven Wright

 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.terminals,comp.os.linux.development.system
Message-ID: <3A37B40C.C5838F79@post.publicly>
References: <3A373361.3AE50551@gmx.de>
NNTP-Posting-Host: dhcp224.glerl.noaa.gov
Date: Wed, 13 Dec 2000 12:38:20 -0500
From: Ron <please@post.publicly>
Subject: Re: Q: Linux serial line programming, open() hangs

Christoph wrote:
>
> Hi,
>
> if i start my program the second time, it hangs infinitly at the open()
> system call. The first time everthing worked fine.
>
> Do you know why  this is and how to avoid it ?
> Would be nice, if you could have a quick look at the serial connection
> part of the sources attached.
>
> Thanks in advance,
> Christoph Hagedorn

Don't have time to review your code, but consider this: you have to open the
device before you can set the flags.  So it opens under the old settings,
which may block!  What I do is open the port non-blocking, set the flags,
close it and then reopen it in the blocking mode before using it.

Ron

 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.unix.solaris
Message-ID: <9dac6a$41u$1@bob.news.rcn.net>
References: <l.989355830.1460357666@[208.226.242.23]>
Date: 9 May 2001 03:05:46 GMT
From: lstowell@lenny.sfrn.dnai.com (Lon Stowell)
Subject: Re: Resistor circumvention of BREAK signal

In article <l.989355830.1460357666@[208.226.242.23]>,
 <u242004394@spawnkill.ip-mobilphone.net> wrote:
>Does anyone have some light to add to this exchange?  Thanks,
>
>    - Stephen P. Schaefer
>
>    From: "Celeste Stokely" <celeste@stokely.com>
> Subject: RE: http://www.stokely.com/unix.sysadm.resources/faqs.sun.html
>    Date: Tue, 8 May 2001 14:23:57 -0600
>      To: <Stephen.Schaefer@emis-intl.com>
>Reply-To: <celeste@stokely.com>
>
>Ooh - you got me there. In The Olde Days, pin 25 used to be attached
>to ground (frame ground?). It isn't these days. My most recent info
>came from a Cisco doc about this, but I don't know if it includes
>WHY pin 25 should work. (But, I bet it wouldn't work on modern Suns.)



   Pin 25 hasn't been a ground that I can ever recall in the
   EIA or RS spec.  

   Pin 1 is chassis ground, which really shouldn't be used for
   signal referencing, and Pin 7 is the data signal reference,
   aka signal ground.   

   The EIA binary 1 for data is a voltage between -3 and
   -25 or -30 volts.  A binary 0 for data is between +3
   and +25 [or 30] volts into the input impedance.  The
   receiver is SUPPOSED to totally ignore any transitions
   that occur strictly between the +3 and -3 region, but
   far too many don't, and will trigger data sensing on
   changes in that region when they shoud not. 

   A break results when the input to RX Data goes from a 
   binary 1 [-3 or more] volts up thru +3 [or less for
   a crappy EIA circuit] and stays there through what
   should have been the stop bit time.   

   A 4.7K ohm resistor to pin 7 frequently works, you can
   get more exotic with a diode, cap, and resistor but
   it is rarely needed.  Some also use the resistor 
   between pin 20 [DTR which is a voltage high, a binary
   1, but a data 0] and RX Data.  


 //////////////////////////////////////////////////////////////////////////////

Date: 9 May 2001 01:36:16 GMT
Organization: I have a map of the United States that's actual size
Newsgroups: comp.unix.solaris
Message-ID: <9da6ug$7hq$1@news.panix.com>
From: Greg Andrews <gerg@panix.com>
Subject: Re: Resistor circumvention of BREAK signal

u242004394@spawnkill.ip-mobilphone.net writes:
>
>In the section on overcoming the BREAK signal, you report
>
>    * Resistor/soldering iron hack method:
>      
>          * This solution may not work for all devices. If you tie a    
>4.7K resistor (1/4 Watt) between pins 3 and 25 of the ttya
>          port, you electrically prevent a BREAK signal either from the
>          key or from disconnecting or powering down the terminal. This
>          prevents intentional halts except by removing the resistor,
>          but does allow recabling.
>
>
>I'd appreciate a better explanation.  Your page on the pinouts for most
>Sun systems shows Pin 25 as a ``No Connection'' -- not a ground, not a
>constant on/space/0/+3V thru +12V, not a constant off/mark/1/-3V thru
>-12V.  If the ``No Connection'' is true, I believe a resistor to that
>pin would have no effect.  I Am Not An Electrical Engineer, but it seems
>like a resistor to a *ground* pin, like pin 7, *might* work.  Do you
>have access to any real EE's who could pronounce on this?  Thanks,


It won't work, in most instances.  The Cisco web page is Enormously
misleading, and any sites that echo the Cisco page are just as
misleading.  (Celeste's page is the least misleading of the ones
I've seen so far)

The resistor between pin 3 and 25 method originated in an e-mail message
sent to Sun Support several years ago (ca. 1992 or 1993) by a Sun customer.
It was something that the customer tried and enjoyed some success with.
Sun support has given the details of the method out from time to time,
but they have never promised that it would work.  Apparently some folks
at Cisco got hold of the method and re-published it on their web site.

Here are the three most important facts about the resistor method,
followed by a more technical explanation of its effects:

  1) It was never designed to *block* break signals sent by a terminal,
     computer, or terminal server connected to the Sun machine.

  2) It was never *possible* for the resistor to block break signals
     transmitted from the terminal/computer/terminal-server.

  3) It was only intended to suppress glitches produced by plugging or
     unplugging an RS232 cable, so those glitches would not look like
     a break signal to the Sun.


Unplugging or plugging an RS232 cable causes the pins to make and break
contact a few times as you slide the connectors together.  This can
cause the signal on the Sun's RxD (Receive Data) pin to jump from 0V
to -5V and back as contact is made and broken.  Capacitance and/or
inductance in the cable can cause the voltage jump from -5V back to
0V to overshoot and produce a glitch of positive voltage.  If the cable
conditions are right, the glitch can rise above +3.5V, and can last
longer than a couple thousandths of a second (milliseconds).  This kind
of glitch looks exactly like a break signal to the Sun machine.

Glitches caused by cable capacitance or inductance like that usually
don't have a lot of energy behind them.  The resistor we're talking about
was designed to drain off enough energy so the cable-induced glitches
can't rise high enough or last long enough to look like a break signal
to the Sun.  So the resistor can sometimes help when unplugging or
plugging the console cable causes your Sun to halt.

However, it can't help the other kinds of break signals.  These are
often caused by powering the attached terminal/computer/terminal-server
down or up.  When this happens, the RS232 driver circuitry in the attached
device forces the voltage on the pin to +3.5V (or higher), and backs it
up with a LOT of energy from its power supply.  Since this kind of glitch
has plenty of energy behind it, the resistor can't drain enough away to
prevent the signal from looking like a break to the Sun.  The resistor
won't help.  (it was never intended to help this situation anyway)

The only solutions when you have equipment that glitches its outputs like
that are to (a) re-design the equipment to clamp the output voltage to
zero volts when the power is cycled, (b) replace the equipment with other
equipment that doesn't let its outputs glitch, or (c) reconfigure the Sun
to not halt on the break signal.


Infodoc 21258 on sunsolve.sun.com describes the patches and procedure
to make Solaris 2.6 and later halt on an "alternate" abort sequence
instead of the RS232 break signal.

     
  -Greg
-- 
+++++ Greg Andrews +++ gerg@panix.com +++++
I have a map of the United States that's actual size
                 -- Steven Wright


 //////////////////////////////////////////////////////////////////////////////

Date: Wed, 09 May 2001 00:10:16 GMT
Organization: Excite@Home - The Leader in Broadband http://home.com/faster
Newsgroups: comp.unix.solaris
Message-ID: <3AF88AD1.EA878F64@home.com>
From: Andrew Sun <as000004@home.com>
Subject: Re: Resistor circumvention of BREAK signal



According to a copy of EIA/TIA-232-E, pin 25 is TM "test mode",
direction is from DCE.
"Signals on this circuit indicate whether the local DCE is
in a test condition."

Whether pin 25 is really connected and used on a Sun workstation
is implementation specific (I don't know, and my guess is
no connection).

A "break" signal is a prolonged space/logic0/+3V thru +12V
condition on a data (transmit/receive) line.  To prevent
a false break, it would be necessary to hold the affected line
as mark/logic1/-3v thru -12v during transient events.
Grounding the pin, via resistor or otherwise, would place the
line in an ambiguous state, since -3v < 0 gnd < +3v.  Thus,
it might, or might not work as a false break prevention method.
Similarly, floating (disconnecting) an input pin would also place it
in an ambiguous state, which may also be interpreted as a break.

A powered down console terminal likely places its output
signal lines in a floating state.  Thus, a resister on the
Sun connecting a now floating RD to a line that's usually in a
mark state (TD, RTS, or DTR should be mark for an idle port)
should prevent the floating pin ambiguity, and hold the pin as
mark.  The resister should allow the RD line to operate normally
when the console terminal is powered.  Note that I haven't given
this much thought, so I will not advise whether this is a good
solution, or whether it would even work.  Thus, all the usual
disclaimers apply.

Another item of concern are the simple solutions that
electrically prevents an intentional BREAK.  This could prevent
normal serial communications from working at all.  Transmitting
characters is the electrical equivalent of sending large numbers of
carefully timed, very short duration BREAKs.


> If the ``No Connection'' is true, I believe a resistor to that
> pin would have no effect.

If the resister isn't connected to anything (no connection),
yes, it would have no effect.

> but it seems
> like a resistor to a *ground* pin, like pin 7, *might* work.

Or it might not, as discussed above.  


-- 
"Using & Managing PPP," http://www.oreilly.com/catalog/umppp

  
 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.sys.sun, comp.sys.sun.hardware, comp.unix.solaris
References: <03p38.8963$l61.29054@rwcrnsc54>
    <7Es58.38703$oE5.3506141357@newssvr21.news.prodigy.com>
Message-ID: <a36grc$ro2$1@news.panix.com>
Organization: I have a map of the United States that's actual size
Date: 29 Jan 2002 15:58:36 GMT
From: Greg Andrews <gerg@panix.com>
Subject: Re: HELP!!! how to send a break across a modem to a console port?

Darren Dunham <ddunham@redwood.taos.com> writes:
>
>Most will not simply pass through a BREAK signal, the modem itself won't
>(it's an RS-232 signal, not a character).
>


False.  Modems have always transported RS232 break signals for decades.

It's true that the break signal can't "pass through" modems as it does
through a cable.  However, when the modems are configured properly, the
local modem will recognize your break signal, send a notice to the remote
modem (these days it's usually through the error control protocol), and
the remote modem will generate a break signal on its RS232 interface.

That's what a terminal server would do from an attached RS232 terminal.
>
>*however*, if you Solaris 8, or 2.6 or 7 with sufficient patches, you
>can change the halt signal on the box (only with the OS running) from
>the RS-232 BREAK signal, to a 3 character ascii string: A <RETURN>,
>followed by a "~", followed by a "b".  If you set that up, then you may
>not need the BREAK signal at all.
>

That's Return, Tilde (~), Control-B.


  -Greg
-- 
+++++ Greg Andrews +++ gerg@panix.com +++++
I have a map of the United States that's actual size
                 -- Steven Wright

  
 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.sys.sun.admin
References: <58e9e63e.0210100422.1644888f@posting.google.com>
Message-ID: <ao48rj$es8$1@reader1.panix.com>
Date: Thu, 10 Oct 2002 16:11:31 +0000 (UTC)
From: Greg Andrews <gerg@panix.com>
Subject: Re: V120 serial port -- the same pin assigment with Netra t1 AC200?

hugeng@yahoo.co.jp (Hu, Geng) writes:
>
> A quick question: does the Sun V120 server use the same
> serial port pin assignment as the Netra T1 AC200?

Yes.  If you want to connect a modem, you can wire the V120's DSR
pin to your modem's DCD pin.  This won't work with the Netra t1 or
Netra X1 machines, but it will with the Vxxx machines with RJ45
serial port connectors.

  -Greg

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.solaris
NNTP-Posting-Host: byers.east.sun.com
NNTP-Posting-Date: Mon, 3 May 2004 14:08:39 +0000 (UTC)
References: <c7d57ea4.0405030310.1e7afeba@posting.google.com>
Message-ID: <c75jp7$j19$1@news1nwk.SFbay.Sun.COM>
Organization: Sun Microsystems Corporation
Date: Mon, 03 May 2004 10:08:38 -0400
From: ML Starkey <martha.starkey@sun.com>
Subject: Re: Access Sun E250 via cable

Trev wrote:
> Hi,
> 
> I've been trying to connect my windows pc to my solaris E250 server
> using a null modem cable 9pin to 25pin. I have no problems connecting
> to my Sun Fire 210 using the cable those servers came with - 9pin to
> RJ45.
> I've bought and created my own null modem cable to be sure it's not
> the cable.  Is there a setting on the E250 to allow terminal
> connections.  There is no keyboard pluged into the server too.  There
> is a video card in the server which is comming out, but before I
> remove the video card I need to ensure that I can connect to the
> server via cable.
> I have tried using hyperterminal and Secure CRT.


The E250 has a 25-pin (DB-25) serial port and the 210 has a serial 
management port and a 9-pin (DE-9) serial port.  Despite similarites
(they are all serial ports of some kind), best to think of them as
apples and oranges.

There is no setting to allow terminal connections.  If you are having 
problems, then it's your cabling, your null modem connectors, your 
gender changers, etc. Something in that setup.  All you need on the 
terminal side is 9600, 8, n, 1 no flow control.

You would want to make sure that the eeprom settings for the 250 for 
input-device and output-device are either keyboard and screen 
respectively OR both set explicitly to ttya (or ttyb)  You don't have
to remove the video card if you don't want to.

If you have other Sun systems available, try a standard null modem between
the 250 and another sun with an available 25-pin serial port and use

    # tip -9600 /dev/cua/X

(where X is whatever that available port is) as root.

-- 
Martha

 //////////////////////////////////////////////////////////////////////////////
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Newsgroups: comp.dcom.telecom
Path: cs.utk.edu!news.msfc.nasa.gov!sol.ctr.columbia.edu!howland.reston.ans.net
      !news.moneng.mei.com!uwm.edu!lll-winken.llnl.gov!telecom-request
Message-ID: <telecom14.407.5@eecs.nwu.edu>
Organization: TELECOM Digest
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 14, Issue 407, Message 5 of 7
Lines: 98
Date: Tue, 09 Nov 1994 03:11:44 -0400
From: Monty Solomon <monty@roscom.COM>
Subject: GeoPort Technology

Passed along FYI to the Digest -

Strong Support for GeoPort Technology Paves Way for Development of
Standard Link Between Computers and Telephones
 

CUPERTINO, CA--October 19, 1994--Apple Computer, Inc., together with
leading computer and telephony vendors, today announced the emergence
of GeoPort as their preferred cross-platform computer telephony
interconnect standard.  Vendors participating in the announcement
include: AOX, Inc., AT&T Corp., Crystal Semiconductor Corp., Cypress
Research Corp., IBM Corp., Motorola, Inc., SAT Groupe SAGEM, Siemens
PN, Siemens Rolm Communications, Inc., and Zilog, Inc.

     GeoPort, developed by Apple Computer, is a plug-and-play serial
interface which is backward compatible with the serial ports used in
most personal computers, but offers over 200 times the bandwidth.
Beyond just providing a physical connection, it also hides the
differences between differing computer platforms and communications
systems, while allowing any kind of data to pass between them.

     Apple first introduced GeoPort in August 1993.  Later that year,
it began working with the major telephony and computer vendors
including AT&T, IBM, and Siemens Rolm, to refine GeoPort to fully meet
the needs of both communities.  Today's announcement reflects the
results of that joint effort.

     "With GeoPort, we are working to eliminate the technical and
economic barriers which have constrained the development and adoption
of personal communication products," said Rick Shriner, vice president
of Apple's core technologies group.  "With the support of both the
telephony and computer industries, we believe we are developing a
powerful building block for global communications and collaboration."

     GeoPort offers a powerful solution for both the computer and
telephony markets.  Telephone and computer customers will be able to
communicate and collaborate more easily and effectively than ever
before.  They will be able to talk to each other, send faxes and
computer data to each other, see each other, and share common
information, without having to worry about what kind of telephone,
telephone line, or computer happens to be present at each point of the
connection.

     Apple Computer, Inc., a recognized pioneer and innovator in the
information industry, creates powerful solutions based on easy to use
personal computers, servers, peripherals, software, online services,
and personal digital assistants.  Headquartered in Cupertino,
California, Apple (NASDAQ: APPL) develops, manufactures, licenses and
markets products, technologies and services for the business,
education, consumer, scientific & engineering and government markets
in over 140 countries.

     Apple, the Apple logo and Macintosh are registered trademarks, and
GeoPort is a trademark of Apple Computer, Inc.
 
ATTACHMENT

Fact Sheet
 
GeoPort Technology

GeoPort , developed by Apple Computer, is a plug-and-play serial
interface which is backward compatible with the serial ports used in
most personal computers, but offers over 200 times the bandwidth.
The serial communications architecture of GeoPort is optimized for
computer-telephony integration:

  - It allows any telephone (or telephone line, up to T1/E1 rates)
    to be connected to any computer, in any country in
    the world.
  - It supports any set of Telephony APIs (application programmatic
    interfaces) such as AT&T/Novell's TSAPI, IBM's
    CallPath, Microsoft's TAPI, or Apple's Telephone Manager.
  - It allows any telephone to take full advantage of the services
    provided by the computer, and vice versa.
  - It is inexpensive to implement, and uses existing technology.
  - It supports any type of information: computer data, voice,
    fax, modem, voice, video.
  - It allows multiple simultaneous streams of informationQincluding
    real time information like voice and videoQto pass through a
    telephone connection in order to be processed by the computer.
 
These services will allow vendors and developers the opportunity to
offer such features as:

  - An integrated mail-box for voice mail, email, and facsimiles.
  - Fax and modem capability over a digital telephone connection,
    like that found in an ISDN line or in many PBX environments.
  - Document sharing or other simultaneous voice and data
    applications over conventional phone lines.
  - Video conferencing over a PBX or ISDN connection.
  - Telephone assistant services, like automated call screening,
    call forwarding, and call tracking.

Apple, the Apple logo and Macintosh are registered trademarks and
GeoPort is a trademark of Apple Computer, Inc.

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  [As of 2002, the only mention of "GeoPort" on Apple's web site is a legal
   notice listing all of Apple's trademarks.  I guess the GeoPort product
   never made much impact.

   Now Firewire...

  ...RSS]

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.sys.sun.admin
Organization: I have a map of the United States that's actual size
Message-ID: <b1rkg6$kth$1@reader1.panix.com>
References: <b1orj0$2lc$1@news2.ipartners.pl>
    <b1p1ve$n47$1@reader1.panix.com> <b1qg69$vaf$1@news2.ipartners.pl>
Date: Wed, 5 Feb 2003 18:17:43 +0000 (UTC)
From: Greg Andrews <gerg@panix.com>
Subject: Re: Serial port configuration

"Jarek Tomaszewski" <jarek-tomaszewski@vertel.pl> writes:
> >
> >I'm trying to use one of serial port on Sparc workstation (Ultra 10 with
> >Solaris 8) to communicate with a device. Does anyone have an idea how to
> >configure a serial port (e.g. ttyb)?

"Greg Andrews" <gerg@panix.com> wrote:
>
> You don't configure a serial port.  The software that opens the port
> and communicates with the external device performs the port configuration.

"Jarek Tomaszewski" <jarek-tomaszewski@vertel.pl> writes:
>
>That sounds reasonable but what should I do when I get information
>that the port is already in use.
>

Find out what is using it.  For serial port "A", you can use fuser:

  fuser /dev/term/a
  fuser /dev/cua/a
  fuser /dev/ttya

If fuser finds processes that have the port open, it lists the
process numbers, each with a letter appended to the number.
The fuser man page describes the meaning of the letter.

Once you have one (or more) process numbers, use ps to see
what the processes are.  For example, process number 327:

  ps -fp 327
       UID   PID  PPID  C    STIME TTY      TIME CMD
      root   327   324  0   Feb 03 ?        0:00 /usr/lib/saf/ttymon


>
>I managed to delete login service association but it
>is still in use :-(
>

If the serial port is the system console, you won't be able
to use it for other things.  Use the other serial port.


>
>What is the best terminal console application working with serial port?
>

Depends on what you're using the serial port for.  Your question is
vague, but it suggests you are trying to connect from your local
SPARC serial port to the serial console of another machine.

If that's what you are trying to do, then the combination of dtterm
or xterm and a program like tip or kermit or minicom will do.
Dtterm or xterm handles the terminal emulation, and the other program
(tip, kermit, or minicom) handles the serial port I/O.  Tip comes
with Solaris, and all you need to do is log in as root and type:

  tip  -9600  /dev/cua/a      (or /dev/cua/b for the "B" port)

Then your keystrokes will go out the port and what comes in the port
will be displayed in the dtterm/xterm window.  When you want to send
a break signal, type Return, then Tilde (~), then Number sign (#).
When you want tip to close the serial port and exit, type Return,
then Tilde (~), then Period (.).


  -Greg

-- 
Do NOT reply via e-mail.
Reply in the newsgroup.

/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /

   [Archiver's Note: I have found by personal experience that Greg 
    really does prefer to communicate via newsgroups.]

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.sys.sun.admin
Organization: Sun Microsystems
Message-ID: <3E40FB92.FDC90840@sun.com.spam>
References: <b1orj0$2lc$1@news2.ipartners.pl>
Date: Wed, 05 Feb 2003 11:54:58 +0000
To: Jarek Tomaszewski <jarek-tomaszewski@vertel.pl>
From: Chris Lawson <chris.lawson@sun.com.spam>
Subject: Re: Serial port configuration

Jarek Tomaszewski wrote:
> 
> Hi,
> I'm trying to use one of serial port on Sparc workstation (Ultra 10 with
> Solaris 8) to communicate with a device. Does anyone have an idea how to
> configure a serial port (e.g. ttyb)?

Jarek,

Try this site.

    http://www.stokely.com/unix.serial.port.resources/index.html

-- 
Chris

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.sys.sun.admin, comp.sys.sun.hardware
References: <3E46F79E.EAA1E4C9@ntlworld.com>
    <b275q6$eoq$1@reader1.panix.com> <b27pgv$19v0i8$1@ID-40235.news.dfncis.de>
Message-ID: <b2gh7n$nqt$1@mozo.cc.purdue.edu>
Organization: Purdue University
Date: Thu, 13 Feb 2003 16:30:47 +0000 (UTC)
From: Jeff Wieland <wieland@nospampurdue.edu>
Subject: Re: Any way of getting cheap serial ports??

In article <b27pgv$19v0i8$1@ID-40235.news.dfncis.de> "David Wade" <g8mqw@yahoo.com> writes:
>
>"Greg Andrews" <gerg@panix.com> wrote in message
>news:b275q6$eoq$1@reader1.panix.com...
>> "Dr. David Kirkby" <drkirkby@ntlworld.com> writes:
>> >Rich Teer wrote:
>> >
>> >Yes, ethernet is fine until there is a problem!
>> >
>> >>         2. Get a PCI card with multiple serial, and a driver for them.
>> >>            Ebay might be a good source for these, but I have no idea
>> >>            what the cost would be.
>> >
>> >I was hoping that someone might say use model XYZ and the drivers in
>> >Solaris will work for it, but perhaps no such luck.
>> >
>>
>> Well, you can get Sun's SAI/P card, but your subject line
>> uses the word "cheap", and I haven't hear Sun's card called
>> cheap.
>>
>> Digi makes multiport PCI cards, I believe, though I don't know
>> if they're cheap either.
>>
>
>In the PC world the DIGI cards are widely used, but as Greg says they are
>far from cheap new.
>The DIGI web site (www.digi.com) seems to indicates some have Solaris
>drivers.
>
>There are also one or two on E-Bay but I am not sure how old they are, if
>there are Solaris drivers for them to whatever. However the current prices
>do look cheap so it might be worth a bid. Just make sure you get all the
>bits you need first, (cables and card) as getting any missing bits from digi
>is likely to be very expensive.
>
>>   -Greg
>> --
>> Do NOT reply via e-mail. Reply in the newsgroup.


If you can find any of the old Central Data SCSI terminal servers,
they work quite well.  Digi bought out Central Data.  There are
drivers for up to at least Solaris 8.  You don't want to put them
on the same bus with UltraSCSI devices, but they'll work fine
with the Symbios-based UltraSCSI HABs.

There's a 16 port unit on Ebay right now:

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3401611084&category=1484

We ran a pair of these on an SS20, driving a total of 24 Courier
V.Everything modems.  They are very low overhead devices.

Assuming that you have a PCI slot to spare, you could pick up
a cheap Symbios SCSI controller, and be off and running.
--
Jeff Wieland


 //////////////////////////////////////////////////////////////////////////////


Newsgroups: comp.unix.solaris
References: <iFGba.37095$Rc7.528990@news2.e.nsc.no>
Message-ID: <b4od3s$22d691$1@ID-128882.news.dfncis.de>
Organization: San Francisco, CA
Date: 12 Mar 2003 22:42:05 GMT
From: Andrei Ivanov <iva@racoon.riga.lv>
Subject: Re: linux and solaris serial connection

Howieman <l-han3@online.no> wrote:
> I am using my laptop with Linux mandrake at work.
> But I need to be able to connect it to Sun-computers through a serial-line.
> Can anyone help me with this. I need an explaination on how to do this.
> With two Solaris-computers I can use the "tip hardwire"-command. How is this 
> done from linux to solaris?

Under linux you can use 'minicom'. By default it assumes higher speed,
so, you might place the following into your /etc/minirc.dfl:

  pr port             /dev/ttyS0
  pu baudrate         9600
  pu bits             8
  pu parity           N

Then start 'minicom -o'.

-- 
andrei

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: alt.folklore.computers
Message-ID: <1kck7b.d0a1.ln@via.reistad.priv.no>
References: <3e8ae086.45754328@news.m.iinet.net.au>
    <mi1c9vsheprtl6jme56vg5bs4vd20i180i@4ax.com>
    <sb9f7b.mei.ln@escape.shannon.net>
    <d8mp9v8qm66rreucp5svj8213lrh6q4jo6@4ax.com>
Date: Wed, 16 Apr 2003 21:57:53 +0200
From: Morten Reistad <mrr@reistad.priv.no>
Subject: Re: Any DEC 340 Display System Doco ?

According to Brian Inglis  <Brian.Inglis@SystematicSw.ab.ca>:
>
>On Mon, 14 Apr 2003 17:31:40 -0400 in alt.folklore.computers,
>Charles Shannon Hendrix <shannon@news.widomaker.com> wrote:
>
>>In article <mi1c9vsheprtl6jme56vg5bs4vd20i180i@4ax.com>, David Powell wrote:
>>>
>>> In article <b73pco$2j0m$1@citadel.in.taronga.com>,
>>>  peter@taronga.com (Peter da Silva)  in alt.folklore.computers wrote:
>>> 
>>>>
>>>>You have to remember how slow 9600 bps is, and how slow the vt100 is.
>>> 
>>> Yup, VT100s are s-l-o-o-o-o-o-w.
>>
>>One thing I noticed with them, is that under PrimeOS, I rarely had any
>>screen corruption problems, but had it frequently when accessing DEC
>>systems, or some UNIX systems.


That was only because the original Prime AMLC (8/16 port async card)
was designed even more bogus than the RS232 drivers in the VT100.

This board and its drivers were the single most expensive design
mistake Prime ever did.


>Lousy wiring and/or RS-232 drivers and receivers: you're only
>guaranteed up to about 25' at 9600bps with good cables and
>electronics, and proper grounding at both ends; half that for
>each speed doubling; some drivers may source 5V, others may
>source 25V; there are no guarantees in the spec, only limits;
>better cables and better cable routing can solve some problems;
>neither UTP or STP are really good for RS-232; external limited
>distance datasets (LDSes) can handle the wiring better; YMMV. 


RS232 stinks, pure and simple. 

Follows a line of backwards compatability with bogus open-ended
half-specified interfaces dating way too far back.


>>These days I run a DEC 510, and I get corruption now and then.  Not sure
>>if the old Sun server can't keep up, or the terminal is having problems.
>
>Corruption is almost always electrical or line/wire problems, not
>really the fault of the terminal or the host (unless the drivers
>and/or receivers are wimpy); their chips sample according to the
>spec, and interpret the bits according to the voltages received;
>your only recourse is to shorten the wires or boost the signal;
>this is based on my experiences long ago with RS-232 and wiring. 


Bad async hardware and drivers was a common problem on minicomputers and
their terminals. It made a whole aftermarket of line drivers, local-modems, 
optoisolators, and muxes that went away with the Internet. 

-- mrr

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.bsd.freebsd.misc
Message-ID: <86y8xgo3wl.fsf@cail.baugher.pike.il.us>
Organization: ESC
Date: Tue, 26 Aug 2003 10:05:30 -0500
From: Aaron Baugher <abaugher@esc.pike.il.us>
Subject: Dead serial ports

I've got a really odd serial port problem.  I'm not even sure it's
FreeBSD related, but I have to start somewhere...

I had a system running 4.8-RELEASE on an old Pentium 200 system,
dialing up ppp through an external modem on /dev/cuaa0 (COM1).  All
worked fine, until the hard drive had to be replaced.  I thought I'd
upgrade to 5.1 while I was at it.  Everything worked fine, except ppp
timed out waiting for a response from the modem.  I tried talking
directly to the modem, and while the TR light comes on, nothing I type
does anything and the send/receive lights don't flash like they
should.

So I tried a different modem.  Tried COM2.  Different old motherboard
(Cyrix 166).  luck.  Different serial cable.  Tried going back to
4.6_2-RELEASE (what I happened to have on CD).  Finally I even tried
OpenBSD.  Nothing worked; in every case I can't get any data through
the serial ports, although the TR light on the modem lights up to show
it's got a connection.

The only way I can get it to work is to plug the modem into the serial
port on a newer computer (Pentium 800), but I can't spare that for my
dialup system right now, so that's not a long-term option.

Anyone have any suggestions?  As you can see, I've now replaced every
component in the chain -- software, hardware, cables, etc -- and
nothing helps.  It sort of seems like an IRQ problem, but I don't know
why that would have started happening all of a sudden, especially
since this is a very bare-bones system -- just a video card and
ethernet card; nothing to cause an IRQ conflict.

Just had a thought: Is it possible for a faulty power supply to cause
problems with the serial ports while everything else works?  I think
that's the only part I haven't swapped out.


Thanks,
-- 
Aaron
abaugher@esc.pike.il.us


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.bsd.freebsd.misc
References: <86y8xgo3wl.fsf@cail.baugher.pike.il.us>
Message-ID: <bigbgv$k1b$1@bob.news.rcn.net>
Date: Tue, 26 Aug 2003 15:13:27 -0400
From: Jason Bourne <testuser@workstation.zip>
Subject: Re: Dead serial ports

"Aaron Baugher" <abaugher@esc.pike.il.us> wrote in message
news:86y8xgo3wl.fsf@cail.baugher.pike.il.us...
[snip]
> Just had a thought: Is it possible for a faulty power supply to cause
> problems with the serial ports while everything else works?  I think
> that's the only part I haven't swapped out.
[snip]

Greetings:

    The serial ports make use of +/- 12 volts dc from the power
supply to generate the rs-232 signal. Check the 12vdc output
from the power supply; even if present it would be nice to view
it on an oscilloscope to look for excessive ripple.

-Jason

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals, comp.os.linux.hardware
Message-ID: <rshu_20030917232323@stratagy.com>
References: <3f689f9f$0$20186$626a54ce@news.free.fr>
Organization: The Late, Great Stratagy Users Group
Date: Wed, 17 Sep 2003 23:23:23 GMT
From: Richard S. Shuford <shuford%list.stratagy.com>
Subject: Re: How to plug a WYSE 185ES (serial connections)

David le Bourgeois wrote:
|
| I have a WYSE 185-ES terminal and a classic PC under Linux.
| But I know neither where to connect it nor how.  I don't understand
| anything with all that relates to the possibility of "wiring".  I
| know serial and parallel port. I see what is a null modem cable
| (DB9, DB25). But I'm not able to do something, because I don't know
| how to plug the device :-(  Which sort of cable?  I tested with the
| same cable which is useful for my scanner (a null one I suppose?).
| But it seems to me that it is the parallel one, because it is more
| larger than the serial one.   
  
On a typical PC, a 25-pin D-shaped connector (DB-25) may be either
a serial or a parallel port.  However, the custom adopted in 1981
by IBM for its first Intel-8088-based PC is that a serial connector
mounted on a chassis is expected to present pins (male), whereas a
parallel connector should be a female type.  If you have a mix of
male and female DB-25 connectors on the back of a PC, then,
probably the male ones are serial and female ones are parallel.


On a typical PC, if you have a 9-pin D-shaped connector, it is
usually a serial port, although rarely it might be for a joystick
or something else unusual.  Such a connector would properly be
called a "DE-9", yet because shell-size code letter's function is
not widely known, most descriptions call it a "DB-9".  Oh, if the
connector name has a suffix letter "DE-9-P" or "DE-9-S", in that
context it means "plug" (male) or "socket" (female), *not* parallel
or serial!
    
IBM introduced use of the DE-9-P for RS-232-C interfaces in 1985
with the "PC/AT" model (which was based on the 8-MHz Intel 80286
processor).

Furthermore, the serial port on a PC should be a DTE-type RS-232-C
interface.  If a DTE port is being connected to a DCE-type RS-232-C
interface (as you would find on a modem), a straight-through cable
is used.  To connect a DTE directly to another DTE (as connecting
a PC to a terminal), you need a cross-over cable wired as the
infamous "null modem", by means of which the two DTE serial ports
are each fooled into thinking it is connected to a modem.

Some equipment, however, may use female DB-25's for serial ports,
and the gender may not match the DTE or DCE flavor.  Your mileage
may vary.  No smoking.  Fasten seat belts.

A web site with diagrams is here:

    http://www.hardwarebook.net/connector/serial/serial25.html
    http://www.hardwarebook.net/connector/serial/serial9.html
    http://www.hardwarebook.net/connector/serial/rs232.html

Accumulated information on video terminals resides here:

    http://www.cs.utk.edu/~shuford/terminal_index.html

 ...Richard S. Shuford
    shuford(at)list.stratagy.com
-- 
/usr/xpg4/bin/date '+%C%y-%m-%d_%H:%M:%S'

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
NNTP-Posting-Host: ip70-185-194-243.ok.ok.cox.net
NNTP-Posting-Date: Wed, 05 Oct 2005 01:05:36 EDT
References: <1128198587.234600.195490@g44g2000cwa.googlegroups.com>
Message-ID: <AaJ0f.2881$eW1.970@okepread04>
Date: Wed, 05 Oct 2005 05:05:36 GMT
From: mroberds@worldnet.att.net
Subject: Re: Using Wyse 60 Terminals with Welch Allyn 8300 MICR scanners

s10jam@yahoo.com wrote:
>
> I have a customer who is using Wyse 60 Terminals with Welch Allyn 8300
> MICR scanners in a POS enviornment. The scanners connect through a
> serial wedge that runs between the serial port and the terminal.


Has this setup ever worked, or are you trying to bring up something new?


> When the wedge is not connected, the terminals work fine. When the wedges
> are connected, the terminals lock up when an item is scanned.


I can think of a couple of things that might be happening.  First, as
you hinted, the scanner could be set to the wrong serial speed.  This
probably makes the host computer see garbage when an item is scanned,
and it then doesn't give the right output to the terminal, so the
terminal appears to be locked up.  Most likely, the scanner should be
set to the same speed, data bits, parity, and stop bits that the
terminal is using.  Quite often this information is expressed as
something like "9600 8N1", which means 9600 bits per second, 8 data
bits, no parity, one stop bit.  This information should be in the
terminal setup screen somewhere--read the setting and then set the
scanner to match.

Another possibility is that the scanner might be doing something with
the handshaking lines that the terminal doesn't like.  Besides the data
lines, there are various control lines that can be used to start or stop
transmission.  For instance, if the host computer is sending too much
data to the terminal, the terminal can use a control line to signal the
host computer to wait for a little while.  The host can also tell the
terminal to stop, which is what might be happening.  First, see how many
wires are in the cable from the terminal to the host computer.  If it's
only two or three, then this isn't your problem.  If there are more
wires, get a serial "breakout box" with LEDs.  This plugs into the
serial line, just like the scanner does, and the LEDs indicate the state
of the data and control lines.  You can compare what the control lines
are doing before and after the terminal locks up to see if one of the
control lines isn't being reset by the scanner.

If none of this works, you may need to "snoop" on the communications
with a laptop with a serial port.  You can't see both sides of the
conversation at once, but sometimes looking at one side is enough.
You can get a two-port serial card and software if you want to see
everything, or you can rent a dedicated serial analyzer.

Matt Roberds

 ..............................................................................

Newsgroups: comp.terminals
NNTP-Posting-Host: 66.211.211.248
NNTP-Posting-Date: Thu, 6 Oct 2005 14:22:57 +0000 (UTC)
References: <1128198587.234600.195490@g44g2000cwa.googlegroups.com>  
    <AaJ0f.2881$eW1.970@okepread04>
Message-ID: <1128608571.572797.235310@z14g2000cwz.googlegroups.com>
Date: 6 Oct 2005 07:22:51 -0700
From: s10jam@yahoo.com
Subject: Re: Using Wyse 60 Terminals with Welch Allyn 8300 MICR scanners

Thanks alot for your help. I will look into this. It's not exactly a
new setup. The previous technicians were fired because this system did
not work correctly when they installed it and they could not resolve
the issue. Since then, I have been assigned to this project with no
prior experience with serial communications. I'm trying to find a
support number for Welch Allyn to make sure I am programming these
correctly. Now, I have set the scanners back to factory defaults and I
get no cummunication whatsoever to the terminal. I will try a few
things you have suggested. Thank you very much for your assistance.

 ..............................................................................

Newsgroups: comp.terminals
NNTP-Posting-Host: ip70-185-194-243.ok.ok.cox.net
NNTP-Posting-Date: Thu, 06 Oct 2005 23:30:33 EDT
References: <1128198587.234600.195490@g44g2000cwa.googlegroups.com>  
    <AaJ0f.2881$eW1.970@okepread04>
    <1128608571.572797.235310@z14g2000cwz.googlegroups.com>
Message-ID: <tZl1f.3246$eW1.1126@okepread04>
Date: Fri, 07 Oct 2005 03:30:33 GMT
From: mroberds@worldnet.att.net
Subject: Re: Using Wyse 60 Terminals with Welch Allyn 8300 MICR scanners

s10jam@yahoo.com wrote:
>
> Since then, I have been assigned to this project with no prior
> experience with serial communications.

You might look in "The Art of Electronics" by Horowitz and Hill, second
edition, pages 719-726, for a pretty good overview of RS-232 serial
communications.

Here are a few examples of the "breakout box" that I mentioned.  This
will show you if any of the data lines are changing at all, and may help
you debug the control lines, if used.

    http://www.trianglecables.com/rsbreakboxmo.html  (US$20)
    http://www.connecttech.net/product_info.php?products_id=791  (US$30)
    http://www.bb-elec.com/product.asp?sku=232bob1   (US$40)

(Standard disclaimers apply; I don't get money from any of the companies
mentioned.)

What you probably "should" have is something like this.  View this in a
fixed-width font:

+----------+      +---------+      +----------+
| Wyse 60  |      | Scanner |      |   Host   |
|          |      | "Wedge" |      | Computer |
|          |      |         |      |          |
|   Ground o------o---------o------o Ground   |
|          |      |         |      |          |
|  Receive o------o---------o------o Transmit |
|          |      |         |      |          |
|          |      |   A   C |      |          |
| Transmit o------o---O --O-o------o Receive  |
|          |      |         |      |          |
+----------+      | --O     |      +----------+
                  | | B     |
                  | |       |
                  +-o-------+
                    |
                    |
                    |
                  +-o--------+
                  | |        |
                  | Transmit |
                  |          |
                  |  Scanner |
                  |   Head   |
                  +----------+

The ground line between the Wyse 60, scanner wedge, and host computer
is always connected.  So is the line from the host computer "transmit",
through the wedge, and to the Wyse 60 "receive".  This line is how the
host computer sends data to be displayed on the Wyse 60.

The line from the Wyse 60 "transmit" is a little different.  When you
are not scanning anything, the scanner wedge should connect A to C.
This makes the data from the Wyse 60 go straight to the host computer
"receive", as if the scanner wedge wasn't even there.  But, when you
scan something, the wedge temporarily disconnects A and C, and connects
B to C.  This allows the scanner head to send data to the host computer
"receive".  When the scanner head is done, the wedge disconnects B and
C, and connects A to C again, so the terminal can send data to the host
again.

If, for some reason, the scanner head or wedge doesn't reconnect A to C
when it's done scanning, it will appear that the terminal has locked up.
If the scanner is set to the wrong speed, the host computer may see
garbage characters, as has been discussed.  The above picture and
description doesn't include the control lines that might also be in use.

Good luck!

Matt Roberds

 //////////////////////////////////////////////////////////////////////////////

Message-ID: <3F79BD82.1080900>
References: <3F621F2A.4070807> <3F652144.7040100@>
Date: Tue, 30 Sep 2003 10:29:38 -0700
To: Michael B.
From: Serge N.
Subject: Re: Serial cable for Apple iBook printing

> Serge N. wrote:
>
>> Hi ,
>> I just got an Apple iBook and am wondering if there is a way/cable
>> to connect my iBook to the serial port of a Sun box ??
>>
>> Also , I have a HP laserjet 4L , is there a cable to connect the 
>> parallel port of the printer to the USB on the iBook ??
>>

Michael B. wrote:
>
> Keyspan makes some really nice serial to USB adapters 
> (http://www.keyspan.com/). I have used their PDA adapter and it works 
> fine. Also they have a 4 port serial adapter I purchased. And that 
> works great with multiple windows. I use the serial ports to configure 
> new server in racks during installations. Also, I use Z-term (really a 
> great serial window emulator
>
> http://homepage.mac.com/dalverson/zterm/


Keyspan is great !

Both serial and parallel adapters work with OSX,

I use Gimp Print and Ghostprint for the Laserjet 4L .
And zterm to connect to the serial console of my Sun machines .
I bought both cables from CDW.

 http://www.cdw.com/

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
NNTP-Posting-Host: panix5.panix.com
NNTP-Posting-Date: Wed, 21 Nov 2007 07:53:37 +0000 (UTC)
References: <1194799022.891334.258620@o38g2000hse.googlegroups.com>
    <fhad70$5dk$1@nenevr.demon.co.uk> <fhdn09$f7g$1@panix1.panix.com>
    <fhf532$1lr$1@nenevr.demon.co.uk>
Message-ID: <fi0o61$fvu$1@panix5.panix.com>
Organization: Jeff's House of Electronic Parts
Date: 21 Nov 2007 02:53:37 -0500
From: Jeff Jonas <jeffj@panix.com>
Subject: Re: VT220 garbage characters

> I've got 2 VT420s doing multisession and a stray VT320 hanging off my
> Linux box - I've got an 8-port serial card in my machine to give me
> 10 serial ports in total.

I was just sorting my inventory of 2/4/6/8 port serial cards,
mostly ISA such as Stallion and Digi.
What ones are you still running?
Are they the bare UART or the "smart" ones?
I think the great cosmic joke upon us is how
the "dumb" ones are still useable with generic drivers
whereas the advanced "smart" ones may be useless
because the object-code-only drivers cannot run on new operating systems.

By any chance do you have a source for odd modular connectors
such as 10 position RJ69 (already crimped to a cable)?
Some of my serial cards have modular connector "harmonicas"
on the edge requiring RJ69 10-pin connectors.

Only 2 serial ports from the system: no COM3/4?
Gosh, I remember upgrading all my PC/AT systems
with a pair of ISA multi I/O cards for
4 serial ports, 2-3 parallel ports, etc.
But that's back when using a modem
and direct cables to all preipherals was the norm:
no ethernet or home network for device sharing.


> I've also got some USB->RS232 adapters as well
> which is a cheaper way of adding ports these days (as long as
> you don't mind not knowing which TTY
> will be assigned to which device when you power up!)

I am trying a bunch of those and it's quite a problem.
Most use the same USB to serial chip (so Linux auto-recognizes it),
but it is NOT 8 bit safe!
I could not download firmware to my microprocessor using one.

And I agree, the USB auto-magic configuration is useless
when dealing with multiples of any device!

-- 
-- mejeep deMeep ferret!

 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Newsgroups: comp.terminals
NNTP-Posting-Host: 70.185.217.138
NNTP-Posting-Date: Wed, 21 Nov 2007 02:00:01 MST
References: <1194799022.891334.258620@o38g2000hse.googlegroups.com>
    <fhad70$5dk$1@nenevr.demon.co.uk> <fhdn09$f7g$1@panix1.panix.com>
    <fhf532$1lr$1@nenevr.demon.co.uk> <fi0o61$fvu$1@panix5.panix.com>
Message-ID: <lsS0j.3319$mY1.1904@newsfe24.lga>
Date: Wed, 21 Nov 2007 09:00:01 GMT
From: mroberds@worldnet.att.net
Subject: Re: VT220 garbage characters

Jeff Jonas <jeffj@panix.com> wrote:
>
> I think the great cosmic joke upon us is how the "dumb" ones are
> still useable with generic drivers whereas the advanced "smart"
> ones may be useless because the object-code-only drivers cannot
> run on new operating systems.


I've gone through this lately myself with different hardware:

"We Support Linux!"

"Uh, does that mean I can download some random Linux distribution
and poke bytes at I/O ports and make your card do useful stuff, or
does that mean you're going to give me a binary-only driver that
refuses to run unless the kernel version matches down to the fifth
decimal place?"


> By any chance do you have a source for odd modular connectors such
> as 10-position RJ69 (already crimped to a cable)?


Googling gives

    http://www.trynci.com/cat/telco41.htm

they also claim to have loose RJ69 connectors

    http://www.trynci.com/cat/conn3.htm

and the crimp tool

    http://www.trynci.net/product_details.aspx?productid=4330

I've never tried to order from this company before; I just found them on
a search.

Standard disclaimers apply; I don't get money or other consideration
from any companies mentioned.

-- 
Matt Roberds


 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
 //////////////////////////////////////////////////////////////////////////////

Sun Netra/T1 serial port: one way to wire a DB25-RJ45 connector
   
        RJ45    DB25
RTS     1        5      CTS 
DTR     2        6      DSR
TXD     3        3      RXD
GRD     4        7      GND
GRD     5        7      GND
RXD     6        2      TXD
DSR     7       20      DTR
CTS     8        4      RTS
   
* system to system

U80(Serial Port B) <-------------------------> Netra T AC200(Serial Port B) 
  DB25 Connector     CAT5 Fast Ethernet Cable         RJ-45 Connector


 //////////////////////////////////////////////////////////////////////////////

Message-ID: <200310311825.h9VIP5c0006393@eastmail1bur>
Date: Fri, 31 Oct 2003 13:23:15 -0500 (EST)
From: Martha Starkey
Subject: Re: Looking for SunBlade-150 J13 adapter

Jim C. wrote:
|
| Anyone out there know where I can get one of these beasts?

The infamous "missing" Sunblade port b!
(Serial ports? Customers don't need any stinkin' serial ports!)

Here is some info on where Kenneth C. found a cable that would work:

---------
     A second serial port header is located on the riser board at
     J13--I took information  on the pin-out from the "Sun Blade
     150 Service Manual" (June 2002)--Sun document  816-4379-10;
     Appendix B5. You will need a DB9 serial connector to IDE-10
     mounted in a PCI slot--I took  mine from a very old 33DX PC
     which had the correct connections and gender as "ttya" i.e.,

         IDE/1  -  DB9/1
         IDE/2  -  DB9/6
         IDE/3  -  DB9/2
         IDE/4  -  DB9/7
         IDE/5  -  DB9/3
         IDE/6  -  DB9/8
         IDE/7  -  DB9/4
         IDE/8  -  DB9/9
         IDE/9  -  DB9/5

     Check  these yourself; do not rely on my typing them in
     correctly.  Given a ribbon connector of the correct type--a
     visual inspection of the back of the DB9 connector should
     reveal odd/even wires being connected to upper/lower rows (it
     looks very tidy).  Any crossing  of wires and you have the
     wrong inter-connect (could re-solder them to fix).

----------

The SunBlade 150 system handbook shows a mysterious
"DB9 Serial Extension Connector", but the 370-5267
part number is unknown to store.sun.com:

I'd like to know where to get this adapter myself.

Martha

 ..............................................................................

[One suggestion from Kyle M. is to get the DB9 face plate that was
 standard on a Sun Ultra 10, or the one that comes with the SunPCi
 card. It's a "DB9" connected to a ribbon cable to a 2x5 pin connector,
 with one pin filled in.]

 ..............................................................................

James C. wrote:
|
| This IDC-to-DE9 connector from an Ultra 10 can be put into a SunBlade 150.
| The only discrepancy seems to be that DCD and DSR are inexplicably swapped.

 //////////////////////////////////////////////////////////////////////////////

Message-ID: <0HOC00ELJPZ5SH@eris-mail1>
Date: Fri, 14 Nov 2003 17:03:48 +0000 (GMT)
To: Luca M.
From: Eddie K.
Subject: Re: parallel port GPIB IEEE 488

The GPIB (General Purpose Interface Bus) was specifically designed to
connect laboratory instruments to computers and peripherals.

It allows a computer (bus controller) to communicate with oscilloscopes,
multimeters, spectrum analysers, etc. These kinds of instruments can
also use it to connect to printers and plotters. The purpose of the bus
is to help automate experiments, and to provide a standard interface to
most lab equipment.

It is also known as IEEE-488 or HPIB ( Hewlett Packard Instrumentation
Bus ), and is electrically equivalent to the IEC-625 bus.  It is
defined completely in the IEEE standard 488.1-1987 "Standard Digital
Interface for Programmable Instrumentation".

To use the GPIB you need a GPIB adapter card in your computer and a GPIB
lead. Fourteen devices can be connected to one GPIB and data can be
transferred at up to 200,000 bytes per second. 

An RS-232 to GPIB interface converter could be used, e.g., National Instruments

    http://sine.ni.com/apps/we/nioc.vp?lang=US&cid=1261

or

    http://www.BlackBox.com/

RS-232 <-> 488 Interface Converter  Part Number IC026A-R2  Price  $849.99

You will need to have a manual for the instrument to
know what commands to send to it and what to expect back.

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals
Message-ID: <3E97F0F5.4050004@BellSouth.Net>
References: <87ptrhcosv.fsf@hurd.crasseux.com> <06d36cb79ab714f0@mayday.cix.co.uk>
Organization: Hall Communications
X-NNTP-Posting-Date: Sat, 12 Apr 2003 06:49:29 EDT
Date: Sat, 12 Apr 2003 06:56:53 -0400
From: "Scott G. Hall" <ScottGHall@BellSouth.Net>
Subject: Re: Best way to connect many terminals to a PC

On 1 Jan 2003, Bijan Soleymani wrote:
>
> I'd like to connect about 20 character-based terminals (I have a
> mixture of different DEC and WYSE terminals.) to one PC. What would
> be the best way to do so if the terminals have standard RS232 connectors
> (My PC has only two serial ports)?  (running Debian GNU/Linux 3.0) 


I am surprised that this came up in this group -- the original manner
of using UNIX.

As you might have surmised from the other postings, what you are looking
for is a 16-port, 24-port or 48-port multiport serial card for your PC.
Most Linux distros have drivers for a number of cards.  There are quite a
number of boards from which to choose:

    Digi International (formerly DigiBoard)   - many current and older models
    BocaBoard                                 - many old and new boards
    Equinox                                   - many old and new boards
    Lantronix
    BlackBoard
    Cyclom Y RISC-Based Multiport Serial Board
    Intellio
    Comtrol RocketPort Card
    VOX Technologies

(See the A-Plus-Computers below for an Equinox 16-port at $373)

What you want to keep in mind is that you want an "intelligent" or "smart"
multiport serial board -- this is one with its own processor handling its
own interrupts and buffering.  A "dumb" board relies on your PC processor
handling the interrupts, and at more than 4 ports for greater than 1200
baud this is going to slow you down and lose characters.

Another thing to consider is that the board have buffered UARTs -- such
as the Intel 16550 or equivalent--so that you do not lose any characters
coming or going.

A lot of boards allow you to select between RS-232 (unbalanced 8-wire --
can be 3 (RX,TX,Gnd), 5 (add RTS,DTS), 7 (add DTR,CD) or all 8 wires
(add DSR)) and RS-422/485 (balanced dual-channel 4-wire) signaling.  If
it saves you money, forget RS-422/485.

You want to turn on DMA transfers, so get a board with that capability.

I personally like RJ-45 connectors, but you can go with DB-25s if you want.

You can specify software-only, or hardware-and-software handshaking in
the "getty" parameters in Linux.  I prefer hardware-and-software handshaking,
so that I can be flexible on how I connect any one terminal.  I do try to
connect each terminal with hardware flow control (all 8 wires, including
not just DTR/DSR (DSR tied to CD), but RTS/CTS too) whenever possible,
so that the Linux login session is terminated if the terminal is powered
off, and the "getty" process is woken up when the terminal is powered on
to cause it to spew the login prompt again.

For further reading:
    http://yebisu.ics.es.osaka-u.ac.jp/linux/HOWTO/Serial-HOWTO-9.html
    https://www.conserver.com/pipermail/users/2002-January/msg00001.html
        ["Initial installation and configuration (of a Linux System)"]
    https://www.conserver.com/pipermail/users/2002-January/msg00002.html
    http://www.linuxdevices.com/articles/AT2470203390.html

Here is a couple of helpful links:

    http://www.apluscomputers.com/vendor_m_gdept.asp?dept_id=17-002
    http://www.axiomtek.com/product-list.php?cat=Multiport+Serial+Solutions
    http://www.compuadds.com/Category.asp?catcode=0441
    http://www.gtek.com/bb8a.html
    http://www.voxtechnologies.com/MOXA_Products/pos_sol.htm
    http://www.globetek.com/moxa/pdf/Intellio%20C320Turbo%20Multiport%20Controller.pdf

-- 
Scott G. Hall,
Raleigh, NC, USA
ScottGHall@BellSouth.Net

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.solaris, alt.solaris.x86
References: <bvdon9$quvkl$2@ID-222939.news.uni-berlin.de>   
    <bve07r$qjp$1@new-usenet.uk.sun.com>   
    <bve7td$rkboc$1@ID-222939.news.uni-berlin.de>
Message-ID: <bveh85$3iq$1@new-usenet.uk.sun.com>
Date: 30 Jan 2004 21:10:29 GMT
From: Andrew Gabriel <andrew@cucumber.demon.co.uk>
Subject: Re: 16 bit ISA serial card on Solaris 9 x86

In article <bve7td$rkboc$1@id-222939.news.uni-berlin.de>,
        synospam <syn_NOSPAM_uw@hotmail.com> writes:
> 
> Ahhh finally it now works !!! First I had problems because the card was 
> on IRQ 9 for COM4, Solaris wouldn't boot anymore, just hangs after the 
> kernel version line. So then what I did is deactivated the parallel port 
> and changed COM4 on the serial card to use IRQ 7. With IRQ 7 it works 
> well. I've now got /dev/cua/a,b,c,d ! Btw: this card has jumpers to 
> configure it's IO and IRQ setings. I would like to thank you, Andrew, for 
> your detailed explanations; they were very helpful!!


Excellent.

By the way, the asy(7D) driver supports up to 10 ports, and not just
4 as it says in the man page. However, the hardware interface to the
standard UARTs used in x86 PC's isn't very efficient, so I would not
expect it could drive a such a number at the higher speeds.

-- 
Andrew Gabriel

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.solaris
NNTP-Posting-Host: 217.205.155.130
NNTP-Posting-Date: Fri, 7 May 2004 15:26:39 +0000 (UTC)
Message-ID: <160afc40.0405070726.7191cb1e@posting.google.com>
Organization: http://groups.google.com
Date: 7 May 2004 08:26:39 -0700
From: Darren Robertson <darren@orcsoftware.com>
Subject: Serial Fun

Please bear with me on this long tale.

I was called to a client site last week after the flood in the
basement caused a power outage. The Sun Server with no graphics card
etc connected did not come us as it was stuck asking for the root
password to run fsck.

I grabbed the laptop, serial cable and 25 pin serial terminal, and off
I shot--got to the client site and silly me--Port A female, serial
terminal also female. I had to shoot off to Maplin to get a male-to-
male gender bender. While there I spotted a terminal to make up on my
own.

I have found out about which cable to connect to which port on this
terminal but how can I identify which is which pin?

Therefore I have a serial cable with an RJ45 type connector which
(with the spring clip down looks like:
grey:orange:black:red:green:yellow:blue:brown

How can I identify the RX and TX pins for example so that I can match
this through the 25 pin serial terminal that I have to make up?

Thanks.
D.

 ..............................................................................

Newsgroups: comp.unix.solaris
NNTP-Posting-Host: abpc10296.cern.ch
References: <160afc40.0405070726.7191cb1e@posting.google.com>
Message-ID: <20040507173457.40d89723.Levente.Kovacs@cern.ch>
Organization: CERN - European Laboratory for Particle Physics
Date: Fri, 7 May 2004 17:34:57 +0200
From: Levente KOVACS <Levente.Kovacs@cern.ch>
Subject: Re: Serial Fun

On 7 May 2004 08:26:39 -0700
darren@orcsoftware.com (Darren Robertson) wrote:
>
> Please bear with me on this long tale. ...
> ...
> I grabbed the laptop, serial cable and 25 pin serial terminal, and off
> I shot--got to the client site and silly me--Port A female, serial
> terminal also female. I had to shoot off to Maplin to get a male-to-
> male gender bender. While there I spotted a terminal to make up on my
> own.

I had such feeling, when I've tried to connect my Picstart+ to my
ULTRA1. The pinout is the same, only a gender changer is needed.


> Therefore I have a serial cable with an RJ45 type connector which
> (with the spring clip down looks like:
> grey:orange:black:red:green:yellow:blue:brown

The specification of V.24, you do not have RJ45. You have to consult the
manufacture of that device. Note that some CISCO routers use RJ45 for
serial terminal.
 
I have to add, that in V.24 a male connector is specified. So SUN is
against the standard. I don't know why.

 ..............................................................................

Newsgroups: comp.unix.solaris
NNTP-Posting-Host: fiesta.cs.tu-berlin.de
NNTP-Posting-Date: 8 May 2004 10:41:38 GMT
References: <160afc40.0405070726.7191cb1e@posting.google.com>
    <20040507173457.40d89723.Levente.Kovacs@cern.ch>
Message-ID: <c7idh2$i2r$1@news.cs.tu-berlin.de>
Organization: Technische Universitaet Berlin, Deutschland
Date: 8 May 2004 10:41:38 GMT
From: Joerg Schilling <js@cs.tu-berlin.de>
Subject: Re: Serial Fun

In article <20040507173457.40d89723.Levente.Kovacs@cern.ch>,
Levente KOVACS  <Levente.Kovacs@cern.ch> wrote:
>
> I have to add, that in V.24 a male connector is specified. So SUN is
> against the standard. I don't know why.

Looks like you did not understand V.24

It defines the communiation between a terminal and a modem.
A Computer is theither of both, so a manufacturer choses
which if both variants he implements.

ADAIR, Sun implements a Modem, so the connector is completely
OK in contrary to what PCs do. A 9 pin connector is not in the
standard.

-- 
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
      js@cs.tu-berlin.de                (uni)  If you don't have iso-8859-1
      schilling@fokus.fraunhofer.de     (work) chars I am J"org Schilling
URL:  http://www.fokus.fraunhofer.de/usr/schilling
ftp://ftp.berlios.de/pub/schily

 ..............................................................................

Newsgroups: comp.unix.solaris
References: <160afc40.0405070726.7191cb1e@posting.google.com>
    <20040507173457.40d89723.Levente.Kovacs@cern.ch>
    <c7idh2$i2r$1@news.cs.tu-berlin.de>
Message-ID: <70bdea73b70143849932c9b388a79834@ghytred.com>
Date: 08 May 2004 14:33:21 +0100
From: g8mqw@yahoo.com
Subject: Re: Serial Fun

Na, not always a MODEM. It defines "Data Communications Equipment" (DTE)
and "Data Terminal Equipment" (DTE).  So whilst DCE includes modems, it
also allows for things like ISDN TA's and physical terminal switches. 

The standard envisaged that you would have a link that went :-

    Terminal <==> Comms <==> Comms <==> Computer.

When we wire a terminal directly to a computer, we are outside the scope
of the spec. Personally I think the SUN should be DTE and you should need
to use a "NULL Modem" or Crossover cable to connect to a Terminal.

 ..............................................................................

Newsgroups: comp.unix.solaris
References: <160afc40.0405070726.7191cb1e@posting.google.com>
    <20040507173457.40d89723.Levente.Kovacs@cern.ch>
    <c7idh2$i2r$1@news.cs.tu-berlin.de>
Message-ID: <c7j491$3q9$1@reader2.panix.com>
Organization: I have a map of the United States that's actual size
Date: Sat, 8 May 2004 17:09:53 +0000 (UTC)
From: "Greg Andrews (Do NOT reply via e-mail.)" <gerg@panix.com>
Subject: Re: Serial Fun

js@cs.tu-berlin.de (Joerg Schilling) writes:
>
>ADAIR, Sun implements a Modem, so the connector is completely
>OK in contrary to what PCs do. A 9 pin connector is not in the
>standard.
                                                                                
                                                                                No,
Sun does not implement a modem.

Sun implements Transmit Data on pin 2 and Receive Data on pin 3
(of the 25-pin connector). Also, the DTR and RTS pins are outputs
on Sun equipment, while the DSR, CTS, and DCD pins are inputs.
This is the opposite of a modem implementation.

Sun implements a Terminal device according to RS232/EIA232/V.24.

 -Greg

 ..............................................................................

Newsgroups: comp.unix.solaris
References: <160afc40.0405070726.7191cb1e@posting.google.com>
Message-ID: <409bad18$1@news.kcl.ac.uk>
Date: Fri, 07 May 2004 16:37:11 +0100
From: Mark Clements <mark.clements@kcl.ac.uk>
Subject: Re: Serial Fun

Darren Robertson wrote:
>
>  <snip>
> I have found out about which cable to connect to which port on this
> terminal but how can I identify which is which pin?
> 
> Therefore I have a serial cable with an RJ45 type connector which
> (with the spring clip down looks like:
> grey:orange:black:red:green:yellow:blue:brown
> 
> How can I identify the RX and TX pins for example so that I can match
> this through the 25 pin serial terminal that I have to make up?

Check out

    http://www.stokely.com/unix.serial.port.resources/A-B-Ycablepinout.html

Convincing simple serial connections to work is one of my least
favourite pastimes:  you'd best invest in a crate of chickens and
make sure ladies and young children are out of the room.

Mark

 ..............................................................................

Newsgroups: comp.unix.solaris
NNTP-Posting-Host: h182n1fls33o847.telia.com [213.65.154.182]
NNTP-Posting-Date: Sun, 09 May 2004 19:25:04 CEST
References: <160afc40.0405070726.7191cb1e@posting.google.com>
    <20040507173457.40d89723.Levente.Kovacs@cern.ch>
    <c7idh2$i2r$1@news.cs.tu-berlin.de>
    <70bdea73b70143849932c9b388a79834@ghytred.com>
    <c7k1h4$bf3$2@new-usenet.uk.sun.com>
Message-ID: <x0llk1cy35.fsf@Hax.SE.remove-to-reply>
Organization: HB Hax
Date: Sun, 09 May 2004 17:25:04 GMT
From: Thomas Tornblom <thomas@Hax.SE.remove-to-reply>
Subject: Re: Serial Fun

andrew@cucumber.demon.co.uk (Andrew Gabriel) writes:
>
> In article <70bdea73b70143849932c9b388a79834@ghytred.com>,
>       <g8mqw@yahoo.com> writes:
> > 
> > 
> > Na, not always a MODEM. It defines "Data Communications Equipment" (DTE)
> > and "Data Terminal Equipment" (DTE).  So whilst DCE includes modems, it
> > also allows for things like ISDN TA's and physical terminal switches. The
> > standard envisaged that you would have a link that went :-
> > Terminal <==> Comms <==> Comms <==> Computer.
> > 
> > When we wire a terminal directly to a computer we are outside the scope
> > of the spec. Personally I think the SUN should be DTE and you should need
> > to use a "NULL Modem" or Crossover cable to connect to a Terminal.
> 
> I think Sun expected that you would connect a terminal to its serial
> port to get a login prompt, whereas a PC expected that it would *be*
> a terminal.
> 
> I think newer Sun systems' serial ports are DTEs though (I vaguely
> recall I need a crossover to connect an Ultra-60 to a PC).
> 
> -- 
> Andrew Gabriel
> Consultant Software Engineer


Any V.24/RS232 device is either DTE (Data Terminal Equipment) or
DCE (Data Communications Equipment, and for DB25 connectors the
standard is male connectors for DTE and female for DCE.

One of very few manufacturers that got the connector gender correct was
DEC (Digital Equipment Corporation), at least in the 1980s with VT-100
terminals and DECsystem-20s, which was what we had at the university.

I agree with the OP, Sun has always had the wrong gender on the
systems with DB25 connectors. I believe that the newer ones with DB9
got it right though, although one may argue that it is more a defacto
standard setup by IBM for the PC.

In a perfect world, one glimpse of the connector should be enough to
know if a straight cable (male to female) is needed, or a crossed
(male to male or female to female).

This seldom works in our imperfect world. Connecting a modem to a
Sun requires a straight cable with male connectors, yuck!

Cheers,
Thomas

-- 
Real life:      Thomas Törnblom             Email:  Thomas.Tornblom@Hax.SE
Snail mail:     Banvallsvägen 14            Phone:    +46  18 290 290
                S - 754 40 Uppsala, Sweden  Cellular: +46  70 261 1372

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.solaris
NNTP-Posting-Host: panix3.panix.com
NNTP-Posting-Date: Fri, 27 Aug 2004 05:57:21 +0000 (UTC)
References: <9981f19f.0408250422.654bd943@posting.google.com>
    <cgin8a$sqf$1@reader1.panix.com>
    <9981f19f.0408252356.4c424ce2@posting.google.com>
Message-ID: <cgmig1$9ka$1@reader1.panix.com>
Organization: I have a map of the United States that's actual size
Date: Fri, 27 Aug 2004 05:57:21 +0000 (UTC)
From: Greg Andrews <gerg@panix.com>
Subject: Re: Setting baudrate (serial ports installed in Sun machine)

michael_laajanen@yahoo.com (Michael) writes:
>
> This is on a unused serial port(b), and will later be on a 16 port
> cyclades board.
>
> But also I should ask you also, how do I shutdown the login process on
> /dev/term/a /dev/term/b?


Getting rid of the default login services on the a and b ports:

        pmadm -r -p zsmon -s ttya
        pmadm -r -p zsmon -s ttyb

There are pretty much three approaches for configuring a serial
port the way you're asking.  From best to worst:

 1) The application that uses the port also configures it.
    This is the best all around because the settings are applied
    to the port when the application needs them and exactly how
    the application needs them to be set.


 2) Use a separate shell command to apply port settings with stty
    and hold the port open (so the settings don't return to defaults):

    ( stty 4800 cs7 parenb ixoff ixon ; sleep 999999 ) < /dev/cua/b &

    This runs the stty and sleep commands in a subshell so the stdin
    from both of them can be redirected in from the b port.  The stty
    command sets the parameters you want, and the sleep command holds
    the port open for 11.5 days.  You would run one of these commands
    for each port, followed by the command(s) to run your logger app
    on the port.

 3) Set up an "Initialize Only" login service to apply settings to
    the port at boot time.  This can be a "set it and forget it"
    solution, as long as the application is started after Solaris
    has fully finished booting.  (starting the login services is
    the last thing Solaris does at boot time)

    See Document 44722 for a ksh script that makes it reasonably
    easy to set up an Initialize Only service on a serial port:

    http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsrdb%2F44722


Normally, I recommend option #3 over #2, but I have a feeling you're
going to want to start your logger application before Solaris starts
the login services.  It's also easier to play around with different
settings in option #2.

Another possibility is that the Cyclades can have its default settings
configured with its own utility program.

Hope this helps,

  -Greg


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.solaris
NNTP-Posting-Host: 81.187.162.106
NNTP-Posting-Date: 14 Apr 2005 14:59:34 GMT
References: <d3lvdl$19b8$1@node2.news.atman.pl>
Message-ID: <425e8556$0$38044$5a6aecb4@news.aaisp.net.uk>
Date: 14 Apr 2005 14:59:34 GMT
From: Andrew Gabriel <andrew@cucumber.demon.co.uk>
Subject: Re: ups (smart 2200) and ttyb serial

In article <d3lvdl$19b8$1@node2.news.atman.pl>, via ph-ibb-atm4-1.icm.edu.pl,
	"=?ISO-8859-2?Q?Micha=B3?= Kurowski" <mkur@poczta.gazeta.pl> writes:
> Hi,
>
> I'm having hard time figuring out what's going on with my serial line.
>
> The machine is SunFire 210 and it's connected to APC SmartUPS 2200.
> It is controlled by apcupsd-3.10.11 (compiled in house) which was
> working great in a "slave" mode for a long time.
>
> Now I need to go with the master mode on the machine but I'm not able
> to communicate with the ups ...
>
> "apctest" breaks with an error saying there's no connection, etc - in
> fact the source code clearly suggests there's no proper file
> descriptor available. Strangely, I also have no data when I do "cat
> /dev/ttyb".
>
> ttya works OK with a ttymon and console logins. I'm aware there should
> be no program monitoring ttyb in order for ups serial to work properly.
> I played with "pmadm" quite a lot for no avail. At the moment the line
> is set like that:
>
> $ eeprom | grep ttyb
> ttyb-rts-dtr-off=false
> ttyb-ignore-cd=true

These two strange settings are for when ttyb is being used as
a console. For most other serial port applications, you would
flip them both the other way around, i.e.,

    ttyb-rts-dtr-off=true
    ttyb-ignore-cd=false

I don't have any experience with what apcupsd expects, though.

> ttyb-mode=2400,8,n,1,-
> output-device=ttya,ttyb
> input-device=ttya,ttyb
>
> -- 
> Micha³ Kurowski
> mkur(at)poczta.gazeta.pl


You probably want to remove ttyb from these.

-- 
Andrew Gabriel

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.solaris
NNTP-Posting-Host: 81.187.162.106
NNTP-Posting-Date: 03 May 2005 18:02:42 GMT
References: <d55lbp$g4m$1@driftwood.ccs.carleton.ca>
    <42767194$0$38043$5a6aecb4@news.aaisp.net.uk>
    <d56lqo$ehs$1@reader1.panix.com>
Message-ID: <4277bcc1$0$38041$5a6aecb4@news.aaisp.net.uk>
Date: 03 May 2005 18:02:42 GMT
From: Andrew Gabriel <andrew@a10>
Subject: Re: Direct Serial port access

In article <d56lqo$ehs$1@reader1.panix.com>,
        gerg@panix.com (Greg Andrews) writes:
>
> andrew@cucumber.demon.co.uk (Andrew Gabriel) writes:
>>
>>In article <d55lbp$g4m$1@driftwood.ccs.carleton.ca>,
>>
>>      " Lemieux" <jlemieux@ccs.carleton.ca> writes:
>>>
>>> I'm trying to use a serial port to monitor and control
>>> access to a computer room. I was hoping to use the
>>> CTS/RTS lines to read status and control.
>>> I'm presently using /dev/term/a and by following the
>>> /devices path, I could figure out the control port address.
>>> Now, Im looking for information on the control port
>>> (port status and control bit IDs) or some tool that would
>>> let me read/control the port directly. I'm presently testing
>>> on a Blade-100.
>>
>> man termio, and look for TIOCMBIS, TIOCMBIC, TIOCMGET, TIOCMSET
>> ioctls, and the TIOCM_* values.
>>
>> Also, ttya and ttyb are setup by default in a strange way which
>> is intended for use as the system console. If you are using them
>> for some purpose other than the system console, you might want
>> to switch their modem line handling back to normal serial port
>> mode:
>>
>>eeprom ttya-rts-dtr-off=true
>>eeprom ttya-ignore-cd=false
>
>
> But why?  The eeprom settings are only in control of the serial
> port hardware while the Open Boot Prom is in control of the machine.
> I.e. at the "ok" prompt, booting up, and shutting down.
>
> While the Solaris kernel is loaded, the serial port hardware is
> controlled by the device driver, not the eeprom settings.


The Solaris serial port kernel drivers read and act on the eeprom
settings too (and on x86, so does the real mode serial port driver
used by the DCA).

-- 
Andrew Gabriel


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.unix.solaris
NNTP-Posting-Date: 12 Apr 2007 14:52:17 CDT
References: <1176325483.693128.320220@w1g2000hsg.googlegroups.com>
    <461d5df8$0$36739$892e0abb@auth.newsreader.octanews.com>
    <slrnf1shul.70s.liam@nessie.xinqu.net>
Message-ID: <461e8df1$0$36698$892e0abb@auth.newsreader.octanews.com>
Date: 12 Apr 2007 19:52:17 GMT
From: Doug McIntyre <merlyn@geeks.org>
Subject: Re: USB serial dongle (wasRe: Does one have to buy any special equipment for the V125?)

Liam Greenwood <liam@nessie.xinqu.net> writes:
>
> On 11 Apr 2007 22:15:20 GMT, Doug McIntyre <merlyn@geeks.org> wrote:
>>
>> On the Mac, you'll need a USB to Serial dongle to do the initial setup
>> to get at least an IP address/gateway/root password/user account setup
>> on the box before it'll talk on the Network.

>Does anyone have a recommendation for a USB serial dongle that works on the
>Mac for connecting to Sun boxes? I have an old Thinkpad that I boot off CD
>(dead HD) for this purpose at the moment, and would like to not have to
>depend on it.


Keyspan work great. Driver support is great (as opposed to others like
the Prolific chipset based ones). Since I work on a bunch of routers
as well as machines, I have the 4-port Keyspan unit as well as single
dongles for my powerbook.

Then Kermit [for software], although thats a personal preference, although
I see it echoed by at least one other here...

 //////////////////////////////////////////////////////////////////////////////

Most NetApp storage appliances, including the FAS2020 and FAS2050, provide a
maintenance-console serial RJ45, 2 logical ports with the following pinouts:

    1  (tied to pin 8)
    2  TX2
    3  TX1
    4  Ground
    5  Ground
    6  RX1
    7  RX2
    8  (tied to pin 1)

The voltages are consistent with RS-232-C, and the port can normally be
used with a "null-modem" cable.  No handshaking lines.

Be careful not to confuse this serial port with the Management LAN Ethernet
port, also with RJ45 connections, on some models.

 //////////////////////////////////////////////////////////////////////////////



