Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!hplabs!hplabsz!dleigh
From: dleigh@hplabsz.HPL.HP.COM (Darren Leigh)
Newsgroups: comp.sys.amiga.tech
Subject: Re: TICK and J300
Summary: 60 Hz vs. 59.94 Hz
Message-ID: <3334@hplabsz.HPL.HP.COM>
Date: 15 May 89 17:17:36 GMT
References: <3319@hplabsz.HPL.HP.COM> <6854@cbmvax.UUCP> <286@xdos.UUCP>
Reply-To: dleigh@hplabs.UUCP (Darren Leigh)
Distribution: na
Organization: Hewlett-Packard Laboratories
Lines: 30

In article <286@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes:
>In article <6854@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) responds
 to my question about the TICK signal and J300.
>>Normally, the A2000 takes its 1/60sec  (or 1/50) ticks from the power
>>lines, which should be fairly accurate.  When you switch the jumper
>>to the "A500" position your A2000 then takes its ticks from the
>>video. Which is not quite as accurate.
>
>Unless there is something more going on than what you stated, this
>is inaccurate. Power line frequencies drift quite a bit, although
>the utilities usually take some care to make the drift average out to
>approximately zero over a period of time.

I guess Andy means that the TICK signal taken from the video is
clocked at 59.94 Hz (the NTSC vertical rate) instead of 60 Hz (the
power-line rate).  If this is true, then the real-time clock will lose
about 86 seconds a day.  Ouch!  I suppose this is not much of a
problem if the user reboots at least once a day, but would be
intolerable if the machine is left on continuously.  What else is
controlled by the TICK signal?  The context switch interrupt?

The real-time clock problem alone is enough to make me want to build a
precision 60 Hz clock signal for the TICK line.  What should the
signal look like?  A TTL level square wave at 60 Hz, duty cycle
unimportant?

========
Darren Leigh
Internet:  dleigh@hplabs.hp.com
UUCP:      hplabs!dleigh