22

The C64 has two Time of Day (TOD) clocks, one in each of its 6526 CIA chips U1 and U2. These calculate time based on a 60 Hz or 50 Hz input to the TOD pin (pin 19); the clock input frequency assumed by the CIA is selected via programming bit 7 (TODIN) of CRA (Control Register A) to 0 for 60 Hz or 1 for 50 Hz.

According to the C64/C64C Service Manual, 50 Hz or 60 Hz input to both TOD pins is generated from the 9 V AC power input converted to a TTL signal using one of the AND gates of a 74LS08 (U27). Though the schematic on page 21 claims that this is a 60 Hz signal, this will surely be 50 Hz in regions of the world where AC mains power is 50 Hz, since as far as I know the external power supply always generated unregulated 9 V AC from the from the region's AC mains via a transformer. (The schematic for a newer version of the board on page 32 does say "50 Hz OR 60 Hz" at the AND gate output/U2 input, though it still says just "60 Hz" at the U1 input.)

It doesn't seem possible to conclusively tell whether the input is actually 50 Hz or 60 Hz. Not only might someone run a PAL C64 in a 60 Hz mains power region (using that region's external power supply or via a step-down transformer), but the NTSC C64 was also sold in Japan, where consumers might have either 50 Hz or 60 Hz mains power, depending on region.

Did the Commodore-supplied software (Kernal, BASIC, other programs) have any facilities to set TODIN, or was that just always set to 60 Hz, causing the TOD clock to run 17% slow outside of North America, western Japan and other 60 Hz regions? (And did the software set the bit for both CIAs, or was there one that was considered the standard one to use?) How did third-party programs that relied on the TOD clock deal with this?


Bonus points if you can give the implications of all this for popular emulators. For example, Codebase 64's has an article "Initializing TOD clock on all platforms" which explains how to count screen cycles against a TOD clock set for 60 Hz input in order to figure out what the actual input should be. But it also says:

When running this in Vice, it will always end up detecting the Vice TOD Clock as 60Hz clocked and it will always be counting correct despite of this. In other words: Vice seems to ignore bit 7 of $dc0e and just always clock correctly.


Here are some related questions for even further bonus points. (I include these here since the answers are likely to be turned up during research for this question.)

  1. Did C64 BASIC use one of the TOD clocks, or can one check if the TOD clock is accurate only with PEEK/POKE or machine language?
  2. Were there any other components of the C64 that might also be affected by the 50 Hz vs. 60 Hz difference in the 9 V AC power supply?
12
  • 3
    It seems that the built-in software (e.g. BASIC) did not use the RTC - even not TIME$. So maybe Commodore intended that third-party SW that uses the RTC is setting TODIN correctly. Nov 12, 2019 at 6:59
  • 1
    @Martin Ah! TIME$ works properly on VICE emulating a PAL system even though PEEK(56334) = 1 and PEEK(56590) = 8, i.e., neither CRA register has bit 8 set. BASIC not using the TOD clock would explain this.
    – cjs
    Nov 12, 2019 at 7:26
  • 2
    The one piece of Commodore-supplied OS Software that does use the TOD clock is CP/M on the C128. You can boot CP/M and then at the A> prompt enter the command date c to see the clock ticking along. IIRC, C128 CP/M contains code that sets the CRA bit, though I don't remember which CIA it uses.
    – TeaRex
    Nov 12, 2019 at 8:43
  • 5
    @TonyM That's just the short term worst-case tolerance, most electrical grids adjust their frequencies daily to ensure that in the long term the grid frequency is accurate enough for time keeping: en.wikipedia.org/wiki/…
    – user722
    Nov 12, 2019 at 17:38
  • 1
    @Raffzahn, Ross already covered that.
    – TonyM
    Nov 13, 2019 at 13:00

1 Answer 1

16

How does the C64 get an accurate TOD clock on 50 Hz power?

It doesn't, as the Kernal doesn't care about the built-in TOD. The Kernal is a quick hack, taken straight from the VC20, operating the clock on interrupt base - as alwasy since PET times (as explained on another question about the 6526).

If it had cared, it could do so by simply handling Bit 7 of CRA (Register 14, $DC0E for CIA1, $DD0E for CIA2).

  • Set to ZERO lets the counter wrap at 60, while
  • set to ONE already flips the second at 50

[...] 50 Hz or 60 Hz input to both TOD pins is generated from the 9 V AC power input [...]

Exactly, thus any clock delivered is based on the power frequency - and its reliability at point of measurement (*1).

It doesn't seem possible to conclusively tell whether the input is actually 50 Hz or 60 Hz

As with measuring any external signal, it needs to be quantified against a known source. The C64 offers in fact two. One is the system clock, the other would be the video frame rate. While both vary according to the video system used, their relation is in either case unique.

There are three basic methods to do so:

  1. Using the 6526 timer to test TOC advancement vs. CPU clock.

  2. Counting frames vs. CPU clock

  3. Comparing TI$ and TOD

The last one in particular can easily be done from BASIC.

Then there is of course the ability to cheat by peeking the Kernal to get the Jiffy-Clock setting :)

Did the Commodore-supplied software (Kernal, BASIC, other programs) have any facilities to set TODIN,

No, not as part outside of diagnosis that is.

How did third-party programs that relied on the TOD clock deal with this?

In the only case I've seen back then, the program peeked the Kernel to get the clock rate and set the TOD flag accordingly. This would have failed in places where the mains frequency diverged from that assumption.

Did C64 BASIC use one of the TOD clocks,

No, as already included before, neither Kernal nor BASIC uses the TOD function(*2). Heck, not even Simons' BASIC, sold by Commodore to cover the lack of BASIC V2.0 (*3), didn't touch the TOD clock(s).

or can one check if the TOD clock is accurate only with PEEK/POKE or machine language?

Exactly. Well, unless using some BASIC extension that is.

Were there any other components of the C64 that might also be affected by the 50 Hz vs. 60 Hz difference in the 9 V AC power supply?

None - unless you count interference to sound and graphics due to inadequate shielding :)


A little nitpick:

Not only might someone run a PAL C64 in a 60 Hz mains power region (using that region's external power supply or via a step-down transformer)

  1. PAL is not necessarily associated with 50 Hz. For example, Brazil (and other South American countries) use 60 Hz power and 60 Hz frame rate, but PAL encoding.

  2. Usually it would be a step-up, as most places using 60 Hz have lower mains voltages than 50 Hz countries.


*1 - This is only a good source if noise stays below a certain threshold. Otherwise it may be read and let the clock run faster than expected.

*2 - It's worth remembering that the C64 design was a quick hack based on existing hardware (proposed console) and Software (VIC20 Kernal and PET BASIC). As a result none of the new abilities are used in the BASIC, while the Kernal got only minor adjustments to make it work (aka get it out of the door) as fast as possible.

*3 - In some countries, notably the UK, the C64 faced tough competition by computers offering much better BASIC interpreters, so Commodore made several special bundles with Simons' BASIC included.

5
  • 5
    To back up the footnote, from last year, albeit slightly digressively: nytimes.com/2018/03/08/world/europe/… — 25 European countries were affected by a distribution dispute between Serbia and Kosovo that effectively lowered the European grid to 49.996 Hz over a prolonged period, making affected clocks "run up to six minutes slow".
    – Tommy
    Nov 12, 2019 at 14:43
  • 4
    @Tommy At 49.996Hz the grid is about 0.008% slower than nominal, which is about seven seconds per day. If nobody touched the clocks for the entire seven weeks this went on, then six minutes is about correct - the article could be more clear about their numbers.
    – J...
    Nov 12, 2019 at 18:59
  • 1
    @Tommy yes, but that shift has been corrected afterwards. There is a central station in Switzerland making sure that it's one of the most stable time sources on the planet. Stable as in having no long time shift. What it's not is being a most accurate source at a single given moment. Power generation is in fact a very complex analogue networking issue, one normally never notices - and it's the continent wide coordination that makes the European net a quite reliable one as well.
    – Raffzahn
    Nov 13, 2019 at 12:13
  • 1
    Perhaps footnote 2 should say the Kernel "got only minor adjustments to get it working (out the door) as fast as possible". Otherwise, someone who wasn't familiar with the C64 might misread the sentence as saying the goal was to maximize the efficiency of kernel routines.
    – supercat
    Dec 15, 2021 at 18:07
  • @supercat you got a point there.
    – Raffzahn
    Dec 15, 2021 at 20:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .