RISC OS Open: Forum: Timer 1 minimum period

Mar 2, 2024 3:26pm

I’ve been using RPCEmu 0.9.4 (windows) running os 5.28 and I have a problem with timer 1 not giving me a 1ms interrupt. It seems to limit at 2ms even though the period is reported as being 1ms. No error is produced when the period is set, it is just ignored. Periods of 2ms and longer work correctly. The code works fine on a Pi4 (os 5.29 16/12/23).

Is this an RPCEmu limitation ?

I can cope with the reduced rate but it would be nice to be able to read the actual rate, rather than having to time it against the system ticker to find out.

For both Pi4 and RPCEmu, HAL_TimerMaxPeriod and HAL_TimerReadCountdown always return 1 and HAL_TimerPeriod always returns what is set by HAL_TimerSetPeriod.

Here are the return values for the HAL timer calls. (input value for HAL_TimerSetPeriod)

                              RPCEmu     PI4
HAL_Timers                      2         2
HAL_TimerDevice (timer 1)       6         3
HAL_TimerGranularity            2000000   1000000
HAL_TimerMaxPeriod              1         1
HAL_TimerSetPeriod              2000      1000
HAL_TimerPeriod                 2000      1000
HAL_TimerReadCountdown          1         1
rate relative to system ticker  5x        10x

Mar 2, 2024 4:02pm

André Timmermans (100) 655 posts

I am not sure that you will get what you want on RPCEmu.

I used Timer1 with non-Hal machines to derive how much CPU TimPlayer used in order to limit the number of notes it was attempting to play. On RPCEmu the CPU % was just jumping between a few fixed values, indicating that the timer wasn’t updated at a very high frequency.

Mar 2, 2024 4:26pm

Peter Everett (9846) 59 posts

André,
I was only using the RPEmu to test a 4k colour mode plotter. Your post about extra colour modes prompted me to try and it worked a treat. It was then I noticed that the MIDI file player was going at half speed and the Synth was not putting enough samples in the audio buffer and the overall effect was absolutely awfull :-)
I am actually quite amazed that the emulator provides what seems to be a very reliable 2ms interrupt. The only iritation is not being able to read the actual (emulated in this case) period that has been used.

Timer 1 minimum period

Reply

Search forums

Social

ROOL Store

Donate! Why?

RISC OS IPR

Description

Voices

Options

Mar 2, 2024 3:26pm Peter Everett (9846) 59 posts	I’ve been using RPCEmu 0.9.4 (windows) running os 5.28 and I have a problem with timer 1 not giving me a 1ms interrupt. It seems to limit at 2ms even though the period is reported as being 1ms. No error is produced when the period is set, it is just ignored. Periods of 2ms and longer work correctly. The code works fine on a Pi4 (os 5.29 16/12/23). Is this an RPCEmu limitation ? I can cope with the reduced rate but it would be nice to be able to read the actual rate, rather than having to time it against the system ticker to find out. For both Pi4 and RPCEmu, HAL_TimerMaxPeriod and HAL_TimerReadCountdown always return 1 and HAL_TimerPeriod always returns what is set by HAL_TimerSetPeriod. Here are the return values for the HAL timer calls. (input value for HAL_TimerSetPeriod) RPCEmu PI4 HAL_Timers 2 2 HAL_TimerDevice (timer 1) 6 3 HAL_TimerGranularity 2000000 1000000 HAL_TimerMaxPeriod 1 1 HAL_TimerSetPeriod 2000 1000 HAL_TimerPeriod 2000 1000 HAL_TimerReadCountdown 1 1 rate relative to system ticker 5x 10x

Mar 2, 2024 4:02pm André Timmermans (100) 655 posts	I am not sure that you will get what you want on RPCEmu. I used Timer1 with non-Hal machines to derive how much CPU TimPlayer used in order to limit the number of notes it was attempting to play. On RPCEmu the CPU % was just jumping between a few fixed values, indicating that the timer wasn’t updated at a very high frequency.

Mar 2, 2024 4:26pm Peter Everett (9846) 59 posts	André, I was only using the RPEmu to test a 4k colour mode plotter. Your post about extra colour modes prompted me to try and it worked a treat. It was then I noticed that the MIDI file player was going at half speed and the Synth was not putting enough samples in the audio buffer and the overall effect was absolutely awfull :-) I am actually quite amazed that the emulator provides what seems to be a very reliable 2ms interrupt. The only iritation is not being able to read the actual (emulated in this case) period that has been used.