Subject: Re: Baudrates not what they used to be?
To: Walter Ruetten <walter@ghpc8.ihf.rwth-aachen.de>
From: Bill Studenmund <wrstuden@loki.stanford.edu>
List: port-mac68k
Date: 11/14/1995 10:48:17
> has anybody using a Mac IIci/si/vi/vx noticed that using a baud rate
> of 9600 baud or lower doesn't work with the last changes in the
> serial driver code?
Kinda. For now, try 10200 on one of these machines & it will work.
The problem is that the new code reveals (IMHO) a pre-existing problem.
The code now rounds the time constant instead of truncating it as before
(which is why 9600 gets a TC for 9415), and the new code also tells
us what the real baud rate is (it converts baud to TC, then converts
back & stores in the tty structure).
> What I saw using my IIvi is that setting the baudrate to 9600 baud
> results in an effective baudrate of approx. 8900 baud being used.
>
> This might be attributable to a sccClkConst of 122400 being set in
> mac68k/machdep.c for the MacIIci/si/vi/vx.
> Using BPS_TO_TCONST (dev/z8530reg.h) with this sccClkConst and 9600
> baud gives a tcount of 11 (divide by 13) which should lead to a
> baudrate of 9415 baud. This wouldn't result in any problems.
>
> But as things look to me, the sccClkConst for the IIvi is more like
> 115200.
>
> Does anybody know where this sccClkConst of 122400 for
> MacIIci/si/vi/vx comes from
> and
> could those of you having NetBSD running on one of those machine
> check the actual baudrate?
>
I agree totally. While re-writing the serial code, I wondered why the
sccClkConst is different across models. Allen said the different numbers
came out of dividing available clock rates quoted in the hardware guide.
In trying to figure out why my code didn't work, I hooked my MacIIsi
up to a Digital Logic Analyzer & looked at the clock rate. I got a
rate which agreed with 115200 for sccClkConst. I think I also found
the confusion. The clock signal was a bit weird.
Every now & then (in a regular pattern whose details I forgot), the
clock skipped a transition. So the clock rate wasn't a factor-of-two
divisor of any clock. As this clock is divided by 16 before anything
really happens, the jitter doesn't matter. The clock looked something like:
___~~~___~~~___~~~___~~~___~~~~~~___~~~___~~~
^^ skipped transition
I'd vote we just change all the sccClkConst values to 115200.
Take care,
Bill