Hatari midi compatibility

A forum about the Hatari ST/STE emulator - the current version is v2.0.0

Moderators: simonsunnyboy, thothy, Moderator Team

squall
Atari maniac
Atari maniac
Posts: 98
Joined: Thu Dec 26, 2013 7:20 am

Re: Hatari midi compatibility

Postby squall » Fri Mar 20, 2015 12:42 pm

Thanks for spending time investigating this.

I integrated the the latest changes and the timing seems to be really inconsistent. Setting it to 16mhz doesn't help anymore either.

I'm not sure if you've heard twinkle twinkle little star before (it's a popular children's tune), but that simple example (twinkle.mid) sounds like it's skipping notes (from listening, it's like maybe it's buffering up lots of notes and playing them all at once).

If you didn't get that example file (twinkle.mid) last time, I can upload it again.

User avatar
npomarede
Atari God
Atari God
Posts: 1070
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari midi compatibility

Postby npomarede » Fri Mar 20, 2015 1:21 pm

I made some changes when cpu is not 8 MHz, it's possible this broke midi when cpu 16 MHz. I need to check this. For now, I'd like to have it work at 8 MHz first.
I didn't try this song twinkle.midi yet.

Just in case, did you try with latest Steem 3.7 to see if it works better or similar to Hatari ?

squall
Atari maniac
Atari maniac
Posts: 98
Joined: Thu Dec 26, 2013 7:20 am

Re: Hatari midi compatibility

Postby squall » Sat Mar 21, 2015 7:36 am

I installed the latest Steem 3.7.0 and it seems to work a lot better. The outrun midi file (magical.mid) still doesn't play properly in Steem though, but the others play ok.

I also tried twinkle.mid in Steem 3.6.4 and it sounds broken, similar to what Hatari currently sounds like.

I also recorded twinkle.mid playing on my real ST and a yamaha synth if you need it for reference:

http://youtu.be/up-NHlwyq9g

User avatar
npomarede
Atari God
Atari God
Posts: 1070
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari midi compatibility

Postby npomarede » Sat Mar 21, 2015 1:50 pm

Hi
it seems the link http://wikisend.com/download/503782/example_midi.zip had a very short liftetime, it doesn't work anymore.
Can you upload it again ? Or even better, attach it to this forum, it should not be that big and will remain available.

Nicolas

squall
Atari maniac
Atari maniac
Posts: 98
Joined: Thu Dec 26, 2013 7:20 am

Re: Hatari midi compatibility

Postby squall » Sun Mar 22, 2015 12:29 am

I've attached the examples here
You do not have the required permissions to view the files attached to this post.

User avatar
npomarede
Atari God
Atari God
Posts: 1070
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari midi compatibility

Postby npomarede » Tue Mar 24, 2015 11:08 pm

Hi
I tried twinkle.mid and I can see the same overflow behaviour as you do. However, I can't see where it comes from so far as I don't know that much about composing a song with Notator.
What would be helpful is to have a song, the simplest possible, maybe only 2 or 3 notes that shows this overflow behaviour.
For example :
- 5 sec of blank at start
- 2 or 3 notes (maybe even 1 ?) separated by 1 sec.
- 5 sec at the end (so the player keep sending midi data).

From what I see in the traces, some $F8 bytes are regularly sent over MIDI when no notes are played, to ensure a constant tempo. I wonder if it could be during those blank parts that overflow increases (hence the blank part to see if we have overflow during the 5 first/last seconds too)
Would you be able to provide such a simple midi file that shows the overflow behaviour under Hatari (and not under a real ST) with as little notes played as possible ?

Nicolas

squall
Atari maniac
Atari maniac
Posts: 98
Joined: Thu Dec 26, 2013 7:20 am

Re: Hatari midi compatibility

Postby squall » Wed Mar 25, 2015 12:16 pm

I've attached a couple of simple midi files as requested:

- test1s.mid : ~5s blank, 1 note, 5s blank, 1 note
- test2s.mid : ~5s blank, 3 notes (sep 1s), 5s blank, 1 note
- test3s.mid : ~5s blank, 3 notes (sep 2s), 5s blank, 1 note
- test4s.mid : ~5s blank, 3 notes (sep 0.5s), 5s blank, 1 note

They all overflow, but the first 3 sound ok.
The last one sounds broken.

Let me know if you need any more examples
You do not have the required permissions to view the files attached to this post.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1659
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Hatari midi compatibility

Postby Steven Seagal » Thu Mar 26, 2015 10:14 am

squall wrote:I installed the latest Steem 3.7.0 and it seems to work a lot better. The outrun midi file (magical.mid) still doesn't play properly in Steem though, but the others play ok.


I've also been trying to improve Notator support in Steem, but we need to know what precisely is wrong.
Maybe the ST is connected to some synth, but Steem uses Windows Media Player or anything?
I suspect instrument selection is wrong somehow, but know nothing about MIDI unfortunately.
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

User avatar
npomarede
Atari God
Atari God
Posts: 1070
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari midi compatibility

Postby npomarede » Thu Mar 26, 2015 10:25 am

I can't tell whether Steem is wrong or not with MIDI, but there's definitely a bug in Hatari, as even the simple songs posted here created some overflow (which I can see in traces, the "key release" event is sent several times, creating the overflow, as if Notator considered it was not correctly sent).
These same songs seem to work under Steem, at least I don't see any overflow (but as I don't have correct sound under Linux with Steem+Wine, I can't tell if the sound itself is correct also).
So, whatever bad MIDI rendering there might be in Hatari and Steem, I don't think they're related to the same cause.

squall
Atari maniac
Atari maniac
Posts: 98
Joined: Thu Dec 26, 2013 7:20 am

Re: Hatari midi compatibility

Postby squall » Thu Mar 26, 2015 9:51 pm

Steven Seagal wrote:I've also been trying to improve Notator support in Steem, but we need to know what precisely is wrong.
Maybe the ST is connected to some synth, but Steem uses Windows Media Player or anything?
I suspect instrument selection is wrong somehow, but know nothing about MIDI unfortunately.


I was getting big overflows (half the bar) and the notes where stuttering (like they were playing multiple times).
I think it might be an intermittent issue as I tried it again this morning and after a cold reset it was working properly.
I'll try to see if I can get it to occur again.

User avatar
npomarede
Atari God
Atari God
Posts: 1070
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari midi compatibility

Postby npomarede » Sat Apr 11, 2015 11:51 am

Hi steven

I was trying the test1.mid posted by squall above under Steem. With 3.6.0, I get the overflow bar after the 2 notes at 5 sec and 10 sec. With 3.7.0, there's no more overflow.
Do you remember what change was needed between 3.6 and 3.7 ? Was it just some updates on the status register (and the timing for TDRE), or maybe some MFP timers ?
I still have the overflow bar under Hatari, and I can't see what creates it, although timers A and C and MIDI SR look right to me :(

Nicolas

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1659
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Hatari midi compatibility

Postby Steven Seagal » Sat Apr 11, 2015 5:02 pm

npomarede wrote:Hi steven

I was trying the test1.mid posted by squall above under Steem. With 3.6.0, I get the overflow bar after the 2 notes at 5 sec and 10 sec. With 3.7.0, there's no more overflow.
Do you remember what change was needed between 3.6 and 3.7 ? Was it just some updates on the status register (and the timing for TDRE), or maybe some MFP timers ?
I still have the overflow bar under Hatari, and I can't see what creates it, although timers A and C and MIDI SR look right to me :(

Nicolas


From memory, it is more precise timing of MIDI SR update, not MFP.
Before, it was computed in HBL, now in CPU cycles.
You can check this fact by checking or not SSE options C1 (for MIDI) and C2 (for MFP).

Which brings to mind:

squall wrote:I was getting big overflows (half the bar) and the notes where stuttering (like they were playing multiple times).
I think it might be an intermittent issue as I tried it again this morning and after a cold reset it was working properly.
I'll try to see if I can get it to occur again.


Maybe you were messing with option C1, which would explain the intermittent issue.
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

User avatar
npomarede
Atari God
Atari God
Posts: 1070
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari midi compatibility

Postby npomarede » Sun Apr 12, 2015 8:53 pm

Steven Seagal wrote:From memory, it is more precise timing of MIDI SR update, not MFP.
Before, it was computed in HBL, now in CPU cycles.
You can check this fact by checking or not SSE options C1 (for MIDI) and C2 (for MFP).

I forgot I could change this option in 3.7.0 ; but the strange thing is that without C1 and C2 test1s.mid is working without overflow. It also works if I check C1 and/or C2.
So, C1 / C2 seem to have no effect on this midi file and the overflow problem, but nevertheless test1s.mid gave overflow in 3.6.0.
Do you see the same thing ? Any idea of what could make the difference ?

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1659
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Hatari midi compatibility

Postby Steven Seagal » Mon Apr 13, 2015 8:37 am

npomarede wrote:I forgot I could change this option in 3.7.0 ;


C1 option changes emulation a lot. Don't forget there's also a 'hints' file, Notator is in it.

but the strange thing is that without C1 and C2 test1s.mid is working without overflow. It also works if I check C1 and/or C2.
So, C1 / C2 seem to have no effect on this midi file and the overflow problem, but nevertheless test1s.mid gave overflow in 3.6.0.
Do you see the same thing ? Any idea of what could make the difference ?


I checked that with current 3.7.1 build and apparently you may evade jam without option C1 in some simple cases, it's random.
But if you take a bigger file, like magical.mid or rozes.mid, it should work only with option C1 enabled.
C2 should have no effect.
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

User avatar
npomarede
Atari God
Atari God
Posts: 1070
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari midi compatibility

Postby npomarede » Mon Apr 13, 2015 12:37 pm

Hi

I still can't see what makes the difference :(
In 3.7 with test1s.mid, a note is played at 5 sec, which sends 0x90 0x3c 0x3f (note down) then 0x80 0x30 0x00 (note release). What I don't understand is that in 3.7 TDRE is sometime not empty when timer C tries to write those bytes. So, instead of sending them on each timer C call, they get sent every 2 calls. But timer C is running at approximatively 2570 cycles, so this should be ok to send 1 byte to MIDI on each call (1 byte takes 256*10 = 2560 cycle and TDRE should be cleared after approx 256 cycles). I don't understand why in 3.7 the midi byte are sometimes sent every 2 calls of timer C

In 3.6 (which has the same problem as Hatari), the note at 5 sec sends 0x90 0x3c 0x3f, but after it sends several 0x80 0x30 0x00 0xf2 0x2c 0x00 0xf8, which will create the overflow.

Nicolas

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1659
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Hatari midi compatibility

Postby Steven Seagal » Tue Apr 14, 2015 6:00 pm

I can just confirm that the "fix" (for Steem) is more precise timing of MIDI SR update.
If compile switch SSE_ACIA_MIDI_SR02_CYCLES is disabled it will jam again.
Code is simple (ior.cpp)

Code: Select all

#if defined(SSE_ACIA_MIDI_SR02_CYCLES)
/*  v3.7.0
    More precise MIDI out timing, fixes overflow with some files in Notator
*/
#if defined(SSE_ACIA_TDR_COPY_DELAY)
          else
#endif
          if(abs(ACT-ACIA_MIDI.last_tx_write_time)<ACIA_MIDI_OUT_CYCLES)
          {
            TRACE_LOG("ACIA SR TDRE busy (%d)\n",ACT-ACIA_MIDI.last_tx_write_time);
            ior_byte&=~BIT_1;  // busy
          }
          else
#endif
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

User avatar
npomarede
Atari God
Atari God
Posts: 1070
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari midi compatibility

Postby npomarede » Wed Apr 29, 2015 8:51 pm

Hi squall,
after spending quite a lot of time trying to figure where's this overflow comes from, I noticed I made all my tests using the recent WinUAE cpu core.
I just compiled Hatari to use the old cpu core (the one recommanded for STF/STE 68000 games and demos) and as far as I can see, I don't get the overflow anymore with my devel version.
Can you check if you were using "./configure" or "./configure --enable-winuae-cpu" to build Hatari in your test ?
New WinUAE cpu core has a different way to handle the exception/interrupt logic, so it's possible something is not correct yet.

Nicolas

squall
Atari maniac
Atari maniac
Posts: 98
Joined: Thu Dec 26, 2013 7:20 am

Re: Hatari midi compatibility

Postby squall » Thu Apr 30, 2015 12:29 pm

That's great news! :)

I've been using the old cpu core (I always just run ./configure and then ./make).
I've double checked the Makefile and it's using the old one correctly.

Looking forward to trying out the fixes when you push them.

Thanks,

User avatar
npomarede
Atari God
Atari God
Posts: 1070
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari midi compatibility

Postby npomarede » Thu Apr 30, 2015 1:17 pm

squall wrote:That's great news! :)

I've been using the old cpu core (I always just run ./configure and then ./make).
I've double checked the Makefile and it's using the old one correctly.

Looking forward to trying out the fixes when you push them.

Thanks for the confirmation, I will do some more tests to ensure my latest fix are correct (I sometimes saw some cases where overflow seemed to be gone and came back randomly later) and push the changes later.

Nicolas

User avatar
npomarede
Atari God
Atari God
Posts: 1070
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari midi compatibility

Postby npomarede » Mon May 04, 2015 7:19 pm

Hi
I just pushed my latest midi changes to the main dev repo.
From what I can see, the TDRE bit at $FFFC04 is now handled much more correctly, I can't see the previous overflow and the results I get for twinkle.mid and demo8.son look very similar to the video you posted above.
Also, magical.mid / outrun seems to play fine, there're some overflows from time to time, but as the music uses several channels, I guess it's normal. Can you confirm if it works like on your STF ?

Nicolas

squall
Atari maniac
Atari maniac
Posts: 98
Joined: Thu Dec 26, 2013 7:20 am

Re: Hatari midi compatibility

Postby squall » Tue May 05, 2015 1:01 pm

npomarede wrote:Hi
I just pushed my latest midi changes to the main dev repo.
From what I can see, the TDRE bit at $FFFC04 is now handled much more correctly, I can't see the previous overflow and the results I get for twinkle.mid and demo8.son look very similar to the video you posted above.
Also, magical.mid / outrun seems to play fine, there're some overflows from time to time, but as the music uses several channels, I guess it's normal. Can you confirm if it works like on your STF ?

Nicolas


Wow! Notator works beautiful now! :cheers:
It's very close to my STFM now. (I think Hatari overflows a little bit more frequently, but it's insignificant).

There's a couple of issues that's come up though:

- When resetting the midi output hangs sometimes
- I think this is due to the new TDR/TSR variables not getting reset (they also aren't initialized). If I reset those in the MIDI_Reset() it works fine
- Not sure if any of these new variables also need to be put in the memory snapshot as well

- Some other midi programs are broken again (like "M").
- I think this is due to the change in Midi_InterruptHandler_Update() where you commented out clearing of:
// MidiStatusRegister |= ACIA_SR_TX_EMPTY;
If I re-enable that line, the programs work again (Notator still works fine as well).

Thanks a lot for fixing Notator!

User avatar
npomarede
Atari God
Atari God
Posts: 1070
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari midi compatibility

Postby npomarede » Tue May 05, 2015 1:23 pm

squall wrote:
npomarede wrote:Hi
I just pushed my latest midi changes to the main dev repo.
From what I can see, the TDRE bit at $FFFC04 is now handled much more correctly, I can't see the previous overflow and the results I get for twinkle.mid and demo8.son look very similar to the video you posted above.
Also, magical.mid / outrun seems to play fine, there're some overflows from time to time, but as the music uses several channels, I guess it's normal. Can you confirm if it works like on your STF ?

Nicolas


Wow! Notator works beautiful now! :cheers:
It's very close to my STFM now. (I think Hatari overflows a little bit more frequently, but it's insignificant).

There's a couple of issues that's come up though:

- When resetting the midi output hangs sometimes
- I think this is due to the new TDR/TSR variables not getting reset (they also aren't initialized). If I reset those in the MIDI_Reset() it works fine
- Not sure if any of these new variables also need to be put in the memory snapshot as well

Great news :cheers: , I really spent hours on this, one of the problem seems to be that when the program starts, it sends midi data (even if no song is loaded) and start to compute the drift/overflow.
So, if you save memory state at this point and load it later, even with a correct midi emulation you will still get the overflow/drift that was computed before saving the state. You really need to exit/restart Notator to get an updated behaviour.
I used memory states for faster debugging, but in that case it just hides the changes you makeand gives the feeling it still doesn't work :(

Code is not finished, it was a quick update to have your result.
- I need to clear TDR/TSR timing after a reset
- I need to save/restore those variables. This is optional if you consider a memory snapshot will never be created between 2 writes to the MIDI register FFFC06 in less than ~2600 cycles (ie the snapshot will never be made when midi transfer is in progress). In that case, you can just leave those 2 variables to 0 (as done by MIDI_Reset() ), you might just get a brief overflow when restoring in that case.
In your case where you try to keep a stable compatibility in Hataroid between snapshot versions, you can skip restoring those 2 vars. But in Hatari, I will add them to the save/restore function as I want to handle all cases.

- Some other midi programs are broken again (like "M").
- I think this is due to the change in Midi_InterruptHandler_Update() where you commented out clearing of:
// MidiStatusRegister |= ACIA_SR_TX_EMPTY;
If I re-enable that line, the programs work again (Notator still works fine as well).

Thanks a lot for fixing Notator!

Test code also :) As I wanted to be sure ACIA TX interrupt didn't interfer with Notator (TX interrupt is not used in Notator), I commented this line to debug the case where TX_EMPTY bit is only updated when reading status register at $FFFC04.

Now that you confirm everything works better, I will push an update later with cleaned / definitive code.

Nicolas

User avatar
npomarede
Atari God
Atari God
Posts: 1070
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari midi compatibility

Postby npomarede » Tue May 05, 2015 8:21 pm

Hi squall,
I updated the sources to a more complete state ; can you check everything still work for you in 'Notator' and 'M' for example ?

Nicolas

squall
Atari maniac
Atari maniac
Posts: 98
Joined: Thu Dec 26, 2013 7:20 am

Re: Hatari midi compatibility

Postby squall » Wed May 06, 2015 12:52 pm

npomarede wrote:Hi squall,
I updated the sources to a more complete state ; can you check everything still work for you in 'Notator' and 'M' for example ?

Nicolas


Yep, they still work great. :)
I also tried saving and loading from memory snapshots and they seem to work fine as well.

Thanks so much!

siriushardware
Captain Atari
Captain Atari
Posts: 298
Joined: Thu Aug 21, 2014 7:55 pm
Location: UK

Re: Hatari midi compatibility

Postby siriushardware » Mon Jul 06, 2015 10:02 pm

I've been following this thread with interest but some of the discussion has been a little bit beyond the range of my technical radar.

One of my main motives for wanting to get Hatari to run is so that I can run ST Cubase 2, with MIDI support of course.

I'm running the latest stable build of Hatari V8 (Linux) but I have a problem where, if I run up Cubase and load in a .ALL file which works on a real ST, the tune plays for about a second and then 'dries up', usually leaving the target synth with a few stuck notes droning away - activity continues to be shown on the 'output' meter on Cubase, but no more hardware MIDI events are forthcoming.

The MIDI hardware I originally had this problem with was the MIDI interface built into the motherboard's GAME port, with a commercially made lead supplying the output drive / input optocoupler portions of the interface. Thinking it might be a problem with the motherboard interface I then tried a commonly available USB to cable MIDI interface and directed Hatari's MIDI output through that, with similar results - plays for about a second, then MIDI output stalls although the sequencer keeps going as though nothing has happened.

This problem is repeatable in the sense that if I back completely out of Hatari, go back in, reload Cubase. reload a file and set it playing, it starts off playing again for a short while, then stalls.

Is it likely that the fixes which were discussed earlier in this thread could fix this problem, and if so how do I incorporate them into my Hatari build?


Social Media

     

Return to “Hatari”

Who is online

Users browsing this forum: No registered users and 2 guests