FastTickerV

This topic has come up a lot recently in the context of MIDI and Maestro, so I decided to have a play. I think we need to make some decisions if it’s all to work.

FastTickerV seems to be documented as existing, but my experiments indicate that it doesn’t (yet?) do anything. But what should it do?

The name is vague. It suggests that it generates ticks faster than TickerV, but doesn’t say how fast. From there, I can see two possibilities:

1) There is or needs to be an interface to set its tick frequency;

2) Its tick frequency is fixed.

Either way, we need some more documentation.

There is a problem with the first option. There have been protests about the idea of claiming a timer when there aren’t many. Use FastTickerV instead. But now we’re talking about claiming a resource that is guaranteed to be unique! (My BBxM tells me it has 7 timers.)

So it makes sense to me that FastTickerV’s frequency be fixed by definition, just like TickerV’s is set at 100 Hz. I nominate 1 kHz. This fits in nicely with MIDI, which seems to be the only claimant on the horizon. Then anyone can claim it (and leave its frequency unaltered so as not to affect anyone else).

I can’t see any events on it, so is there a switch somewhere to switch it on/off, or is it simply not yet implemented? Again, if it’s a fixed frequency, it needs to be permanently enabled, otherwise multiple claimants can affect each other.

So it makes sense to me that FastTickerV’s frequency be fixed by definition, just like TickerV’s is set at 100 Hz. I nominate 1 kHz. This fits in nicely with MIDI, which seems to be the only claimant on the horizon. Then anyone can claim it (and leave its frequency unaltered so as not to affect anyone else).

What sort of practical limit is there for ticker speed? A “timespec” in C can go right down to nanosecond precision, which is probably overkill for RISC OS, but I wonder whether there might be some benefit in getting the ticker running as fast as is practical.

I would agree that millisecond precision is likely the most suitable for the sorts of things that are going to be generally used in RISC OS, and would agree that a fixed frequency is going to be the best way forward (imagine the chaos if software could arbitrarily change the frequency of TickerV¹).

¹ I think the time slewing does, but that’s small adjustments for a very specific purpose.

What sort of practical limit is there for ticker speed?

The problem is that each tick generates an interrupt, which requires a little CPU time even if no client is using the vector. I don’t think it’s possible to put up a numeric answer – and in any case it’s going to depend on the platform and the CPU clock setting.

The more accurate you want the timing, the more difficult it is to achieve. There are multiple interrupt sources, so you can’t guarantee that you have the CPU at any given instant – another interrupt routine may be running, so neither an application nor an interrupt routine of your own can guarantee to be able to access a timer.

A small point for everyone to remember is that FastTickerV running at 1 kHz gives us 1 ms resolution, but not as much accuracy as some people may expect. The frequency is never going to be exactly 1 kHz, and the interrupts are certainly not going to occur exactly 1 ms apart because other interrupt service routines may be running at the instant at which the timer trips. So let’s remember to talk about resolution rather than precision or accuracy.

So, does anyone know for sure whether FastTickerV is implemented (i.e. generating events) or not?

It suggests that it generates ticks faster than TickerV

Really? :)

That’s the best information we have. Really :)

FastTickerV is a ROL invention. It’s not implemented by RISC OS 5. Apparently OS_ReadSysInfo 6 item 22 will tell you how fast it is.

Thanks, Jeffrey.

On RO5.27, the call returned no error, but a very large negative number.

So, unless I can work out how to add FastTickerV to RO5, we won’t have it for some time.

On RO5.27, the call returned no error, but a very large negative number.

Yep. Under RISC OS 5, item 22 has always returned the address of the sound workspace.

What sort of practical limit is there for ticker speed?

The problem is that each tick generates an interrupt, which requires a little CPU time even if no client is using the vector.

The timer interrupt could be enabled/disabled by OS_Claim/OS_Release.

Perhaps something like OS_CallEvery and OS_CallAfter would be a better interface as it would allow the timer interval to be adjusted as required.

OK, people, I’ve reached the stage where FastTickerV might be useful, if it exists, works, is specified, and the specification suits the intended purpose!

(I’ve taken the source of Rick’s USB MIDI module and got it to time-tag incoming MIDI data with 1 ms resolution, and I’ve added scheduled playback of TxCommand with 1 ms resolution. My faster timer tick comes from Timer 1, if it exists.)

So: can we agree on a specification for FastTickerV, and can someone implement it please? I repeat my nomination of 1 kHz. And, since it’s a shared resource (multiple simultaneous claimants can hang off it), I don’t want it to be alterable; that would be chaos.

How does my module find out whether FastTickerV is implemented in a particular version or build of RISC OS 5? (RO 4 and 6 don’t affect me as they have a different and icompatible USB host implementation.)

I don’t want it to be alterable; that would be chaos.

Agreed. It should be fixed ¹ like the centisecond ticker is.

How does my module find out whether FastTickerV is implemented in a particular version or build of RISC OS 5?

I would say there is definitely potential for reading the fast tick rate (akin to ReadMonotonicTime), so if the SWI exists, then FastTickerV is supported.
All we need now is FastTickerV and the SWI… ;-)

Perhaps something like OS_CallEvery and OS_CallAfter would be a better interface

The problem with the plain vector vs the call SWIs is that the minimum resolution of the call SWIs is “2”. So something that would like to run every millisecond (give or take) simply cannot without directly hooking into the vector. I don’t know if this, in practice, would be an issue at ms resolution. It was at cs speeds.

As for processor time, I don’t imagine it would add up to much in reality. Every ms it would trigger the FastTickerV vector. This isn’t like a ServiceCall, it isn’t broadcast around the system. There will be a list of claimants that will be called, so only the code that actually wants to use FastTickerV will be “attached”. If nobody, it ought to return quickly.

¹ I think NetTime fiddles the high resolution clock to tweak the passage of time, but it’s a subtle thing so probably not particularly noteworthy…

MIDI 2.0 promises “tighter timing” so I wonder whether it might be worth waiting for a spec before committing to a decision here.

https://www.midi.org/articles-old/the-midi-manufacturers-association-mma-and-the-association-of-music-electronics-industry-amei-announce-midi-2-0tm-prototyping

MIDI 2.0 promises “tighter timing”

I can’t imagine this is going to be that relevant in our case, given that USB 1.1 can easily outpace any serial MIDI device (indeed one of my module’s hacks was to insert enough of a delay as not to overload rubbish hardware).

MIDI 2.0 is supposed to be backwards compatible, and it seems that the general opinion of what I’ve found online is that MIDI 2.0 will likely replace the lethargic 31250 baud serial rate with something more appropriate to modern hardware, with the old speed being a fallback since it isn’t out of the question these days to have a UART design that can auto sync to the actual baud rate in use.

it isn’t out of the question these days to have a UART design that can auto sync to the actual baud rate in use.

Just like our VAX computers used to do in the 1980’s? OK, they only went to 19200 baud…