An old project of mine I dug up and rewrote (C64)

[kelli217]

For a couple of years of my time in high school (for those not familiar with US usage, the 4 years right before university), I used my Commodore 64 as an alarm clock.

I first got my 64 for Christmas during my second year. I didn't do much with it at first, because I didn't have any sort of storage device. No peripherals of any kind whatsoever, really. I played some games on cartridge, and dabbled in BASIC. But starting in my third year, I'd been digging through the user guide and found out about TI$, and decided to use it to wake me up in the mornings.

At first, I just PRINTed TI$ directly to the screen, with no formatting. And every cycle through the main loop, it would check for being equal to a hard-coded alarm time, and GOSUB to a subroutine that would play an upward frequency sweep in triangle wave at maximum volume, and I likewise had the sound on the television monitor cranked up... well, not all the way up, but quite loud. At least halfway through the volume knob's range.

As the weeks and months rolled on, I added more formatting features to the output. Eventually it would parse the TI$ 24-hour time into 12-hour AM/PM and suppress the zero in the hours display, so that a TI$ value of "170522" would print out as " 5:05:22 PM".

Even though I still didn't have storage (I finally got a 1541 in the middle of fourth year), I was so familiar with the structure of the program that I could type it in again in just a few minutes if the computer lost power.

But once I did have storage, I saved my best version. Armed with my new Programmer's Reference Guide, I started working on a new version that would use the 6526 CIA internal time-of-day clock (TOD). I'd learned that any I/O would cause the TI$ clock to lose time, and I'd already noticed that it would drift quite a bit over the course of only a few nights.

I still have a lot of bits and pieces of paper around that I've held onto since back in those days, over 30 years ago at this point, and as it turns out one of those bits pf paper was a listing from when I'd finally gotten a printer, only a couple of months before graduating high school, an MPS803, and I'd listed out the contents of the work in progress, probably right before I'd stopped working on it.

The point where I'd left it was where I was comparing TOD to TI$, printing them both out, fully formatted, but without the alarm feature yet. (I'd had some ideas about changing that as well, such as making the alarm time user-adjustable instead of hard-coded, adding a snooze function, or a progressively louder alarm.) I wanted to see for myself ho much better TOD was before committing to it... and I still hadn't quite worked out how to check for the alarm-set time.

What I had done was a fair amount of cleanup. I added some very simple comments, and had all the line numbers incrementing by 10. This would allow me to stuff in several extra lines to handle however complicated the alarm check might turn out to be.

Anyway, I rewrote retyped it from the listing. I made PET-Gazette-style curly-brace replacements for special characters. I've included it here as 'time.asc'.

I've also loaded it into VICE. However, the host computer I used does CPU throttling for power savings and heat reduction, so starting a run of the program when the machine was at full speed and then leaving it overnight caused both clocks to run almost 30 minutes slow over an 8-hour period. For best results, then, I would suggest running this on a real machine or, if emulated, on a host machine that doesn't slow down the CPU.

time.asc

[John Chow Seymour]

Neat, thanks for sharing this.  I tried it out on my C64 just now. I'd never worked with either the TOD clock nor with TI$ before, so it was interesting to see the different ways you had to handle them.

Incidentally, line 130 as-written is 81 characters long, so I simply broke it up.

I also modified line 1090 like so:

     1090 PRINT"{CLR}";:RETURN

Which clears the time-setting text before running the clocks.

Now I'll leave it running for a bit and see how the two clocks do.

 

EDIT:

After about 10 hours, they've diverged by about a second. It appears that both have lost time (slowed down) compared to the clock to which I set them (on my modern computer), but the TI$ version has fallen only slightly behind, while the CIA's TOD is now over a second behind.

This has been interesting, thank you for bringing it to our attention.  I wonder how time like this will be handled on the X16.

[kelli217]

11 hours ago, John Chow Seymour said:

After about 10 hours, they've diverged by about a second. It appears that both have lost time (slowed down) compared to the clock to which I set them (on my modern computer), but the TI$ version has fallen only slightly behind, while the CIA's TOD is now over a second behind.



This has been interesting, thank you for bringing it to our attention.  I wonder how time like this will be handled on the X16.

There are routines in the old KERNAL for getting the old jiffy clock... SETTIM and RDTIM. But there's also a TOD clock in the emulated hardware and a couple of Sweet16 routines, clock_set_date_time and clock_get_date_time for accessing it. These are documented in the Programmer's Reference Guide. (The year field supports values up to 2155, and jiffies are not supported, though they are used by the routines.)

Messing around with X16 BASIC, it seems that TI and TI$ are no longer tied together; setting TI$ to "000000" no longer sets TI to 0 as well, like it did on the C64. Also, TI can be set directly by the user, since it's no longer affected by setting TI$. That leads me to believe that TI$ now uses the onboard TOD clock while TI uses the software jiffy clock like before.

Back to the C64, the big hit you get on TI$ is if you do any IEC or tape I/O. The software clock doesn't usually update at all while the I/O is going on. So you'll take a big hit if you do any of that and then try to run the program again without updating the time. The accuracy problem with the CIA is, I'm guessing, in variations of the frequency of the system oscillator from minor voltage differences and components changing characteristics as they age. But it should continue to keep time through I/O operations, even if it's not the best at accuracy.

Line 130 was originally entered with keyword abbreviations, and I did the same thing when retyping it into VICE; that's why it's longer than it should be. Whoops.

I appreciate the modification to line 190. Thanks for spotting that. The time setting subroutine used to be something you'd have to run explicitly with 'RUN 1000' and wasn't included in a GOSUB, and I changed that when 'cleaning up' the text version without testing it in the actual version. Whoops again.

[John Chow Seymour]

That makes sense. In my case, I never stopped the program to go do something else, I just shut off the monitor and let it run, and checked back at the end of the day. 

So it's possible that the act of running the clock loop itself is what incrementally bogged down TI$.