Ok. I admit I've been away a few days and haven't read the ENTIRE thread
on this topic, but I thought I'd at least weigh-in with a "sort of"
example of a mid-60s time-of-day clock on a mainframe machine.
The good old Control Data 3300 had a 24 bit millisecond counter that was
used (at least on our operating system) as a pseudo real-time clock.
With 24 bits, you could count up to about 16k seconds before overflow.
Normal use of the counter was to program future timer events (another
register was set to the count at which you wanted an interrupt.) Rather
than just resetting the count register for every interrupt and
programming the length in the limit register, the OS would read the
current count, add the desired delay and write THAT value to the limit.
Thus, the counter would count monotonically. For our purpose, we did
reset counter every hour, so the "real time clock" register (which was
readable by any user process) counted accumulated milliseconds in the
current hour. Another read-only register was used to hold the "date"
(packed in good-old non-y2k compliant form,) with a 5 bit field reserved
for "hour of the day."
One advantage of this "free running" counter as a time-of-day clock was
that in the unlikely of a system hang where interrupts might not get
serviced for a while (the only recoverable one of these was a memory
parity error on "pure" system code, where a checksum was recalculated to
recover the "lost" location of the parity error) and that could take a
few milliseconds. Never fear, the RTC register was counting away and
wouldn't lose time. Even if it happened to count beyond an hour, it
would be caught before the next user task was scheduled and the date
register would be recalculated.
This is basically what was done on the VAX series, but they had the
luxury of LOTS MORE BITS and a faster counter.
-Gary