These two cases are interesting, they write to ACR to change the timer from continuous mode to one-shot mode (and visa versa) at the same time the timer is expiring. Except for jsbeeb, the write seems to take effect before the timer fire logic runs.

Tests cases are VIA.AC2 and VIA.AC3 in the SSD, or also pasted inline below. Once some kindly soul has run these, it's possible I'm getting low on test cases, at least for core functionality

That's definitely an unexpected result but that makes it interesting. None of the emulators return 0,0 for both test cases. Would it be an imposition to run the extra two tests, VIA.AC4 and VIA.AC5? They try to test only ACR flip behavior a bit more thoroughly and not mix in crazy timing.

Thanks! This is as expected. jsbeeb and b-em nail both of those tests (b2 needs to not re-arm the timer on a flip from one-shot to continuous). There must be something timing related going on, or maybe my original test cases had a bug. I'll go away and study them some more.

Ok, here's my (final?) attempt to shed light on the weird asymmetric behavior of ACR write vs. timer interrupt. These two test cases are kind of behemoths now (VIA.AC6, VIA.AC7) but if BigEd or some other kind soul ran these, we might learn a bit more for how emulators should behave in corner cases.

Bonus test: what does "PRINT ?&FE6A" say after a fresh power on? I read one resource that thinks SR might be initialized to $FF, but others say $00.

Thanks BigEd. This confirms the quirky result with no additional quirks uncovered.

This is easy enough to emulate but it is strange to think what could be going on in the silicon to make ACR 00 -> 40 at IRQ time asymmetric with ACR 40 -> 00 at IRQ time. In both cases, ACR==00 wins; the irq flags the timer as one-shot expired.

I don't know anything about this, but could there be a pipeline delay? Does writing to ACR once cycle before expiry affect the IRQ in a more understandable way? Or maybe that's already been well covered?

it is strange to think what could be going on in the silicon to make ACR 00 -> 40 at IRQ time asymmetric with ACR 40 -> 00 at IRQ time.

As has been remarked before, it's only "strange" if you assume that everything is synchronous (clocked). For somebody like me who, back in the 1970s and 80s, designed mostly asynchronous logic it isn't very surprising since it's the sort of thing that can easily be explained by 'fall times' being faster than 'rise times' (particularly in the case of wired-and signals with a passive pull-up but an active pull-down).

it is strange to think what could be going on in the silicon to make ACR 00 -> 40 at IRQ time asymmetric with ACR 40 -> 00 at IRQ time.

As has been remarked before, it's only "strange" if you assume that everything is synchronous (clocked). For somebody like me who, back in the 1970s and 80s, designed mostly asynchronous logic it isn't very surprising since it's the sort of thing that can easily be explained by 'fall times' being faster than 'rise times' (particularly in the case of wired-and signals with a passive pull-up but an active pull-down).

I'd love to read more about this if there are any good resources. Sounds fascinating.

I don't know anything about this, but could there be a pipeline delay? Does writing to ACR once cycle before expiry affect the IRQ in a more understandable way? Or maybe that's already been well covered?

One of the tests in the most recent dump did the same ACR writes one cycle before IRQ (the counter is 0). Writes take effect "normally" best I can see.