[CSDb] - User Forums - Excact Vertical Frequency / Refresh Rate

Welcome to our latest new user maak ! (Registered 2024-04-18)

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Excact Vertical Frequency / Refresh Rate

2017-07-18 21:22

TWW

Registered: Jul 2009
Posts: 541

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....

2017-07-21 21:25

chatGPZ

Registered: Dec 2001
Posts: 11100

yeah i know these sites (there are quite a bunch of them) ... i was talking about the guaranteed maximum deviation etc

2017-07-21 21:54

JackAsser

Registered: Jun 2002
Posts: 1987

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

2017-07-21 22:09

lft

Registered: Jul 2007
Posts: 369

Quoting Groepaz

trying 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.

2017-07-21 23:11

chatGPZ

Registered: Dec 2001
Posts: 11100

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)

2017-07-22 16:30

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.

2017-07-22 20:45

chatGPZ

Registered: Dec 2001
Posts: 11100

Quote:

50Hz will quite often drop to 49.5

wow, thats quite a bit worse than it is in europe then :)

2017-07-22 23:21

MagerValp

Registered: Dec 2001
Posts: 1055

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.

2018-03-06 22:54

Repose

Registered: Oct 2010
Posts: 222

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.

2018-03-07 14:44

Scan

Registered: Dec 2015
Posts: 110

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..

2018-03-07 18:50

chatGPZ

Registered: Dec 2001
Posts: 11100

kinda funny how they hype this in the media atm :)

Previous - 1 | 2 | 3 - Next

Refresh

Subscribe to this thread: