=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 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 ////////////////////////////////////////////////////////////////////////////// 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> <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" 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" 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: 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 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: 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: 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: References: <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: <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: <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: 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 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> 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 , 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: Organization: My Individual Private Site Subject: Braindead 6551 (was: Re: DIP vs. NVRAM) References: <288tk6$pk7@agate.berkeley.edu> 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 , 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: Date: Thu, 25 Nov 93 09:52:17 GMT Lines: 50 In article 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: 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> 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: References: From: Marco S Hyman 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: References: Organization: http://groups.google.com/ Date: 18 Jul 2003 07:00:59 -0700 From: Tim Shoppa Subject: Re: Designing an NTP network for a research ships at sea... ptrojane@mion.elka.pw.edu.pl (Piotr Trojanek) wrote in message news:... > > In article , 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: 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." Subject: Re: DEC 3000-300 serial port speed? In article , 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> <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 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: <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> 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 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: 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 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 Langmea