Re: Original Apple IIc serial inaccuracy (?)

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

schmidtd <schmidtd@my-deja.com> wrote:

> So, my $12.01 IIc arrived a couple of days ago.  It turned out to be
> an original ROM 255 model, with the 74LS161 chip instead of the
> oscillator.  So, it should have the 3% timing deficiency with its
> serial ports. 
> (ref: http://en.wikipedia.org/wiki/Apple_IIc#Serial_port_timing_fix)
> 
> Strangely enough, trying out ADTPro with it on both Windows and OSX,
> this little IIc was able to transfer disks back and forth flawlessly
> all the way up to 115.2kbps.  Have computers become more tolerant of
> timing inaccuracies over time?  Or was the problem only with more
> hardware-ish devices like modems and printers?

The unmodified original IIc uses a clock derived from the 14.31818 MHz
crystal, specifically 14.31818 / 8 = 1.787725 MHz.  The ideal frequency
is 1.8432 MHz. As you say, this is a 3.1% error. (It might be worse for
a PAL IIc, which has a slightly slower master clock frequency due to
patching PAL timing rather than NTSC.)

Each transmitted bit is therefore 3.1% shorter than it is supposed to be
at any particular baud rate, and received bits will appear to be 3.1%
wider from the IIc's point of view.

Computer UARTs operate by oversampling (typically at 16x the baud rate)
to detect the beginning of the start bit, then sample once at the
midpoint of each bit, given the clock frequency and configured baud
rate. This process is repeated for each subsequent byte.

This means that the transmitter and receiver baud rates must be
sufficiently in sync so that they drift by less than 50% over the entire
character, otherwise the wrong bit will be sampled within the byte, or
the next start bit will be missed. (You also need to allow for 1/16th of
a bit for differences in sample timing, which is another 6.25%, so the
worst case limit is 43.75%.)

With 3.1% error per bit, the total drift by the time ten bits have been
sent is about 31%, so this is still within the margin of error. It would
be OK even if you were using parity and two stop bits (12 bits per
character, 37.2% total drift).

If the other end was also out by 3% in the opposite direction, then
there would be a problem: by the ninth bit, the timing would be out by
more than half a bit and the receiver would have dropped a bit or
double-sampled one (depending on whether the transmitter was faster or
slower).

This means that an unmodified IIc should work with another device which
has an accurate or slightly slow clock and uses the standard sampling
algorithm (most computers) but it might not work with devices which have
a clock that is a few percent too fast, or if the device uses a more
complex sampling algorithm which can't cope with transitions that don't
line up with its expected bit boundaries.

The stop bit might also be a problem: if either device waits an entire
bit time for the stop bit before looking for the next start bit, then it
might miss it if the faster device is transmitting. This can be avoided
by forcing the faster device to transmit 1.5 or 2 stop bits (as long as
it doesn't also require that number of stop bits when receiving - some
I've encountered are stupid enough to do this).

-- 
David Empson
dempson@actrix.gen.nz