Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
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: 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)
2017-07-18 21:25
chatGPZ

Registered: Dec 2001
Posts: 11386
just calculate cycles per frame and you have the exact numbers. it differes a little bit from the regular PAL/NTSC refresh
2017-07-19 06:33
TWW

Registered: Jul 2009
Posts: 545
GPZ: Maybee I missunderstood you but I already have calculated cycles / frame for all formats by doing:

Cycles/Line X Lines

Following example illustrate the PAL calculation:

    // PAL:
    //   Lines:                            312
    //   Cycles each Line:                  63
    //   Total Cycles each frame:       19.656
    //   Frames each second:                50,125
    //   Total cycles each second:     985.257


The framerate would impact the calculation quite a bit so it must be as exact as possible or is it as simple as PAL = 50,0000 Hz and NTSC = 60,0000 Hz?
2017-07-19 07:14
AmiDog

Registered: Mar 2003
Posts: 97
The framerate is the system clock divided by the number of cycles each frame, thus:

PAL: 985248/(63*312)=50.12454212
NTSC old: 1022727/(64*262)=60.99278387
NTSC new: 1022727/(65*263)=59.8260895
DREAN: 1023443/(65*312)=50.46563116
2017-07-19 08:59
oziphantom

Registered: Oct 2014
Posts: 490
Umm if you want 1 Second, use the TODs that will count 1 second on all the machines without any code changes.
2017-07-19 10:45
Style

Registered: Jun 2004
Posts: 498
Quote: The framerate is the system clock divided by the number of cycles each frame, thus:

PAL: 985248/(63*312)=50.12454212
NTSC old: 1022727/(64*262)=60.99278387
NTSC new: 1022727/(65*263)=59.8260895
DREAN: 1023443/(65*312)=50.46563116


are the clocks accurate? I can imagine there being some variation.
2017-07-19 11:15
AmiDog

Registered: Mar 2003
Posts: 97
I have no idea how accurate the crystals used in the C64 are, or what effects aging and temperature may have, or if all crystals used had the exact same frequency. I'm just using the best figures I've been able to find online :-)
2017-07-19 12:03
TWW

Registered: Jul 2009
Posts: 545
Thanks Amidog, that should be sufficient. Any variance is impossible to take into account and shouldn't matter much anyway.

Ozi: No KERNAL and special time trickery ;-)

EDIT:

For sake of good order:

    // PAL:        985.248 / (63 * 312) = 50,12454212
    // NTSC new: 1.022.727 / (65 * 263) = 59,8260895
    // NTSC old: 1.022.727 / (64 * 262) = 60,99278387
    // DREAN:    1.023.443 / (65 * 312) = 50,46563116
    //
    // PAL:
    //   Lines:                            312
    //   Cycles each Line:                  63
    //   Total Cycles each frame:       19.656
    //   Frames each second:                50,12454212
    //   Total cycles each second:     985.248
    //
    // NTSC New:
    //   Lines:                            263
    //   Cycles each Line:                  65
    //   Total Cycles each frame:       17.095
    //   Frames each second:                59,8260895
    //   Total cycles each second:   1.022.727
    //
    // NTSC Old:
    //   Lines:                            262
    //   Cycles each Line:                  64
    //   Total Cycles each frame:       16.768
    //   Frames each second:                60,99278387
    //   Total cycles each second:   1.022.727
    //
    // DREAN:
    //   Lines:                            312
    //   Cycles each Line:                  65
    //   Total Cycles each frame:       20.280
    //   Frames each second:                50,46563116
    //   Total cycles each second:   1.023.443


Edit2: Which then exactly translates to the system clock ;-) LOL
2017-07-19 19:45
Stryyker

Registered: Dec 2001
Posts: 468
TOD does not use the kernal.
2017-07-19 20:39
chatGPZ

Registered: Dec 2001
Posts: 11386
more relevant: to make an actual clock - use the CIA TOD, it has excellent long term stability (more than the system clock). CIA timer is useful only for short-time measurements.
2017-07-19 22:37
TWW

Registered: Jul 2009
Posts: 545
Ah yeah, I mixed up TOD with the KERNAL TI... Totally forgot about it.

I chained two timers on CIA #2 to trigger a NMI which incremented the second counter. Guess I could just as easily use the TOD.

Just to confirm, is the TOD correct on all systems (PAL/NTSC/DREAN)?
2017-07-19 23:01
chatGPZ

Registered: Dec 2001
Posts: 11386
the TOD uses the power grid frequency - so you need to set it up according to that. if you want it to be 100% correct always, you need to measure the power grid frequency first, then set up the TODs 50/60Hz bit correctly. see this test program for inspiration: https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/CIA.. - you cant rely on the video system because eg on the SX64 its always 60Hz.
2017-07-20 09:44
Style

Registered: Jun 2004
Posts: 498
I wouldnt use the power frequency (and thus the TOD) for anything that requires any accuracy at all.

Power grids are notoriously bad in terms of frequency.
2017-07-20 12:31
chatGPZ

Registered: Dec 2001
Posts: 11386
ehrm, no they are not. please read up on the topic. they are putting a lot of effort into keeping all grids in sync and keeping the frequency stable.

edit: to make it clear.... shorttime this is correct, the frequency may drift up and down quite a bit, sth like +/- 1% or so at max (it usually does so during the day - you can use the mentioned test program to examine this). however, the number of periods for long time periods (a weeek, a month... i dont remember what is guaranteed) is very accurate, and certainly ok to use for a wall clock.
2017-07-20 19:01
soci

Registered: Sep 2003
Posts: 480
Not all C64s are running on the original brick any more. Some replacements use an inverter or are DC only except those with a small 9V transformer bolted on the side.

I didn't bothered to do an inverter and just installed a 555 next to the CIA and hand tuned it to ~50 Hz or so to keep the TOD running. Wondering how much ppm can it be ;)

Also the pre-scaler can't be reset so starting it accurately is problematic.

Therefore I rarely use the TOD and go with the timers instead, those always work.

Btw. is it possible to make a centisecond longer by switching it from 60 to 50 Hz pre-scaling at the right time?
2017-07-20 19:12
chatGPZ

Registered: Dec 2001
Posts: 11386
if you are running the C64 with some half-broken PSU... yeah no guarantees then =P

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 ....)
2017-07-20 19:29
Compyx

Registered: Jan 2005
Posts: 631
What about using NTP via RRNet? Sounds fun to do.
2017-07-20 20:53
soci

Registered: Sep 2003
Posts: 480
I thought about that too.

But it'd be more fun to connect a RS232 GPS time receiver to the user port at 9.6 kbit/s with it's PPS output on CNT input of CIA.

Once synchronized it stays so without further effort ;) The NTP synchronization on the other hand needs to be repeated to compensate for any drift.
2017-07-21 07:19
Style

Registered: Jun 2004
Posts: 498
Quote: ehrm, no they are not. please read up on the topic. they are putting a lot of effort into keeping all grids in sync and keeping the frequency stable.

edit: to make it clear.... shorttime this is correct, the frequency may drift up and down quite a bit, sth like +/- 1% or so at max (it usually does so during the day - you can use the mentioned test program to examine this). however, the number of periods for long time periods (a weeek, a month... i dont remember what is guaranteed) is very accurate, and certainly ok to use for a wall clock.


Dude. I work in power generation :)
2017-07-21 12:20
chatGPZ

Registered: Dec 2001
Posts: 11386
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)
2017-07-21 20:52
JackAsser

Registered: Jun 2002
Posts: 2014
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)


There are real time data for it: UK f.e. http://www2.nationalgrid.com/uk/Industry-information/electricit..
2017-07-21 21:25
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
2017-07-21 21:54
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
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: 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)
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: 11386
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: 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.
2018-03-06 22:54
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.
2018-03-07 14:44
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..
2018-03-07 18:50
chatGPZ

Registered: Dec 2001
Posts: 11386
kinda funny how they hype this in the media atm :)
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Martin Piper
Flashback
Alakran_64
rambo/Therapy/ Resou..
Matt
Hein
LDX#40
Guests online: 118
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 No Listen  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Rainbow Connection  (9.5)
7 Dawnfall V1.1  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Original Suppliers
1 Derbyshire Ram  (9.7)
2 Fungus  (9.3)
3 Black Beard  (9.2)
4 Baracuda  (9.2)
5 hedning  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.092 sec.