Moderators: simonsunnyboy, thothy, Moderator Team
squall wrote: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
Code: Select all
void MFP_ActiveEdge_WriteByte(void)
{
...
if ( ((MFP_AER ^ IoMem[0xfffa03]) & MFP_AER & MFP_IERB & 1) )
{
MFP_InputOnChannel ( MFP_INT_GPIP0, 0 );
}
squall wrote: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.
squall wrote: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 wrote: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 ?
npomarede wrote: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
squall wrote: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 wrote:But do you have a working config under linux where you actually get sound from the midi interface ?
Code: Select all
sudo modprobe snd-virmidi
qsynth &
aconnectgui &
hatari -m --midi-out /dev/snd/midiC1D0 musmouse.prg
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
squall wrote: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 wrote: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) ?
squall wrote: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)
Users browsing this forum: No registered users and 3 guests