[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GS to GS Serial Communications



In article <1993Jul20.180507.27362@sinkhole.unf.edu> swarde@unf6.cis.unf.edu (Rico) writes:
> Can anyone tell me the absolute maximum baud rate that can be achieved by
> two IIgs's connected to each other's serial ports via a null-modem?  I've
> been told that the max baud rate for such a setup is 137.4k baud, but I
> find it _very_ difficult to believe that the SCC8530 (Serial Controller
> Chip) could handle such speeds.  Also, if anyone answers this question
> I'd like to know what source I should reference to find the info. 

The absolute maximum speed that the IIgs's 8530 can handle is 230,400
bps, in synchronous mode.  The maximum normally quoted for Async mode
is 57,600, but it may be possible to go faster than this.

Refer to the Zilog Z8530 SCC Technical Reference Manual for a
description of the clock circuitry.  Here is a brief summary.

The IIgs uses a 3.6864 MHz crystal on the SCC.

If the baud rate generator is used, the bit rate is:

F = XTAL / (2 * (TC + 2) * MODE)

TC is the time constant (a sixteen bit number, ranging from 0 to 65535).

MODE is 1 for Synchronous, and 16, 32 or 64 for Async.  Thus, in ASync
mode, the fastest baud rate is 3686400 / (2 * 2 * 16) = 57600.


AppleTalk uses SDLC mode (synchronous) with FM data encoding.  This
uses the DPLL (digital phase-locked loop), for which the frequency is:

F = XTAL / 16, which is 230,400 bps.

(You can also use the baud rate generator as the clock source for the
DPLL, to allow lower speeds for synchronous communications).


In Async mode, you could theoretically bypass the baud rate generator
and use the crystal as the clock source.  In this case, the frequency is:

F = XTAL / MODE, i.e. 230,400 or 115,200 or 57,600, depending on the
clock divider.

I've never heard of anyone running the IIgs in async mode at faster
than 57,600 bps.  At 230,400, your characters are coming in about 43
microseconds apart.  It would be pretty hard to cope with interrupts
at this rate (especially for large amounts of continuous data), so
you'd probably have to use "polled" mode.

AppleTalk can manage it (34.7 microseconds per byte in synchronous
modes), but only has to deal with short packets, and the SCC can filter
out packets addressed to other network devices.

The SCC has a three byte receive buffer, which helps somewhat.
-- 
David Empson                                                               
dempson@swell.actrix.gen.nz                                                
Snail mail: P.O. Box 27-103, Wellington, New Zealand