Re: Z8530SCC

[dempson@actrix.gen.nz (David Empson)]

Frank Carney <frankc@cyberhighway.net> wrote:

> >What gives you that idea?  The Z8530 doesn't fully support Ethernet
> >bit-level data formatting (Manchester) without external hardware
> >support, has absolutely no protocol support for Ethernet, and probably
> >isn't fast enough to cope with 10 Mbps Ethernet.
> 
> Hmmm, okay, back to square one.  Anybody know how to program the Z8530
> chip.

Yep.  I've programmed the Z85230 ESCC, which is an enhanced version of
the SCC, in an embedded project at work.  I also have the data book for
the Z8530 here.

I haven't actually done much directly with the SCC in the IIgs, but I
know the principles.

> Maybe I can get it to talk at a higher baud rate than 57600.

Not easily.  As you've already noted, the firmware only lets you set
rates as high as 19200 bps.  It is possible to go as high as 57600 if
you bypass the firmware and write directly to the baud rate generator
divisor registers (there is actually a low-level firmware call which is
able to do this - you don't need to access the hardware directly).

If you want to go higher than 57600, the only remaining option is to
change the clocking mode used by the SCC, so that the baud rate
generator is disabled and the transmitter and receiver are clocked
directly off the internal clock (3.6864 MHz).  This gives you 230400 bps
in asynchronous mode.  (You can't get any rates between 57600 and 230400
using the built-in crystal, or anything faster than 230400.)

However, this option is almost completely useless in a IIgs, because the
machine is not fast enough to actually deal with interrupts at this baud
rate.  (It has to process a character interrupt every 43 microseconds on
average.)  Even having an accelerator wouldn't make enough of a
difference, in my opinion.

It may be feasible to use this rate for specially written programs which
poll the serial port hardware directly, rather than relying on
interrupts.


Note that AppleTalk uses the same bit rate, but with a different
operation mode: the SCC is running in SDLC/HDLC mode (bit-synchronous
with framing characters), and the data is transmitted and received using
FM modulation instead of NRZ.  The receive clock is recovered from the
data stream using the DPLL, and the transmit clock is generated
internally (using the same method I described above).

AppleTalk on the IIgs works differently from standard asynchronous
serial communications software.  The SCC deals with most of the gory
details of the framing (e.g. bit insertion and CRC calculation), so the
computer only has to deal with streaming data to and from the chip, and
identifying frame boundaries.

When a frame starts to arrive, the SCC interrupts the main CPU, which
then has three character times (about 104 microseconds) to get into its
interrupt handler, due to the three character receive buffer in the SCC.
It then remains in the interrupt handler, polling the SCC for the rest
of the frame (up to 580 bytes or so, which is around 23 milliseconds).

Transmit works similarly - tying up the computer for the full time
required to transmit the frame.

This is why AppleTalk causes such a performance hit on the IIgs.


It is possible to use an external clock with the SCC in the IIgs: the
"General Purpose Input" signal (pin 7) goes to one of the clock inputs
on the SCC, as well as to the DCD pin.  The main example of the use of
this clock input is with the Apple MIDI interface, which provides a
clock signal at a different base frequency to allow the IIgs (or Mac) to
derive the MIDI baud rate, which is 31250 bps (32 microseconds per bit).

On the Mac, the "Handshake In" pin can also be used as a clock input, so
you can provide independent transmit and receive clock signals.  (This
isn't supported on the IIgs.)

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P O Box 27-103, Wellington, New Zealand