USB MIDI with Minimig and ao486 cores

[BBond007]

Greetings:

I recompiled the MiSTer Linux kernel to support ALSA USB MIDI sound and wrote a user-space "midilink" program to take input from /dev/ttyS1 and push it to /dev/sequencer.

I'm using a Roland UM-ONE USB MIDI adapter and a Roland Sound Canvas SC88Pro for testing.

Right I need to turn off Amiga serial PPP/Console and start the "midilink" process via SSH.

Next I'm looking into altering MiSTer menu to have an option for MIDI for serial port as well as the existing Console and PPP options. I'm looking for suggestions and advice and help there...

https://youtu.be/X4AqFJoJ_9A

[Sorgelig]

Good work!
Probably your midilink program can be a part of MiSTer binary.

Unfortunately i have no MIDI playback devices, so cannot test it myself or give any advice in this area. Once you finish, make a pull request, so i will integrate it into master branch.

[witchmaster]

Nice! MIDI input would be really nice to have also (for Octamed and oher music making programs). 486/Atari ST cores support?

[BBond007]

Nice! MIDI input would be really nice to have also (for Octamed and oher music making programs). 486/Atari ST cores support?

Support for Atari ST should be simple I'd think once FC CAST supports MIDI and serial ports. The ao486 core is more complicated as very few games and software support serial port MIDI. They expect Roland "Smart MIDI" MPU-401 hardware at port 0x0330. There is something called SoftMPU which is a TSR for DOS that may offer some compatibility. http://bjt42.github.io/softmpu/

[BBond007]

Good work!
Probably your midilink program can be a part of MiSTer binary.

Unfortunately i have no MIDI playback devices, so cannot test it myself or give any advice in this area. Once you finish, make a pull request, so i will integrate it into master branch.

Thanks,

I'd like the link to be bidirectional and make sure it works with sysex messages (used a lot with MT32) before integrate it into the master branch...

I have a lot of MIDI playback devices but not any MIDI Input devices such as a keyboard.

Maybe I can source something from the thrift shop.

I do keyboard but its USB and probably needs some special driver.

[witchmaster]

Support for Atari ST should be simple I'd think once FC CAST supports MIDI and serial ports. The ao486 core is more complicated as very few games and software support serial port MIDI. They expect Roland "Smart MIDI" MPU-401 hardware at port 0x0330. There is something called SoftMPU which is a TSR for DOS that may offer some compatibility. http://bjt42.github.io/softmpu/

@ijor said that MIDI support is already implemented but currently disabled in the FC CAST core. Oh, yes, I see why ao486 is a bigger problem.

[BBond007]

Update:

Good news System exclusive "sysex" messages work just fine.

In the beginning of the videos, before the music starts, you may notice a bunch of data being sent over the MIDI interface.

The Roland MT32 is a programmable MIDI device and what is happening at this point is custom instruments and sounds are being uploaded to the MT32.

These sysex messages also have the ability to display text on the LCD screen such as "INSERT BUCKAZOID" or "SequelPoliceAreWatchin" .

Space Quest IV : Roger Wilco and the Time Rippers --> https://youtu.be/TCDBnfUFDVU
Leisure Suit Larry 5 : Passionate Patti Does a Little Undercover Work --> https://youtu.be/i9O_ypeZxA0
Leisure Suit Larry Enhanced : Land of the Lounge Lizards --> https://youtu.be/Sa1_TUP_dVw
King's Quest V : Absence Makes the Heart Go Yonder! --> https://youtu.be/iOYR2QhLWks

[Sorgelig]

Impressive!
Too bad it requires specific hardware. Implementation of MT32 in FPGA would be good.

[Newsdee]

The MT-32 is quite pricey nowdays... so FPGA emulation would be very nice. That's probably a major project in itself, though.

[BBond007]

Impressive!
Too bad it requires specific hardware. Implementation of MT32 in FPGA would be good.

It may be possible to take a hybrid approach run Munt (Roland MT-32 emulator) in the Linux space.

I ran it on a cheap netbook/tablet thing with an external USB DAC. Sounded pretty impressive to me.

The MT-32 is quite pricey nowdays... so FPGA emulation would be very nice. That's probably a major project in itself, though.

Yes, that would be nice

When I bought my MT-32 they were inexpensive.

I think what happened is LGR and 8-Bit Guy's reviews and that's caused the price spike.

[Sorgelig]

It may be possible to take a hybrid approach run Munt (Roland MT-32 emulator) in the Linux space.

I ran it on a cheap netbook/tablet thing with an external USB DAC. Sounded pretty impressive to me.

do you know open source MT32 emulator for Linux?

[witchmaster]

(double post)

[witchmaster]

It may be possible to take a hybrid approach run Munt (Roland MT-32 emulator) in the Linux space.

I ran it on a cheap netbook/tablet thing with an external USB DAC. Sounded pretty impressive to me.

do you know open source MT32 emulator for Linux?

Would this help? https://retropie.org.uk/forum/topic/125 ... on-rpi-3/2 For Raspberry PI based on https://github.com/munt/munt.

[Sorgelig]

looks heavy

[BBond007]

do you know open source MT32 emulator for Linux?

https://github.com/munt/munt

looks heavy

Yeah, not only is Munt CPU intensive, but it requires a bunch of x11 stuff...

https://github.com/munt/munt/tree/maste ... mu_alsadrv

[BBond007]

Greetings,

Just a quick update and short video.

I've gotten my MidiLink daemon working from the MiSTer menu. --> https://youtu.be/SnfiXyCez-E

[Sorgelig]

It's interesting to check if lag is in acceptable range. I remember MIDI is dependent on it very much.

[BBond007]

It's interesting to check if lag is in acceptable range. I remember MIDI is dependent on it very much.

For simple output like I have been demonstrating, I doubt if lag makes much difference.

I've not even been able to test MIDI input yet, and for that I'm sure lag makes more of a difference.

witchmaster,

Do you have the ability to test the input and perhaps lag? I have no idea how to test lag

Testing would involve replacing your kernel, your MiSTer menu, one file in linux image (/sbin/uartmode) and adding one more (midilink).

Oh, yes, I see why ao486 is a bigger problem.

I tried ao486 with SoftMPU but that required QEMM and now that I have installed QEMM 7.5 my ao486 can't boot. So not looking as promising there...

Thanks

[Sorgelig]

I use QEMM 8 - it works.
ao486 may crash sometimes if key is pressed when it's supposed to be disabled.

[witchmaster]

It's interesting to check if lag is in acceptable range. I remember MIDI is dependent on it very much.

For simple output like I have been demonstrating, I doubt if lag makes much difference.

I've not even been able to test MIDI input yet, and for that I'm sure lag makes more of a difference.

witchmaster,

Do you have the ability to test the input and perhaps lag? I have no idea how to test lag

Testing would involve replacing your kernel, your MiSTer menu, one file in linux image (/sbin/uartmode) and adding one more (midilink).

Sure, I can test input, I will think how input lag could be measured. I'm quite sensitive to input lag myself (I play piano/synth) but I doubt the input lag is in the range of being noticeable. The lag would come from the USB polling rate I assume? What kind of lag are we talking about, a few milliseconds I guess? Regarding MIDI, the most sensitive is the beat clock that keeps devices in sync.

Just give me the necessary files and I will test it. I need the experimental version of Minimig also I presume?

[BBond007]

Sure, I can test input, I will think how input lag could be measured. I'm quite sensitive to input lag myself (I play piano/synth) but I doubt the input lag is in the range of being noticeable. The lag would come from the USB polling rate I assume? What kind of lag are we talking about, a few milliseconds I guess? Regarding MIDI, the most sensitive is the beat clock that keeps devices in sync.

Just give me the necessary files and I will test it. I need the experimental version of Minimig also I presume?

PM sent

This works with the existing core. I don't think you'd want an experimental core from me anyway. I'm more of a software guy...

I don't think USB polling rate is going to be an issue that causes any noticeable lag. If it was then all people using a USB MIDI adapter (regardless of platform) would have lag. The USB polling rate does not seem to be an issue with game controllers.

The MidiLink uses two threads (one for input and the other for output) which are normally stalled waiting for data (blocking on reads). The process itself only uses about 2% of the Linux CPU resource when playing a MIDI file. As long as the Linux system is relatively idle, the lag time will probably be minimal. As the system load increases (do to activities such as disk access) so will the lag increase as midilink will be transferring larger amounts of data at less frequent intervals. If this occurs it may be possible to minimize the lag by elevating the priority of the midilink daemon.

Thanks for testing!

[BBond007]

I use QEMM 8 - it works.
ao486 may crash sometimes if key is pressed when it's supposed to be disabled.

Sorgelig,

Thanks!

You were right QEMM 8 works for me too! I was also a version behind on ao486 as well... my bad.

QEMM allowed SoftMPU to run, which initially did not work, but I could see flashing LED on my USB MIDI adapter meaning that it was getting some data but there was no activity on my MT-32. I was fairly certain it had to be incorrect baud rate. I took a guess and tried 38400 baud and it worked!

I think SoftMPU is designed to work with the RS232 port on the Sound Canvas series (which is a round DIN like on a MAC and not db9 or db25) which I'm assuming is 38400 baud. PCs of that era may not have been able to do 31250 baud and I seem to recall that being something somewhat unique to the Amiga that it could.

SoftMPU really sends the sysex commands slowly. I think It may do that intentionally because some of the 1st gen MT-32 like mine suffer from overflow...

Space Quest III - Roland MT-32 Sound - MiSTer FPGA - ao486 DOS --> https://youtu.be/bFD3S-44z9c

[nightshadowpt]

Now this is something... great to see Midi working on the 486 core...

Just a question, why did it take forever to load the game? Is is just my memory, or is it much slower than what it should be?

[witchmaster]

Now this is something... great to see Midi working on the 486 core...

Just a question, why did it take forever to load the game? Is is just my memory, or is it much slower than what it should be?

I assume it is due to the slow transmission of sysex data to the MT-32.

[BBond007]

Now this is something... great to see Midi working on the 486 core...

Just a question, why did it take forever to load the game? Is is just my memory, or is it much slower than what it should be?

I assume it is due to the slow transmission of sysex data to the MT-32.

It did not take forever to load - just took forever to start. Also, if you think that's forever then you have never used a Commodore 64 with 1541 drive

After the game loads (and before it starts) it reprograms the MT-32 by uploading custom waveforms and other settings. I think that is SoftMPU just being cautious with the sysex commands. Once the music gets playing the MIDI data goes a lot faster. I'm impressed with SoftMPU so far.

Maybe softMPU sees that we have a "486" and adds more delays to the sysex commands then is really necessary. It also could be performing some sort of calibration loop that is just not accurate on ao486.

This should not happen with General MIDI modules, just the reprogrammable modules like the MT-32 and CM.

An option does exist to make it even slower

"The optional /DELAYSYSEX switch enables small transmission delays to prevent buffer overflow with the Rev.0 MT-32."

UPDATE:

The slowness with the sysex commands may be just related just to Sierra games (Space Quest IV took almost 4 minutes). They were notorious making stuff overly dependent on CPU speed.

For GODS I did have to use that /DELAYSYSEX SoftMPU setting with my Rev.0. It also starts pretty quickly. --> http://y2u.be/EpbSQcNVe9I