Like many early microcomputers, the Commodore VIC-20 did not come with an interna real-time clock built into the system. [David Hunter] has seen fit to rectify that with an add-on module as his entry to the 2025 One Hertz Challenge.
[David]’s project was inspired by a product that Hayes produced in the 1980s, which provided a serial-port based real-time clock solution for computers that lacked one on board. The heart of the project is an Arduino Uno, which itself uses a Dallas DS3231 RTC module to keep accurate time. [David] then drew from an IEC driver developed by [Lars Pontoppidan] for the MM2IEC project. This enables the Arduino to report the time to the VIC-20 via its IEC port.
The project is a neat way to provide a real-time clock source to programs written in Commodore BASIC. It’s also perfectly compatible with the IEC bus, so it can be daisy chained along with printers and disk drives without issue. [David] hasn’t tested it with a Commodore 64, but he suspects it should work just as well on that platform, too.
If you’ve ever wanted to build something clock-based for the VIC-20 but didn’t know how, this is a great piece of hardware to solve that problem. Meanwhile, you might find joy in reading about real-time clock hacks for other systems like the Raspberry Pi. Meanwhile, if you’re working on your own nifty timekeeping projects, don’t hesitate to let us know!
I remember wiring up some sort of RTC to a VIC-20 back in the 1980s — of course, I connected it directly to the address and data bus of the 6502 so it would be in the memory space along with gobs or bank-switched RAM and cool TTL-logic-enabled tricks like RAM I could write to under the BASIC ROMS if I did a write to those addresses. I also made a character editor that include lots of Adobe Photoshop features, but back in 1983. It fit in 3K because I wanted it to work on any VIC-20:
https://github.com/judasgutenberg/vic20_character_editor
Looks like this can be used on C64 and 128 as well. They do have internal clock but no battery backup and are reset to zero time when the system is power cycled. Load the clock variable and store them in TI$ to set the date and time.
Receiving a radio time signal such as DCF-77 would have been another alternative to an RTC at the time.
Unfortunately, it required syncing and decoding the time information all time.
Since the VC-20 and C64 were so busy with not to drown even when being idle, this wouldn’t have worked well.
On an C128 or Amiga it might have been possible, since they can multitask/have a more powerful chipset.
Hm, maybe not? DCF-77, WWV, and MSF are all 1 bit per second formats. After getting the initial bit clock, the you can steal just one/two vsync’s processing to get the next bit.
Hm, yes. There are people who built mechanical clocks and used the 1 Hz pulses directly.
What I thought of being problematic were interrupts.
I remember how a DCF-77 dongle worked fine under Windows 3.x,
but same driver caused issues on then-new Windows 95 (multitasking issues).
Sure, C64 platform is very different, but the sync in background must happen precisely – because it’s all about time.
Using an internal timer to periodically check for an external time signal wouldn’t make that much sense.
Using an interrupt event that can be caused anytime by the pulse of the time signal would be more precise.
It should work on the C64. Worst case, you might have to blank the screen during communication.,