Hardware programmable timers

[Dave]

MIDI is a 'bit' different, in that it can be used as an 'immediate event' serial stream - a 'note on' code received is immediately played.

That's the trap I'm in, yes. MIDI events are acted on immediately.

A MIDI file measures time in ticks. The file contains a header that establishes the speed of the music, and configures how many ticks divide up a quarter note. This is a Tempo metadata event. Next it sets up Time signature event, eg: 3/4, 4/4, 7/4* etc.

The playing of the file first configures the tick rate, then retrieves MIDI groups from the file. A note or action (master volume, key velocity, various effects or etc) can contain several bytes establishing the note, how and where it is to be played. Actions that happen simultaneously are grouped together. Subsequent events are indicated by the number of ticks separating the events.

A MIDI beat clock is used to synchronize multiple MIDI instruments. This is 24 ticks per quarter note. 96 ticks per beat. 384 ticks per 4-beat bar. At 120 beats per minute that's 192 ticks per second. Anyone who's used a digital logic analyser knows you need to have at least 4-5x the frequency as your sample rate to the fundamental frequency of your sampled signal. This is true in the inverse. A 192 Hz ticker suggests a 960 Hz service interval in a system where other services also make time demands. Faster is better, to a point. Allowing for the music playback and screen updates to scroll displayed music/patterns, plus other events like capturing external MIDI, keypresses simulating keyboard inputs, etc. all need to be serviced in priority order during the timeslice. If time runs out and the next tick occurs before everything's done, the lowest priority elements - anything non-playback or composition related - need load shedding. Thus a new tick with events the events happen first. If there are no events in the period - which is known ahead of time because we can see the future - we can do the more mundane tasks like updating the sequencer display, etc.

With this background, a 50 Hz poll that's also doing other things is insufficient. A fixed fast interrupt may or may not be appropriate. That is affected by many factors: CPU/bus speed, tick frequency, how much MIDI data you can transfer within a tick**, etc. The last item becomes an issue because situations arise where I may need to play notes to gthe MIDI device while also checking MIDI IN and parsing that to see if it needs to be directly retransmitted for live playback, or live plus record data to timeline, or if the packet bytes are non-audio data (config/tick/etc.)...

So here I am working out a programmable interrupt timer that's simple to implement, use, and is flexible enough to meet more than just my own needs.

* Solsbury Hill by Peter Gabriel is a really great example of 7/4 time. Catchy and fun. Give it a listen and get a feel for how it throws you off-kilter to match the theme of the song. Most people have a sense of being unsettled but can't put their finger on why.

** MIDI serial runs at 31250 bps, with 8 bit data start and stop bits. This gives a theoretical 3125 bytes/second. The average playback MIDI message is 3 bytes. Typical peak throughput on serial MIDI is..... 960 characters per second. 1.042 milliseconds per byte or 3.126 milliseconds per typical note. In this environment, +/-20 ms is a 3 tick range, and +/- 70ms is 10 ticks. Our ears can hear that. We determine sound direction using sub-1 millisecond phase shifts. Ears are amazing!

[Popopo]

...
For clarity, the chip I am using is the SAM2695. It's a very powerful single chip MIDI synthesizer used in the Yamaha TX7. There are two makers of this, and I am using the French "Dream" version which correctly implements General MIDI, chorus/echo/reverb/pan effects, and XG50 secondary sound set.

Datasheet: https://docs.dream.fr/pdf/Serie2000/SAM ... AM2695.pdf

Wonderful.
Great sound. Mine is more modest.
I will read the datasheet to understand how are you going to integrate into the QL system.
Amazing project and OpenSource thank you for your work!
VIDEO DEMO of the SAM2695

[M68008]

A MIDI beat clock is used to synchronize multiple MIDI instruments. This is 24 ticks per quarter note. 96 ticks per beat. 384 ticks per 4-beat bar. At 120 beats per minute that's 192 ticks per second. Anyone who's used a digital logic analyser knows you need to have at least 4-5x the frequency as your sample rate to the fundamental frequency of your sampled signal. This is true in the inverse. A 192 Hz ticker suggests a 960 Hz service interval in a system where other services also make time demands. Faster is better, to a point.

The 'beat' in BPM is a quarter, not a beat, so if you wanted 24 ticks per quarter note, at 120 bpm that would be 48 ticks per second.

In the end, what is acceptable depends on the ear more than theoretical numbers and one should experiment.

Btw, MIDI has "running status", so a "note on" event can be just 2 bytes.

[Dave]

The 'beat' in BPM is a quarter, not a beat, so if you wanted 24 ticks per quarter note, at 120 bpm that would be 48 ticks per second.

In the end, what is acceptable depends on the ear more than theoretical numbers and one should experiment.

Btw, MIDI has "running status", so a "note on" event can be just 2 bytes.

This is a default in many sequences packages and synths. Absolutely. I use different defaults from a couple of trackers/sequencers that are used for more.... busy.... content.

This will be adjustable in the software. Too fast beats can consume available bandwidth.

[Dave]

I have spent some time incorporating the discussion and feedback. I am making some changes and expansions in reaction to what I have learned.

Instead of the register being a divider, it would be a counter. This would give much finer timing control than a divider where each value is half the previous interval. The original system proposal becomes more coarse the smaller the divider value.

A system with this interrupt handler added would by default have a CPU that replaces the 68008, even if it's just a 68SEC000. Therefore, IPL0 and IPL2 will be separated. This opens up more than just level 5 interrupts. QDOS/Minerva/SMSQE all ReTurn from Exception on anything not 2 or 7 if auto-vector is used.

So I have the choice of either using a vector and bypassing the OS, or editing QDOS and Minerva binaries to auto-vector on other interrupt levels.

The first option requires that my expansion respond to the CPU's IACK response by placing a vector number on the data bus then asserting /DTACK. The first and second options both require the interrupt being asserted until it is responded to, and then released. This does require different logic depending on whether a manual- or auto-vector was used.

Mainstream interrupt timers have multiple registers for counters, dividers, resets, you name it. I would like to keep this interrupt timer as simple and as foolproof as possible.

So, would this have enough traction to make it worth editing QDOS and Minerva versions to support other interrupt levels (fairly straightforward I am told) and have that written into SMSQ/E, or should I avoid that and manually vector?

What do you think?

[Peter]

After the recent experience with Minerva 1.98j4, a dependency on Minerva/QDOS ROM changes doesn't seem a good idea to me.

Anyway it is probably better to first bring the sound card into existence at all, so there is practical relevance.

[Dave]

It exists and functions. That’s how I know the 50 Hz timer is inadequate. It’s not the only item. I need a much lower latency interrupt for my SATA SSD interface too. That works but could be an order of magnitude faster using the existing driver. It’s not just a matter of having a faster interrupt, but of having the handler code be the only code called instead of the general purpose multi-function handler being called.

[janbredenbeek]

The L7 interrupt vector can be redirected via the MT.TRAPV trap. One caveat: this is on a per-job basis, the vector itself isn't modified as it is in ROM.

If you want a device driver to respond to an interrupt, link your service routine into the external interrupt linked list and use the EXTINTL line - of course this uses the L2 system interrupt and comes with an overhead (you're not bound to the 50Hz frame interrupt, but it's shared with all peripherals).

Otherwise, there is no documented way to allow for the interrupt vectors to be redefined. But if you're going to use alternative hardware anyway, it's likely that the vectors are in RAM and hence can be modified. Which already happens when using (S)GC, and is even a requirement for SMSQ/E.

[Peter]

It exists and functions.

Any chance to post a picture?

I need a much lower latency interrupt for my SATA SSD interface too.

The external interrupt handling does not add much overhead. If a block device can not live with that, there is (very likely) insufficient system performance anyway.

[Dave]

Any chance to post a picture?

Any chance to post a timing chart for the Q68 extension bus? HD/ED floppy interface seeks SMSQ/E DP8473V floppy driver remapping to extension bus and details for logic.

The external interrupt handling does not add much overhead. If a block device can not live with that, there is (very likely) insufficient system performance anyway.

This is my experience with slower devices, yes. When a storage device can handle multiple thousand sectors/second the math changes. Especially when the CPU is anything faster than a 7.5 MHz 68008.