I'm seeing some behaviors on javatari with the PIA timer that don't seem to match what I expect from the documentation. Unfortunately, I don't have an actual 2600 to test my code on, and it's very possible that javatari's behavior matches that of real hardware. If that's the case, I apologize in advance for the inaccurate bug report.
My understanding is that, after the timer reaches 0 (where it was originally meant to fire an interrupt), the timer is supposed to count once from 255 down to 0 at a rate of 1T. The original intent was to detect how long it took for an interrupt handler to actually fire, though we have no interrupts in the 6507.
The relevant part of the documentation http://archive.6502.org/datasheets/mos_6532_riot_preliminary_feb_1977.pdf seems to be "After the interrupt flag is set the internal clock begins counting down to a maximum of -255T. Thus, after the interrupt flag is set, a Read of the timer will tell how long since the flag was set up to a maximum of 255T", combined with "After interrupt, the timer register decrements at a divide by 1 rate of the system clock".
In javatari, I observe behaviors that don't match my expectations:
-after counting down to 0, I expect that the timer should switch to 1T. I think I see that in Pia.js in decrementTimer() but my experiments suggest otherwise.
-after counting to -255, the timer seems to wrap around, when I expect it'd stay at -255 forever (i.e. INTIM == 0). Reading through Pia.js, I am not finding code that would try to make it count that underflow only once.
Here's the code I'm testing with: https://github.com/jbqueru/demo1-2600/blob/3b602c872f91c6e7f97dbb9dc1f1203978bdacee/main.asm (which compiles in 8bitworkshop).
The code sets a 12-tick 1024T timer on the first active line, and displays the value of a timer as a color throughout the frame, one color per timer value (4 shades of dark gold and 8 shades of grey). After black (timer value 0), I expect a quick ramp through all the colors (256T is 3 1/3 lines) then staying black for the rest of the frame. Instead. I see that the time speed seems to remain at 1024T. Experiments with faster timers (8T and 1T), which can count 256 ticks within one frame, suggest that the count down after black runs more than once.
I should mention, the theoretical risk would be for code developed against javatari to rely on the fact that INTIM stays a long time at 255 after wrapping, especially in 64T and 1024T modes, and could fail to read that value on real hardware.
Hi there,
I'm seeing some behaviors on javatari with the PIA timer that don't seem to match what I expect from the documentation. Unfortunately, I don't have an actual 2600 to test my code on, and it's very possible that javatari's behavior matches that of real hardware. If that's the case, I apologize in advance for the inaccurate bug report.
My understanding is that, after the timer reaches 0 (where it was originally meant to fire an interrupt), the timer is supposed to count once from 255 down to 0 at a rate of 1T. The original intent was to detect how long it took for an interrupt handler to actually fire, though we have no interrupts in the 6507.
The relevant part of the documentation http://archive.6502.org/datasheets/mos_6532_riot_preliminary_feb_1977.pdf seems to be "After the interrupt flag is set the internal clock begins counting down to a maximum of -255T. Thus, after the interrupt flag is set, a Read of the timer will tell how long since the flag was set up to a maximum of 255T", combined with "After interrupt, the timer register decrements at a divide by 1 rate of the system clock".
In javatari, I observe behaviors that don't match my expectations: -after counting down to 0, I expect that the timer should switch to 1T. I think I see that in Pia.js in decrementTimer() but my experiments suggest otherwise. -after counting to -255, the timer seems to wrap around, when I expect it'd stay at -255 forever (i.e. INTIM == 0). Reading through Pia.js, I am not finding code that would try to make it count that underflow only once.
Here's the code I'm testing with: https://github.com/jbqueru/demo1-2600/blob/3b602c872f91c6e7f97dbb9dc1f1203978bdacee/main.asm (which compiles in 8bitworkshop). The code sets a 12-tick 1024T timer on the first active line, and displays the value of a timer as a color throughout the frame, one color per timer value (4 shades of dark gold and 8 shades of grey). After black (timer value 0), I expect a quick ramp through all the colors (256T is 3 1/3 lines) then staying black for the rest of the frame. Instead. I see that the time speed seems to remain at 1024T. Experiments with faster timers (8T and 1T), which can count 256 ticks within one frame, suggest that the count down after black runs more than once.
I should mention, the theoretical risk would be for code developed against javatari to rely on the fact that INTIM stays a long time at 255 after wrapping, especially in 64T and 1024T modes, and could fail to read that value on real hardware.