MidiLink 2.0 looking for testers. (no MIDI devices required)

[BBond007]

Greetings,

I have been working on MidiLink 2.0 and now I think I am happy with the features.

2.0 also supports MUNT (Roland MT-32 / CM-32) and FluidSynth (General MIDI) running on the HPS ARM core.

This is MUNT running on the FX CAST Atari ST core --> http://y2u.be/cM3YELrRRsY

Right now an (inexpensive) ALSA compatible USB sound dongle is required. I'm using a Turtle Beach device.

2.0 also supports sending and receiving MIDI data over UDP. MUNT or Roland Sound Canvas VA (or whatever softsynth) can be run on the PC.

I have a UDP MIDI listener (C#.NET) for Windows. "UDPMIDI.ZIP" (Loopmidi is also required)

The UDP option also works extremely well for networking the various cores over a "null-modem" type connection on a local area network.

Two MiSTers with ao486 running Tyrian (Christmas mode) --> http://y2u.be/u_zZQl7AWis

Sorry if I'm staring to sound like Ron Popeil, Billy Mays or the ShamWow Guy - but wait there's more...

The TCP option works like a WiFi232 adapter supporting a small subset of the Hayes "AT" command set.

ATDT - dial --> ATDT192.168.1.131:23 or ATDTBBS.DOMAIN.COM:31337 ( '*' can also be used in place of ':')
ATIP - show IP address --> ATIP
ATBAUD - set baud rate (can't auto-detect yet) --> ATBAUD9600 or ATBAUD6
AT&K0 - disable local flow control
AT&K3 - RTS/CTS bi-directional hardware flow control
AT&K4 - XON/XOFF bidirectional software flow control
ATTEL0 - disable basic telnet negotiation
ATTEL1 - enable basic telnet negotiation (default)
ATSZ - Send a file via Zmodem
ATRZ - Receive a file using Zmodem
ATMID - Play MIDI file
ATMID1 - Switch soft-synth to MUNT
ATMID2 - Switch soft-synth to FluidSynth
ATMID! - Stop currently playing MIDI
ATMP3 - Play MP3 file
ATMP3! - Stop currently playing MP3 File
ATROWS - do terminal row test
ATROWS## - Set number of terminal rows for MIDI, MP3 and Zmodem file picker
ATINI - show /media/fat/config/MidiLink.INI
ATVER - show MidiLink version
+++ATH - hang-up.

TCP Modem Demo --> http://y2u.be/lVhUU7xzhrE
LGR WiFi232 Review --> http://y2u.be/fsS0E4G310Y

Roland MT-32 supported games --> https://en.wikipedia.org/wiki/List_of_M ... uter_games
Amiga Compatible modem games --> https://www.mobygames.com/attribute/she ... d,84/p,19/
DOS Compatible modem games --> https://www.mobygames.com/attribute/she ... Id,84/p,2/
Atari ST Compatible modem games --> https://www.mobygames.com/attribute/she ... d,84/p,24/
Telnet BBS Guide --> https://www.telnetbbsguide.com/
LoopMidi --> https://www.tobias-erichsen.de/software/loopmidi.html

[Newsdee]

So it does need a USB device though? And how is the sound mixed with non MIDI music?

[BBond007]

So it does need a USB device though? And how is the sound mixed with non MIDI music?

It needs a (ALSA Compatible) USB sound device for the MUNT & FSYNTH options.

Without a compatible adapter installed those options won't be available in the system menu. You can still use the TCP and UDP options without one.

I have analog sound output on one of my MiSTers so I'm just using a cheapo mixer from Radio Shack that I bought a real long time ago. I use that and several switch boxes as I have a Roland SC-88pro, SC-55MK2, MT-32 and the USB all connected for testing.

If you have analog audio, You could probably use a simple audio Y-adapter and set the level of MUNT and FluidSynth in the MidiLink.INI to balance out the sound. At lot of DOS games also contain separate adjustments for Music and SFX volume.

Eventually, if there is interest, I hope to get it working without needing the a USB audio adapter.

In the olden days, if you had a real MT-32 and PC Sand Blaster, Amiga, Atari or whatever then you'd also run into the same mixing issue.

Karate Kid II on the Atari ST plays some of the musical notes on the PSG and the percussion on the MT-32. It sounds absolutely awful no matter how well you balance out the sound. Fortunately, I've not seen any other games that do that

[Sorgelig]

I'm thinking about adding audio support through FPGA.
I have one implementation but it requires AXI bridge. This implementation is used in my release of LXDE Linux. While it works fine, it's not compatible with run-time core reloading. Kernel will hang upon core reloading. Besides this, every core has to include audio implementation regardless the real usage.

Need some less coupled implementation like virtual audio card which will stream PCM to file. With some modification it will be possible to stream the audio to memory buffer instead which will be caught on FPGA side.

[NegSol]

Thanks BBond007 and Sorgelig for working on the midi front
I really like the idea and it is a great step for midi in ao486 games. Like most of us here - I have limited time on my hand right now but will surely look at it in the next weeks!

[bitfan2011]

MIDI support will be mind-blowing for the X68K, MSX, etc. cores once everything has had time to mature more.

[BBond007]

I'm thinking about adding audio support through FPGA.
I have one implementation but it requires AXI bridge. This implementation is used in my release of LXDE Linux. While it works fine, it's not compatible with run-time core reloading. Kernel will hang upon core reloading. Besides this, every core has to include audio implementation regardless the real usage.

Need some less coupled implementation like virtual audio card which will stream PCM to file. With some modification it will be possible to stream the audio to memory buffer instead which will be caught on FPGA side.

You lost me at "AXI bridge"
Hopefully we can figure something out. MUNT already has support for streaming to WAV file in the xwindows front end. I'm looking at that code to see how it works. I don't know if that will help.

I really like the idea and it is a great step for midi in ao486 games. Like most of us here - I have limited time on my hand right now but will surely look at it in the next weeks!

While neither the Amiga or Atari ST have a huge selection of Roland MT-32 games compared to ao486/DOS (I'm not sure about General MIDI) they only have one game in common - Space Quest III : The Pirates of Pestulon. So, together they have a pretty good selection of of games

MIDI support will be mind-blowing for the X68K, MSX, etc. cores once everything has had time to mature more.

I don't own a X68000, but I do have a real Roland MT32 and a few Sound Canvas modules and I have used then with a X68000 emulator on my PC, and yes it is impressive

I had no idea that MIDI was used on MSX. But I did find some youtube videos of people using MSX and MT-32 cool!

I have been working on a install script to make testing this easier.

The script can be run from the menu and will download and install MidiLink related Linux user-space stuff and the Linux Kernel with PCM support. The existing Kernel will be renamed to zImage_dtb.old. The only thing required which not installed is the MiSTer menu.

Also Installed (from external sources):

- Roland MT-32 and CM-32 ROMS for MUNT (CM-32 made active)
- Roland Sound Canvas SC-55 soundfont for FluidSynth

Thanks!

[Sorgelig]

You lost me at "AXI bridge"
Hopefully we can figure something out. MUNT already has support for streaming to WAV file in the xwindows front end. I'm looking at that code to see how it works. I don't know if that will help.

In simple words i need solution which will output the PCM stream into memory by just writing into circular buffer. Format is pretty much simple. for example first word is sample rate (44/48KHz), second word is buffer size, third word is current position in the buffer and then buffer itself. So if you can make this part on HPS side, then i will be able to read it on FPGA side.

[bitfan2011]

Same here, I have an MT-32 I've tested out with my MSX Turbo R GT, as well as the X68K emulators. It actually works pretty great when combined with a USB --> MIDI adapter from Roland. I route the sound from the emulated X68K game into a small audio mixer, then run the MT-32 sound into another channel and do the final mixdown. Those Konami games are pretty great, you can find a user named Superdeadite on YT who showcases a lot of this original MIDI hardware.

MSX MIDI is relatively scarce where official games are concerned, I think I have only tried out Illusion City (it sounds awesome for 8-bit). BUT I think there is a healthy music production scene using MSX hardware and people have developed trackers to use MSX with MIDI hardware? I still need to explore this area, but I have noticed many 1-Chip MSX owners have MIDI boxes attached via cartridge.

IIRC the FM-Towns has decent support for MIDI sound in games, but not at the level of the X68K. The latter is basically king of MIDI where retro gaming is concerned.

BTW have you ever seen the SEGA Saturn's MIDI hardware? In Japan, there are several titles which include a MIDI dongle for the Saturn ext. port. One package even comes with a Yamaha MIDI k/b!! Check out Saturn Music School when you get a chance. I just got the software at auction and finally received my Yamaha k/b from Japan (scored the transparent blue version!).

If I can help you test anything, please let me know. I don't have hardcore dev skills like you guys, but I know a shitload about electronic music and retro gaming :]

Sorry for rambling on...

MIDI support will be mind-blowing for the X68K, MSX, etc. cores once everything has had time to mature more.

I don't own a X68000, but I do have a real Roland MT32 and a few Sound Canvas modules and I have used then with a X68000 emulator on my PC, and yes it is impressive

I had no idea that MIDI was used on MSX. But I did find some youtube videos of people using MSX and MT-32 cool!

I have been working on a install script to make testing this easier.

The script can be run from the menu and will download and install MidiLink related Linux user-space stuff and the Linux Kernel with PCM support. The existing Kernel will be renamed to zImage_dtb.old. The only thing required which not installed is the MiSTer menu.

Also Installed (from external sources):

- Roland MT-32 and CM-32 ROMS for MUNT (CM-32 made active)
- Roland Sound Canvas SC-55 soundfont for FluidSynth

Thanks!

[Paradroyd]

The TCP option works like a WiFi232 adapter supporting a small subset of the Hayes "AT" command set.

ATDT - dial --> ATDT192.168.1.131:23 or ATDTBBS.DOMAIN.COM:31337
ATIP - show IP address --> ATIP
ATBAUD - set baud rate (can't auto-detect yet) --> ATBAUD9600 or ATBAUD6
+++ATH - hang-up.

This is really great! I'm mostly interested in the TCP modem emulation at the moment. The only gotcha I've run into is that it seems to choke with actual telnet servers (things using telnet protocol, as opposed to raw TCP), like Linux telnet servers or BBSs that expect it to answer telnet negotiations. It seems to just hang on connect in that case, probably because the server never gets the response it's waiting for.

Still, amazing progress!

[BBond007]

You lost me at "AXI bridge"
Hopefully we can figure something out. MUNT already has support for streaming to WAV file in the xwindows front end. I'm looking at that code to see how it works. I don't know if that will help.

In simple words i need solution which will output the PCM stream into memory by just writing into circular buffer. Format is pretty much simple. for example first word is sample rate (44/48KHz), second word is buffer size, third word is current position in the buffer and then buffer itself. So if you can make this part on HPS side, then i will be able to read it on FPGA side.

Sorgelig,

I have made some progress:

I compiled the snd-dummy.ko kernel module that will allows MUNT & FluidSynth to run without PCM device.

I was able using these instructions to redirect ALSA to a 48000Khz "raw" in format to file --> http://www.swview.org/blog/how-redirect ... utput-file

I created a kernel module (MrBuffer.ko) implementing a character device ("/dev/MrBuffer") and I changed the the .asoundrc to point to that instead of a file.

Right now "MrBuffer" only keeps track of how many times its been written to and disregards the actual data, however this device is where I intend on implementing the ring buffer as you described. Reading from the device the returns the number of times it has been written to.

After playing a test MIDI (ELO Xanadu) I had to killall mt32d before I could read from MrBuffer as it said "Device or resource busy", but when I did read it said that it had been written thousands of times.

I hope I'm on the right track. I'm not sure how you will be able to locate the circular buffer on the FPGA side? The buffer will be in kernel address space so maybe that helps.

MrBuffer READ --> 2 MrBuffer WRITE --> 121861 MaxWriteLength --> 512

What is a good size for the buffer?


Thanks

[BBond007]

This is really great! I'm mostly interested in the TCP modem emulation at the moment. The only gotcha I've run into is that it seems to choke with actual telnet servers (things using telnet protocol, as opposed to raw TCP), like Linux telnet servers or BBSs that expect it to answer telnet negotiations. It seems to just hang on connect in that case, probably because the server never gets the response it's waiting for.

Still, amazing progress!

I'm glad that someone is taking interest in the TCP the modem emulation.

I'm not sure about the exact cause of the telnet server problem you are having, but I think I know what you are taking about. I seem have better luck with Qmodem Pro and Procomm Plus under ao486 DOS in that regard. Some of the initial negotiations seem to make NCOMM (on Minimig core) totally stoned.

I've also changed recently behavior of the hang-up (+++ATH) command to be more compatible. Now there needs to be .9 second delay between +++ and ATH (which is more consistent with the Hayes standard) and won't cause unintended hang-ups while sending binary data. I doubt that fixes the problem you are having though.

[BBond007]

Sorry for rambling on...

No problem

NEC PC 98 also has a lot of MT-32 support if someone makes that core

[Paradroyd]

I'm glad that someone is taking interest in the TCP the modem emulation.

I'm not sure about the exact cause of the telnet server problem you are having, but I think I know what you are taking about. I seem have better luck with Qmodem Pro and Procomm Plus under ao486 DOS in that regard. Some of the initial negotiations seem to make NCOMM (on Minimig core) totally stoned.

I've also changed recently behavior of the hang-up (+++ATH) command to be more compatible. Now there needs to be .9 second delay between +++ and ATH (which is more consistent with the Hayes standard) and won't cause unintended hang-ups while sending binary data. I doubt that fixes the problem you are having though.

There are many people on twitter excited about the TCP modem emulation. It'd be great if there was eventually a way to add this to the C64 core and maybe some others (I know that the hooks probably aren't in the 64 core right now).

Is there any way to change flow control of the emulated modem? (this would normally be done with at&k on a real or Wifi modem)
I think being able to set at&k0 is necessary to make "64 Door" (a popular Amiga PETSCII terminal program) work. Otherwise, it starts up but the "modem" is unresponsive.

I've been using Term on the Amiga, Procomm Plus and even the Windows 3.1 terminal on AO486 with this with great success. Looking forward to trying The Atari ST core with it later tonight.

Again, thanks for your work on this!

[duhproject]

This is really great! I'm mostly interested in the TCP modem emulation at the moment. The only gotcha I've run into is that it seems to choke with actual telnet servers (things using telnet protocol, as opposed to raw TCP), like Linux telnet servers or BBSs that expect it to answer telnet negotiations. It seems to just hang on connect in that case, probably because the server never gets the response it's waiting for.

Still, amazing progress!

I'm glad that someone is taking interest in the TCP the modem emulation.

I'm not sure about the exact cause of the telnet server problem you are having, but I think I know what you are taking about. I seem have better luck with Qmodem Pro and Procomm Plus under ao486 DOS in that regard. Some of the initial negotiations seem to make NCOMM (on Minimig core) totally stoned.

I've also changed recently behavior of the hang-up (+++ATH) command to be more compatible. Now there needs to be .9 second delay between +++ and ATH (which is more consistent with the Hayes standard) and won't cause unintended hang-ups while sending binary data. I doubt that fixes the problem you are having though.

I am *very* interested in the TCP support. This is fantastic news and I know at least 5 or 6 people on Twitter who will be very glad to hear that. On the old MiST boards we would wire up the GPIO pins to do serial out and it worked great with Amiga and Atart ST cores. Glad to see something like this being worked on. Sure I game here and there, but will use the modem emulation more than anything else.

Thanks!

[NegSol]

I did some testing tonight - external midi devices work as normal (using MLINK-38K option) - However I could not get the USB dongle to output any beep...

I plugged in a usb sound device that I know works with linux (also dmesg shows no problems) - However, I do not get any additional menu entries. Midilink is greyed out - Only UART connection can be switched. Also on HTOP I cannot see MUNT running. Do I have to start it? How?

Are you sure your install instructions are complete - Did anyone report back positive? I would really like to test it on the ao486 as I am more familiar with this setup.

I am still amazed that external midi works like it does now - so don't get me wrong

[NegSol]

OK - I figured out that I have to unplug the Roland UM-ONE usb adaptor to get the menu entry Midilink working. Good to know...

Also I now do see that fluid synth is started when I select the option in the menu. Still no sound though.

Maybe I will figure it out

[NegSol]

Ok - I figured it out now ... I will test some of my usb devices and will look for any trouble.

I do not know were the real problem was yet. Maybe I used incorrect MT32 rom files... mt32d was not starting up. after I switch the rom files and MT32d started it began to work. Also FluidSynth works.

I switched usb sound device inbetween tests so I have to investigate what the real cause was. Anyhow - I like what I see. Big thank you!!

[NegSol]

OK So I did some testing a again. I am really impressed. The General Midi emulation on the ARM side is perfect.
MT32 is also impressive. Also I see MUNT uses more resources on the ARM side. This in combination with General Midi being nicer makes MT32 a though sell - I love it.

I used an el cheapo Realtek like sound device. 5 Euros or less from ebay. Works perfectly!

CIMG0065.JPG

Nice Y-Bridge plugged into an external midi device - ridiculous in our times but it mixes the source ... also I did the same as a teen... so this is pure nostalgia gold.

CIMG0063.JPG

Again Big Thanks to BBond007 and Sorgelig.

Please keep it up. It would be nice for every MiSTer user to enjoy.

PS: The important part is to get the MT32 roms right. otherwise I guess MUNT blocks the output device (only a wild guess but plausible).

Colonization - MT32/SC55 - Test https://youtu.be/gP3-WJfQa4o

[BBond007]

OK - I figured out that I have to unplug the Roland UM-ONE usb adaptor to get the menu entry Midilink working. Good to know...

Also I now do see that fluid synth is started when I select the option in the menu. Still no sound though.
Maybe I will figure it out

Yes, (for now) when MidiLink starts, it assumes that if you have a MIDI adapter plugged in then you want to use that overriding other options. I do this so that less menu options are required. So if Midilink has been started, unplugging the USB MIDI will reflect the changed in the MiSTer menu but won't restart MidiLink which is still trying to talk to the USB MIDI adapter. Cycling through Uartmode or MidiLink settings will cause MidiLink to be reloaded.

Also..

Sometimes when you are using MUNT and switch to FSYNTH while a MIDI is playing you'll get no sound from FluidSynth. I think this is because I've not delayed long enough after killing MUNT and its not totally gone as far as ALSA is concerned and FluidSynth get put on MIDI port 129 vs 128. I can fix this by adding a longer delay or just always assign MUNT to port 128 and FSYNTH to port 129. Cycling through the options selecting MidiLink : FSYNTH again always works for me if this happens.

Are you sure your install instructions are complete - Did anyone report back positive? I would really like to test it on the ao486 as I am more familiar with this setup.

I don't think I've left anything out of the instructions, however they are complicated and there is the possibility of someone sourcing the wrong ROMS or a broken soundfont, so I would recommend using the installer script. http://www.atari-forum.com/viewtopic.ph ... 31#p363040

PS: The important part is to get the MT32 roms right. otherwise I guess MUNT blocks the output device (only a wild guess but plausible).

I'd suggest using CM-32 ROMS. The CM-32 ROMS have addition sound effects used in some games.

The installer script will download both sets (MT-32 and CL-32) and place them in /media/fat/mt32-rom-data/mt32-roms.zip and only extract the CM32L ROMS.

It will also install a Sound Canvas SC-55 sound font.

I used an el cheapo Realtek like sound device. 5 Euros or less from ebay. Works perfectly!

The el cheapo sound cards are the ones that seem to work best. I have some higher-end stuff like a Fiio e10k and a few Creative Sand Blasters that don't seem work with the ALSA driver.

Thanks for testing

[NegSol]

I don't think I've left anything out of the instructions, however they are complicated and there is the possibility of someone sourcing the wrong ROMS or a broken soundfont, so I would recommend using the installer script. http://www.atari-forum.com/viewtopic.ph ... 31#p363040

I do not think it is overly complicated - I just find analogue audio topics hard to troubleshoot. Has to to with lack of equipment and lack of practice as most audio thinks are digital nowadays. it shows

I like the current way of handling MidiLink in the menu. It is easy enough. Also I like I can kill off the mt32d threads by simply switching to TCP. Helps whenever a note gets stuck due to unexpected reboots - All in all the sound is amazing - I dare to say that it is much like the original HW and could be better once we get the mixing done internally. It is cheaper in any case... original midi sound modules getting expensive these days.

[HappyBirthday]

I would love to jump in and start trying some of this stuff out, but after skimming through the midilink read me it's unclear to me if any hardware is required for this apart from what the title of this thread suggests. Will this work with the audio coming out via hdmi?

PS, I am super stoked about this midi stuff, thank you for your efforts @BBond007 et al

[bitfan2011]

I would love to jump in and start trying some of this stuff out, but after skimming through the midilink read me it's unclear to me if any hardware is required for this apart from what the title of this thread suggests. Will this work with the audio coming out via hdmi?

PS, I am super stoked about this midi stuff, thank you for your efforts @BBond007 et al

It would be pretty cool to actually implement the Roland MT-32 using FPGA, it looks like they are doing this?
Also, it would be great to be able to real USB-->MIDI adapters like the ones from Roland.
If Mister can achieve both, wow

[NegSol]

I would love to jump in and start trying some of this stuff out, but after skimming through the midilink read me it's unclear to me if any hardware is required for this apart from what the title of this thread suggests. Will this work with the audio coming out via hdmi?

For external midi modules to be connected you will need a usb to midi adapter cable. For internal midi emulation using soundfonts on the arm/linux side you only need an alsa sound device. Basically a mini usb sound card in stick form is enough to listen to mt32 or GM sound. Not more the 5 Euros .. see picture above. As this usb sound device has it own analog audio out you can listen to it via speakers or headphone or by mixing it with other sources. So you could mix it with the IO board analog or digital output. Not really necessary but for games using both in parallel it makes sense.

It would be pretty cool to actually implement the Roland MT-32 using FPGA, it looks like they are doing this?
Also, it would be great to be able to real USB-->MIDI adapters like the ones from Roland.
If Mister can achieve both, wow

Real usb to midi adapters are still supported. Also MUNT is working quite well. FPGA MT 32 would bring little benefit imho as midi device were always separated from the computer anyway.

[bitfan2011]

Super COOL

I'll have to give it a go with my adapter and real MT-32, but not sure which of the current cores have games w/ MIDI support. But it does make the future of the X68K core very exciting inDEED. Plus, producers of chiptunes and music in general will appreciate.