Re: IIGS 115,200 Baud Serial Port - How?

[Hugh Hood <hughhood@earthlink.net>]

David (Empson),

Thanks for weighing in on this SCC business.

Over the years I've come to rely on your accurate and detailed explanations
on what are oftentimes complex subjects. This time you've not disappointed.

Frankly, before I tore into the SCC manual and the ADTPro Source, and
started patching ProTERM a couple of weeks ago, I suspect your post would
have left me dumbfounded.

Mr. Wilson had previously mentioned that I wasted my time trying a 1X clock
in async with the Baud Rate Generator and NRZ encoding, and it seems you
agree. (So do I - it didn't work).

My patches to ProTERM (PT3.Code0, Blocks 19 and 20) have been:

WR11 - Instruct the Transmit Clock and the Receive Clock to source from the
RTxC Pin rather than from the Baud Rate Generator. Bit 7 is set per IIGS
Tech Note 18 ('1' for Printer Port/Channel A/$C039 and '0' for Modem
Port/Channel B/$C038).

WR14 - Disable the Baud Rate Generator (I'm not sure if this is necessary
since the clocks source from RTxC, but it was done regardless).

WR4 - Changed the clock mode from 16X to 32X. [3.6864 MHz / 32 = 115,200]

So far, my results are unsatisfactory.

The Apple IIGS (Zip 9/32) on which I'm testing this is connected to a Beige
PowerMac G3 (strangely also with built-in SCC-type ports) set to communicate
at 115,200 baud with 8N1 parameters.

Inexplicably, I achieve _some_ measure of functionality by instructing
ProTERM to communicate at 7O1 rather than 8N1. It _receives_ characters just
fine, but introduces errors when sending characters with an even number of
'1's, as would be expected when trying to talk to an 8N1 device with 7O1.

I've gone over the disassembled code again, but have not been able to figure
out how I could introduce a framing/parity error with my patches. The WR's
that deal with bits and parity have not been touched.

Oh well. <g>

Thanks again for the expert instruction.

Hugh Hood...


> AppleTalk has the SCC operating in a different mode (SDLC) with a
> different clocking system (FM modulation, but I forget offhand whether
> it uses FM0 or FM1), and a DPLL to recover the clock from received data.
> When using the DPLL in FM mode and the SCC master clock at 1X as the
> source (3.6864 MHz), the DPLL outputs a divide-by-16 clock, so AppleTalk
> runs at 3.6864e6/16 = 230400 bps.
> 
> In async mode with NRZ encoding, the SCC can't be operated with a 1X
> clock if you want to receive anything, because it needs oversampling to
> detect bit transitions. You therefore must use a 16X, 32X or 64X
> clocking mode.
> 
> In the IIgs, for async mode, the SCC is normally configured to use baud
> rate generator and a 16X clock source. The baud rate generator has a
> minimum divisor of 4 due to the 2x multiplier and offset of 2 from the
> value programmed into the registers. The maximum baud rate is therefore
> 3.6864 MHz / 16 / 4 = 57600 bps.
> 
> To get higher baud rates, you must bypass the baud rate generator and
> use the RTxC pin as the direct source for the transmit and receive clock
> (controlled via WR11, with separate settings for receiver and
> transmitter).
> 
> In combination with the clock mode options in WR4, this gives you
> potential baud rates of 3.6864 MHz divided by 16, 32 or 64, which are
> 230400, 115200 or 57600 bps.
> 
> I haven't experimented with these high baud rates, and I wouldn't expect
> the IIgs to be able to keep up with 230400 async data even with an
> accelerator. 115200 is more likely to be achievable.
> 
> (AppleTalk uses high priority interrupts combined with polled operation
> to achieve 230400, but it locks out normal operation for tens of
> milliseconds at a time and relies on relatively short packets of data
> and half duplex operation. This technique is likely to be impractical
> for asynchronous communication.)
> 
> -- 
> David Empson
> dempson@actrix.gen.nz