Serial Communications

updated 2009-07-25.


see also local pages

Communication standards

standard protocols


If you design a new serial protocol, here are some ideas and suggestions you may want to consider:

Mac Serial Port

[FIXME: move to ]

I have pushed the Mac serial ports to 1 Mbps; email me for more info. Comments?

the communications protocol for the Mac QuickCam takes advantage of many of the Mac serial ports to communicate at 918 Kbps (synchronous). /* the protocol description *was* available at */

[1.4] How fast can the Macintosh serial ports really go? --------------------------------------------------------

Orignally the MacOS supported up to an asynchronous data rate of 57600 bps though the serial hardware could support much higher transfer rates externally clocked (as much as 16 times synchronously). The AV and Powermac introduced a different SCC clock and DMA based serial driver which allowed 115,200 and 230,400 bps. ...

While the ability to achive these speeds was useful in the days of communications software (see [3.1]) its importance dwindled with the introduction of Intenet communications and PPP (see [5.3]). The reason is that many non-text files on the Internet are already compressed which renders the built in MNP5 and V.42bis compression methods virturally useless. In addition due to limiations in equipment and phone line quality even a 56K modem rarely gets a sustained throughput over 50K.

For these reasons the modem scripts that come with Open Transport have 57600 bps as the maximum serial speed for a modem.

-- comp.sys.mac.comm FAQ

David Cary's experiences

David Cary's experiences with a pulse generator hooked to HSKi .... Mac data out (TxD+ and TxD-) changes only on rising edge of clock. (works fine when *input* data changes only on rising edge of clock).

clock specs: 4Vpp seems adequate, but it *must* go below ground. I used a green (all green LEDs are around 2.0 V, it's a physical property of quantum electronics) LED in my level-shift circuit to give me +1 V and -4 V on my clock. It was very distorted (more triangular than square), but it worked OK transmitting stuff back and forth between 2 macs. (using custom software).

_Inside Macintosh IV_ has a nice circuit diagram on p. 249.

The Macintosh Toolbox provides support for serial speeds up to a maximum of 57 600 bps. All my standard modem software is set to 57 600 bps; the 2 modems I use can handle talking to the Mac at that speed.

Technically speaking, however, the Mac serial port hardware can go much faster. You just need special hardware and special software.

I've witnessed a (prototype) gizmo that plugs into the Mac modem port and talks at 1 000 000 bps (roughly 1 Mega-bit / second) with a (1 MHz) pulse generator hooked to HSKi. (Of course, the 2 Macs involved were doing *nothing* but run my communication code).

(The hardware guys cranked it to 2 Mbps -- most characters still made it through, but many were lost.). It went that fast plugged into a PowerBook 520 or when plugged into a Quadra 605.

I got the information I needed to write software for a Mac to interface to this gizmo from the book _Inside Macintosh:Devices_ , a few paragraphs that talk about a "synchronous modem" connection.

_Inside Macintosh_ from Apple says that Mac serial port hardware can be made to go at 500Kbps (900 Kbps or more on most recent models) by supplying a appropriate clock on HSKi. the book seems to indicate GPiA is used for devices with *different* transmit and receive rates. Wierd.

the GPi line ... it appears that the Mac SE has one connected, while the Mac Classic and the Mac Plus has no connection to that line (?).

I used the "officially sanctioned" call from the new Inside Macintosh books,

    const Byte external_clock = 0x40;
    gOSErr = Control(gOutputRefNum, 16, &(external_clock)); /* set bit 6 to enable external clocking */

This works fine on my PowerBook520c, a Quadra, and a PowerPC (the only machines I tested my homebrew program, cable, and oscillator on). Mac data out (TxD+ and TxD-) changes only on rising edge of clock. Communication works fine when *input* data changes only on rising edge of clock. (This was the easiest to do -- I simply connect the same clock to both Macs). (I never got around to testing whether it would still work if input data changes on falling edge of clock -- I figure, if it works, don't fix it).

RS-232 is quiescent *low* (normally low, at -5V on Mac serial port) I have succeded in writing a program that uses a toolbox call "set up Serial A to use HSKi as the receive and transmit clock". The normal serial toolbox calls only let me go up to 57Kbps. They say "it's easy -- just poke the appropriate values in the Z8530 SCC. If you don't know it's address, just dissassemble the Mac ROMs and figure out how Apple did it". But of course they want the thing to work plugged into the serial port of *any* Macintosh, including the 1996 models. _Inside Macintosh_ from Apple says that Mac serial port hardware can be made to go at 500Kbps (900 Kbps or more on most recent models) by supplying a appropriate clock (on HSKi, I think). I *think* it's easier to use the same clock as both transmit and receive, but the book seems to indicate GPiA is used for devices with *different* transmit and receive rates. Wierd. Surely someone, somewhere has done this before; I'd appreciate any programming tips, pointers to magazine articles, books, etc. I'll post a summary of emailed responses, as well as a report on how well they work on my Quadra and on my friend's Mac PowerPC. -dc

Date: Tue, 5 Dec 89 16:36:44 EST
From: zben at (Ben Cranston)
Subject: Serial port document (long)

MIT EE claims it is benign but confusing.  Caveat Solderor...

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

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 the mini-Din-8 connectors at our local electronics surplus store.
They cost just under four dollars each, but are not quite as nice as the
Apple molded plugs (for example, they don't have the nice orienting-D shape).
We are now carefully removing the pins from the connector, soldering the wires
to the pin, then replacing the pin in the connector body.  We fan out the
end of the (stranded) wire into a little umbrella around the head of the pin,
then we solder all around.  A "third hand" reduces this task from impossible
to merely tedious.

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  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 (Receive 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)


                                     +--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.


Somebody on comp.sys.mac.hardware asked for cables for a 128K/512K 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:

128K/512K 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)

128K/512K 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)


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:


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!

Ben Cranston <zben at Trantor.UMD.EDU>
Network Infrastructures Group
Computer Science Center
University of Maryland at College Park
of Ulm

             Macintosh Serial Connector (Mini-DIN-8)
		(looking into *cable*)

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

# Name	typical color typical color
		(white cable)(grey cable)
1 HSKo	red		brown
2 HSKi	brown	red
3 TxD-	green 	orange
4 gnd		yellow	yellow
5 RxD-	orange	green
6 TxD+	black		(nc)
7 GPi		purple	(nc)
8 RxD+	blue		black

(pin names from _Apple Mac Family Hardware Reference_ 1988)

Laplink accelerator:
using HSKo (typically +4.2 V) and gnd for power, put
-1.5 V to 2.0 V, 0.75 MHz clock on (both) HSKi.
Connected a Quadra 605 to a Mac Powerbook 160; 900KHz clock worked OK but 926 KHz failed.
  (1 HSK0)---diode>|--R--+-->+Vcc->oscillator>-||--+--->(2 HSKi)
                         |                         |
  (4 gnd)-gnd----diode>|-+         gnd-------LED>|-+

  oscillator>-||--+--->(2 HSKi)

(another pinout document: )

Date: Wed, 28 Jun 1995 00:15:36 -0500
From: bill at (Bill Stewart-Cole)
Subject: Info-Mac Digest V13 #69

In Info-Mac Digest V13 #69, iedh1 at (Dan Hofferth) writes

>Responding to:
>>Date: Thu, 22 Jun 1995 17:13:47 +0200
>>From: thomas at (Thomas H Eberhard)
>>Fast modems with budget mac?
>>LC II (this also apply to the LC and all the Classics including the II and
>>colors) According to "Guru" the modemport only support hardware handshake
>>on output. Does that mean that I can't get fast input speed even with
>>28800 modems??
>The Mac Plus, LC, and Classic do _not_ support hardware handshaking.  The
>Classic II and LC II _do_ support it, both send and receive.  So your "guru"
>is incorrect.

Not quite correct. *EVERY* Mac supports what is called "Hardware Handshaking" in the Mac world. Technically some RS-232 purists will say this is strictly hardware flow control, and NO Mac can implement all the hardware handshaking of RS-232 (which includes hardware ring indication, hardware speed control, and other things) EVERY Mac serial port has a pair of handshake lines, one in and one out. (abbreviated HSKi and HSKo in pinout shorthand) SOME Macs (all but the 'classic' sized models, the //si, and the LC & LC II) also have an additional input on pin 7 (which is disconnected in those other Macs) termed "general purpose' by Apple and designated GPi. This is used by some programs like FirstClass (given the rare correct cable) to do hardware carrier detection.

Hardware flow control is done with the pair of handshake lines in all Mac serial ports. HSKo is run to the modem's RTS (Request to send) pin, and HSKi is run to the CTS (Clear to send) pin. A good modem cable runs HSKo also to the DTR pin, since that is useful for using DTR in uni-directional flow control and for older (non-compressing and slower) modems. A few cables will also wire GPi to CD, useful in a few programs, but sadly that is still rare in OEM cables. The effect of using an old-style modem cable on a fast or compression-capable modem is in fact that you can only implement flow control on the data stream from the computer, whereas the computer has no way (due to the cable, not the computer) to ever tell the modem to stop. This is a serious problem with slower Macs, which can easily fall behind the data rate of a fast modem.

The reason that many people think the Plus, LC, and other Macs cannot do flow control is that Apple's move to the better serial port (with GPi) was somewhat around the same time as the move from vanilla 2400 bps modems to v.42/v.42bis 2400 modems and 9600bps modems. Pure coincidence, but it meant that Apple was making port changes right as people were buying modems that did not work with their old cables. (Some modems even shipped with old-style cables, and in 1990 it was hard to find a 'hardware handshaking" cable except via mail-order) With Apple using a slightly enhanced serial port on high-end models of the day and high-end modems not working right without a special cable, it is easy to mistakenly connect the two.

Of course I could have just said that I ran a Plus and used "hardware handshaking" for 4 years with 3 different modems that demanded it, but that's not so convincing perhaps. The proof is in the pinouts.

-- Bill Stewart-Cole What is Stewart-Cole Consulting? Hell if I know. I'll find out when I finish the web page. Newsgroups: comp.sys.mac.portables From: nirvana at Subject: Re: 150 vs 160 Organization: Cruzio Community Networking System, Santa Cruz, CA Date: Fri, 25 Nov 1994 09:28:11 GMT Sender: nirvana at (Leo Baschy) Lines: 36 rudolf mittelmann <rm at> wrote: > I tried to use MacRecorder (a serial-device external microphone) on > a PB150 - but it did not work (with the newest MacRecorder driver > installed!). > I also could not get the CP Sound to work with it. > Why? > Did Apple cripple the ROMs to disallow sound input? Or what else > is missing? The problem is that "the" serial port device, the MacRecorder by Macromedia, has code that violates Inside Mac, therefore crashes. "The other" serial port device (a version of Voice Navigator from Articulate Systems) is no longer supported because the company now focuses on high-end automated dictation systems, I've been told. A possible solution would be to fix the code of MacRecorder, but I've tried to convince the manufacturers (it's been transferred from one company to another) for more than four years without result. The new Connectix serial port camera is neat, but the sound is limited to 5kHz, which is not so good. If anybody knows a serial port sound input solution that works for the PB150 I'd be more than glad to know about it and to write about it. We could even help out if anybody wants to fix the MacRecorder code, we have the know-how to rewrite that code from scratch. After all the manufacturer makes money on selling the hardware anyway, so they shouldn't mind if we write software that makes it work. It's just so much work, and little demand. - Leo Baschy nirvana at Nirvana Research (408) 459-9663 --

From cary at Wed Feb  1 19:31:33 1995
Date: Wed, 16 Nov 1994 11:30:54 -0700 (MST)
From: Mark Lankton <LANKTON%PISCES at VAXF.Colorado.EDU>
Subject: synchronous serial port
To: d.cary at
X-Vms-To: VAXF::IN%"d.cary at"
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: O


There is a fairly recent Control call you can make to the serial driver
that lets you use HSKi as a clock, at least for receiving. I have never
tried transmitting that way; all I have to do is listen to an instrument.

The call goes like this:
Control(driverNum,16,0x40);  /* Set bit 6 to enable external clocking */

By the way, setting bit 7 with this call means DTR will be unchanged when
you close the driver (if you ever happen to care).

I am right in the middle of building some new hardware to use this method;
for years I have used a home-grown get-in-and-fiddle-with-the-Z8530 input
driver. It always worked fine *except* for exploding on PowerBooks, and
if I didn't have to work on PowerBooks and wasn't worried about maintaining
it in the face of the changing device driver API, I would just keep on
that way.

One important note: the external clock signal apparently wants to be 1x
the bit rate, not 16x as you might guess. And I am still trying to decide
how important the clock polarity is.

Information comes from NIM:Devices.

Good luck, and please let me know how it goes for you.

Mark Lankton
Laboratory for Atmospheric and Space Physics
University of Colorado

From cary at Wed Feb  1 19:32:31 1995
Date: 22 Nov 94 05:57 EST
From: intolabb at (Steven Intolubbe)
Subject: high speed serial stuff
To: d.cary at

.Hi David,

Do you need to use a synchronous protocol, or do you just need to
externally clock the serial port?  The other problem is duty cycle
of the data.  Is it a constant stream, bursts, or do you request
what you want when you want it?  There is a toolbox call for setting
the external clock mode (on HSKi) but it is in the new inside Mac
books, which I don't have.  I accessed the chip directly to set the
external clock mode, and it appeared to work on the 840AV, but the
toolbox would be the best way to do it.  As far as synchronous modes
go, I have also done that, all with direct chip register access,
which is was very rude of me.  If you want to run a machine in a
synchronous mode,  you should write a driver to replace apple's serial
manager (I didn't do that because I don't know how).  Apple has a
driver for one of their Personal Laserwriters that was supposed to
be close to 1 Mbaud, so if you were in the APDA fold, I'm sure they
could help you out.

				 Hope this helps,

APDA: (800)282-2732
APDA developers support (408)974-4897

Are the 2 serial ports on your machine inadequate ?

Date: Fri, Jun 3, 1994, 20:51:26

The only serial port boards for the Mac I know of are the "Hurdler" and the "Hustler" from

Creative Solutions Inc.
4701 Randolph Dr.   Suite 12
Rockville, Maryland  20852

There are *lots* of serial port boards for the PC.

A little bit of information about the PC serial port

From: helge at (Helge-Wernhard Suess)
Subject: Re: Question about serial ports
Date: 12 Sep 1995 11:32:18 GMT
Organization: Siemens AG Austria
Lines: 26

In <>, <H.Olsen at> (Hakan Olsen) writes:
>I am writing a program that does some commmunication via modem. My problem is
>that I have not found any functions to initialize or communicate with the
>serial ports on a PC. Are there any libraries containing useful functions for
>serial communication?  I would prefere if the libraries were for standard C
>as I am not very familiar with C++.
>I am using Borland C/C++ 4.0
>Any help would be much appreciated!

Look up the OpenComm(), CloseComm(), WriteComm(), ReadComm() etc.
in your SDK helpfile. For a more elaborate communication (X, Y, Z-Modem)
you should get (buy) a communication library supporting some of the
common protocols.

Helge ;-)=)

      (c) All Thoughts are Mine -- Genuine Genius
helge at        -----         VIENNA -- AUSTRIA
Subject: Re: ADB Physical Specs
From: st93urnu at (Aaron D. Marasco)
Date: Fri, 23 Feb 1996 17:24:21 -0500

In article <>, Bryan Dunn
<bryan.dunn at> wrote:

>Hello all!
>I'm designing some hardware that will use the ADB interface.  Can anyone
>suggest a good reference (on the net or in print) that describes ADB in
>Thanks in advance!

"Guide to the Macintosh Family Hardware: Second Edition"

Tells everything about the Macs up to the IIfx, including ADB, and a
standard is a standard, so it shouldn't have changed (however, this *IS*
Apple we're talking about!)

Anyway, it is a book I have for a school class, so I have all the info:

$26.95 US, $34.95 CAN


ISBN 0-201-52405-8

I haven't checked any of the online bookstores, you might get it cheaper!
Also, it's a paperback, to letcha know.

_Inside AppleTalk, Second Edition_

notes from _Inside AppleTalk, Second Edition_ by Sidhu, Andrews, Oppenheimer[1]. and from AMD's _Analog and Communications Products 1983 Data Book_[2]. and Apple _Macintosh Family Hardware Reference_ (1988) [3]. LocalTalk uses Synchronous Data Link Control (SDLC) frame format and a frequency modulation technique called FM-0. Each bit cell (nominally 4.34 usec -> nominal 230.4 Kbit/sec). differential, balanced voltage signaling over a maximum distance of 300 meters. ... transformer provides ground isolation as well as protection from static discharge. "In the preferred hardware implementation of LocalTalk, a Zilog 8530 Serial Communications Controller (SCC) is used." [1] The classic Macs and the Mac SE [3] both use the 8530 SCC, a 26LS30 differential transmitter, a 26LS32 differential receiver, and a fistfull of RFI filters. The Mac II replaces the 26LS32 with a 75175 differential receiver. (I have no info on other macs) (the Maxim MAX216 Low-Power AppleTalk Interface Transceiver looks interesting). The SCC is clocked at 3.672 MHz hooked to /RTxCa, /RTxCb, and PCLK. on classic, Mac SE, and Mac II. (Mac SE and Mac II has software switching of /RTxCa to the GPiA pin).[3] "don't access the SCC chip more often than once every 2.2 us. ... on the Mac SE [and the Mac II] it is not neccessary to do so because [other circuits ensure the proper delay]"[3] "the transmitter and receiver hardware for LocalTalk is built into every Macintosh and AppleIIGS computer, .... and many peripheral devices ..." "If you are designing your own AppleTalk hardware from scratch, it is easiest to use a 3.6864 MHz oscillator and a Z8530. This has been tested and works just fine." [HW 545 - Serial I/O Port Q&As - Technical Notes - Developer Support ] "LocalTalk hardware can detect a flag byte, the distinctive bit sequence 01111110 ($7E)." [1], but i can't find any reference to this capability in [2]. Well, the hardware guys have done it again. They're making this gizmo that they're hooking to the Mac serial port. They say it communicates "like a synchronous modem". They want it to go at least 500Kbits/sec. "see that Z85C30 on the Mac motherboard there ? the databooks say it can go at 10MHz ... cancha just poke the right values into it? dissassemble the Mac ROMs and figure out how Apple did it ? ... But of course we want the thing to work plugged into the serial port of *any* Macintosh, including the 1996 models." I know it can be done; the hardware guys had LapLink for Mac running on 2 Macs (homebuilt cable between them) "See that O'scope ? they're pumping 750KHz into the HSKi input ... LapLink just transferred a megabyte file at rougly 70KB/s."

Controller Area Network (CAN)

[What is the endianness of CAN ? ]

"CAN we talk? : Distributed systems require protocols for communication between devices. CAN and SPI are two of the most common." article by Niall Murphy 2003-05-14

... a text-based protocol. This is how most of the Internet works; HTTP and SMTP are both built on text protocols. This approach allows the protocol to remain architecture agnostic. Text is less efficient than a protocol where each byte is given a meaning, but the upside is a protocol that's easy for a human to read and debug.


The biggest difference between CAN and SPI is that the CAN protocol defines packets. In SPI (and serial interfaces in general), only the transmission of a byte is fully defined. Given a mechanism for byte transfer, software can provide a packet layer, but no standard size or type exists for a serial packet. Since packet transfer is standardized for CAN, it's usually implemented in hardware. Implementing packets, including checksums and backoff-and-retry mechanisms, in hardware hides a whole family of low-level design issues from the software engineer.


There are a number of higher layer protocols that have been layered on top of the basic CAN specifications . These include SAE J1939, DeviceNet, and CANOpen. ...

points to the Linux CAN-bus driver project

Open DeviceNet Vendor Association, Inc. (DeviceNet is a more detailed specification for CAN)

information from "Hard real-time connectivity: It's in the CAN" article by Bruce Boyes in _Computer Design_ 1998-01, p. 88

"CAN is a robust network designed for hard real-time distributed control systems in harsh environments. It's an open standard (and the subject of ISO 11898)..." ... "CAN is a peer-to-peer network ... packets with a maximum payload of 8 bytes ... ... adept at passing around simple commands or small amounts of data quickly... ... not well-suited to moving around large files ..." "can go up to 1 Mbit/s, CAN systems most commonly operate at 250 Kbit/s or 125 Kbit/s, because lower baud rates are more resistant to brief bursts of noise." " fiber-optic cable also is common. ..." "The ISO 11898 document specifies a 120 Ohm nominal impedance using terminated twisted-pair media. ... line length versus baud rate ... ... 40 m, 1 000 Kbits/s ... 1 000 m, 50 Kbits/s ..."

"low cost and relative simplicity" "Kevin Parkinson ... typically uses optically isolated chip-to-bus electronics using RS485 type drivers."

"Emphasis on content" "When data is transmitted by a CAN node, no other nodes are /addressed/; rather, the /content/ of the message (pressure, voltage, temperature, etc.) is designated by the identifier, which is unique throughout the network. The identifier also prioritizes the message. With care, this prioritizing guarantees the most important messages are transmitted with the least delay. ... Arbitration is nondestructive. In the case of an overloaded network, the highest-priority messages still get through. ... Latency ... is also very low. ... CAN hardware also provides message acknowledgment and automatic re-transmission in the event of an error."

"CAN data bits are either "dominant" or "recessive". ... A frame always begins with a dominant-level SOF (start-of-frame) bit. A dominant bit always "wins" over a recessive bit being transmitted at the same time. ... If 2 nodes start transmitting concurrently, each node performs bit-wise arbitration to resolve the conflict. ... A transmitter stops sending if it sends a recessive bit, but monitors a dominant bit. That guarantees a lower-priority CAN device immediately stops transmitting, while the higher-priority device continues unimpeded. The lower-priority device waits for the next bus idle time and tries again. ... 2 nodes [should] never send the same [arbitration field] followed by different data ..."

"... ACK ... indicates sucessful message ... reception by at least one receiver ... the hardware ACK is an important component of CAN's real-time capability."

"For example, a vehicle wheel-speed sensor should transmit its data properly and let other nodes, if any, handle the data as they wish."

"The RTR bit permits any node to request data from another node."

"receiving nodes which detect a problem ... transmit... in the end of frame space. The sender monitors the error flag, which triggers an automatic retransmission by the sending node."

"Honeywell's Smart Distributed System (SDS) ... DeviceNet (initiated by Allen-Bradley) ... ... DeviceNet and SDS also include specifications for rugged cable and connectors."

"The CAN in Automation (CiA) group (Erlangen, Germany) promotes the CAL"

"CAN specification 2.0B describes the extended message frame with a 29-bit ID."

Siemens (SAE81C91), Motorola (MC68376), Intel (i82527), Philips (SJA1000), National Semiconductor (COP87L84BC). offer CAN controllers and/or microprocessors with CAN 2.0B capability.

CAN extended message format (bit field width is not to scale)

| Arbitration field | Control Field | Data field | CRC field | Response field

Arbitration field:
| SOF | 11 bit identifier | SSR | IDE | 18 bit identifier | RTR |

Control field:
| R1 | R0 | DLC |

Data field:
| Data: 0 to 8 bytes |

CRC field:
| 15 bit CRC |

Response field:
| ACK field | EOF 7 bits | INT 3 bits | bus idle (or another node starts transmitting)

SOF: Start of Frame, a single dominant bit
SRR: Substitute Remote Request
IDE: identifier extension bit is recessive for extended format
ID Fields: a total of 29 ID bits for extended frmat
RTR: remote transmit request, dominant for data frames, recessive for remote frames.
R1, R0 are reserved, dominant bits.
DLC: a 4 bit data length code indicates the number of bytes in the data field.
DATA: 0 to 8 bytes. A remote frame contains zero bytes.
CRC: a 15 bit CRC and a recessive CRC delimiter bit. (Covers what ? just the data ?
The entire packet before the CRC ? )
ACK: acknoledgement is a single dominant bit followed by a recessive delimiter bit
EOF: End of Frame: seven recessive bits end a frame
INT: intermission is 3 bits between remote and data frames

For an extended frame, this is a total of 64 to 128 bits (depending on data size). With 8 bytes of data, overhead (non-data bits) is therefore 1/2.

keyboard information

the various standard keyboard layouts, information on alternative keyboard-like data entry devices, and technical information on making your own devices that plug into the "keyboard socket".

[FIXME: consider moving this information to massmind: ]


The human-keyboard interface. Various standard keyboard layouts, information on alternative keyboard-like data entry devices [woefully incomplete]

alternatives to the standard keyboard are useful for wearable electronic devices wearable_electronic.html .

some chairs have a built-in keyboard 3d_design.html#furniture ; all furniture is (or should be) designed with ergonomics in mind.

I'm paranoid about wrist pain. #RSI

[FIXME: put all this ergonomics, keyboard+other, on another page] Other ergonomics

Keyboard ergonomics

Weird and wonderful keyboard layouts. [FIXME: make seperate section for ``QWERTY-like'' layouts, that can be used with commodity keyboards with some remapping software, vs. stuff that needs completely different hardware ? ]

PC Keyboard port

The keyboard-PC interface. Technical information on making your own devices that plug into the "keyboard socket" (or making a socket to plug standard keyboards into your device). Includes serial protocol, numlock light commands, etc. See also "wedges" .


IEEE1394, also called "FireWire"

"1394 right now is specified to run up to 400Mbits per second and 800Mbits in the future. It will be plug and cable backwards compatible. "

Often used to transfer movies from digital camcorders machine_vision.html#digital_cameras ... machine_vision.html#IEEE-1394_digital_camera

serial protocol converters

See also FIXME serial ADCs and DACs.

RS-232 to PC keyboard (often called "wedges" -- the most common versions allow you to plug a barcode reader FIXME barcode (RS-232) and a standard PC keyboard into the wedge, and then you plug the wedge into the keyboard port of a PC.)

Other protocol converters:

USB info (Universal Serial Bus)

Often used to transfer still images from digital cameras machine_vision.html#digital_cameras . [FIXME: move information to a wiki ?]


[FIXME: I know I have more MIDI info scattered elsewhere ... move it here.]




SCRAMNet (Shared Common RAM Network) looks interesting.

MIL-STD 1553

MIL-STD 1553 is a military avionics bus.



Barker code

some links I stumbled over on a quick search of Google for Barker code info.


Think serial communication is serious ? Hah.


This page started 1997 and has backlinks

known by AltaVista

known by Yahoo!

known by infoseek

comments, suggestions, errors, bug reports to

David Cary

Return to index // end