From: jackb@mdd.comm.mot.com (Jack Brindle)
Subject: Re: Serial Port Programming
Organization: Motorola, Mobile Data Division - Seattle, WA
Date: Wed, 15 Apr 1992 21:01:01 GMT

In article <1992Apr15.161249.25140@ncar.ucar.edu> hpoppe@ncar.ucar.edu (Herb Poppe) writes:
>In article <73763@netnews.upenn.edu> green@eniac.seas.upenn.edu (Bradley 
>Green ) writes:
>
>> I'm trying to run a distributed processing network, using a Mac as the 
>> master controller, with dedicated microcontrollers at the oother nodes
>> of the network.  What I want to do is to be able to run the Mac serial
>> port at its maximum asynchronous speed, which I believe is 230Kbaud, but
>> I haven't found any real info on how to program the serial port to do
>> this.  Note that I don't want to use AppleTalk protocols, but just to
>> send data byte-by-byte.
>
>The Mac's serial driver (software) is limited to a maximum speed of 
>57.6KB. According to the conventional wisdom, this is the maximum speed 
>that Apple could achieve with an interrupt driven driver on the original 

The 57.6KB limit has far more to do with limitations imposed by the 
hardware designers at Zilog who did the 8530 than the software folks
at Apple. Quite simply, the limitation is imposed by the use of the
internal SCC baud rate generation clock. Take a good look at the SCC
technical manual; it will explain why. You will also find out that the
SCC will go faster than 56KB for asynchronous format if you supply an
external clock.

>Mac. Note that the 230KB AppleTalk drivers are not event driven. It is 

They also run quite different. The incoming LocalTalk frame causes an
interrupt when the address matches the one programmed into the SCC. The
remaining bytes of the frame are then read during that first interrupt
service response. So, it's one interrupt per packet.

>probably the case that Macs like the IIsi, etc. could support higher 
>interrupt driven baud rates, but the current serial driver has no 
>mechanism for specifying a baud rate higher than 57.6KB.

Only if the clocking rate of the SCC is changed, or external clocking is
supplied. The SCC has to run faster, not the CPU. Again, this is simply
not primarily  a software issue!

>
>You will have to write you own driver if you want to run at higher baud 
>rates. This means you will have to get the technical details on the Zilog 
>SCC.

... And run in synchronous mode. Writing a synchronous driver for the
SCC can be quite tricky. There _is_ some *magic* that has to be applied.
Zilog's technical notes make it a lot easier these days, but there still
is a pretty good learning curve.

>
>Suppose you decide to live with the 57.6KB limit and use the Apple serial 
>driver. Depending on how you wire your network, there may be another 
>consideration that may not be handled by the current serial driver. Are 
>you using RS-485 transcievers like the SN75176 with your microcontrollers; 
>that is, is your network a single twisted pair? If so, then only one 
>RS-485 driver on the network can be enabled at any one time. This includes 
>the driver in the Mac. I do not know if the Mac serial driver always 
>enables the driver before each transmission and then disables it at the 
>end of transmission, or whether it enables the driver at open and disables 
>it at close, or whether it is always enabled. You can get around this 

In async mode, the SCC always drives the output line.

>problem by using two twisted pair and separate RS-485 drivers and 
>receivers with your micros. The Mac's driver would be wired to all the 
>micros' receivers and the micros' drivers would all be wired to the Mac's 
>receiver. Then it would not be an issue if the Mac's driver were always 
>enabled.

The output ports on the Mac are controlled by the SCC's RTS signal. This
signal would need to be controlled to avoid problems. By the way this is
not simply a problem of blocking other transmissions. Directly connecting
the outputs of two drivers that are in opposite states can cause a very
large current flow through both devices, and will probably end up damaging
one or both devices.  The other way to resolve the situation is to do what
Apple did with LocalTalk, and provide some form of isolation for each Mac.
The LocalTalk interface box effectively provides DC isolation for each Mac,
while passing the rapidly changing data signals onto the main bus. Possibly
the best way to do this in this situation is to use an RS442 to open-collector
interface. This is also the method used for the ADB. You can then simply
tie the outputs of each open-collector buffer together on the network bus.
You would also need a pull-up resistor to make the network voltage level
sit high when no-one is driving it. I would probably opt for an actual
discrete transistor for this purpose (say a 2N4124, available at Radio Shack)
rather than use an IC. You only need one per node, and the transistor has
higher current capabilities. This would be useful for driving longer cable
lengths.

>
>At some point in the future, I plan to implement a network like the one 
>you mention. For me, the 57.6KB limit is not a problem, but I will need to 
>know how the Mac serial driver handles enabling/disabling the RS-422 
>driver. If anyone can answer that question, I'd like to know.

See above. The RTS line does it.

>
>If you decide you need to write your own driver, I seem to recall that at 
>one time Apple made the source code of a (maybe not THE) serial driver 
>available. If I remember correctly, does anyone remember how to get this 
>code?

If it wasn't THE driver, it sure was a good fake. I remember it quite well.
I have no idea where you could get it. I have a feeling that Apple's
driver will suit the original poster's purpose quite well. All that is
needed is a bit of cleverness on the hardware side to make things play
together. It's not hard to do, and is a great opportunity to learn things.

By the way, you might wish to look at an MC14469 Addressable Asynchronous
Receiver/Transmitter. It is a really neat device that allows you to set
an address for each AART, and send data on a common bus to each device.
It will respond only to data sent to its address. It's only catch is that
it runs rather slow, max data rate is 9600 baud. Still, the addressing
concepts and usage might provide some good ideas.

Jack Brindle
ham radio: wa4fib
internet: jackb@mdd.comm.mot.com