VIA timer underflow troubles

[pixel]

If you read T1 count low at the start of an ISR that explicitly handles T1 interrupts *and* the foreground program has a deterministic timing (like a simple JMP *), that arrangement is likely to 'lock' onto a single interrupt latency cycle. As then always the same number of cycles has passed between the VIA causing the interrupt, and the ISR reading T1 low, you'll always read the same value.

True. But I'm not using interrupts at all. Am just looping for the tape pulse status bit with an odd number of cycles.

[tlr]

If you read T1 count low at the start of an ISR that explicitly handles T1 interrupts *and* the foreground program has a deterministic timing (like a simple JMP *), that arrangement is likely to 'lock' onto a single interrupt latency cycle. As then always the same number of cycles has passed between the VIA causing the interrupt, and the ISR reading T1 low, you'll always read the same value.

That's not my experience in the general case. Perhaps if the ISR is constant in timing as well. Probably also if the ISR timing jumps in steps of 3 cycles.

[tlr]

The test case via_wrap2.prg seems to run fine in vice.

I think a little code snippet of the code that generates the problem would be in order...

[darkatx]

I think he posted some of it up here...not sure if its up to date though.

http://sleepingelephant.com/ipw-web/bul ... 416#p79842

And he has downloadable programs on top.

[pixel]

If you read T1 count low at the start of an ISR that explicitly handles T1 interrupts *and* the foreground program has a deterministic timing (like a simple JMP *), that arrangement is likely to 'lock' onto a single interrupt latency cycle. As then always the same number of cycles has passed between the VIA causing the interrupt, and the ISR reading T1 low, you'll always read the same value.

That's not my experience in the general case. Perhaps if the ISR is constant in timing as well. Probably also if the ISR timing jumps in steps of 3 cycles.

Doesn't the current instruction have to finish before an interrupt can be handled? Would explain the inaccuracies nicely.

[pixel]

The test case via_wrap2.prg seems to run fine in vice.

I think a little code snippet of the code that generates the problem would be in order...

Am at it. Doesn't work. Same problems I had with the tape video player. Am out of wits here. But thanks a lot.