Hatari midi compatibility

[squall]

Hi,

I tried running this midi software called "M" (Download at the bottom of the page: http://tamw.atari-users.net/m.htm), but there's some emulation issue with it in Hatari.

It works fine in STeem (3.6.4), but in Hatari (1.80), I just get a couple of midi control messages and then nothing else from the midi output. (Load one of the sample files and click "Start/Stop")

Do any of the Hatari authors know what could be causing the issue (or maybe have a fix for it) or have any tips on where I could start investigating the problem?

If not, I'll probably try stepping through the STeem and Hatari debuggers and try to see what it is doing.

Thanks

Edit: I started to look into this and it seems like the issue is that the program is causing the mfp irq0 (centronics interrupt) to be generated (that jumps to their playback code), but the interrupt is not getting generated in Hatari.

[squall]

I put a temporary fix into Hatari to get this working.
I'll have to check to see if this is the proper way to do it or if there's a better way. But it seems to work ok now, and it hasn't broken anything else

[Hippy Dave]

As far as I know, the centronics interrupt can only be caused by a printer (or some external hardware) that uses the printer busy line. Hatari can emulate a connected printer to capture printer data. Does 'M' use external hardware on the printer port?

[squall]

I don't think "M" used any extra hardware.

[Eero Tamminen]

Does the issue happen when you have printer port both disabled and enabled in Hatari?

[Hippy Dave]

I put a temporary fix into Hatari to get this working.
I'll have to check to see if this is the proper way to do it or if there's a better way. But it seems to work ok now, and it hasn't broken anything else

What did you do to make it work? A patch with a quick explanation would be helpful.

[squall]

@Eero Tamminen

Yeah I tried having the printer enabled and disabled and it didn't make a difference.


@Hippy Dave

I was hoping to do some tests to confirm this on real hardware first (but I need to find some time to setup my ST again).

The program seems to write to the Active Edge Register which determines whether an interrupt should occur when the signal goes from high -> low or low -> high.
I suspect flipping that value from 1 -> 0 in this specific case will cause an interrupt to be triggered.

The change I did was the following.
NOTE: This was just a quick test, so I don't think it's something that should be integrated directly into Hatari.
It's probably better for the Hatari authors who know more about how they've implemented the mfp stuff to confirm and write this properly if they want to.

Code: Select all

void MFP_ActiveEdge_WriteByte(void)
{
   ...
   
   if ( ((MFP_AER ^ IoMem[0xfffa03]) & MFP_AER & MFP_IERB & 1) )
   {
      MFP_InputOnChannel ( MFP_INT_GPIP0, 0 );
   }


[npomarede]

The program seems to write to the Active Edge Register which determines whether an interrupt should occur when the signal goes from high -> low or low -> high.
I suspect flipping that value from 1 -> 0 in this specific case will cause an interrupt to be triggered.

The change I did was the following.
NOTE: This was just a quick test, so I don't think it's something that should be integrated directly into Hatari.
It's probably better for the Hatari authors who know more about how they've implemented the mfp stuff to confirm and write this properly if they want to.

Hi,

thanks for the report, I will have a look at this. So far, AER was only emulated for the case of the timer B ; I was planning to handle it in a more generic way, so this could be the oppotunity to do it
Nicolas

[npomarede]

Hi
this is now fixed in latest Hatari dev version. Please report if it's OK for you (are you testing by redirecting the midi output to another program / sound card ?)

With this, MFP's registers GPIP, AER and DDR are now correctly handled.
This will trigger interrupt when GPIP is changed (as before), but it will also work with 'M' and 'Realtime' (same author) that change AER to trigger an interrupt.

Why he's doing that is really a mystery. From a timer A interrupt, he triggers the GPIP0 interrupt that will execute immediately when timer A completes. I don't see the point of this, better call the GPIP0 routine from the timer A interrupt (and clearing ISRA/B in case he really wanted higher MFP interrupt to be still possible).

Funny, this was fixed in Steem 2.4 in 2002, as can be seen here http://atari-forum.com/viewtopic.php?f=5&t=262&p=1085&hilit=realtime+AER#p1085

Nicolas

[squall]

@npomarede

Thanks for refactoring the mfp code. Wow, it's been fixed so long ago in STeem! And yeah, it's a strange way of doing it...

I'm testing this with the upcoming release of Hataroid which will have built-in midi output support on Android (via fluidsynth).

I'm still on the 1.70 branch at the moment, but I've back ported your changes to it and there's just one issue so far (I've also verified this problem occurs on the latest dev version (1.81) of Hatari on Linux as well).

- MIDI no longer outputs anything unless I move the mouse. This is the case with "M" and previously working MIDI programs (like EditTrack).
It's easy to test, just print the data being output inside Midi_Data_WriteByte() and you'll see it won't output anything unless the mouse is moved in these programs.

[npomarede]

I'm still on the 1.70 branch at the moment, but I've back ported your changes to it and there's just one issue so far (I've also verified this problem occurs on the latest dev version (1.81) of Hatari on Linux as well).

- MIDI no longer outputs anything unless I move the mouse. This is the case with "M" and previously working MIDI programs (like EditTrack).
It's easy to test, just print the data being output inside Midi_Data_WriteByte() and you'll see it won't output anything unless the mouse is moved in these programs.

Hi
I saw this behaviour at one point, ikbd and midi share the same interrupt in MFP, and there was an old bug in midi.c where GPIP bit was not changed in Midi_Data_WriteByte after clearing ACIA_SR_INTERRUPT_REQUEST. It was already fixed in change #5610, and now bytes are correctly sent to midi without needing to move the mouse anymore (I see the bytes if I add a printf in Midi_Data_WriteByte). Are you sure you have the latest dev version ?

Nicolas

[squall]

I saw this behaviour at one point, ikbd and midi share the same interrupt in MFP, and there was an old bug in midi.c where GPIP bit was not changed in Midi_Data_WriteByte after clearing ACIA_SR_INTERRUPT_REQUEST. It was already fixed in change #5610, and now bytes are correctly sent to midi without needing to move the mouse anymore (I see the bytes if I add a printf in Midi_Data_WriteByte). Are you sure you have the latest dev version ?

Yeah, I have the latest (I did a hg clone from the repository on a fresh folder last night when I tried out the changes).
I did some more testing and it doesn't work if I have the MIDI Emulation option enabled. It works if I disable MIDI emulation option.

[npomarede]

Hi
the change I made in midi.c was to have correct interrupts when midi was not enabled, so maybe I broke midi output.
I would need to setup my linux to emulate midi and try it ; in the meantime, can you try to comment MFP_GPIP_Set_Line_Input at line 263 in midi.c ; does it work better when midi is enabled ?

Nicolas

[npomarede]

I would need to setup my linux to emulate midi and try it ; in the meantime, can you try to comment MFP_GPIP_Set_Line_Input at line 263 in midi.c ; does it work better when midi is enabled ?
Nicolas

It seems it doesn't change anything. Just to be sure I test the same midi setup, can you give the commands you run (aconnect, fluidsynth, ...) ?
Nicolas

[squall]

I can't see MFP_GPIP_Set_Line_Input on line 263, but I tried commenting out them one by one and commenting the one on line 226 (inside Midi_InterruptHandler_Update) works partially (it has midi output ~10 secs then you have to move input a bit and it'll work for another ~10sec)

- For testing on Linux, I'm just printing a line inside Midi_Data_WriteByte():
printf("midi out: %x\n", nTxDataByte);

In the options - I enable Midi output, and set the input to /dev/null and the output to a new file

- I'm also testing on the Android build which has proper MIDI output linked directly in code.

[npomarede]

I can't see MFP_GPIP_Set_Line_Input on line 263, but I tried commenting out them one by one and commenting the one on line 226 (inside Midi_InterruptHandler_Update) works partially (it has midi output ~10 secs then you have to move input a bit and it'll work for another ~10sec)

my bad, it was the one on line 183, but I don't think it changes anything.

- For testing on Linux, I'm just printing a line inside Midi_Data_WriteByte():
printf("midi out: %x\n", nTxDataByte);

In the options - I enable Midi output, and set the input to /dev/null and the output to a new file

- I'm also testing on the Android build which has proper MIDI output linked directly in code.

But do you have a working config under linux where you actually get sound from the midi interface ? Maybe with Hatari 1.8 or 1.7 ? I can do some tests with some printfs, but I would need a test case where I'm sure the midi sound worked.

[squall]

I don't have one set up at the moment, but I can look into doing it maybe this weekend if I get some time.

[Eero Tamminen]

But do you have a working config under linux where you actually get sound from the midi interface ?

Hatari doc/midi-linux.txt tells what options there are and how to use them.

Nowadays I use mostly:

Code: Select all

sudo modprobe snd-virmidi
qsynth &
aconnectgui &
hatari -m --midi-out /dev/snd/midiC1D0 musmouse.prg

In aconnectgui, I connect first virtual midi connection output to Fluidsynth input.

If you want to do ALSA connection from command line instead of with aconnectgui, use something like this:

Code: Select all

aconnect -x
input=$(aconnect -i | awk '/client/{clnt=$2} /VirMIDI 1-0/{print clnt;exit}' | tr -d :)
output=$(aconnect -o | awk '/client/{clnt=$2} /Synth/{print clnt;exit}' | tr -d :)
aconnect $input $output


[npomarede]

@Eero, thanks for your example ; I read the doc/midi-linux.txt but it always take some time to setup this kind of things the first time where different SW/HW components are involved.
In the meantime, I was able to setup fluidsynth and use it under Hatari

@squall : with fluidsynth running, I was able to get some sound under Hatari, which is much easier to debug MIDI
Apart from the GPIP case that was fixed, it turned out some interrupt conditions were not correct/complete for the MIDI's ACIA. I made some changes and music is now OK when MIDI is ON (but when MIDI is OFF, bytes will also be handled as if MIDI was ON, to prevent programs from locking when they expect MIDI to be present).

I guess this could also fix some other MIDI programs that didn't work until then.

Nicolas

[squall]

Thanks Nicolas for working on this properly.
I've tested out the latest changes and "M" works correctly now.
All the previous midi programs I tested works the same as before as well.

The only program that doesn't work correctly is Notator, but I don't think I've ever found any emulator that works properly with it (the midi timing is broken in it). I think I saw on one of the recent STeem threads that Steven was working on fixing it STeem though.

[npomarede]

The only program that doesn't work correctly is Notator, but I don't think I've ever found any emulator that works properly with it (the midi timing is broken in it). I think I saw on one of the recent STeem threads that Steven was working on fixing it STeem though.

I tried Notator with the demo song son8, and it seemed to work ; I don't have a real MIDI HW to compare the result, but timings didn't seem to be broken.
But I wonder if Notator can handle all complex songs on a simple 8 MHz STF ? Maybe it was just a feeling, but setting CPU speed at 16 MHz looked to be more responsive to me, with less overflow in the bottom bar while playing the song.
Can you try to change CPU speed from 8 MHz to 16 or 32 (but 16 shoul be enough) ?

Nicolas

[squall]

I tried Notator with the demo song son8, and it seemed to work ; I don't have a real MIDI HW to compare the result, but timings didn't seem to be broken.
But I wonder if Notator can handle all complex songs on a simple 8 MHz STF ? Maybe it was just a feeling, but setting CPU speed at 16 MHz looked to be more responsive to me, with less overflow in the bottom bar while playing the song.
Can you try to change CPU speed from 8 MHz to 16 or 32 (but 16 shoul be enough) ?

Changing the freq from 8 to 16mhz helps in the emulator. Maybe the emulator is incorrectly triggering too many events slowing the cpu down?

I used to use Notator when I was younger, and I do know that it will overflow when sending large sysex messages, but during the song, it wouldn't overflow.

http://youtu.be/-GJF8j0sVtI

I've recorded a video (see above) of it running on my real ST and you can see there's no overflow during playback (apart from the beginning when it's sending sysex messages)

[npomarede]

Changing the freq from 8 to 16mhz helps in the emulator. Maybe the emulator is incorrectly triggering too many events slowing the cpu down?

I used to use Notator when I was younger, and I do know that it will overflow when sending large sysex messages, but during the song, it wouldn't overflow.

http://youtu.be/-GJF8j0sVtI

I've recorded a video (see above) of it running on my real ST and you can see there's no overflow during playback (apart from the beginning when it's sending sysex messages)

Great for the video, I will be able to really compare emulation with the real thing
I also think that maybe some interrupts are happening too often and slow down the cpu too much. I will give it a look, not all bits are correctly handled in midi's status register so far in Hatari, maybe Notator rely on them.
Did you try some other songs to see if the slowdown is related to the complexity of the song (number of voices, ...) or if even simple songs are sometimes not correct ?

EDIT : by the way, when you connect your ST to your midi instrument, do you use only the MIDI out port of the ST, or does notator also require to connect the MIDI in too ?

Nicolas

[squall]

- The slowdown happens on the emulator with simple songs as well.
- You don't need to connect the MIDI IN to use Notator.

I've put a few example midi files you can load in Notator if you need more test files (Load Midi file instead of Load Son file in Notator):

These all run fine on a real ST without any overflow (I haven't recorded videos of them as the instruments aren't mapped correctly to my Yamaha keyboard so it doesn't sound very good)

- twinkle.mid [twinkle twinkle little star played on piano] (really simple file that slows down in the emulator)
- sfaryu.mid [street fighter alpha ryu theme] (medium use of the midi channels)
- magical.mid [magical sound shower from outrun] (complex song which uses all the midi channels). Some of the percussion is a bit over the top in this version.

[npomarede]

Hi
I pushed a new dev version where bit TDRE of status register FFFC04 should be better handled. Can you check if this gives better results than the previous version ?

Nicolas