Re: [hatari-devel] Hatari ACIA TX interrupts

Hi Eero, thanks for the reply.

TODO:
- Most bits in the ACIA's status + control registers are currently
ignored.

That could be a problem, yes. Enabling TX interrupts involves writing bits 5/6 at least in the ACIA control register, which are not in common use in most programs (except maybe Cubase and some sequencer software).

- Check when we have to clear the ACIA_SR_INTERRUPT_REQUEST bit in the
ACIA status register (it is currently done when reading or writing to
the data register, but probably it should rather be done when reading
the
status register?).
------------

Seems important to get that right also. The status register has multiple status bits and most cases I have seen check bits in the status register directly (as opposed to fetching the state once and testing bits from a copy). This would mean the ACIA_SR_INTERRUPT_REQUEST would need tested first (of all available bits) if it clears on reading that byte, which is possible but seems a bit hazardous and unlikely.

However clearing status when writing the data register also seems unlikely, since the data register can be either read or written for different reasons - cases are too complicated..

Not sure exactly how that works but it would be helpful to know.

The documentation on ACIA and interactions with MFP is awful. We (myself + Saulot) have been using the Atari Minix, MiNT and BSD sources to piece some of it together. It seems some bits are not even listed in the common Atari Hardware Register guides (like most of the other bits in the GPIO port $fffa01, one of which can be used to assist reading from the ACIAs)

It would be good to improve that, is there documentation
somewhere how it should work?

The best documentation we have seen so far are from very old newsgroup posts from '89 and existing sources for various kernels.

It may also be properly detailed in one of the Atari books but I haven't found a good source yet.

At least MIDI playback works in all the sequencers I've tested.
I didn't try replay in one Hatari instance with recording in
another.

I have read that Cubase uses TX interrupts for transmitting MIDI out. However I don't know if it always uses that, or if it is a configurable thing.

> Setting TX interrupt enable on the MIDI ACIA seems to have no effect - no
> interrupts are generated when writing to the MIDI data port.

I'm not really familiar how this should work at the HW level,
what means "interrupts being generated" in case of writing to
MIDI port?

The ACIAs can generate interrupts for data in both directions. For the keyboard ACIA, the RX interrupts are used to pick up keystrokes, mouse movements etc. There are not many cases for writing to the keyboard ACIA, except to occasionally reset it or change its state.

For the MIDI ACIAs, RX interrupts are used to pick up incoming data in a timely manner without polling.

If you want to transmit MIDI out, you can poll for writing - which takes a lot of CPU time because the ACIAs are very slow to accept each byte - or you can use TX interrupts.

The TX interrupts pass control to the CPU each time the ACIA transmit port clears, allowing you to load another byte.

There are at least three obscure details in the use of TX interrupts (maybe more, but I know of these).

1) The ACIA config register is also the status register. So it is write-only. Enabling TX interrupts is done by writing some bits in this register. This means you need to know what the full bit pattern is for that byte in the first place, for valid MIDI communications. You can't just save the current value and mask in new state. (After a lot of digging, it turned out to be: 8 bits, no parity 1 stop bit, with a divider of 16).

2) To start the TX interrupt sequence for a MIDI packet sequence of known size, you need to enable the TX mode immediately before loading the first byte into the ACIA data port.

3) When your TX interrupt handler has no more bytes to send, you need to turn off the TX interrupt mode immediately before loading the last byte, otherwise you get a new interrupt and can't recover from it without loading a dummy byte.

This works for me on a real Falcon. Under Hatari (Windows version at least) I get no interrupts at all with TX mode enabled. It never reaches the handler. And for some reason, enabling RX mode does cause interrupts when writing each byte into the port.

Hatari's internal MIDI interrupts happen constantly at fixed
interval. Only thing that depends on reads/writes, is what is
done with MIDI/ACIA register bits.

I expect the fixed interval interrupts are host-side though? The emulated side is not fixed-interval. The MFP interrupts are time-critical responses to ACIA port events.

What happens at the code level on MIDI data reg write ($FFFC06):
0. Nothing happens if MIDI emulation is disabled, or
Hatari MIDI output file is specified, but not writable
(in which case MIDI output & interrupts are disabled)

Ok, fair enough. I did have a file mapped, but it is possible the Windows version of Hatari just treats that as 'no file' anyway, and nothing happens - this could perhaps explain why I get no interrupts since no data is presented to the port in the first place..

1. Otherwise, ACIA_SR_TX_EMPTY & ACIA_SR_INTERRUPT_REQUEST bits
are cleared for MidiStatusRegister variable

Ok. The second one is interesting but lets assume its right for now.

2. at MIDI interrupt interval:
-------------
if (!(MidiStatusRegister & ACIA_SR_TX_EMPTY))
{
/* Do we need to generate a transfer interrupt? */
if ((MidiControlRegister & 0xA0) == 0xA0)
{
LOG_TRACE(TRACE_MIDI, "MIDI: WriteData transfer
interrupt!\n");

This is the part which doesn't seem to be happening for me.

/* Acknowledge in MFP circuit, pass
bit,enable,pending */
MFP_InputOnChannel ( MFP_INT_ACIA , 0 );
MidiStatusRegister |= ACIA_SR_INTERRUPT_REQUEST;
}
MidiStatusRegister |= ACIA_SR_TX_EMPTY;
}
-------------

Looks sensible. So perhaps it is the host side interfering with that sequence then?

What "--trace midi" tells you? Does it show any errors?

I'll try it and report. I didn't have the new version when I last debugged this, and moved back to a real machine.

Cheers,
D