[Coco] CoCo's TIMER and 60hz

[Dave Philipsen]

Most of the modern RTC chips have a method where all of the registers' 
contents can be transferred to a latch at any moment in time which 
effectively freezes the time although no 'catch up' is required because 
the RTC continues to run normally when the registers are latched. Then, 
the CPU can read each of the latched register values at its own pace 
without worry that something will change before all of the values have 
been read.

Dave


On 5/29/2019 1:37 PM, Gene Heskett wrote:
> On Wednesday 29 May 2019 12:32:58 pm Allen Huffman wrote:
>
>> How precise is the CoCo’s 60hz IRQ from machine to machine? I’ve
>> really only used two CoCo 3s in my lifetime, and I don’t recall the
>> software clock under OS-9 being terribly inaccurate.
>>
>> I did some tests with Roger Tayloer’s Matchbox CoCo FPGA and saw that
>> the time gets off pretty badly under NitrOS-9.
>>
>> I then did some BASIC tests between it and a stopwatch, assuming TIMER
>> is 60/second. It also gets off.
>>
>> Now I am testing Matchbox CoCo against my real CoCo 3, and see
>> Matchbox is already 2 seconds behind in the first 8 minutes.
>>
>> Since I don’t have multiple CoCos to compare, I wonder if this is just
>> normal drift? Since we are using the video outputs 60hz, I assume it
>> has to be pretty precise and consistent, but maybe not perfect from
>> machine to machine? NTSC was never perfect, yes?
>>
>> I can share my simple test program if someone would be interested in
>> trying it on two real CoCos side-by-side.
>>
> This is where a realtime clock chip is worth its price in bottled beer.
>
> The vertical interrupt is driven the the same counters, and is actually a
> smidgeon slower than ntsc, which is 59.94 if your clock crystal is dead
> on. But those rocks were bblb in the first place and will fade slow as
> the silver plate oxidizes over the years, so the silver gains the weight
> of the oxygen that is now silver oxide, So in 30+ years that rock has
> gotten slower by  up to 1%, maybe even more.
>
> So the vertical irq could be as slow as 59.5, and the coco's clock will
> lose time accordingly.
>
> There was a hardware clock, I forget if it was the B&B-XTC or the 4in1
> Disto, which also lost time, but only when the coco was running. That
> turned out to be the wrong freeze command in the clocks reader code, the
> idea being to get monotonic time from the chip, but the supplied driver
> froze the whole clock while it was being read, but there was another
> freeze that only applied to the outbuffers, and it would then play
> internal catchup when that freeze was ended. I fixed my driver at the
> time but this was long before we left chestnut and went to princeton,
> and I've no clue if that change now exists in the nitros9 versions, nor
> am I certain it even exists in my system right now since that drive got
> moved to my office machine a couple years later when I conned the
> station into buying me a later B&B-XTC.
>
> More than you wanted to know, but there it is. I do recall that the disto
> version once the driver was fixed was only off a second or 2 a month. So
> maybe it was the disto driver I fixed, but after all these years, I've
> made it a practice to not keep a bible to swear on within reach.
>
>
>> --
>> Allen Huffman - PO Box 7634 - Urbandale IA 50323 - 515-999-0227
>> (vmail/TXT only) http://www.subethasoftware.com -
>> https://www.facebook.com/subethasoftware Sent from my MacBook.
>>
>> P.S. Since 4/15/2014, I have earned over $4050! Sign up using my link
>> and I get credit: http://swagbucks.com/refer/allenhuffman (Ask me for
>> the tip/howto doc.)
>
> Cheers, Gene Heskett