On Sat, 23 Oct 1999, der Mouse wrote:

> > That's the whole problem with 1x; the receiver is not using the same
> > clock as the transmitter.  Even if both chips are running at the same
> > clock rate, it's not the same clock - there's no circuitry in these
> > computers to synchronize them.
> 
> That's equally true of X16; if nothing else there are variations in
> crystals.

In 16x, 32x, and 64x mode, it doesn't matter. There's no requirement that
the stop bit perceived by the receiver be exactly 16 (or 32 or 64) clock
cycles long. So as the clocks slip relative to each other, in other than
1x mode, the start bit detection will just slip a little. Bytes will still
reliably get received.

In fact, the mac versions of this driver copied a feature of the com.c
driver - there's a 5% tolerance on the baud rate calculation code. Because
in the over-sampling modes (16x, 32x, 64x), you can tolerate that.

> In each case, there is no reason the chip can't hold the divisor chain
> cleared until it sees the beginning of the start bit, then always do a
> divide-by-2 as the last stage (note that even at X1 the PCLK frequency
> is always divided by 2*(tconst+2), an even number), so it has an edge
> available at the middle of its nominal bit time to sample on.
> Depending on where in the PCLK cycle the start bit's edge falls, this
> may be off by as much as one PCLK clock cycle, which is not more than a
> quarter of a bit time.  (If PCLK is a square wave and the chip is
> *really* smart, it could be off by no more than half of a PCLK cycle,
> but I'm not sure that wouldn't violate the 8530 interface spec.)
> 
> And once the stop bit has been sampled, the divisor chain can be frozen
> again - half a bit time before the nominal end of the stop bit - to
> await the next character's start bit.  This allows the sender to be up
> to about 2.5% faster than the receiver - a quarter of a bit time after
> ten bits - without ever seeing the "drifting out of sync" problem Bill
> outlined.  (The sender can be slower by the same amount; the problem if
> the sender is slower by more than that is that the supposed stop bit
> sample can hit what the sender thinks is a data bit instead; while this
> may produce a framing error, it won't miss the next character's start
> bit unless it's so slow that the receiver thinks the start bit ends
> before the sender thinks the last data bit begins, a difference of
> about 20%, and even then, only with certain data patterns.)

What you describe is not the 8530. :-) While it could be done, that's not
what the chips in all of these computers do. :-) First off, you can't stop
the BRG as that would stop transmission. Second off, the BRG feeds ONE
clock to a clock selection circuit, one each for the transmitter and
receiver. Two of these signal sources are from the outside, and so this
extra bit edge you describe won't really work.

> More important, the bitstream will get shifted by a bit - a bit will
> get inserted or deleted, depending on which is faster.  This will
> almost certainly cause a burst of framing errors as the receiver hunts
> for the correct timing of the start and stop bits in the data stream;
> how long this takes to settle depends on the data.

I think that bit insertion will effectivly happen right when the
transmitter is changing state right when the receiver is sampling.

> > To quote the _SCC_User's_Manual_, Zilog document DC-8293-02, page 4-6,
> > "[...] The 1X mode is used when bit synchronization external to the
> > received clock is present (i.e., the clock recovery circuit, or
> > active receive clock from the sender side)."
> 
> Without seeing more context, I'd read that as "here's how to do it if
> you want to use an external clock" rather than "this is the only thing
> 1X mode is good for".  If you believe the context supports the latter,
> I'll happily accept that...but would still want to know whether that's
> equally true of clones like the AMD chips I found in an IPX I just now
> opened up. :-)

It's more the latter - this is what 1x is for - locking to an external
data source.

As for the AMD chips being equivalent to the Zilog ones, why would you
expect them to be different?

Apple descibes macs as having Zilog Z8530 SCC's in a number of places. The
Mac IIci for one, had AMD chips. That says, "second source," to me. Second
sources provide a secoud source for what the other company makes.

Take care,

Bill