Maestro

For IN endpoints the Upcall_RxDataPresent upcall happens when data enters an empty buffer and this happens directly from the USB interrupt – ie no callback is involved.

That’s handy. So if the UpCall client calls my FastTicker module, it would get a millisecond tick number, and could timestamp the USB input to millisecond resolution?

When you open an OUT endpoint and write to it the data is sent immediately if the buffer is empty. The data is removed from the buffer on successful transfer and if there is more data in the buffer that has arrived later that is transferred at this point.

Wow.

We are working with the same definition of “immediately”, right? Not waiting for a callback or anything?

It’s more real-time than I thought.

I would expect so.

You do need to ensure that the USB buffer is emptied when you read it in the upcall handler otherwise you won’t get an UpCall_RXDataPresent upcall when new data arrives.

Make the USB buffer 1 packet in size so that USB doesn’t wait for more packets and you get a packet as soon as it is transferred.

The buffer is read with the BufferManager functions (not swis)

By Jove.

So we could conceive of a system where Maestro reads the FastTicker timestamp, adds a bit to give itself a bit of breathing space, and then sends note commands to a scheduler, which queues them in app’s time and trots them out in real time to USB. As long as Maestro can keep the queue from emptying, we would expect to hear music played fluidly.

Some bits need filling in…

The same principle could be applied to playback through the sound system.

We could be back to the same MIDI fluidity that we had 30 years ago.

Better than what we have now, but exactly as good as we had 30 years ago.

Wish I could say that about pop music… There’s a reason I mostly listen to a streaming station that only plays stuff from the eighties…

Removed post due to better MIDI pdf has been made available

There’s a copy of the Acorn MIDI User Guide here if that helps.

And the user guide for mine which has a similar API and some expanded details…
http://heyrick.co.uk/random/usb-midi-0-01-user-guide-preliminary.pdf

Chris said.

Maestro’s had some fairly extensive changes to its interface

Alan replied.
Great work. Looks soo much better now. Huge improvement over the original version from 1988. It only took 30 years.

My thanks to Andrew and Rick for those docs.

Rick, I don’t know how you created that PDF, but !PDF on the BBxM takes about 2 minutes to render each page. I’m going to try another app tomorrow.

On reflection, the only architecture that makes sense is for the USB MIDI module to claim a timer for itself and use it directly. Rick, I’ve got some code that you’re welcome to.

Huge improvement over the original version from 1988. It only took 30 years.

:)

the USB MIDI module

I bought into a 32 bit driver for the Iyonix with the hope of using a 3rd party midi podule (Mr Gibson, I think)
It never worked, but I am wondering if recent open sourcing developments have released the source code for the Acorn podule modules, maybe they could be 32 bitted and tried even if only for the Acorn MIDI podules.
I went to a bit of trouble setting up the podule expansion on my Iyonix, and the sample Acorn SCSI driver never worked for that podule either.
Reportedly, a few podules like the dual serial work, which gives me hope.
No more Iyonix’s so probably less interest now.

Ron:

maybe they could be 32 bitted and tried even if only for the Acorn MIDI podules.

I would imagine there would be a lot of work to get the Acorn MIDI module working because:

• It will be directly accessing an IOC timer
• It will also be directly accessing the ACIA on the MIDI podule

Not to mention some differences in how USB MIDI works (packets) versus how serial MIDI works (bytestream). Thus, things like running status (a way of speeding up serial MIDI by simply discarding the “note on” bytes, they’ll be assumed if the following data isn’t a command) aren’t available. Plus fewer complications as data is sent as complete packets, no more malarky of having some types of status message appear in the middle of MIDI commands!

Of course, if you have an actual MIDI podule, then the problem for you may only be the support of the IOC timer, asides from any technical 32 bit issues. Does the Iyonix fake IOC behaviour like the RiscPC does?

No more Iyonix’s so probably less interest now.

That’s probably it. Not many Iyonixen, even fewer MIDI podules…

Dave:

the only architecture that makes sense is for the USB MIDI module to claim a timer for itself and use it directly

I’m not sure about laying claim to an entire timer. It’s the most logical way for MIDI but maybe not for the rest of the machine. Aren’t timers generally in short supply?
It looks like the HAL provides a counter that counts up at microsecond speeds (usually?). As long as that’s constant (and not arbitrarily resettable), it could perhaps be used to derive a timestamp that is millisecond accurate?

I’m not sure about laying claim to an entire timer. It’s the most logical way for MIDI but maybe not for the rest of the machine. Aren’t timers generally in short supply?

It’s what MIDI did 30 years ago, when there were only two timers available (and the OS was using one). Read the warnings in the MIDI User Guide. That said, does anybody know of any RISC OS software, other than (the OS using timer 0) and MIDI, that use a timer at all?

The question is important. I’ve been thinking about starting a thread here with “IMPORTANT” in the title, to ask the question with a reasonable chance of getting a response. csap is the other forum I can think of.

My BBxM has 7 timers, so it clearly isn’t short of them. I don’t know about the other platforms though.

The other fundamental consideration, to me, is how the MIDI module gets control, reliably, every millisecond. Hanging on the IRQ vector works. Is there any other way?

As Jeffrey (IIRC) pointed out, we really need a way to reserve timers. The old Device Claim protocol is sort-of there, but requires a Wimp task to be running. If we had to use that, the MIDI module would have to become runnable – and for that reason alone.

TL;DR: I don’t think we have a real-world problem by taking control of Timer 1 for MIDI – if it exists; and the code to find out how many timers exist can be done in a single BASIC statement.

If we were to straight 32-bit the MIDI podule code, it would of course claim Timer 1.

I remember Druck’s “TimerMod”: https://armclub.org.uk/free/timermod.zip

Is said to work on 32bit machines with “HAL features”. Worth a try?

That said, does anybody know of any RISC OS software, other than (the OS using timer 0) and MIDI, that use a timer at all?

Yes. Acorn made a module – TimeCode ? – that hijacks Timer1 for itself. I recall there was some annoyance about that back in the day, which suggests that others might have done likewise? Doesn’t IIC use the timer as well, or does it time delays from the OS timer?

My BBxM has 7 timers,

Looks like the Pi has one free running timer with four interrupt generating comparison registers, two of which are claimed by the GPU. That’ll leave one for the OS and…

https://embedded-xinu.readthedocs.io/en/latest/arm/rpi/BCM2835-System-Timer.html

we really need a way to reserve timers

Service call. Forget Wimp messages, they’re irrelevant. This stuff is going to be responding to IRQs and be running always, which means it has to be a module. A Wimp task isn’t up to the job and stands a very real chance of many missed events when paged out. A module is the only way forward, and modules have no problems with service calls. So issue one, see if it is claimed by anything. If not, you’re good to go (assuming other software obeys the same protocol).

it would of course claim Timer 1.

Or not – I don’t expect poking around in IOC registers is terribly useful these days. I mean, if that worked, so would the Wimp2 module… ;-)

If hardware timers are in shoft supply, then isn’t it possible to use one timer for more tssks? Especially as there is a fixed ratio between centisecond and millisecond, isn’t it possible to program the (now in use for centiseconds) timer to millisecond intervals, dispatch 1 ms-events everytime and centisecond ones once per ten msec-ones? Perhaps a stupid idea, but that’s how it’s done/ can be done in an emulator: one (software) counter sliced down every emulated intruction; when it becomes <=zero the interupt-software looks which event is next in a linked list, and resets the counter to the time-to-go upto the next event; from time to time the system is calibrated with another, precise timer (hardware event/system time) resulting in a multiplication factor for use with the first counter. Something similar could be done with the ARM timers, perhaps?

Druck’s TimerMod

does not use Timer1 – the help says…

On Risc PC, A7000 and Archimedes machines the 2MHz IOMD/IOC timer 0 is used. On RISC OS 5 machines the HAL counter 0 is read, which on the Iyonix is provided by the XScale 80321 and runs at 200MHz. It also works on the Raspberry Pi which has a 1MHz timer.

I also had a quick panic that my TaskUsage uses Timer1 … but although it used to many many years ago, it now just uses Timer0.

I would imagine there would be a lot of work to get the Acorn MIDI module working

All above my head but I noticed the PRM reference has Service_MIDI
I wonder why this is needed over and above loading any ordinary module.
“This service provides a variety of MIDI related notifications.”
In typical PRM style, provides more questions than answers.

Service call. Forget Wimp messages, they’re irrelevant.

If you have an app that wants to reserve a timer (or even to find out what timers are reserved), you can’t use a service call, AFAIK.

If you have an app that wants to reserve a timer

… Write a helper module, use that.

Apps are high level things. Timers are low level things. Given the swap out nature of application space, there’s no way to have an app able to be called when a timer expires. The best you can hope for is “soon” if you set a pollword.

It’s like apps drive on the left, modules drive on the right…

does not use Timer1 – the help says…

This is surely a good thing rather than a bad thing?

At the end of the day, who cares which timer is used, as long as it is properly abstracted away and gives the necessary resolution (as far as I understood so far, microsecond resolution would be good enough).

Acorn made a module – TimeCode ? – that hijacks Timer1 for itself.

The TimeCode Reader Podule was sold by Uniqueway. We have a new one in stock! It was used in conjunction with Sibelius.