summary sun din-8 to db-25 cable vs. mac cables

From: Dinesh Gambhir (gambhir@sun490.fdu.edu)
Date: Fri May 29 1992 - 15:06:30 CDT


SUMMARY MAC CABLES VS. SUN CABLES

1. The cables are not 100% compatible. The pin-outs
of the Mac DIN-9 port are different from SUN IPC DIN-9 ports.

2. If you have mac cables should you try them? Yes they will
work for certain connections.

3. If you don't have MAc cables shuld you buy from Sun, make your
own? No. I have ordered custom cables from Micro Computer Cable Co.
Phone # 313-946-9700. My cost = $13.22 + shipping by UPS.

4. Messages sent to me giving mac pinouts, explaining difference
between mac modem and printer cables, and mac vs. sun cables follow.

>From zben@ni.umd.edu Wed May 27 12:12:17 1992
From: Charles B. Cranston <zben@ni.umd.edu>
To: gambhir@sun490.fdu.edu
Subject: apple pinouts

this is very old info and someday i should bring it up to date... also I don't
talk about handshaking vis-a-vis the new fast modems here...

This document contains notes on the Macintosh serial port and its use, with
concentration on hardware interface issues.

*** DANGER WARNING WILL ROBINSON!!! ***
The DB-25 on the back of a Macintosh is NOT a serial port! It is a SCSI
parallel port. Any attempt to use this connector as a serial port will NOT
function correctly and may cause damage to the Macintosh and/or the equipment
being connected.

The two serial ports of a Macintosh are mini-Din-8 connectors which are
labeled with a telephone (the "modem port") and a printer ("printer port").
This is the pinout of the serial connectors. We are looking at the back
of the Macintosh (or alternatively at the BACK of a male plug):

             Macintosh Plus Serial Connectors (Mini-DIN-8)

       /------###------\ 1 HSKo Output Handshake
     / ### \ (Zilog 8530 DTR pin)
   / \ 2 HSKi / Clock Input Handshake or extern clk
  / [|] [|] [|] \ (Depending on 8530 mode)
 / 8 7 6 \ 3 TxD- Transmit data (minus)
| |
| | 4 Ground Signal ground
| === === === |
| 5 4 3 | 5 RxD- Receive data (minus)
| |
| | 6 TxD+ Transmit data (plus)
 \----+ === === +----/
  \###| 2 1 |###/ 7 N/C (no connection)
   \##| |##/
     \| |/ 8 RxD+ Receive data (plus)
       \------###------/
              ###

Note this is a RS-422 interface so the signals come in a balanced pair,
a positive (plus) and a negative (minus), for each data signal. As we shall
see below, there is an easy method for matching this to RS-232.

We buy 12 foot mini-Din-8 to mini-Din-8 cables for $10.00 from the Diskette
Gazette people. We cut them in half to get a pair of 6 foot mini-Din-8 to
bare wire cables. Then we do all our custom wiring at the DB-25 we add at
this bare wire end. It is just not worth it mucking around with mini-Din-8
connectors...

On the original 128K and the 512K upgrade machines (which have a DB-9 connector
instead of the mini-Din-8) the Output Handshake line was held in a "marking"
condition by hardware (a small resistor to the appropriate power supply rail).
On later Macintoshes there are logic and a line driver for this line. This
change introduces the following incompatabilities:

1. SOME of the older terminal programs don't have the code to explicitly
   drive HSKo high.

2. SOME terminal programs drop HSKo when they close down.

3. SOME modems require DTR and will drop carrier if DTR goes away.

If the cable design given below, mapping HSKo to DTR, is used, there are two
recognized pathological conditions which can happen:

A. Cannot use modem at all, because of 1 and 3 together.

B. Modem drops out when switching between terminal programs, 2 and 3 together.

Of course, some people consider B a feature, in that it will hang up the
phone when you switch off the computer. Personally, I hang up the phone when
I am done and I like to switch from terminal program to terminal program.
If one of the above conditions happen, there are only three alternatives.

I. If at ALL possible, set your modem up to IGNORE DTR and stay connected.
     Look for a DIP switch for this. I personally made this choice.
   
II. Use only terminal programs which "properly" drive HSKo.
     You get to operationally define "properly" :-)

III. Drive DTR from DSR at the modem end of the cable, as described below.

Macintosh to modem (or other DCE device):

       DIN-8 MALE DB-25 MALE

       GROUND 4 O--+--------------------O 7 GROUND
  RECV DATA + 8 O--+

  RECV DATA - 5 O-----------------------O 3 RD (Receive Data)
  
  XMIT DATA - 3 O-----------------------O 2 TD (Transmit Data)
  
HANDSHAKE OUT 1 O--+
HANDSHAKE IN 2 O--+--------------------O 20 DTR (Data Terminal Ready)

Note that in RS-232 the data signals are inverted (marking is minus) while
the control signals are not (marking is plus). Thus the transmit data
minus signal from the Mac is just right for driving the modem. Leave the
transmit data plus signal disconnected. If you ground this you will short
out a driver, and it will probably get hot. Similarly the receive data
signal from the modem/DCE is inverted, so it can drive the Mac's receive
data minus line, but in this case the receive data plus line is grounded to
prevent any extraneous signals from being induced into the circuit.

Note also that we are driving both HSKi and DTR from HSKo so the problems
described above can happen. An alternative arrangement would drive these
signals from the modem/DCE's source of DSR, like this:
  
                                     +--O 6 DSR (Data Set Ready)
HANDSHAKE IN 2 O--------------------+--O 20 DTR (Data Terminal Ready)

Some dumb modems might require Request To Send (RTS) which one would wire
like this:

                                     +--O 6 DSR (Data Set Ready)
HANDSHAKE IN 2 O--------------------+--O 20 DTR (Data Terminal Ready)
                                     +--O 4 RTS (Request To Send)

Finally, if you have only 3-wire cable and don't need DTR handshake, you
can wire each side to be happy like this:

HANDSHAKE OUT 1 O--+ +--O 6 DSR (Data Set Ready)
HANDSHAKE IN 2 O--+ +--O 20 DTR (Data Terminal Ready)
                                     +--O 4 RTS (Request To Send)

Macintosh to terminal (or other DTE device):

       DIN-8 MALE DB-25 FEMALE

       GROUND 4 O--+--------------------O 7 GROUND
  RECV DATA + 8 O--+
  
  RECV DATA - 5 O-----------------------O 2 TD (Transmit Data)
  
  XMIT DATA - 3 O-----------------------O 3 RD (Recieve Data)
  
HANDSHAKE IN 2 O-----------------------O 20 DTR (Data Terminal Ready)

The same analysis applies with respect to the data signals, except that
in this case the transmit and receive are switched around, since one guy's
transmit should be the other guy's receive and vice versa. Note receive
data plus is grounded while transmit data plus is left disconnected.

For this particular cable we have wired the terminal/DTE's DTR back into
the Macintoshes HSKi to implement a hardware handshake. Assume the
terminal side is a printer that is being overrun. One of the things these
printers can do is drop DTR. By wiring it through to the handshake input
we make it possible for the Macintosh software to temporarily pause in
sending, until the printer's buffers empty out and the printer reasserts
the DTR signal.

Some terminal devices may need to see DSR (Data Set Ready) or CD
(Carrier Detect) or CTS (Clear to Send), in which case they may be driven
from an appropriate source.

                                     +--O 20 DTR (Data Terminal Ready)
This is probably appropriate +--O 6 DSR (Data Set Ready)
for a communications terminal +--O 8 CD (Carrier Detect)
in which DTR is a totally static
signal and does not move. +--O 4 RTS (Request To Send)
                                     +--O 5 CTS (Clear To Send)

or

                                     +--O 4 RTS (Request To Send)
This is probably appropriate +--O 6 DSR (Data Set Ready)
for a printer that flaps DTR +--O 5 CTS (Clear To Send)
as the buffer fills and empties. +--O 8 CD (Carrier Detect)
                                     
The logic is to drive from whichever of DTR or RTS is NOT flapping around
as buffers fill and empty or as the terminal transmits and receives...

To connect directly to an IBM PC we believe CD must be asserted. That is,
an IBM PC will not accept data unless it also sees the CD signal.

CLASSIC MACINTOSH

Somebody on comp.sys.mac.hardware asked for cables for a Classic Mac!
I didn't know there were any more of those out there!!! :-) Here are
the corresponding connections, please use these in conjunction with the
analysis and suggestions provided above:

Classic Macintosh to modem (or other DCE device):

      DB-9 MALE DB-25 MALE

     GROUND 3 O--+--------------------O 7 GROUND
RECV DATA + 8 O--+

RECV DATA - 9 O-----------------------O 3 RD (Receive Data)
  
XMIT DATA - 5 O-----------------------O 2 TD (Transmit Data)
  
 + 12 Volts 6 O--+
  HANDSHAKE 7 O--+--------------------O 20 DTR (Data Terminal Ready)

Classic Macintosh to terminal (or other DTE device):

      DB-9 MALE DB-25 FEMALE

     GROUND 3 O--+--------------------O 7 GROUND
RECV DATA + 8 O--+

RECV DATA - 9 O-----------------------O 2 TD (Transmit Data)
  
XMIT DATA - 5 O-----------------------O 3 RD (Receive Data)
  
  HANDSHAKE 7 O-----------------------O 20 DTR (Data Terminal Ready)

FINAL CLOSURE

On the DB-25 pin 1 is the FRAME ground and pin 7 is the SIGNAL ground.
Equipment that requires connection to pin 1 is badly designed (IMHO).
As a very last resort you might try a 1 to 7 jumper.

As you can imagine from seeing all these alternatives, an RS232 breakout
box is real handy, since you can try all these patches without having to
warm up a soldering iron. The only other thing I can say is:

IF IT DON'T WORK, DON'T LEAVE IT TURNED ON LONG ENOUGH TO GET HOT!

Communications driver chips are built very ruggedly and will stand an
amazing amount of mistreatment for a short period of time. But if you
let two drivers fight for an hour one or both of them will burn out...

I've read this over a dozen times to make sure there aren't any totally
glaring errors, but I cannot be responsible for anybody's smoked hardware.
Let's be careful out there!
=============================

>From hoop@noaacrd.Colorado.EDU Sat May 23 21:39:53 1992
>From ntg!ntg.com!dplatt@netcom.com Mon May 25 15:46:58 1992

>I need to determine what the difference is between the
>din-9 to rs232 cables used for modem connection and
>those used for printer connection.

Modems are configured as Data Communication Equipment (DCE). Macs and
printers are both configured as Data Terminal Equipment (DTE). The
senses of the "receive data" and "transmit data" pins are different...
DTE's send on the "send data" pin, and DCE's receive data from this pin.

Normally, a DTE expects to be connected to a DCE, and vice versa. A
Mac-to-modem cable supports this sort of connection... it's wired up in
a "straight-through" configuration.

Because Macs and printers are both DTEs, they can't be connected via a
straight-through cable; both of them would try to send data on the same
wire. A Mac-to-printer cable is wired up as a "null modem" - it
connects the "send data" pin at one end to the "receive data" at the
other end, and similarly "crosses over" all of the other signal lines.
In effect, it makes the Mac look like a modem (from the printer's point
of view) and makes the printer look like a modem (from the Mac's point
of view).
==========

Subject: Re: sun din-8 to db-25 cable vs. mac printer/modem cable
>From hoop@noaacrd.Colorado.EDU Sat May 23 21:39:53 1992

Another data point for you: I have found the Mac cable to work on
terminals to be directly connected to a desktop Sparc, but not to
work with a modem hooked to a desktop Sparc. Must not be enough of
the right pins routed through for the modem to work correctly.
=============================

>From mks!andy@watserv1.uwaterloo.ca Sat May 23 04:27:26 1992

The Mac printer cable that I bought had two din-8 plugs. I cut the
cable and added db-25 connectors to the cut ends. Voila, now I have
two sun din-8 to db-25 cables.
=============================

>From hoop@noaacrd.Colorado.EDU Fri May 22 20:28:59 1992

Beats me what the difference is; I tried the cheaper Mac cable on
a Sun serial port, and it worked just fine.



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:42 CDT