The IRQ gets raised in both normal and uart mode, although normal mode supports output irqs as well.

Is it raised on every byte or only on queue full?

Also, in UART mode, do ACK's raise IRQ?

Well, the spec says on the first byte. As for ACKs, I'm not even sure they're sent back in UART mode except maybe after reset.

Could you link to the spec please? Because first byte sounds rather strange.

In interrupt mode, an interrupt occurs when a MIDI code is ready. An interrupt service routine has to be set up to retrieve the MIDI code. Reading from the Data port will clear the interrupt signal.

https://pdos.csail.mit.edu/6.828/2018/reading … oundBlaster.pdf

The MPU-401 interrupt occurs when a MIDI byte is received.

http://mercury.pr.erau.edu/~siewerts/cec450/c … und/DsSolo1.pdf

Thank you very much! The ESS one is especially useful, as for one, it clearly calls the MPU-401 queue a FIFO, and also talks about a transmit FIFO as well. Now I need to read the NS16550 UART datasheet to see how FIFO IRQ's behave there (maybe I'm misrememebring something), becaue while this is not a NS16550, it should be behaving pretty similarly regarding IRQ's.

Edit: The NS16550 datasheet says this:

In non-FIFO mode, there is received data available in the RHR register.
In FIFO-mode, the number of characters in the reception FIFO is equal or greater than the trigger level programmed in FCR.
Note that this is not directly related to LSR bit 0, which always indicates that there is at least one word ready.

I know that the MPU-401 receive status bit corresponds to the 16550's LSR bit 0, so what remains is how the IRQ works. I remember a "Programming the MPU-401" PDF saying that on receiving the interrupt, you should read until the status bit indicates there's no more data available, which means that the interrupt should occur on FIFO full, ie. on the last byte. However, the DOSBox MPU-401 code raises an IRQ on the first byte. I need to read up more on this.

Edit #2: The whole statement from the ESS datasheet:

The MPU-401 interrupt occurs when a MIDI byte is received. It goes low when a byte is read from the MIDI
FIFO and goes high again quickly if there are additional bytes in the FIFO.

I suppose that it keeps receiving bytes after one is read, and if after reading and lowering the IRQ, additional bytes are available, it immediately raises an IRQ again.

I'm not sure what the best trade-off is between being hammered by IRQs and losing MIDI traffic. Better interfaces with deeper queues can probably be periodically drained, perhaps masking the interrupt and unmasking it on a timer, without issue. I don't believe the buffers on a SB16 UART are big enough, though.

The behavior makes me presume that the UART itself has no FIFO, and the FIFO instead stands between the MIDI input and the UART, so bytes enter into the FIFO, and if there is no byte pending to read, one of them is pushed ahead and the IRQ raised. After the byte is read, the IRQ is cleared, and if there are any bytes left to the FIFO, another byte is pushed to the UART. And it is the FIFO pushing bytes that raises an IRQ rather than the UART itself. The operation makes perfect sense now.

Unless the IRQ is forced clear by the read then re-asserted by the UART logic. I'm assuming in most devices that the IRQ is flagged by an embedded MCU running a service loop and not wired logic. My incomplete understanding of the Creative MIDI hung note bug is that the 80c51 and it's limitations is at least partly responsible for that little issue.

How does the Reset command (0xFF) behave on the SB16's built-in MPU-401? The SB16 documentation linked in this thread says it generates an ACK, but is unclear on whether or not it generates an IRQ.

IIRC, the documentation is clear about IRQs when there's content in the input buffer. An ACK is just another MIDI in message, right?