Reading a two byte timer is meat and drink in the land of PIA, CIA, and VIA peripherals. The hazard is that the timer could overflow the low byte in between the two reads. It might even wrap the high byte!

I believe the general plan of attack would be something like this:
- ernq uvtu
- ernq ybj
- ernq uvtu ntnva, vs qvssrerag hfr guvf inyhr naq ernq ybj ntnva.
(Obfuscated with rot13 just in case you haven't thought about this before)

But can you do it elegantly? Feel free to make an assumption that it's either counting up or counting down.

Edit: I have a solution in mind, sbhevafgehpgvbafryriraolgrf (rot13 to the rescue)

Some space for anti-spoilery
.
..
.
...
.
..
.
....
.
..
.
...
.
..
.

For the general case, I have:


and for counting up:


Not at all sure about this...

(I've just tweaked the head post)

Hmm, I see that there's an extra pair of possibilities. In my mind, we're reading a microsecond timer, so we never expect to see the same low byte value twice. But another view is that we're reading something more like a real time clock, where we can usually read the same low byte value twice - I think that's the view in your post, @rwiker?

For the counting-up case, if the low byte is anything else than 0, the high byte should not have changed since it was read a few ticks back. Otherwise, we read the high byte again.

I see what you're thinking... but with 4 cpu cycles between the two loads, there's an assumption there that the timer isn't going from 00ff to 0001. That'll sometimes be true, but for a 1MHz CPU and a 1MHz VIA, I think it won't hold.

The following is compact and general: A disadvantage is that in the edge case, a second triplet of reads occurs, which is markedly slower than the fast path. If you know which way the timer is counting, you can spend a few bytes to gain some performance: This can also be developed into a version which can accommodate both counting directions without re-reading the timer: The key in all cases is that the change in the high half of the timer is what marks the rollover of the low half. But you also need to get a fresh idea of the low half because it could have been read before or after the rollover.

That's nice! My effort was the same as your first cut, with a very dim feeling that something might exist like your second/third. That final version is very nice (but probably unnecessary!)

I did have to adjust it after I realised there was a race condition.

Can you see any potential race conditions in my rookie attempt?


Maybe if the counter rolls between the ldy and the ldx I might be off by one ...

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

That one could be acceptable *if* the timer counts slowly. Often, though, the timer counts at Phi2 rate, so it will have incremented by several counts between the two reads of timer_hi.

More reliable would be to either reload from timer_lo in the event of rollover, or to load it with a constant that's consistent with a rollover having just occurred. Or, yet another variation that I just thought of: This leaves the high half of the timer alone, but adjusts the low half to be consistent with the pre-rollover value.

That's quite clever... took me a while to figure it out.

And now for a 65816 version:

I think you might have a winner there (you have my vote, at least).

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Just a quick note to say thank you to Ed for posting this question, and thank you to everyone who replied.

I ended up using this version from Chromatix:

I'm building an external VGA Frame Buffer with a Blitter for the BBC Micro, and using this code to time how long blitter operations are taking.

Dave