 Previous Messages |
Posted By
Fuzzweed
on 2024-10-21
04:12:45
|  Re: Interupt timers - actual time represented
Ahh brilliant thank you. Yeah I'm working out the programmers guide so the approximate 'how to' is there, but it's pretty light on some of the important details.
|
|
Posted By
siz
on 2024-10-21
03:36:47
| Re: Interupt timers - actual time represented
The timer is independent of the CPU. It always uses single clock cycles (~876kHz for PAL systems) to decrement value. Based on that you can calculate the value you need to write as timer 1 reload value.
Be aware that timer stops as soon as you write the lower byte and starts counting when high byte is written.
|
|
Posted By
Fuzzweed
on 2024-10-20
19:14:53
| Re: Interupt timers - actual time represented
Maybe I should have added more detail. Sorry.
I'm trying to make interrupt driven sample playback.
If my sample is 5khz and CPU is ~1mhz that's 200 cycles between samples.
(Ignoring the actual code and any messy detail for now)
if the interrupt timer decrements every cycle I set reload value to 200.
But I presume it doesn't Dec every cycle because the cpu has other things to do ...
|
|
Posted By
Csabo
on 2024-10-20
18:44:06
| Re: Interupt timers - actual time represented
Maybe I'm misunderstanding the question, but... The shortest instruction you can execute takes 2 cycles. During this, the timer ($FF00/$FF01) appears do count down by one.
In other words, if you were to constantly read from the low byte of the first timer (LDA$FF00), that takes 4 cycles to executes, and the values you would be reading would be decrementing by 2.
Is this what you're asking?
|
|
Posted By
Fuzzweed
on 2024-10-20
16:49:46
| Interupt timers - actual time represented
How many cycles per interrupt timer decrement is there?
|
|
