| |
TWW
Registered: Jul 2009
Posts: 545 |
Excact Vertical Frequency / Refresh Rate
I am making a clock by using a CIA timer. Basically I calculate how many cycles are executed each second by calculating lines x cycles/line x vertical refresh rate.
I then want to make the clock run correct on all systems (NTSC/PAL/DREAN/NTSC_Old) and in this context, I was wondering what is the EXACT vertical refresh rates for these systems (50 and 60 plus 3 decimals or more)?
(I've found conflicting information around the web so that's why I'm asking) |
|
... 20 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yeah i know these sites (there are quite a bunch of them) ... i was talking about the guaranteed maximum deviation etc |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: yeah i know these sites (there are quite a bunch of them) ... i was talking about the guaranteed maximum deviation etc
Some info regarding central europe with allowed deviations: http://www.mainsfrequency.com/frequ_info_en.htm |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting Groepaztrying to confuse the centiseconds counter like you said SHOULD work imho ... kinda like opening the borders =) it should count to $f then and wrap around. make a test program and have a look (it will break on every emulator right now, i guess ....)
I've been thinking of opening the TOD border too, but I assumed it was a 3-bit counter. It only needs to count to 5 or 6 before incrementing the decisecond register.
But who knows; perhaps it is an LFSR?
If this trick works, one could use it repeatedly to make the clock go faster or slower. Totally pointless, but maybe a fun exercise. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
jusdging from my observations (and existing test programs) all the counters are simple binary counters with a binary compare for the proper wrap around (if you initialize them with "invalid" values the will happily count further until they overflow) |
| |
Style
Registered: Jun 2004
Posts: 498 |
Quote: burning speccies i hope :)
edit: care to give the exact numbers then? IIRC its worse in north america than in central europe (and its really terrible in other, less developed areas, i guess)
50Hz will quite often drop to 49.5 or so with a sizeable forced outage here. And we have one of the most secure networks in the world, since my state decided to operate a capacity market (as opposed to energy only).
Due to frequency response it's ok, but I certainly wouldnt do any form of timing with it. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:50Hz will quite often drop to 49.5
wow, thats quite a bit worse than it is in europe then :) |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Occasionally being off by 1%, but good most of the time - I bet that's still more stable than most 30 year old crystals if you account for different units and temperature ranges. |
| |
Repose
Registered: Oct 2010
Posts: 225 |
I don't see why you are tying this to frame frequency, it's just pal/ntsc clock rate.
If you look at the theoretical clockrate of an NTSC C64, it's 8.181818/8=1.022727 MHz. That means 1022727 clock cycles is one second. You want to set a CIA Timer to count some value less than 65535, then increment a byte on interrupt, and check that byte to reach a certain value for seconds.
First we look at the factors of 1022727. There is only 3 x 340909, that's not good, as the larger factor is too long to count in a timer.
1022728 is better:
1, 2, 4, 7, 8, 14, 28, 49, 56, 98, 196, 392, 2609, 5218, 10436, 18263, 20872, 36526, 73052, 127841, 146104, 255682, 511364, 1022728
We pick 36526 for the Timer value, and each interrupt, increment a byte. When that byte reaches 28, it's been 1 second, then increment another byte for your seconds counter, then reset the 28 back to 0. Now we have exact seconds, and you can take it from there to increment the minutes, hours, days, etc.
The equivalent values for PAL are 30789 for the timer and 32 for the counter, which is very nice! You can just shift the counter right by 5 to get seconds directly from 0-7.
The accuracy of the quartz crystal depends on cut, temperature, humidity, pressure, and even the pull capacitors. The one in the c64 is probably AT cut and hermetically sealed, so it mostly depends on temperature, where the mid-point is 25*C. Aging is about 2ppm/year. Temperature is most important, and can be in the area of 100ppm [1].
Using the TOD, sometimes the absolute drift can be 40s over 2 months. With heavy power demand, the power frequency slows down.
Reference:
[1] http://www.electronicdesign.com/analog/minimize-frequency-drift..
[2] http://wwwhome.cs.utwente.nl/~ptdeboer/misc/mains.html
[3] Any crystal datasheet.
ps.
You can be as accurate as you want. Assuming indoors and steady average drift, just wait a few days, compare your c64 to the PC with network sychronized time, then decide how many seconds to add/subtract everyday day to catch up. |
| |
Scan
Registered: Dec 2015
Posts: 111 |
Apparently we currently have some deviations in the European power grid as well due to some bickering between Kosovo and Serbia:
https://www.entsoe.eu/news-events/announcements/announcements-a.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
kinda funny how they hype this in the media atm :) |
| Previous - 1 | 2 | 3 - Next |
