=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 Langmead ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.unix.misc Path: cs.utk.edu!cssun.mathcs.emory.edu!hobbes.cc.uga.edu!news-feed-1.peachnet.edu !gatech!howland.reston.ans.net!pipex!sunic!sunic.sunet.se!news.funet.fi !news.csc.fi!kronos.fmi.fi!dionysos.fmi.fi!hurtta Message-ID: <3mmfcs$16f@kronos.fmi.fi> References: <3l6tkp$cot@umd5.umd.edu> <3ltohv$38g@kronos.fmi.fi> <3lv9tn$e3l@vixen.cso.uiuc.edu> NNTP-Posting-Host: dionysos.fmi.fi In-Reply-To: Article <3lv9tn$e3l@vixen.cso.uiuc.edu> of Owens-Nicholson X-Newsreader: NN version 6.5(beta3).0 #6 (NOV) Organization: Finnish Meteorological Institute (FMI) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Lines: 23 Date: 14 Apr 1995 18:37:16 GMT From: hurtta@dionysos.fmi.fi (Kari E. Hurtta) Subject: Re: vt220 term with vt100 set [ Adding comp.unix.misc as receiver. ] dawn@uxh.cso.uiuc.edu (Dawn Owens-Nicholson) writes in comp.terminals: | | hurtta@dionysos.fmi.fi (Kari E. Hurtta) writes: | > His have wrong settings in terminal triver -- Terminal driver _should_ | > do mapping LF -> CR LF (and this is true also for VT100). | | I'm not sure what you mean by a terminal driver, but this problem | might be solved by typing "stty cooked" or placing this command in | »your login file. Yes. With stty you can change behauviour of unix's terminal driver. Terminal driver is that part of unix's kernel which does special processing for tty connections. Command 'stty -a' gives all fields. For more details, look manual page of termios. -- - Kari E. Hurtta / Elämä on monimutkaista Kari.Hurtta@FMI.FI puh. (90) 1929 658 {hurtta,root,Postmaster}@dionysos.FMI.FI ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.arch.embedded,comp.terminals Message-ID: Followup-To: comp.terminals References: <7JUN199512355584@erich.triumf.ca> Organization: Step Engineering Keywords: VT-100 Date: Sat, 10 Jun 1995 17:55:49 GMT From: dan@stepeng.com (Daniel Weaver) Subject: Re: VT-100 Commands In article <7JUN199512355584@erich.triumf.ca>, bennett@erich.triumf.ca (P.Bennett) writes: > > void gotoxy( int x, int y ) > { > printf( "\033[%d;%dH\000\000", y, x ); > } > > /* \033 = Escape */ > > the \000 chars seem to be needed to give the terminal time to do > its thing... I've got some bad news for you, Peter. The \000 character gets swallowed by printf() and never makes it to the terminal. If you want to send NULLs to the terminal, you need to use putc(), or write(). Another way to do this is to send \200 (0x80 hex). printf() stops parsing when it sees the first NULL. Follow-ups should be redirected to comp.terminals. Dan Weaver ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.os.vms Path: cs.utk.edu!nntp.memphis.edu!netnews.wku.edu!mvb.saic.com!news.mathworks.com !uunet!in1.uu.net!ulowell.uml.edu!willow.uml.edu!welchb Message-ID: <1995Jul10.135133.1@willow.uml.edu> References: <0099303C.509D7DC0.5@earth.oscs.montana.edu> <1995Jul9.163800.5770@cmkrnl> Organization: University of Massachusetts Lowell NNTP-Posting-Host: willow.uml.edu Lines: 18 Date: 10 Jul 95 13:51:33 -0500 From: welchb@willow.uml.edu (Brendan Welch, W1LPG) Subject: Re: DB25 --> DB9 RS232 > Ok, for future reference: (1) It hasn't been "RS232" for years; it's > now the EIA-232-E standard. (2) The 9-pin D-subminiature connectors > are not DB-9, but rather DE-9. (Says so in the manufacturer's > catalogs.) So many people get both of these points wrong that I doubt > that this little post will help, but I can only hope. > > --- Jamie Hanrahan, Kernel Mode Systems, San Diego CA > Internet: jeh@cmkrnl.com (JH645) CompuServe: 74140,2055 Think of how many people mispronounce "modem". They use a long o sound, as in Kernel _Mode_, instead of the short o sound, as in _modulate-demodulate_. -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu working on being as perfect as Ehud ////////////////////////////////////////////////////////////////////////////// Article 4945 of comp.terminals: Path: cs.utk.edu!gatech!news.mathworks.com!uunet!in1.uu.net!nwnews.wa.com !news1.halcyon.com!coho!dagon Newsgroups: comp.terminals Organization: Northwest Nexus, Inc. - Professional Internet Services Message-ID: <45m0b8$5ic@news1.halcyon.com> References: <45konr$e9u@uceng.uc.edu> NNTP-Posting-Host: coho.halcyon.com Lines: 13 Date: 13 Oct 1995 15:24:24 GMT From: dagon@coho.halcyon.com (Mark Rafn) Subject: Re: vt220 through modem ? Abraham George wrote: > >I have a vt220 terminal at my residence. I wish to connect via an >external modem to the college net. Since I haven't purchased a modem, >I would like to know if any of the current external modems in the market >would do the job. Almost any external modem will do the job. Given that you'll only be able to use text applications, there's not much reason to pay for a super-fast modem. 9600bps would do fine, but you probably can't find one. As I recall, the maximum DTE rate on those is 19200, so even if you use a 28.8 modem, you'll only be able to use it as a 14.4. -- Mark Rafn dagon@halcyon.com http://www.halcyon.com/dagon/ ////////////////////////////////////////////////////////////////////////////// Path: cs.utk.edu!gatech!newsfeed.internetmci.com!news1.erols.com!news2.cais.net !news.cais.net!news.vbc.net!samba.rahul.net!rahul.net!a2i!dold.a2i!dold Newsgroups: comp.protocols.kermit.misc Organization: a2i network Lines: 50 Message-ID: <4kf2v8$89p@samba.rahul.net> References: NNTP-Posting-Host: foxtrot.rahul.net NNTP-Posting-User: dold X-Newsreader: TIN [version 1.2 PL2] Date: 10 Apr 1996 01:30:16 GMT From: Clarence Dold Subject: Re: modem won't respond to mskermit : >>>>> "fdc" == Frank da Cruz writes: : fdc> If Kermit were set to an interface speed that is not supported by the : fdc> modem, this would explain why the modem is ignoring your commands. But i Frank, I don't think the modem cares as much as the serial port does. Mark McConnell (mkmcconn@teleport.com) wrote: : Your description of the symptoms associated with a mismatched speed points : in the direction of the solution, apparently. I am using a ZOOM VFX V.32bis : modem. I had attempted to SET SPE 28800. When I changed to 38400, the : modem responded. Also works at 57600 and 14400, but not 28.8. : Anyway, although I'm not happy with the ambiguous fix, I AM connected. Mark, this isn't an ambiguous fix. Many serial ports will not operate at the new, odd speeds that modems have chosen. Standard serial port speeds have always been multiples of the lower speeds. 300 1200 2400 4800 9600 19200 38400 57600 115200 have all been standard speeds, with the ones above 19200 being rare in older systems. Modems that operate at 12000, 14400, 21600, 26400, 28800 are based on the technology of the analog phone line, and do not correspond directly to the serial port interface speeds. I have several Intel 144I and 144E, all have run or are running MS-Kermit, and all have been quite happy, at standard serial port interface speeds. I run 38400 on a DOS machine, and 19200 on my UNIX machine to Intel modems currently. Neither machine will recognize a setting of 14400 (I never tried 28800). Kermit will set the proper bits to set the speed to that rate, but the serial port is likely sending _no_ intelligible data to the modem. The echo that you see is not an intelligent response from the modem. If an Intel (GVC) modem won't give you a status display with AT&V, it isn't working. With compressing modems (14.4 or 28.8), you want your serial port set faster than the connect speed. How much higher will produce any effective results depends on your environment, and the data being transferred. If you transfer primarily .zip files, there is probably no value to be seen with a speed greater than 19.2, which is enough to keep a 14.4 modem running at its maximum transfer speed of 1660 characters per second. -- --- Clarence A Dold - dold@rahul.net - Pope Valley & Napa CA. .............................................................................. Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!news.msfc.nasa.gov!sgigate.sgi.com!rutgers!news.columbia.edu!watsun.cc.columbia.edu!fdc Organization: Columbia University Message-ID: <4khbd5$44f@apakabar.cc.columbia.edu> References: <4kf2v8$89p@samba.rahul.net> NNTP-Posting-Host: watsun.cc.columbia.edu Lines: 41 Date: 10 Apr 1996 22:06:29 GMT From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Subject: Re: modem won't respond to mskermit In article <4kf2v8$89p@samba.rahul.net>, Clarence Dold wrote: : : >>>>> "fdc" == Frank da Cruz writes: : : : fdc> If Kermit were set to an interface speed that is not supported by the : : fdc> modem, this would explain why the modem is ignoring your commands. .. : : Frank, I don't think the modem cares as much as the serial port does. : Right -- I should have prefaced all that with "assuming your serial port supports 28800 (or 14400) as a speed..." However, in theory, and I believe also in practice, Kermit won't let you set the serial port to a speed it does not support. MS-DOS Kermit 3.14 handles 14400 and 28800 bps just fine, as far as I know, by setting the UART's hardware "baud rate divisor" register to the appropriate value. C-Kermit depends on the underlying operating system, hardware, and drivers to do the same, and to report back accurately whether they have, in fact, done so. I grant you, there are cases where the underlying services fail to do these things properly so, yes, this too can be a consideration. : With compressing modems (14.4 or 28.8), you want your serial port set : faster than the connect speed. How much higher will produce any : effective results depends on your environment, and the data being : transferred. : Right, this is standard advice. I should not take it for granted that everybody knows this by now. Plus all the rest regarding flow-control, etc etc etc. : If you transfer primarily .zip files, there is probably : no value to be seen with a speed greater than 19.2, which is enough to : keep a 14.4 modem running at its maximum transfer speed of 1660 : characters per second. : True, but people who also use Kermit for terminal emulation will want to use the highest possible serial speed, because V.42bis compression tends to be very effective for plain text, which is generally what goes back and forth in terminal mode. - Frank .............................................................................. Newsgroups: comp.dcom.modems Path: cs.utk.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!menudo.uh.edu !uuneo!sugar!ficc!peter Message-ID: Organization: Xenix Support, FICC References: <1oplmpINNp49@escargot.xx.rmit.OZ.AU> Date: Thu, 25 Mar 1993 17:54:53 GMT From: peter@ferranti.com (peter da silva) Subject: Re: 16550 buffer and hi speed modems The best prices I found for 16550s were from BG Micro in Dallas TX. They're also pretty savvy people. I don't have the number at hand, try directory assistance. -- Peter da Silva `-_-' Ferranti International Controls Corporation 'U` 12808 West Airport Blvd. Sugar Land, TX 77478 USA +1 713 274 5180 "Zure otsoa besarkatu al duzu gaur?" ////////////////////////////////////////////////////////////////////////////// Newsgroups: alt.folklore.computers Path: utkcs2!stc06.ctd.ornl.gov!news.er.usgs.gov!news1.radix.net !news1.chicago.agis.net!agis!news4.agis.net!newspeer2.dearborn.agis.net !agis!newspeer.santaclara.agis.net!agis!su-news-hub1.bbnplanet.com !cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!dispatch.news.demon.net !demon!mail2news.demon.co.uk!tnglwood.demon.co.uk!unclebob Date: Sun, 13 Apr 97 20:24:53 GMT Message-ID: <860963093snz@tnglwood.demon.co.uk> References: <4ikpi5.l6n.ln@mercury.user-rwaid.es.co.nz> From: Robert Billing Subject: Re: MicroVaxII Terminal In article pekangas@sci.fi "Petteri Kangaslampi" writes: > One trick that I have found useful is to use a voltmeter to determine > which end a given device thinks it is. True, but you *can* do it with a LED. > Of course, the cable itself might be correct, but one end might be > expecting CTS/RTS handshaking, while the other doesn't. DEC kit in general doesn't need the RTS/CTS but your terminal might. Assuming your terminal has a 25-way D then short 2 and 3 at the terminal with a paper clip, and see if you get a local echo. If you do, all well and good, if not try shorting combinations of 4, 5, 8 and 20 until the terminal kicks in and (with the 2-3 short still on) goes local echo (that means what you type something it comes up on the screen). Then wire a cable with whatever shorts you need at the terminal end, and 2, 3 and 7 only wired to the DEC end. If that doesn't go then swap 2&3 in the cable. 2 & 3 are the data in the two directions, 7 is the ground. BTW a box with a male connector should be a DTE, a box with a female connector should be a DCE. A cable with the same gender of connector should be wired crossover, with different genders should be wired straight. Nobody (except DEC) ever seems to do this right. The DEC MMJ connectors on some VAXEN are logically equivalent, and work in the same way, all MMJ cables have 2 male connectors and are crossovers. > Petteri, whose biggest achievement is getting a strange DEC terminal talk > to his PC :) It turned out that I needed a null-modem cable with a 9-pin > male connector in one end (PC) and 25-pin female in the other. Go > figure... This isn't too difficult. I've been threatening to have some little cards printed with the rules for doing it on one side, and an advert for my firm on the other. -- I am Robert Billing, Christian, inventor, traveller, cook and animal lover, I live near 0:46W 51:22N. http://www.tnglwood.demon.co.uk/ "might there be some celestial tribunal at which a crafty advocate could get a sinner off hell? ...my heart sank at the thought of eternal work before a jury of prejudiced saints." ////////////////////////////////////////////////////////////////////////////// Newsgroups: alt.folklore.computers Path: utkcs2!stc06.ctd.ornl.gov!news.he.net!news.enteract.com !feed1.news.erols.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com !ix.netcom.com!netcom.net.uk!nntpfeed.doc.ic.ac.uk!sunsite.doc.ic.ac.uk !lyra.csx.cam.ac.uk!bjh21 Date: 13 Apr 1997 13:37:11 GMT Message-ID: <5iqni7$mj6@lyra.csx.cam.ac.uk> References: <4ikpi5.l6n.ln@mercury.user-rwaid.es.co.nz> From: bjh21@thor.cam.ac.uk (Ben Harris) Subject: Re: MicorVaxII Terminal In article , Petteri Kangaslampi wrote: > > I have somewhere around lying a photocopy of a page from some electronics > book (can't remember what) that contains the connections for a bunch of > "RS-232 cables that actually work". It has proved extremely useful, > especially as the same book section contains some general tips on "how to > become a RS-232 cable guru" or something. The book in question is the second edition of Horowitz and Hill's 'The Art of Electronics', published by Cambridge University Press. -- Ben Harris Undergrad Computer Rep, Corpus Christi College, Cambridge. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Path: transfer.stratus.com!bigboote.WPI.EDU!nntprelay.mathworks.com!fci-se!fci !newsfeed.sunet.se!news99.sunet.se!news01.sunet.se!130.237.72.211.MISMATCH !news.kth.se!acheron.fusion.kth.se!johanc Message-ID: NNTP-Posting-Host: acheron.fusion.kth.se Date: Fri, 12 Dec 1997 19:21:49 +0100 To: SPHudson From: Johan Carlsson Subject: Re: mark/space parity: what is it? > Could anyone please tell me what mark/space parity is? I'm > building a terminal emulator and need to support no, even, odd, > mark, and space parity. Hi, mark parity means the parity bit is always set and space parity means the bit is never set. Good luck w/ the terminal emulator. /Johan ////////////////////////////////////////////////////////////////////////////// >Date: Mon, 20 Apr 1998 11:24:53 +0800 >From: Kenneth Xu >To: Richard Shuford > >...we are providing a solution to connect 50 over terminals to a >host, these terminals are all far from host and located in different area. >That's way we look into RS422 or RS485. > >Our customer does not like external converters because it need extra power >supply and etc for each terminal, they think it will make system maintenance >more difficult. I have seen advertisements for RS-485/RS-422 adapters that are very small and seem to require no external power. (They siphon a tiny amount of power from the RS-232 status signals to operate.) Most recently I saw such things advertised in the back of the magazine called \Circuit Cellar Ink/, published by Steve Ciarcia: http://www.circellar.com/ +1 860-875-2751 I really think that would be the best way to go. --------------------------- OK. I dug around in my office and found an October 1997 issue of this magazine. In it is an ad from a company in Minnesota that sells such items: Integrity Instruments Division of Cogito Software PO Box 451 Pine River, MN 56474 USA +1 218-587-3414 http://www.integrityusa.com/ You could also inquire at Jameco Electronics: http://www.jameco.com/ --------------------------- One more thing to try: contact Wyse Technology and see if that company still sells terminals with RS-485 interfaces. Wyse did, long ago... http://www.wyse.com/ http://www.wyse.co.uk/support/ ...RSS ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.dcom.telecom.tech NNTP-Posting-Host: 32.100.59.159 Message-ID: <354fcfa3.0@news1.ibm.net> References: <3545BB01.32A2635B@netas.com.tr> Date: Mon, 4 May 1998 23:01:26 -0500 From: Subject: Re: What happened to V.35 Yeah, the company I work for manufactures, among ther things, V.35 interfaces to SONET/SDH. I was on the compliance team for testing it to specs, along with our V.11 interface. We had a hell of a time getting the V.35 spec. The ITU finally faxed it to us free of charge since it's now been obsoleted. The ITU says now to build interfaces that are compatible with V.11 for balanced circuits or V.10 for unbalanced circuits. It seems the 100ohm impedence on the twisted pair V.35 transmitter will draw excess current when exposed to moderate voltages. This is most likely the reason for it being obsoleted. Then again DS-1 (which is also balanced twisted pair) has 100ohm TX/RCV impedences, and CEPT-1's(E-1's) balanced twisted pair interface is 120 ohms, although the unbalanced E-1 is 75ohm coax. I'd like to see someone try to obsolete T-1 or E-1. That would go over like a lead zeppelin all right. Anyways: RS-422 is ASYNC V.11 with unbalanced controls RS-232 is unbalanced ASYNC V.24 with unbalanced controls Someone correct me if I'm wrong, but I think RS449 is SYNC V.11 with unbalanced controls EIA-530 is SYNC V.11 with balanced controls RS-423 is ASYNC V.10 with ????? controls Any experts out there who can verify the last 3 for me? Thanks. -- Bo Byrd Systems Technician Intelect Network Technologies ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals References: <01bdefa0$673256c0$63636363@laptop-brc> <361be1ba.16306079@netbsd.haeb.demon.org> <01bdf20c$bd653da0$63636363@laptop-brc> Organization: C.I.C. Ltd Date: Thu, 08 Oct 1998 00:34:01 GMT From: Harry Broomhall Subject: Re: Sending break with Wyse 50 emulator On 7 Oct 1998 16:04:26 GMT, "Bill Creager" wrote: > My original question was obviously written poorly. I have written the > emulator, and need to know what my program must sent to simulate pressing > the break key. > > My Wyse-50 display terminal reference manual does not specify what a break > signal is. My program is communicating with another computer which does not > send breaks, although it expects them for some functions. In the serial comms world (for example RS-232) a BREAK signal is where the line is held at SPACE for longer than a normal character frame. Other rules apply for other media. Regards, Harry. ////////////////////////////////////////////////////////////////////////////// Message-ID: <3638EDEB.43891189@GSC.GTE.Com> References: <3638DF3B.C7B3766E@timesystem.de> Organization: GTE Government Systems Date: Thu, 29 Oct 1998 22:36:27 GMT From: "Scott G. Hall" To: Tobias Galitzien Newsgroups: comp.terminals Subject: Re: RS232 connector on Nixdorf BA80 Tobias Galitzien wrote: > I have a Nixdorf BA80 terminal here with a RS232 connector on its > backside (at least this is written above it) but it has 15 pins and I > have never seen such a RS232. > > Can anybody tell me how the pins are connected in order to make a cable? A number of the older terminal manufacturers did something like this. The original EIA standard for serial ports included two ports in the DB-25 connector, both either synchronous or asynchronous. Some vendors did not want folks mixing up the two-port versus one-port variety, so they used a DB-15 connector. Usually the top row (pins 1-8) are the same as for their DB-25 counterparts (1=chassis gnd, 2=TX, 3=RX, 4=RTS, 5=CTS, 6=DSR, 7=sGnd, 8=CD), and the DTR pin was in the same relative position (under pins 6 & 7) -- or pin 10 on a DB-15. The rest of the pins are usually the sychronous clock and timing pins of a synchronous connector. Which ones are which is anybody's guess. -- Scott G. Hall GTE Government Systems North Carolina Systems Center email: Scott.Hall@GSC.GTE.Com ////////////////////////////////////////////////////////////////////////////// Date: Wed, 16 Jul 2003 15:59:46 -0400 (EDT) From: der Mouse Subject: Re: SS10 serial Y-cable Zoltan HERPAI writes ... > > i'm searching an Y-cable for my SparcStation10 > [by implication, for the serial ports]. While I don't know of any source for pre-built cables, they are fairly easy to make if you're not afraid of a soldering iron. Just look at the RS-232 pin names; serial port B is all the "Secondary " signals. (For example, pin 13, Secondary Clear To Send, is the ttyb version of pin 5, Clear To Send.) Since it's small, here is the full table, typed in back when I actually dug out a copy of the EIA RS-232 spec. A few of the pins have multiple uses; the only one that's relevant to what you want is pin 12, which you should treat as secondary DCD. Pin Source Type What 1 Ground Shield, protective ground 2 DTE Data Transmitted Data 3 DCE Data Received Data 4 DTE Ctl Request To Send 5 DCE Ctl Clear To Send 6 DCE Ctl DCE Ready 7 Ground Signal ground 8 DCE Ctl Received Line Signal Detector 9 (Reserved for testing) 10 (Reserved for testing) 11 (Unassigned) 12 DCE Ctl Secondary Received Line Signal Detector DCE Ctl Data Signal Rate Selector (DCE) 13 DCE Ctl Secondary Clear To Send 14 DTE Data Secondary Transmitted Data 15 DCE Timing Transmitter Signal Element Timing (DCE) 16 DCE Data Secondary Received Data 17 DCE Timing Receiver Signal Element Timing (DCE) 18 DTE Ctl Local Loopback 19 DTE Ctl Secondary Request To Send 20 DTE Ctl DTE Ready 21 DTE Ctl Remote Loopback DCE Ctl Signal Quality Detector 22 DCE Ctl Ring Indicator 23 DTE Ctl Data Signal Rate Selector (DTE) DCE Ctl Data Signal Rate Selector (DCE) 24 DTE Timing Transmitter Signal Element Timing (DTE) 25 DCE Ctl Test Mode -- /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B [See also http://www.stokely.com/unix.serial.port.resources/A-B-Ycablepinout.html http://lib1.store.vip.sc5.yahoo.com/lib/anysystem/SunCables.pdf ] ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.palmtops.pilot Organization: Road Runner Message-ID: Date: Fri, 26 May 2000 21:26:44 GMT From: richard f lansing Subject: Star Tac serial cable pin assignment Motorola Star Tac serial cable for star tac digital cdma dual mode cell: pin 1: blue pin 2: orange TD (to pin 3 RD of 10-pin palm platform device hot-sync cable) pin 3: red RD (to pin 5 TD .........................................................................) pin 4: brown DSR (to pin 1 DTR .........................................................................) pin 5: green SG (to pin 10 SG .........................................................................) pin 6: yellow pin 7: black CTS (to pin 4 RTS .........................................................................) pin 8: purple RTS(to pin 6 CTS .........................................................................) pin 9: white ////////////////////////////////////////////////////////////////////////////// Organization: University of Cambridge, England References: Message-ID: <8jq6ng$ji2$1@pegasus.csx.cam.ac.uk> Newsgroups: comp.terminals Date: 3 Jul 2000 14:07:44 GMT From: Ben Harris Subject: Re: Break signal??? to Sun box In article , Tony Singleton wrote: > > Does anyone understand what happens when a terminal sends a Break > signal? I think that the TD line from the terminal to the DTE is held at > zero volts for a period of time, It's a continuous MARK, which in RS-232 is a continuous -12V-ish. If your receiver decides that 0V is closer to -12V than to +12V, it'll consider ground to be MARK. > I believe that this can occur either from > pressing the break key or powering off the terminal. What's the proper > meaning of a break signal (my Sun server running Solaris drops to a > firmware prompt)? I don't think it generally has a defined one. On Unix systems, it's traditional for it to generate a SIGINT. On many systems, it's used as a signal to break out of the current process into some kind of supervisor (or into a ROM monitor as on Suns). > Can software like minicomm generate these break signals? Yes. On POSIX systems, tcsendbreak() sends a break. I expect minicom has some way to request this. -- Ben Harris Unix Support, University of Cambridge Computing Service. If I wanted to speak for the University, I'd be in ucam.comp-serv.announce. .............................................................................. [Solaris 8 (and newer) allows configuration of an "Alternate Break" sequence to avoid problems from serial disruption; see "man kbd".] .............................................................................. Newsgroups: comp.terminals References: <8jq6ng$ji2$1@pegasus.csx.cam.ac.uk> NNTP-Posting-Host: phorcys.east.sun.com Organization: Sun Microsystems Inc. - BDC Message-ID: From: James Carlson Subject: Re: Break signal??? to Sun box bjh21@cus.cam.ac.uk (Ben Harris) writes: > In article , > Tony Singleton wrote: > > Does anyone understand what happens when a terminal sends a break > >signal? I think that the TD line from the terminal to the DTE is held at > >zero volts for a period of time, > > It's a continuous MARK, which in RS-232 is a continuous -12V-ish. If your > receiver decides that 0V is closer to -12V than to +12V, it'll consider > ground to be MARK. That's close but backwards. An idle asynchronous line is held in MARK (-12V) condition. A break is a SPACE (+12V) condition that lasts longer than a valid character time (typically, it's set for at least 100 milliseconds). This is a glitch that terminal server vendors have had to live with for many years. For one example, see: http://www.cisco.com/warp/public/770/fn-tsbreak.html -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.admin,comp.sys.sun.admin,comp.unix.solaris, comp.sys.sun.hardware References: <3A2B5320.59BC2419@cisco.com> <90gnk5$71f$2@news.panix.com> <3A2C61C4.66A0DE5F@cisco.com> <90ht70$hvv$1@news.panix.com> Date: Mon, 04 Dec 2000 23:24:03 -0800 Organization: Cisco Systems Message-ID: <3A2C9813.83BBC4BE@cisco.com> From: Francis Subject: Re: Null Modem Cable fr RJ45-to-DB25 Modem Adapter. Hi Greg, Here's the pinout for RJ45: 1 - RTS 2 - DTR 3 - TXD 4 - GND 5 - GND 6 - RXD 7 - DSR 8 - CTS Actually, this pinout is referring to the console port at Cisco Access Server (which is of type RJ45) Appreciate your help. Regards, Francis. Greg Andrews wrote: > franciso@cisco.com writes: > >Hi Greg, > > The pinout for RJ45-to-DB25 modem adapter is as follow: > > > > 4 (RTS) > > 20 (DTR) > > 3 (TXD) > > 7 (GND) > > 2 (RXD) > > 8 (DCD) > > 5 (CTS) > > > > You have listed the pinout for the DB25 connector on a modem. > > That's not what I asked for, and it doesn't help me answer your > original question. > > Please post the pinout of the Cisco RJ45 jack. Not a diagram of > any cable, just the pinout of the RJ45 jack. > > -Greg > -- > +++++ Greg Andrews +++ gerg@panix.com +++++ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.admin,comp.sys.sun.admin,comp.unix.solaris, comp.sys.sun.hardware Message-ID: <90jedp$173$1@news.panix.com> References: <3A2B5320.59BC2419@cisco.com> <3A2C61C4.66A0DE5F@cisco.com> <90ht70$hvv$1@news.panix.com> <3A2C9813.83BBC4BE@cisco.com> Date: 5 Dec 2000 19:07:37 GMT Organization: I have a map of the United States that's actual size From: Greg Andrews Subject: Re: Null Modem Cable fr RJ45-to-DB25 Modem Adapter. franciso@cisco.com writes: > > Actually, this pinout is referring to the console port at Cisco >Access Server (which is of type RJ45) > You're trying to connect your Sun to the *console* port of your Cisco? I thought you had a terminal server and wanted to connect the sun to one of the regular ports instead of the console port. At any rate, here's the proper wiring for of null modem cable for the console port you posted: Cisco RJ45 Sun DB25 ---------------------- 1 - RTS --- CTS - 5 2 - DTR --- DCD - 8 3 - TXD --- RXD - 3 4 - GND --- GND - 7 5 - GND 6 - RXD --- TXD - 2 7 - DSR --- DTR - 20 8 - CTS --- RTS - 4 Note that you can connect the DB25 ground pin (7) to either of the ground pins on the RJ45 (4 or 5). -Greg -- +++++ Greg Andrews +++ gerg@panix.com +++++ I have a map of the United States that's actual size. -- Steven Wright ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.os.linux.development.system Message-ID: <3A37B40C.C5838F79@post.publicly> References: <3A373361.3AE50551@gmx.de> NNTP-Posting-Host: dhcp224.glerl.noaa.gov Date: Wed, 13 Dec 2000 12:38:20 -0500 From: Ron Subject: Re: Q: Linux serial line programming, open() hangs Christoph wrote: > > Hi, > > if i start my program the second time, it hangs infinitly at the open() > system call. The first time everthing worked fine. > > Do you know why this is and how to avoid it ? > Would be nice, if you could have a quick look at the serial connection > part of the sources attached. > > Thanks in advance, > Christoph Hagedorn Don't have time to review your code, but consider this: you have to open the device before you can set the flags. So it opens under the old settings, which may block! What I do is open the port non-blocking, set the flags, close it and then reopen it in the blocking mode before using it. Ron ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris Message-ID: <9dac6a$41u$1@bob.news.rcn.net> References: Date: 9 May 2001 03:05:46 GMT From: lstowell@lenny.sfrn.dnai.com (Lon Stowell) Subject: Re: Resistor circumvention of BREAK signal In article , wrote: >Does anyone have some light to add to this exchange? Thanks, > > - Stephen P. Schaefer > > From: "Celeste Stokely" > Subject: RE: http://www.stokely.com/unix.sysadm.resources/faqs.sun.html > Date: Tue, 8 May 2001 14:23:57 -0600 > To: >Reply-To: > >Ooh - you got me there. In The Olde Days, pin 25 used to be attached >to ground (frame ground?). It isn't these days. My most recent info >came from a Cisco doc about this, but I don't know if it includes >WHY pin 25 should work. (But, I bet it wouldn't work on modern Suns.) Pin 25 hasn't been a ground that I can ever recall in the EIA or RS spec. Pin 1 is chassis ground, which really shouldn't be used for signal referencing, and Pin 7 is the data signal reference, aka signal ground. The EIA binary 1 for data is a voltage between -3 and -25 or -30 volts. A binary 0 for data is between +3 and +25 [or 30] volts into the input impedance. The receiver is SUPPOSED to totally ignore any transitions that occur strictly between the +3 and -3 region, but far too many don't, and will trigger data sensing on changes in that region when they shoud not. A break results when the input to RX Data goes from a binary 1 [-3 or more] volts up thru +3 [or less for a crappy EIA circuit] and stays there through what should have been the stop bit time. A 4.7K ohm resistor to pin 7 frequently works, you can get more exotic with a diode, cap, and resistor but it is rarely needed. Some also use the resistor between pin 20 [DTR which is a voltage high, a binary 1, but a data 0] and RX Data. ////////////////////////////////////////////////////////////////////////////// Date: 9 May 2001 01:36:16 GMT Organization: I have a map of the United States that's actual size Newsgroups: comp.unix.solaris Message-ID: <9da6ug$7hq$1@news.panix.com> From: Greg Andrews Subject: Re: Resistor circumvention of BREAK signal u242004394@spawnkill.ip-mobilphone.net writes: > >In the section on overcoming the BREAK signal, you report > > * Resistor/soldering iron hack method: > > * This solution may not work for all devices. If you tie a >4.7K resistor (1/4 Watt) between pins 3 and 25 of the ttya > port, you electrically prevent a BREAK signal either from the > key or from disconnecting or powering down the terminal. This > prevents intentional halts except by removing the resistor, > but does allow recabling. > > >I'd appreciate a better explanation. Your page on the pinouts for most >Sun systems shows Pin 25 as a ``No Connection'' -- not a ground, not a >constant on/space/0/+3V thru +12V, not a constant off/mark/1/-3V thru >-12V. If the ``No Connection'' is true, I believe a resistor to that >pin would have no effect. I Am Not An Electrical Engineer, but it seems >like a resistor to a *ground* pin, like pin 7, *might* work. Do you >have access to any real EE's who could pronounce on this? Thanks, It won't work, in most instances. The Cisco web page is Enormously misleading, and any sites that echo the Cisco page are just as misleading. (Celeste's page is the least misleading of the ones I've seen so far) The resistor between pin 3 and 25 method originated in an e-mail message sent to Sun Support several years ago (ca. 1992 or 1993) by a Sun customer. It was something that the customer tried and enjoyed some success with. Sun support has given the details of the method out from time to time, but they have never promised that it would work. Apparently some folks at Cisco got hold of the method and re-published it on their web site. Here are the three most important facts about the resistor method, followed by a more technical explanation of its effects: 1) It was never designed to *block* break signals sent by a terminal, computer, or terminal server connected to the Sun machine. 2) It was never *possible* for the resistor to block break signals transmitted from the terminal/computer/terminal-server. 3) It was only intended to suppress glitches produced by plugging or unplugging an RS232 cable, so those glitches would not look like a break signal to the Sun. Unplugging or plugging an RS232 cable causes the pins to make and break contact a few times as you slide the connectors together. This can cause the signal on the Sun's RxD (Receive Data) pin to jump from 0V to -5V and back as contact is made and broken. Capacitance and/or inductance in the cable can cause the voltage jump from -5V back to 0V to overshoot and produce a glitch of positive voltage. If the cable conditions are right, the glitch can rise above +3.5V, and can last longer than a couple thousandths of a second (milliseconds). This kind of glitch looks exactly like a break signal to the Sun machine. Glitches caused by cable capacitance or inductance like that usually don't have a lot of energy behind them. The resistor we're talking about was designed to drain off enough energy so the cable-induced glitches can't rise high enough or last long enough to look like a break signal to the Sun. So the resistor can sometimes help when unplugging or plugging the console cable causes your Sun to halt. However, it can't help the other kinds of break signals. These are often caused by powering the attached terminal/computer/terminal-server down or up. When this happens, the RS232 driver circuitry in the attached device forces the voltage on the pin to +3.5V (or higher), and backs it up with a LOT of energy from its power supply. Since this kind of glitch has plenty of energy behind it, the resistor can't drain enough away to prevent the signal from looking like a break to the Sun. The resistor won't help. (it was never intended to help this situation anyway) The only solutions when you have equipment that glitches its outputs like that are to (a) re-design the equipment to clamp the output voltage to zero volts when the power is cycled, (b) replace the equipment with other equipment that doesn't let its outputs glitch, or (c) reconfigure the Sun to not halt on the break signal. Infodoc 21258 on sunsolve.sun.com describes the patches and procedure to make Solaris 2.6 and later halt on an "alternate" abort sequence instead of the RS232 break signal. -Greg -- +++++ Greg Andrews +++ gerg@panix.com +++++ I have a map of the United States that's actual size -- Steven Wright ////////////////////////////////////////////////////////////////////////////// Date: Wed, 09 May 2001 00:10:16 GMT Organization: Excite@Home - The Leader in Broadband http://home.com/faster Newsgroups: comp.unix.solaris Message-ID: <3AF88AD1.EA878F64@home.com> From: Andrew Sun Subject: Re: Resistor circumvention of BREAK signal According to a copy of EIA/TIA-232-E, pin 25 is TM "test mode", direction is from DCE. "Signals on this circuit indicate whether the local DCE is in a test condition." Whether pin 25 is really connected and used on a Sun workstation is implementation specific (I don't know, and my guess is no connection). A "break" signal is a prolonged space/logic0/+3V thru +12V condition on a data (transmit/receive) line. To prevent a false break, it would be necessary to hold the affected line as mark/logic1/-3v thru -12v during transient events. Grounding the pin, via resistor or otherwise, would place the line in an ambiguous state, since -3v < 0 gnd < +3v. Thus, it might, or might not work as a false break prevention method. Similarly, floating (disconnecting) an input pin would also place it in an ambiguous state, which may also be interpreted as a break. A powered down console terminal likely places its output signal lines in a floating state. Thus, a resister on the Sun connecting a now floating RD to a line that's usually in a mark state (TD, RTS, or DTR should be mark for an idle port) should prevent the floating pin ambiguity, and hold the pin as mark. The resister should allow the RD line to operate normally when the console terminal is powered. Note that I haven't given this much thought, so I will not advise whether this is a good solution, or whether it would even work. Thus, all the usual disclaimers apply. Another item of concern are the simple solutions that electrically prevents an intentional BREAK. This could prevent normal serial communications from working at all. Transmitting characters is the electrical equivalent of sending large numbers of carefully timed, very short duration BREAKs. > If the ``No Connection'' is true, I believe a resistor to that > pin would have no effect. If the resister isn't connected to anything (no connection), yes, it would have no effect. > but it seems > like a resistor to a *ground* pin, like pin 7, *might* work. Or it might not, as discussed above. -- "Using & Managing PPP," http://www.oreilly.com/catalog/umppp ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.sun, comp.sys.sun.hardware, comp.unix.solaris References: <03p38.8963$l61.29054@rwcrnsc54> <7Es58.38703$oE5.3506141357@newssvr21.news.prodigy.com> Message-ID: Organization: I have a map of the United States that's actual size Date: 29 Jan 2002 15:58:36 GMT From: Greg Andrews Subject: Re: HELP!!! how to send a break across a modem to a console port? Darren Dunham writes: > >Most will not simply pass through a BREAK signal, the modem itself won't >(it's an RS-232 signal, not a character). > False. Modems have always transported RS232 break signals for decades. It's true that the break signal can't "pass through" modems as it does through a cable. However, when the modems are configured properly, the local modem will recognize your break signal, send a notice to the remote modem (these days it's usually through the error control protocol), and the remote modem will generate a break signal on its RS232 interface. That's what a terminal server would do from an attached RS232 terminal. > >*however*, if you Solaris 8, or 2.6 or 7 with sufficient patches, you >can change the halt signal on the box (only with the OS running) from >the RS-232 BREAK signal, to a 3 character ascii string: A , >followed by a "~", followed by a "b". If you set that up, then you may >not need the BREAK signal at all. > That's Return, Tilde (~), Control-B. -Greg -- +++++ Greg Andrews +++ gerg@panix.com +++++ I have a map of the United States that's actual size -- Steven Wright ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.sun.admin References: <58e9e63e.0210100422.1644888f@posting.google.com> Message-ID: Date: Thu, 10 Oct 2002 16:11:31 +0000 (UTC) From: Greg Andrews Subject: Re: V120 serial port -- the same pin assigment with Netra t1 AC200? hugeng@yahoo.co.jp (Hu, Geng) writes: > > A quick question: does the Sun V120 server use the same > serial port pin assignment as the Netra T1 AC200? Yes. If you want to connect a modem, you can wire the V120's DSR pin to your modem's DCD pin. This won't work with the Netra t1 or Netra X1 machines, but it will with the Vxxx machines with RJ45 serial port connectors. -Greg ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris NNTP-Posting-Host: byers.east.sun.com NNTP-Posting-Date: Mon, 3 May 2004 14:08:39 +0000 (UTC) References: Message-ID: Organization: Sun Microsystems Corporation Date: Mon, 03 May 2004 10:08:38 -0400 From: ML Starkey Subject: Re: Access Sun E250 via cable Trev wrote: > Hi, > > I've been trying to connect my windows pc to my solaris E250 server > using a null modem cable 9pin to 25pin. I have no problems connecting > to my Sun Fire 210 using the cable those servers came with - 9pin to > RJ45. > I've bought and created my own null modem cable to be sure it's not > the cable. Is there a setting on the E250 to allow terminal > connections. There is no keyboard pluged into the server too. There > is a video card in the server which is comming out, but before I > remove the video card I need to ensure that I can connect to the > server via cable. > I have tried using hyperterminal and Secure CRT. The E250 has a 25-pin (DB-25) serial port and the 210 has a serial management port and a 9-pin (DE-9) serial port. Despite similarites (they are all serial ports of some kind), best to think of them as apples and oranges. There is no setting to allow terminal connections. If you are having problems, then it's your cabling, your null modem connectors, your gender changers, etc. Something in that setup. All you need on the terminal side is 9600, 8, n, 1 no flow control. You would want to make sure that the eeprom settings for the 250 for input-device and output-device are either keyboard and screen respectively OR both set explicitly to ttya (or ttyb) You don't have to remove the video card if you don't want to. If you have other Sun systems available, try a standard null modem between the 250 and another sun with an available 25-pin serial port and use # tip -9600 /dev/cua/X (where X is whatever that available port is) as root. -- Martha ////////////////////////////////////////////////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Newsgroups: comp.dcom.telecom Path: cs.utk.edu!news.msfc.nasa.gov!sol.ctr.columbia.edu!howland.reston.ans.net !news.moneng.mei.com!uwm.edu!lll-winken.llnl.gov!telecom-request Message-ID: Organization: TELECOM Digest X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 14, Issue 407, Message 5 of 7 Lines: 98 Date: Tue, 09 Nov 1994 03:11:44 -0400 From: Monty Solomon Subject: GeoPort Technology Passed along FYI to the Digest - Strong Support for GeoPort Technology Paves Way for Development of Standard Link Between Computers and Telephones CUPERTINO, CA--October 19, 1994--Apple Computer, Inc., together with leading computer and telephony vendors, today announced the emergence of GeoPort as their preferred cross-platform computer telephony interconnect standard. Vendors participating in the announcement include: AOX, Inc., AT&T Corp., Crystal Semiconductor Corp., Cypress Research Corp., IBM Corp., Motorola, Inc., SAT Groupe SAGEM, Siemens PN, Siemens Rolm Communications, Inc., and Zilog, Inc. GeoPort, developed by Apple Computer, is a plug-and-play serial interface which is backward compatible with the serial ports used in most personal computers, but offers over 200 times the bandwidth. Beyond just providing a physical connection, it also hides the differences between differing computer platforms and communications systems, while allowing any kind of data to pass between them. Apple first introduced GeoPort in August 1993. Later that year, it began working with the major telephony and computer vendors including AT&T, IBM, and Siemens Rolm, to refine GeoPort to fully meet the needs of both communities. Today's announcement reflects the results of that joint effort. "With GeoPort, we are working to eliminate the technical and economic barriers which have constrained the development and adoption of personal communication products," said Rick Shriner, vice president of Apple's core technologies group. "With the support of both the telephony and computer industries, we believe we are developing a powerful building block for global communications and collaboration." GeoPort offers a powerful solution for both the computer and telephony markets. Telephone and computer customers will be able to communicate and collaborate more easily and effectively than ever before. They will be able to talk to each other, send faxes and computer data to each other, see each other, and share common information, without having to worry about what kind of telephone, telephone line, or computer happens to be present at each point of the connection. Apple Computer, Inc., a recognized pioneer and innovator in the information industry, creates powerful solutions based on easy to use personal computers, servers, peripherals, software, online services, and personal digital assistants. Headquartered in Cupertino, California, Apple (NASDAQ: APPL) develops, manufactures, licenses and markets products, technologies and services for the business, education, consumer, scientific & engineering and government markets in over 140 countries. Apple, the Apple logo and Macintosh are registered trademarks, and GeoPort is a trademark of Apple Computer, Inc. ATTACHMENT Fact Sheet GeoPort Technology GeoPort , developed by Apple Computer, is a plug-and-play serial interface which is backward compatible with the serial ports used in most personal computers, but offers over 200 times the bandwidth. The serial communications architecture of GeoPort is optimized for computer-telephony integration: - It allows any telephone (or telephone line, up to T1/E1 rates) to be connected to any computer, in any country in the world. - It supports any set of Telephony APIs (application programmatic interfaces) such as AT&T/Novell's TSAPI, IBM's CallPath, Microsoft's TAPI, or Apple's Telephone Manager. - It allows any telephone to take full advantage of the services provided by the computer, and vice versa. - It is inexpensive to implement, and uses existing technology. - It supports any type of information: computer data, voice, fax, modem, voice, video. - It allows multiple simultaneous streams of informationQincluding real time information like voice and videoQto pass through a telephone connection in order to be processed by the computer. These services will allow vendors and developers the opportunity to offer such features as: - An integrated mail-box for voice mail, email, and facsimiles. - Fax and modem capability over a digital telephone connection, like that found in an ISDN line or in many PBX environments. - Document sharing or other simultaneous voice and data applications over conventional phone lines. - Video conferencing over a PBX or ISDN connection. - Telephone assistant services, like automated call screening, call forwarding, and call tracking. Apple, the Apple logo and Macintosh are registered trademarks and GeoPort is a trademark of Apple Computer, Inc. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [As of 2002, the only mention of "GeoPort" on Apple's web site is a legal notice listing all of Apple's trademarks. I guess the GeoPort product never made much impact. Now Firewire... ...RSS] ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.sun.admin Organization: I have a map of the United States that's actual size Message-ID: References: Date: Wed, 5 Feb 2003 18:17:43 +0000 (UTC) From: Greg Andrews Subject: Re: Serial port configuration "Jarek Tomaszewski" writes: > > > >I'm trying to use one of serial port on Sparc workstation (Ultra 10 with > >Solaris 8) to communicate with a device. Does anyone have an idea how to > >configure a serial port (e.g. ttyb)? "Greg Andrews" wrote: > > You don't configure a serial port. The software that opens the port > and communicates with the external device performs the port configuration. "Jarek Tomaszewski" writes: > >That sounds reasonable but what should I do when I get information >that the port is already in use. > Find out what is using it. For serial port "A", you can use fuser: fuser /dev/term/a fuser /dev/cua/a fuser /dev/ttya If fuser finds processes that have the port open, it lists the process numbers, each with a letter appended to the number. The fuser man page describes the meaning of the letter. Once you have one (or more) process numbers, use ps to see what the processes are. For example, process number 327: ps -fp 327 UID PID PPID C STIME TTY TIME CMD root 327 324 0 Feb 03 ? 0:00 /usr/lib/saf/ttymon > >I managed to delete login service association but it >is still in use :-( > If the serial port is the system console, you won't be able to use it for other things. Use the other serial port. > >What is the best terminal console application working with serial port? > Depends on what you're using the serial port for. Your question is vague, but it suggests you are trying to connect from your local SPARC serial port to the serial console of another machine. If that's what you are trying to do, then the combination of dtterm or xterm and a program like tip or kermit or minicom will do. Dtterm or xterm handles the terminal emulation, and the other program (tip, kermit, or minicom) handles the serial port I/O. Tip comes with Solaris, and all you need to do is log in as root and type: tip -9600 /dev/cua/a (or /dev/cua/b for the "B" port) Then your keystrokes will go out the port and what comes in the port will be displayed in the dtterm/xterm window. When you want to send a break signal, type Return, then Tilde (~), then Number sign (#). When you want tip to close the serial port and exit, type Return, then Tilde (~), then Period (.). -Greg -- Do NOT reply via e-mail. Reply in the newsgroup. / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / [Archiver's Note: I have found by personal experience that Greg really does prefer to communicate via newsgroups.] ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.sun.admin Organization: Sun Microsystems Message-ID: <3E40FB92.FDC90840@sun.com.spam> References: Date: Wed, 05 Feb 2003 11:54:58 +0000 To: Jarek Tomaszewski From: Chris Lawson Subject: Re: Serial port configuration Jarek Tomaszewski wrote: > > Hi, > I'm trying to use one of serial port on Sparc workstation (Ultra 10 with > Solaris 8) to communicate with a device. Does anyone have an idea how to > configure a serial port (e.g. ttyb)? Jarek, Try this site. http://www.stokely.com/unix.serial.port.resources/index.html -- Chris ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.sun.admin, comp.sys.sun.hardware References: <3E46F79E.EAA1E4C9@ntlworld.com> Message-ID: Organization: Purdue University Date: Thu, 13 Feb 2003 16:30:47 +0000 (UTC) From: Jeff Wieland Subject: Re: Any way of getting cheap serial ports?? In article "David Wade" writes: > >"Greg Andrews" wrote in message >news:b275q6$eoq$1@reader1.panix.com... >> "Dr. David Kirkby" writes: >> >Rich Teer wrote: >> > >> >Yes, ethernet is fine until there is a problem! >> > >> >> 2. Get a PCI card with multiple serial, and a driver for them. >> >> Ebay might be a good source for these, but I have no idea >> >> what the cost would be. >> > >> >I was hoping that someone might say use model XYZ and the drivers in >> >Solaris will work for it, but perhaps no such luck. >> > >> >> Well, you can get Sun's SAI/P card, but your subject line >> uses the word "cheap", and I haven't hear Sun's card called >> cheap. >> >> Digi makes multiport PCI cards, I believe, though I don't know >> if they're cheap either. >> > >In the PC world the DIGI cards are widely used, but as Greg says they are >far from cheap new. >The DIGI web site (www.digi.com) seems to indicates some have Solaris >drivers. > >There are also one or two on E-Bay but I am not sure how old they are, if >there are Solaris drivers for them to whatever. However the current prices >do look cheap so it might be worth a bid. Just make sure you get all the >bits you need first, (cables and card) as getting any missing bits from digi >is likely to be very expensive. > >> -Greg >> -- >> Do NOT reply via e-mail. Reply in the newsgroup. If you can find any of the old Central Data SCSI terminal servers, they work quite well. Digi bought out Central Data. There are drivers for up to at least Solaris 8. You don't want to put them on the same bus with UltraSCSI devices, but they'll work fine with the Symbios-based UltraSCSI HABs. There's a 16 port unit on Ebay right now: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3401611084&category=1484 We ran a pair of these on an SS20, driving a total of 24 Courier V.Everything modems. They are very low overhead devices. Assuming that you have a PCI slot to spare, you could pick up a cheap Symbios SCSI controller, and be off and running. -- Jeff Wieland ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris References: Message-ID: Organization: San Francisco, CA Date: 12 Mar 2003 22:42:05 GMT From: Andrei Ivanov Subject: Re: linux and solaris serial connection Howieman wrote: > I am using my laptop with Linux mandrake at work. > But I need to be able to connect it to Sun-computers through a serial-line. > Can anyone help me with this. I need an explaination on how to do this. > With two Solaris-computers I can use the "tip hardwire"-command. How is this > done from linux to solaris? Under linux you can use 'minicom'. By default it assumes higher speed, so, you might place the following into your /etc/minirc.dfl: pr port /dev/ttyS0 pu baudrate 9600 pu bits 8 pu parity N Then start 'minicom -o'. -- andrei ////////////////////////////////////////////////////////////////////////////// Newsgroups: alt.folklore.computers Message-ID: <1kck7b.d0a1.ln@via.reistad.priv.no> References: <3e8ae086.45754328@news.m.iinet.net.au> Date: Wed, 16 Apr 2003 21:57:53 +0200 From: Morten Reistad Subject: Re: Any DEC 340 Display System Doco ? According to Brian Inglis : > >On Mon, 14 Apr 2003 17:31:40 -0400 in alt.folklore.computers, >Charles Shannon Hendrix wrote: > >>In article , David Powell wrote: >>> >>> In article , >>> peter@taronga.com (Peter da Silva) in alt.folklore.computers wrote: >>> >>>> >>>>You have to remember how slow 9600 bps is, and how slow the vt100 is. >>> >>> Yup, VT100s are s-l-o-o-o-o-o-w. >> >>One thing I noticed with them, is that under PrimeOS, I rarely had any >>screen corruption problems, but had it frequently when accessing DEC >>systems, or some UNIX systems. That was only because the original Prime AMLC (8/16 port async card) was designed even more bogus than the RS232 drivers in the VT100. This board and its drivers were the single most expensive design mistake Prime ever did. >Lousy wiring and/or RS-232 drivers and receivers: you're only >guaranteed up to about 25' at 9600bps with good cables and >electronics, and proper grounding at both ends; half that for >each speed doubling; some drivers may source 5V, others may >source 25V; there are no guarantees in the spec, only limits; >better cables and better cable routing can solve some problems; >neither UTP or STP are really good for RS-232; external limited >distance datasets (LDSes) can handle the wiring better; YMMV. RS232 stinks, pure and simple. Follows a line of backwards compatability with bogus open-ended half-specified interfaces dating way too far back. >>These days I run a DEC 510, and I get corruption now and then. Not sure >>if the old Sun server can't keep up, or the terminal is having problems. > >Corruption is almost always electrical or line/wire problems, not >really the fault of the terminal or the host (unless the drivers >and/or receivers are wimpy); their chips sample according to the >spec, and interpret the bits according to the voltages received; >your only recourse is to shorten the wires or boost the signal; >this is based on my experiences long ago with RS-232 and wiring. Bad async hardware and drivers was a common problem on minicomputers and their terminals. It made a whole aftermarket of line drivers, local-modems, optoisolators, and muxes that went away with the Internet. -- mrr ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.bsd.freebsd.misc Message-ID: <86y8xgo3wl.fsf@cail.baugher.pike.il.us> Organization: ESC Date: Tue, 26 Aug 2003 10:05:30 -0500 From: Aaron Baugher Subject: Dead serial ports I've got a really odd serial port problem. I'm not even sure it's FreeBSD related, but I have to start somewhere... I had a system running 4.8-RELEASE on an old Pentium 200 system, dialing up ppp through an external modem on /dev/cuaa0 (COM1). All worked fine, until the hard drive had to be replaced. I thought I'd upgrade to 5.1 while I was at it. Everything worked fine, except ppp timed out waiting for a response from the modem. I tried talking directly to the modem, and while the TR light comes on, nothing I type does anything and the send/receive lights don't flash like they should. So I tried a different modem. Tried COM2. Different old motherboard (Cyrix 166). luck. Different serial cable. Tried going back to 4.6_2-RELEASE (what I happened to have on CD). Finally I even tried OpenBSD. Nothing worked; in every case I can't get any data through the serial ports, although the TR light on the modem lights up to show it's got a connection. The only way I can get it to work is to plug the modem into the serial port on a newer computer (Pentium 800), but I can't spare that for my dialup system right now, so that's not a long-term option. Anyone have any suggestions? As you can see, I've now replaced every component in the chain -- software, hardware, cables, etc -- and nothing helps. It sort of seems like an IRQ problem, but I don't know why that would have started happening all of a sudden, especially since this is a very bare-bones system -- just a video card and ethernet card; nothing to cause an IRQ conflict. Just had a thought: Is it possible for a faulty power supply to cause problems with the serial ports while everything else works? I think that's the only part I haven't swapped out. Thanks, -- Aaron abaugher@esc.pike.il.us ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.bsd.freebsd.misc References: <86y8xgo3wl.fsf@cail.baugher.pike.il.us> Message-ID: Date: Tue, 26 Aug 2003 15:13:27 -0400 From: Jason Bourne Subject: Re: Dead serial ports "Aaron Baugher" wrote in message news:86y8xgo3wl.fsf@cail.baugher.pike.il.us... [snip] > Just had a thought: Is it possible for a faulty power supply to cause > problems with the serial ports while everything else works? I think > that's the only part I haven't swapped out. [snip] Greetings: The serial ports make use of +/- 12 volts dc from the power supply to generate the rs-232 signal. Check the 12vdc output from the power supply; even if present it would be nice to view it on an oscilloscope to look for excessive ripple. -Jason ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals, comp.os.linux.hardware Message-ID: References: <3f689f9f$0$20186$626a54ce@news.free.fr> Organization: The Late, Great Stratagy Users Group Date: Wed, 17 Sep 2003 23:23:23 GMT From: Richard S. Shuford Subject: Re: How to plug a WYSE 185ES (serial connections) David le Bourgeois wrote: | | I have a WYSE 185-ES terminal and a classic PC under Linux. | But I know neither where to connect it nor how. I don't understand | anything with all that relates to the possibility of "wiring". I | know serial and parallel port. I see what is a null modem cable | (DB9, DB25). But I'm not able to do something, because I don't know | how to plug the device :-( Which sort of cable? I tested with the | same cable which is useful for my scanner (a null one I suppose?). | But it seems to me that it is the parallel one, because it is more | larger than the serial one. On a typical PC, a 25-pin D-shaped connector (DB-25) may be either a serial or a parallel port. However, the custom adopted in 1981 by IBM for its first Intel-8088-based PC is that a serial connector mounted on a chassis is expected to present pins (male), whereas a parallel connector should be a female type. If you have a mix of male and female DB-25 connectors on the back of a PC, then, probably the male ones are serial and female ones are parallel. On a typical PC, if you have a 9-pin D-shaped connector, it is usually a serial port, although rarely it might be for a joystick or something else unusual. Such a connector would properly be called a "DE-9", yet because shell-size code letter's function is not widely known, most descriptions call it a "DB-9". Oh, if the connector name has a suffix letter "DE-9-P" or "DE-9-S", in that context it means "plug" (male) or "socket" (female), *not* parallel or serial! IBM introduced use of the DE-9-P for RS-232-C interfaces in 1985 with the "PC/AT" model (which was based on the 8-MHz Intel 80286 processor). Furthermore, the serial port on a PC should be a DTE-type RS-232-C interface. If a DTE port is being connected to a DCE-type RS-232-C interface (as you would find on a modem), a straight-through cable is used. To connect a DTE directly to another DTE (as connecting a PC to a terminal), you need a cross-over cable wired as the infamous "null modem", by means of which the two DTE serial ports are each fooled into thinking it is connected to a modem. Some equipment, however, may use female DB-25's for serial ports, and the gender may not match the DTE or DCE flavor. Your mileage may vary. No smoking. Fasten seat belts. A web site with diagrams is here: http://www.hardwarebook.net/connector/serial/serial25.html http://www.hardwarebook.net/connector/serial/serial9.html http://www.hardwarebook.net/connector/serial/rs232.html Accumulated information on video terminals resides here: http://www.cs.utk.edu/~shuford/terminal_index.html ...Richard S. Shuford shuford(at)list.stratagy.com -- /usr/xpg4/bin/date '+%C%y-%m-%d_%H:%M:%S' ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals NNTP-Posting-Host: ip70-185-194-243.ok.ok.cox.net NNTP-Posting-Date: Wed, 05 Oct 2005 01:05:36 EDT References: <1128198587.234600.195490@g44g2000cwa.googlegroups.com> Message-ID: Date: Wed, 05 Oct 2005 05:05:36 GMT From: mroberds@worldnet.att.net Subject: Re: Using Wyse 60 Terminals with Welch Allyn 8300 MICR scanners s10jam@yahoo.com wrote: > > I have a customer who is using Wyse 60 Terminals with Welch Allyn 8300 > MICR scanners in a POS enviornment. The scanners connect through a > serial wedge that runs between the serial port and the terminal. Has this setup ever worked, or are you trying to bring up something new? > When the wedge is not connected, the terminals work fine. When the wedges > are connected, the terminals lock up when an item is scanned. I can think of a couple of things that might be happening. First, as you hinted, the scanner could be set to the wrong serial speed. This probably makes the host computer see garbage when an item is scanned, and it then doesn't give the right output to the terminal, so the terminal appears to be locked up. Most likely, the scanner should be set to the same speed, data bits, parity, and stop bits that the terminal is using. Quite often this information is expressed as something like "9600 8N1", which means 9600 bits per second, 8 data bits, no parity, one stop bit. This information should be in the terminal setup screen somewhere--read the setting and then set the scanner to match. Another possibility is that the scanner might be doing something with the handshaking lines that the terminal doesn't like. Besides the data lines, there are various control lines that can be used to start or stop transmission. For instance, if the host computer is sending too much data to the terminal, the terminal can use a control line to signal the host computer to wait for a little while. The host can also tell the terminal to stop, which is what might be happening. First, see how many wires are in the cable from the terminal to the host computer. If it's only two or three, then this isn't your problem. If there are more wires, get a serial "breakout box" with LEDs. This plugs into the serial line, just like the scanner does, and the LEDs indicate the state of the data and control lines. You can compare what the control lines are doing before and after the terminal locks up to see if one of the control lines isn't being reset by the scanner. If none of this works, you may need to "snoop" on the communications with a laptop with a serial port. You can't see both sides of the conversation at once, but sometimes looking at one side is enough. You can get a two-port serial card and software if you want to see everything, or you can rent a dedicated serial analyzer. Matt Roberds .............................................................................. Newsgroups: comp.terminals NNTP-Posting-Host: 66.211.211.248 NNTP-Posting-Date: Thu, 6 Oct 2005 14:22:57 +0000 (UTC) References: <1128198587.234600.195490@g44g2000cwa.googlegroups.com> Message-ID: <1128608571.572797.235310@z14g2000cwz.googlegroups.com> Date: 6 Oct 2005 07:22:51 -0700 From: s10jam@yahoo.com Subject: Re: Using Wyse 60 Terminals with Welch Allyn 8300 MICR scanners Thanks alot for your help. I will look into this. It's not exactly a new setup. The previous technicians were fired because this system did not work correctly when they installed it and they could not resolve the issue. Since then, I have been assigned to this project with no prior experience with serial communications. I'm trying to find a support number for Welch Allyn to make sure I am programming these correctly. Now, I have set the scanners back to factory defaults and I get no cummunication whatsoever to the terminal. I will try a few things you have suggested. Thank you very much for your assistance. .............................................................................. Newsgroups: comp.terminals NNTP-Posting-Host: ip70-185-194-243.ok.ok.cox.net NNTP-Posting-Date: Thu, 06 Oct 2005 23:30:33 EDT References: <1128198587.234600.195490@g44g2000cwa.googlegroups.com> <1128608571.572797.235310@z14g2000cwz.googlegroups.com> Message-ID: Date: Fri, 07 Oct 2005 03:30:33 GMT From: mroberds@worldnet.att.net Subject: Re: Using Wyse 60 Terminals with Welch Allyn 8300 MICR scanners s10jam@yahoo.com wrote: > > Since then, I have been assigned to this project with no prior > experience with serial communications. You might look in "The Art of Electronics" by Horowitz and Hill, second edition, pages 719-726, for a pretty good overview of RS-232 serial communications. Here are a few examples of the "breakout box" that I mentioned. This will show you if any of the data lines are changing at all, and may help you debug the control lines, if used. http://www.trianglecables.com/rsbreakboxmo.html (US$20) http://www.connecttech.net/product_info.php?products_id=791 (US$30) http://www.bb-elec.com/product.asp?sku=232bob1 (US$40) (Standard disclaimers apply; I don't get money from any of the companies mentioned.) What you probably "should" have is something like this. View this in a fixed-width font: +----------+ +---------+ +----------+ | Wyse 60 | | Scanner | | Host | | | | "Wedge" | | Computer | | | | | | | | Ground o------o---------o------o Ground | | | | | | | | Receive o------o---------o------o Transmit | | | | | | | | | | A C | | | | Transmit o------o---O --O-o------o Receive | | | | | | | +----------+ | --O | +----------+ | | B | | | | +-o-------+ | | | +-o--------+ | | | | Transmit | | | | Scanner | | Head | +----------+ The ground line between the Wyse 60, scanner wedge, and host computer is always connected. So is the line from the host computer "transmit", through the wedge, and to the Wyse 60 "receive". This line is how the host computer sends data to be displayed on the Wyse 60. The line from the Wyse 60 "transmit" is a little different. When you are not scanning anything, the scanner wedge should connect A to C. This makes the data from the Wyse 60 go straight to the host computer "receive", as if the scanner wedge wasn't even there. But, when you scan something, the wedge temporarily disconnects A and C, and connects B to C. This allows the scanner head to send data to the host computer "receive". When the scanner head is done, the wedge disconnects B and C, and connects A to C again, so the terminal can send data to the host again. If, for some reason, the scanner head or wedge doesn't reconnect A to C when it's done scanning, it will appear that the terminal has locked up. If the scanner is set to the wrong speed, the host computer may see garbage characters, as has been discussed. The above picture and description doesn't include the control lines that might also be in use. Good luck! Matt Roberds ////////////////////////////////////////////////////////////////////////////// Message-ID: <3F79BD82.1080900> References: <3F621F2A.4070807> <3F652144.7040100@> Date: Tue, 30 Sep 2003 10:29:38 -0700 To: Michael B. From: Serge N. Subject: Re: Serial cable for Apple iBook printing > Serge N. wrote: > >> Hi , >> I just got an Apple iBook and am wondering if there is a way/cable >> to connect my iBook to the serial port of a Sun box ?? >> >> Also , I have a HP laserjet 4L , is there a cable to connect the >> parallel port of the printer to the USB on the iBook ?? >> Michael B. wrote: > > Keyspan makes some really nice serial to USB adapters > (http://www.keyspan.com/). I have used their PDA adapter and it works > fine. Also they have a 4 port serial adapter I purchased. And that > works great with multiple windows. I use the serial ports to configure > new server in racks during installations. Also, I use Z-term (really a > great serial window emulator > > http://homepage.mac.com/dalverson/zterm/ Keyspan is great ! Both serial and parallel adapters work with OSX, I use Gimp Print and Ghostprint for the Laserjet 4L . And zterm to connect to the serial console of my Sun machines . I bought both cables from CDW. http://www.cdw.com/ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals NNTP-Posting-Host: panix5.panix.com NNTP-Posting-Date: Wed, 21 Nov 2007 07:53:37 +0000 (UTC) References: <1194799022.891334.258620@o38g2000hse.googlegroups.com> Message-ID: Organization: Jeff's House of Electronic Parts Date: 21 Nov 2007 02:53:37 -0500 From: Jeff Jonas Subject: Re: VT220 garbage characters > I've got 2 VT420s doing multisession and a stray VT320 hanging off my > Linux box - I've got an 8-port serial card in my machine to give me > 10 serial ports in total. I was just sorting my inventory of 2/4/6/8 port serial cards, mostly ISA such as Stallion and Digi. What ones are you still running? Are they the bare UART or the "smart" ones? I think the great cosmic joke upon us is how the "dumb" ones are still useable with generic drivers whereas the advanced "smart" ones may be useless because the object-code-only drivers cannot run on new operating systems. By any chance do you have a source for odd modular connectors such as 10 position RJ69 (already crimped to a cable)? Some of my serial cards have modular connector "harmonicas" on the edge requiring RJ69 10-pin connectors. Only 2 serial ports from the system: no COM3/4? Gosh, I remember upgrading all my PC/AT systems with a pair of ISA multi I/O cards for 4 serial ports, 2-3 parallel ports, etc. But that's back when using a modem and direct cables to all preipherals was the norm: no ethernet or home network for device sharing. > I've also got some USB->RS232 adapters as well > which is a cheaper way of adding ports these days (as long as > you don't mind not knowing which TTY > will be assigned to which device when you power up!) I am trying a bunch of those and it's quite a problem. Most use the same USB to serial chip (so Linux auto-recognizes it), but it is NOT 8 bit safe! I could not download firmware to my microprocessor using one. And I agree, the USB auto-magic configuration is useless when dealing with multiples of any device! -- -- mejeep deMeep ferret! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Newsgroups: comp.terminals NNTP-Posting-Host: 70.185.217.138 NNTP-Posting-Date: Wed, 21 Nov 2007 02:00:01 MST References: <1194799022.891334.258620@o38g2000hse.googlegroups.com> Message-ID: Date: Wed, 21 Nov 2007 09:00:01 GMT From: mroberds@worldnet.att.net Subject: Re: VT220 garbage characters Jeff Jonas wrote: > > I think the great cosmic joke upon us is how the "dumb" ones are > still useable with generic drivers whereas the advanced "smart" > ones may be useless because the object-code-only drivers cannot > run on new operating systems. I've gone through this lately myself with different hardware: "We Support Linux!" "Uh, does that mean I can download some random Linux distribution and poke bytes at I/O ports and make your card do useful stuff, or does that mean you're going to give me a binary-only driver that refuses to run unless the kernel version matches down to the fifth decimal place?" > By any chance do you have a source for odd modular connectors such > as 10-position RJ69 (already crimped to a cable)? Googling gives http://www.trynci.com/cat/telco41.htm they also claim to have loose RJ69 connectors http://www.trynci.com/cat/conn3.htm and the crimp tool http://www.trynci.net/product_details.aspx?productid=4330 I've never tried to order from this company before; I just found them on a search. Standard disclaimers apply; I don't get money or other consideration from any companies mentioned. -- Matt Roberds \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ////////////////////////////////////////////////////////////////////////////// Sun Netra/T1 serial port: one way to wire a DB25-RJ45 connector RJ45 DB25 RTS 1 5 CTS DTR 2 6 DSR TXD 3 3 RXD GRD 4 7 GND GRD 5 7 GND RXD 6 2 TXD DSR 7 20 DTR CTS 8 4 RTS * system to system U80(Serial Port B) <-------------------------> Netra T AC200(Serial Port B) DB25 Connector CAT5 Fast Ethernet Cable RJ-45 Connector ////////////////////////////////////////////////////////////////////////////// Message-ID: <200310311825.h9VIP5c0006393@eastmail1bur> Date: Fri, 31 Oct 2003 13:23:15 -0500 (EST) From: Martha Starkey Subject: Re: Looking for SunBlade-150 J13 adapter Jim C. wrote: | | Anyone out there know where I can get one of these beasts? The infamous "missing" Sunblade port b! (Serial ports? Customers don't need any stinkin' serial ports!) Here is some info on where Kenneth C. found a cable that would work: --------- A second serial port header is located on the riser board at J13--I took information on the pin-out from the "Sun Blade 150 Service Manual" (June 2002)--Sun document 816-4379-10; Appendix B5. You will need a DB9 serial connector to IDE-10 mounted in a PCI slot--I took mine from a very old 33DX PC which had the correct connections and gender as "ttya" i.e., IDE/1 - DB9/1 IDE/2 - DB9/6 IDE/3 - DB9/2 IDE/4 - DB9/7 IDE/5 - DB9/3 IDE/6 - DB9/8 IDE/7 - DB9/4 IDE/8 - DB9/9 IDE/9 - DB9/5 Check these yourself; do not rely on my typing them in correctly. Given a ribbon connector of the correct type--a visual inspection of the back of the DB9 connector should reveal odd/even wires being connected to upper/lower rows (it looks very tidy). Any crossing of wires and you have the wrong inter-connect (could re-solder them to fix). ---------- The SunBlade 150 system handbook shows a mysterious "DB9 Serial Extension Connector", but the 370-5267 part number is unknown to store.sun.com: I'd like to know where to get this adapter myself. Martha .............................................................................. [One suggestion from Kyle M. is to get the DB9 face plate that was standard on a Sun Ultra 10, or the one that comes with the SunPCi card. It's a "DB9" connected to a ribbon cable to a 2x5 pin connector, with one pin filled in.] .............................................................................. James C. wrote: | | This IDC-to-DE9 connector from an Ultra 10 can be put into a SunBlade 150. | The only discrepancy seems to be that DCD and DSR are inexplicably swapped. ////////////////////////////////////////////////////////////////////////////// Message-ID: <0HOC00ELJPZ5SH@eris-mail1> Date: Fri, 14 Nov 2003 17:03:48 +0000 (GMT) To: Luca M. From: Eddie K. Subject: Re: parallel port GPIB IEEE 488 The GPIB (General Purpose Interface Bus) was specifically designed to connect laboratory instruments to computers and peripherals. It allows a computer (bus controller) to communicate with oscilloscopes, multimeters, spectrum analysers, etc. These kinds of instruments can also use it to connect to printers and plotters. The purpose of the bus is to help automate experiments, and to provide a standard interface to most lab equipment. It is also known as IEEE-488 or HPIB ( Hewlett Packard Instrumentation Bus ), and is electrically equivalent to the IEC-625 bus. It is defined completely in the IEEE standard 488.1-1987 "Standard Digital Interface for Programmable Instrumentation". To use the GPIB you need a GPIB adapter card in your computer and a GPIB lead. Fourteen devices can be connected to one GPIB and data can be transferred at up to 200,000 bytes per second. An RS-232 to GPIB interface converter could be used, e.g., National Instruments http://sine.ni.com/apps/we/nioc.vp?lang=US&cid=1261 or http://www.BlackBox.com/ RS-232 <-> 488 Interface Converter Part Number IC026A-R2 Price $849.99 You will need to have a manual for the instrument to know what commands to send to it and what to expect back. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals Message-ID: <3E97F0F5.4050004@BellSouth.Net> References: <87ptrhcosv.fsf@hurd.crasseux.com> <06d36cb79ab714f0@mayday.cix.co.uk> Organization: Hall Communications X-NNTP-Posting-Date: Sat, 12 Apr 2003 06:49:29 EDT Date: Sat, 12 Apr 2003 06:56:53 -0400 From: "Scott G. Hall" Subject: Re: Best way to connect many terminals to a PC On 1 Jan 2003, Bijan Soleymani wrote: > > I'd like to connect about 20 character-based terminals (I have a > mixture of different DEC and WYSE terminals.) to one PC. What would > be the best way to do so if the terminals have standard RS232 connectors > (My PC has only two serial ports)? (running Debian GNU/Linux 3.0) I am surprised that this came up in this group -- the original manner of using UNIX. As you might have surmised from the other postings, what you are looking for is a 16-port, 24-port or 48-port multiport serial card for your PC. Most Linux distros have drivers for a number of cards. There are quite a number of boards from which to choose: Digi International (formerly DigiBoard) - many current and older models BocaBoard - many old and new boards Equinox - many old and new boards Lantronix BlackBoard Cyclom Y RISC-Based Multiport Serial Board Intellio Comtrol RocketPort Card VOX Technologies (See the A-Plus-Computers below for an Equinox 16-port at $373) What you want to keep in mind is that you want an "intelligent" or "smart" multiport serial board -- this is one with its own processor handling its own interrupts and buffering. A "dumb" board relies on your PC processor handling the interrupts, and at more than 4 ports for greater than 1200 baud this is going to slow you down and lose characters. Another thing to consider is that the board have buffered UARTs -- such as the Intel 16550 or equivalent--so that you do not lose any characters coming or going. A lot of boards allow you to select between RS-232 (unbalanced 8-wire -- can be 3 (RX,TX,Gnd), 5 (add RTS,DTS), 7 (add DTR,CD) or all 8 wires (add DSR)) and RS-422/485 (balanced dual-channel 4-wire) signaling. If it saves you money, forget RS-422/485. You want to turn on DMA transfers, so get a board with that capability. I personally like RJ-45 connectors, but you can go with DB-25s if you want. You can specify software-only, or hardware-and-software handshaking in the "getty" parameters in Linux. I prefer hardware-and-software handshaking, so that I can be flexible on how I connect any one terminal. I do try to connect each terminal with hardware flow control (all 8 wires, including not just DTR/DSR (DSR tied to CD), but RTS/CTS too) whenever possible, so that the Linux login session is terminated if the terminal is powered off, and the "getty" process is woken up when the terminal is powered on to cause it to spew the login prompt again. For further reading: http://yebisu.ics.es.osaka-u.ac.jp/linux/HOWTO/Serial-HOWTO-9.html https://www.conserver.com/pipermail/users/2002-January/msg00001.html ["Initial installation and configuration (of a Linux System)"] https://www.conserver.com/pipermail/users/2002-January/msg00002.html http://www.linuxdevices.com/articles/AT2470203390.html Here is a couple of helpful links: http://www.apluscomputers.com/vendor_m_gdept.asp?dept_id=17-002 http://www.axiomtek.com/product-list.php?cat=Multiport+Serial+Solutions http://www.compuadds.com/Category.asp?catcode=0441 http://www.gtek.com/bb8a.html http://www.voxtechnologies.com/MOXA_Products/pos_sol.htm http://www.globetek.com/moxa/pdf/Intellio%20C320Turbo%20Multiport%20Controller.pdf -- Scott G. Hall, Raleigh, NC, USA ScottGHall@BellSouth.Net ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris, alt.solaris.x86 References: Message-ID: Date: 30 Jan 2004 21:10:29 GMT From: Andrew Gabriel Subject: Re: 16 bit ISA serial card on Solaris 9 x86 In article , synospam writes: > > Ahhh finally it now works !!! First I had problems because the card was > on IRQ 9 for COM4, Solaris wouldn't boot anymore, just hangs after the > kernel version line. So then what I did is deactivated the parallel port > and changed COM4 on the serial card to use IRQ 7. With IRQ 7 it works > well. I've now got /dev/cua/a,b,c,d ! Btw: this card has jumpers to > configure it's IO and IRQ setings. I would like to thank you, Andrew, for > your detailed explanations; they were very helpful!! Excellent. By the way, the asy(7D) driver supports up to 10 ports, and not just 4 as it says in the man page. However, the hardware interface to the standard UARTs used in x86 PC's isn't very efficient, so I would not expect it could drive a such a number at the higher speeds. -- Andrew Gabriel ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris NNTP-Posting-Host: 217.205.155.130 NNTP-Posting-Date: Fri, 7 May 2004 15:26:39 +0000 (UTC) Message-ID: <160afc40.0405070726.7191cb1e@posting.google.com> Organization: http://groups.google.com Date: 7 May 2004 08:26:39 -0700 From: Darren Robertson Subject: Serial Fun Please bear with me on this long tale. I was called to a client site last week after the flood in the basement caused a power outage. The Sun Server with no graphics card etc connected did not come us as it was stuck asking for the root password to run fsck. I grabbed the laptop, serial cable and 25 pin serial terminal, and off I shot--got to the client site and silly me--Port A female, serial terminal also female. I had to shoot off to Maplin to get a male-to- male gender bender. While there I spotted a terminal to make up on my own. I have found out about which cable to connect to which port on this terminal but how can I identify which is which pin? Therefore I have a serial cable with an RJ45 type connector which (with the spring clip down looks like: grey:orange:black:red:green:yellow:blue:brown How can I identify the RX and TX pins for example so that I can match this through the 25 pin serial terminal that I have to make up? Thanks. D. .............................................................................. Newsgroups: comp.unix.solaris NNTP-Posting-Host: abpc10296.cern.ch References: <160afc40.0405070726.7191cb1e@posting.google.com> Message-ID: <20040507173457.40d89723.Levente.Kovacs@cern.ch> Organization: CERN - European Laboratory for Particle Physics Date: Fri, 7 May 2004 17:34:57 +0200 From: Levente KOVACS Subject: Re: Serial Fun On 7 May 2004 08:26:39 -0700 darren@orcsoftware.com (Darren Robertson) wrote: > > Please bear with me on this long tale. ... > ... > I grabbed the laptop, serial cable and 25 pin serial terminal, and off > I shot--got to the client site and silly me--Port A female, serial > terminal also female. I had to shoot off to Maplin to get a male-to- > male gender bender. While there I spotted a terminal to make up on my > own. I had such feeling, when I've tried to connect my Picstart+ to my ULTRA1. The pinout is the same, only a gender changer is needed. > Therefore I have a serial cable with an RJ45 type connector which > (with the spring clip down looks like: > grey:orange:black:red:green:yellow:blue:brown The specification of V.24, you do not have RJ45. You have to consult the manufacture of that device. Note that some CISCO routers use RJ45 for serial terminal. I have to add, that in V.24 a male connector is specified. So SUN is against the standard. I don't know why. .............................................................................. Newsgroups: comp.unix.solaris NNTP-Posting-Host: fiesta.cs.tu-berlin.de NNTP-Posting-Date: 8 May 2004 10:41:38 GMT References: <160afc40.0405070726.7191cb1e@posting.google.com> <20040507173457.40d89723.Levente.Kovacs@cern.ch> Message-ID: Organization: Technische Universitaet Berlin, Deutschland Date: 8 May 2004 10:41:38 GMT From: Joerg Schilling Subject: Re: Serial Fun In article <20040507173457.40d89723.Levente.Kovacs@cern.ch>, Levente KOVACS wrote: > > I have to add, that in V.24 a male connector is specified. So SUN is > against the standard. I don't know why. Looks like you did not understand V.24 It defines the communiation between a terminal and a modem. A Computer is theither of both, so a manufacturer choses which if both variants he implements. ADAIR, Sun implements a Modem, so the connector is completely OK in contrary to what PCs do. A 9 pin connector is not in the standard. -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily .............................................................................. Newsgroups: comp.unix.solaris References: <160afc40.0405070726.7191cb1e@posting.google.com> <20040507173457.40d89723.Levente.Kovacs@cern.ch> Message-ID: <70bdea73b70143849932c9b388a79834@ghytred.com> Date: 08 May 2004 14:33:21 +0100 From: g8mqw@yahoo.com Subject: Re: Serial Fun Na, not always a MODEM. It defines "Data Communications Equipment" (DTE) and "Data Terminal Equipment" (DTE). So whilst DCE includes modems, it also allows for things like ISDN TA's and physical terminal switches. The standard envisaged that you would have a link that went :- Terminal <==> Comms <==> Comms <==> Computer. When we wire a terminal directly to a computer, we are outside the scope of the spec. Personally I think the SUN should be DTE and you should need to use a "NULL Modem" or Crossover cable to connect to a Terminal. .............................................................................. Newsgroups: comp.unix.solaris References: <160afc40.0405070726.7191cb1e@posting.google.com> <20040507173457.40d89723.Levente.Kovacs@cern.ch> Message-ID: Organization: I have a map of the United States that's actual size Date: Sat, 8 May 2004 17:09:53 +0000 (UTC) From: "Greg Andrews (Do NOT reply via e-mail.)" Subject: Re: Serial Fun js@cs.tu-berlin.de (Joerg Schilling) writes: > >ADAIR, Sun implements a Modem, so the connector is completely >OK in contrary to what PCs do. A 9 pin connector is not in the >standard. No, Sun does not implement a modem. Sun implements Transmit Data on pin 2 and Receive Data on pin 3 (of the 25-pin connector). Also, the DTR and RTS pins are outputs on Sun equipment, while the DSR, CTS, and DCD pins are inputs. This is the opposite of a modem implementation. Sun implements a Terminal device according to RS232/EIA232/V.24. -Greg .............................................................................. Newsgroups: comp.unix.solaris References: <160afc40.0405070726.7191cb1e@posting.google.com> Message-ID: <409bad18$1@news.kcl.ac.uk> Date: Fri, 07 May 2004 16:37:11 +0100 From: Mark Clements Subject: Re: Serial Fun Darren Robertson wrote: > > > I have found out about which cable to connect to which port on this > terminal but how can I identify which is which pin? > > Therefore I have a serial cable with an RJ45 type connector which > (with the spring clip down looks like: > grey:orange:black:red:green:yellow:blue:brown > > How can I identify the RX and TX pins for example so that I can match > this through the 25 pin serial terminal that I have to make up? Check out http://www.stokely.com/unix.serial.port.resources/A-B-Ycablepinout.html Convincing simple serial connections to work is one of my least favourite pastimes: you'd best invest in a crate of chickens and make sure ladies and young children are out of the room. Mark .............................................................................. Newsgroups: comp.unix.solaris NNTP-Posting-Host: h182n1fls33o847.telia.com [213.65.154.182] NNTP-Posting-Date: Sun, 09 May 2004 19:25:04 CEST References: <160afc40.0405070726.7191cb1e@posting.google.com> <20040507173457.40d89723.Levente.Kovacs@cern.ch> <70bdea73b70143849932c9b388a79834@ghytred.com> Message-ID: Organization: HB Hax Date: Sun, 09 May 2004 17:25:04 GMT From: Thomas Tornblom Subject: Re: Serial Fun andrew@cucumber.demon.co.uk (Andrew Gabriel) writes: > > In article <70bdea73b70143849932c9b388a79834@ghytred.com>, > writes: > > > > > > Na, not always a MODEM. It defines "Data Communications Equipment" (DTE) > > and "Data Terminal Equipment" (DTE). So whilst DCE includes modems, it > > also allows for things like ISDN TA's and physical terminal switches. The > > standard envisaged that you would have a link that went :- > > Terminal <==> Comms <==> Comms <==> Computer. > > > > When we wire a terminal directly to a computer we are outside the scope > > of the spec. Personally I think the SUN should be DTE and you should need > > to use a "NULL Modem" or Crossover cable to connect to a Terminal. > > I think Sun expected that you would connect a terminal to its serial > port to get a login prompt, whereas a PC expected that it would *be* > a terminal. > > I think newer Sun systems' serial ports are DTEs though (I vaguely > recall I need a crossover to connect an Ultra-60 to a PC). > > -- > Andrew Gabriel > Consultant Software Engineer Any V.24/RS232 device is either DTE (Data Terminal Equipment) or DCE (Data Communications Equipment, and for DB25 connectors the standard is male connectors for DTE and female for DCE. One of very few manufacturers that got the connector gender correct was DEC (Digital Equipment Corporation), at least in the 1980s with VT-100 terminals and DECsystem-20s, which was what we had at the university. I agree with the OP, Sun has always had the wrong gender on the systems with DB25 connectors. I believe that the newer ones with DB9 got it right though, although one may argue that it is more a defacto standard setup by IBM for the PC. In a perfect world, one glimpse of the connector should be enough to know if a straight cable (male to female) is needed, or a crossed (male to male or female to female). This seldom works in our imperfect world. Connecting a modem to a Sun requires a straight cable with male connectors, yuck! Cheers, Thomas -- Real life: Thomas Törnblom Email: Thomas.Tornblom@Hax.SE Snail mail: Banvallsvägen 14 Phone: +46 18 290 290 S - 754 40 Uppsala, Sweden Cellular: +46 70 261 1372 ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris NNTP-Posting-Host: panix3.panix.com NNTP-Posting-Date: Fri, 27 Aug 2004 05:57:21 +0000 (UTC) References: <9981f19f.0408250422.654bd943@posting.google.com> <9981f19f.0408252356.4c424ce2@posting.google.com> Message-ID: Organization: I have a map of the United States that's actual size Date: Fri, 27 Aug 2004 05:57:21 +0000 (UTC) From: Greg Andrews Subject: Re: Setting baudrate (serial ports installed in Sun machine) michael_laajanen@yahoo.com (Michael) writes: > > This is on a unused serial port(b), and will later be on a 16 port > cyclades board. > > But also I should ask you also, how do I shutdown the login process on > /dev/term/a /dev/term/b? Getting rid of the default login services on the a and b ports: pmadm -r -p zsmon -s ttya pmadm -r -p zsmon -s ttyb There are pretty much three approaches for configuring a serial port the way you're asking. From best to worst: 1) The application that uses the port also configures it. This is the best all around because the settings are applied to the port when the application needs them and exactly how the application needs them to be set. 2) Use a separate shell command to apply port settings with stty and hold the port open (so the settings don't return to defaults): ( stty 4800 cs7 parenb ixoff ixon ; sleep 999999 ) < /dev/cua/b & This runs the stty and sleep commands in a subshell so the stdin from both of them can be redirected in from the b port. The stty command sets the parameters you want, and the sleep command holds the port open for 11.5 days. You would run one of these commands for each port, followed by the command(s) to run your logger app on the port. 3) Set up an "Initialize Only" login service to apply settings to the port at boot time. This can be a "set it and forget it" solution, as long as the application is started after Solaris has fully finished booting. (starting the login services is the last thing Solaris does at boot time) See Document 44722 for a ksh script that makes it reasonably easy to set up an Initialize Only service on a serial port: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsrdb%2F44722 Normally, I recommend option #3 over #2, but I have a feeling you're going to want to start your logger application before Solaris starts the login services. It's also easier to play around with different settings in option #2. Another possibility is that the Cyclades can have its default settings configured with its own utility program. Hope this helps, -Greg ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris NNTP-Posting-Host: 81.187.162.106 NNTP-Posting-Date: 14 Apr 2005 14:59:34 GMT References: Message-ID: <425e8556$0$38044$5a6aecb4@news.aaisp.net.uk> Date: 14 Apr 2005 14:59:34 GMT From: Andrew Gabriel Subject: Re: ups (smart 2200) and ttyb serial In article , via ph-ibb-atm4-1.icm.edu.pl, "=?ISO-8859-2?Q?Micha=B3?= Kurowski" writes: > Hi, > > I'm having hard time figuring out what's going on with my serial line. > > The machine is SunFire 210 and it's connected to APC SmartUPS 2200. > It is controlled by apcupsd-3.10.11 (compiled in house) which was > working great in a "slave" mode for a long time. > > Now I need to go with the master mode on the machine but I'm not able > to communicate with the ups ... > > "apctest" breaks with an error saying there's no connection, etc - in > fact the source code clearly suggests there's no proper file > descriptor available. Strangely, I also have no data when I do "cat > /dev/ttyb". > > ttya works OK with a ttymon and console logins. I'm aware there should > be no program monitoring ttyb in order for ups serial to work properly. > I played with "pmadm" quite a lot for no avail. At the moment the line > is set like that: > > $ eeprom | grep ttyb > ttyb-rts-dtr-off=false > ttyb-ignore-cd=true These two strange settings are for when ttyb is being used as a console. For most other serial port applications, you would flip them both the other way around, i.e., ttyb-rts-dtr-off=true ttyb-ignore-cd=false I don't have any experience with what apcupsd expects, though. > ttyb-mode=2400,8,n,1,- > output-device=ttya,ttyb > input-device=ttya,ttyb > > -- > Micha³ Kurowski > mkur(at)poczta.gazeta.pl You probably want to remove ttyb from these. -- Andrew Gabriel ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris NNTP-Posting-Host: 81.187.162.106 NNTP-Posting-Date: 03 May 2005 18:02:42 GMT References: <42767194$0$38043$5a6aecb4@news.aaisp.net.uk> Message-ID: <4277bcc1$0$38041$5a6aecb4@news.aaisp.net.uk> Date: 03 May 2005 18:02:42 GMT From: Andrew Gabriel Subject: Re: Direct Serial port access In article , gerg@panix.com (Greg Andrews) writes: > > andrew@cucumber.demon.co.uk (Andrew Gabriel) writes: >> >>In article , >> >> " Lemieux" writes: >>> >>> I'm trying to use a serial port to monitor and control >>> access to a computer room. I was hoping to use the >>> CTS/RTS lines to read status and control. >>> I'm presently using /dev/term/a and by following the >>> /devices path, I could figure out the control port address. >>> Now, Im looking for information on the control port >>> (port status and control bit IDs) or some tool that would >>> let me read/control the port directly. I'm presently testing >>> on a Blade-100. >> >> man termio, and look for TIOCMBIS, TIOCMBIC, TIOCMGET, TIOCMSET >> ioctls, and the TIOCM_* values. >> >> Also, ttya and ttyb are setup by default in a strange way which >> is intended for use as the system console. If you are using them >> for some purpose other than the system console, you might want >> to switch their modem line handling back to normal serial port >> mode: >> >>eeprom ttya-rts-dtr-off=true >>eeprom ttya-ignore-cd=false > > > But why? The eeprom settings are only in control of the serial > port hardware while the Open Boot Prom is in control of the machine. > I.e. at the "ok" prompt, booting up, and shutting down. > > While the Solaris kernel is loaded, the serial port hardware is > controlled by the device driver, not the eeprom settings. The Solaris serial port kernel drivers read and act on the eeprom settings too (and on x86, so does the real mode serial port driver used by the DCA). -- Andrew Gabriel ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.unix.solaris NNTP-Posting-Date: 12 Apr 2007 14:52:17 CDT References: <1176325483.693128.320220@w1g2000hsg.googlegroups.com> <461d5df8$0$36739$892e0abb@auth.newsreader.octanews.com> Message-ID: <461e8df1$0$36698$892e0abb@auth.newsreader.octanews.com> Date: 12 Apr 2007 19:52:17 GMT From: Doug McIntyre Subject: Re: USB serial dongle (wasRe: Does one have to buy any special equipment for the V125?) Liam Greenwood writes: > > On 11 Apr 2007 22:15:20 GMT, Doug McIntyre wrote: >> >> On the Mac, you'll need a USB to Serial dongle to do the initial setup >> to get at least an IP address/gateway/root password/user account setup >> on the box before it'll talk on the Network. >Does anyone have a recommendation for a USB serial dongle that works on the >Mac for connecting to Sun boxes? I have an old Thinkpad that I boot off CD >(dead HD) for this purpose at the moment, and would like to not have to >depend on it. Keyspan work great. Driver support is great (as opposed to others like the Prolific chipset based ones). Since I work on a bunch of routers as well as machines, I have the 4-port Keyspan unit as well as single dongles for my powerbook. Then Kermit [for software], although thats a personal preference, although I see it echoed by at least one other here... ////////////////////////////////////////////////////////////////////////////// Most NetApp storage appliances, including the FAS2020 and FAS2050, provide a maintenance-console serial RJ45, 2 logical ports with the following pinouts: 1 (tied to pin 8) 2 TX2 3 TX1 4 Ground 5 Ground 6 RX1 7 RX2 8 (tied to pin 1) The voltages are consistent with RS-232-C, and the port can normally be used with a "null-modem" cable. No handshaking lines. Be careful not to confuse this serial port with the Management LAN Ethernet port, also with RJ45 connections, on some models. //////////////////////////////////////////////////////////////////////////////