MiSTer MidiLink

[dwmcqueen]

Is there anything else I should try or look at (or reload the files)?

[Alkadian]

Is there anything else I should try or look at (or reload the files)?

Just trying to help you out.

I have just tested it again and Striketerm works fine here. I can type the atdt command without any issues and I can connect to a few BBS's.

Just to double check. Did you select the option modem (UART mode) in the OSD menu? Ensure the settings are correct, by default you should get TCP @2400.

Try to download Striketerm again, just in case:

https://csdb.dk/release/?id=130807

Just out of curiosity, which BBS are you trying to connect to? I can try it as well.

Other than that I cannot think of anything else I am afraid.

[dwmcqueen]

I'll try Striketerm. I am using QuantumLink Reloaded (http://q-link.net/) which worked great before this change.

[dwmcqueen]

It works in STriketerm. I think the issue is the 1200 baud. If I run QuantumLink in the patched version that allows 2400 baud - all is well. If I change the setting to 1200 and run the normal QuantumLink (that only runs at 1200 baud), it doesn't work.

[patamar4]

It's been a long time since I don't use core ao486 and now it's no longer working by the SC-55 using roland's usb cable, when using the fluidsynth using soundfont works normally, is there any bug in the core? Last time I used it was at the time we implemented intelligent MPU401

[dwmcqueen]

I figured out the issue - but not sure how to solve. Changing the baud rate in the C64 menu does not change the baud rate in MidiLink.INI and it stays at 2400 baud.

I am not sure how to debug, but let me know if there is anything else I can look at.

[abbub]

So, is 'Modem' currently broken on C64? When I select it from 'UART Mode' it jumps back a screen and shows 'Connection: None' with no other options other than 'save'. Updates have been run, and the current C64 core on the sd card is: C64_20210216.rbf

[bbond007]

So, is 'Modem' currently broken on C64? When I select it from 'UART Mode' it jumps back a screen and shows 'Connection: None' with no other options other than 'save'. Updates have been run, and the current C64 core on the sd card is: C64_20210216.rbf

Have you installed this update?

https://misterfpga.org/viewtopic.php?p=17936#p17936

[dwmcqueen]

You have to do the update and it works (sort of - having issues changing the baud rate).

[bbond007]

You have to do the update and it works (sort of - having issues changing the baud rate).

I'll look into the baud rate change issue for C64

[abbub]

So, is 'Modem' currently broken on C64? When I select it from 'UART Mode' it jumps back a screen and shows 'Connection: None' with no other options other than 'save'. Updates have been run, and the current C64 core on the sd card is: C64_20210216.rbf

Have you installed this update?

https://misterfpga.org/viewtopic.php?p=17936#p17936

I had not installed that update. I have now, and it's working as expected at 2400 baud for some Sunday night telnet BBSing.
Thanks!

[bbond007]

I figured out the issue - but not sure how to solve. Changing the baud rate in the C64 menu does not change the baud rate in MidiLink.INI and it stays at 2400 baud.

MidiLink.INI no longer defines the baud rate. It is now set by the OSD.

You have to do the update and it works (sort of - having issues changing the baud rate).

With CCGMS I was able to change the modem to 300/1200/2400 BAUDs...

Looking at debug info everything seem to be working properly as far as BAUD rate change as far as I can tell...

[ryanvb]

I've been trying for 2 days to get Space Quest 1 VGA or SQ4 to work on my MT32 without generating a "Exc. Checksum Error" message on the MT32 at launch.

I do have "DELAYSYSEX = TRUE" set in /media/fat/linux/MidiLink.INI which I thought was supposed to avoid these presumably speed related issues. I'm using the official Roland USB cable and a first-gen MT32.

Does anyone know a solution for this?

EDIT:

After many more hours of testing today, here’s what worked for me for perfect MT-32 playback on Space Quest 1 and 4 (and possibly other Sierra games of that generation). This balances game performance with perfect music performance, with no buffer errors or checksum errors:

Performance settings:

56 or 90mhz CPU (30mhz gets stuttering in game, 90mhz may make animations a bit faster than acceptable so 56mhz is probably a good middle ground)
L1 cache off
L2 cache on

Only the L2 cache can be enabled, otherwise the game runs too fast and generates buffer overflows and / or checksum errors on the MT32.

Config Settings:

DELAYSYSEX FALSE in MidiLink.ini. If it’s TRUE then music starts playing late, after the Sierra logo has displayed for a while. So there’s no need to have MidiLink slow down the transmission, disabling L1 cache already seems to do that well enough.

EMM386 MUST be enabled. With just HIMEM, the MT32 checksum error occurs at startup of both SQ1 and SQ4 (regardless of whether DELAYSYSEX is set in SoftMPU or MidiLink.INI, unfortunately).

Notes:

I'm using the official Roland UM-ONE mk2 USB cable from my Mister to a first-gen MT-32. I'm the software from the Top 300 DOS games pack.

[FoxbatStargazer]

Is there any way to lower the mixing quality of MUNT to try and shore up performance on a Pi or even Mister? Midilink has a MUNT options= line but I can't find documentation anywhere about what you can put there.

[bbond007]

Is there any way to lower the mixing quality of MUNT to try and shore up performance on a Pi or even Mister? Midilink has a MUNT options= line but I can't find documentation anywhere about what you can put there.

Code: Select all

-r           : Enable reverb (default)
-n           : Disable reverb 
-m           : Manual buffering mode (buffer does not grow)
-a           : Automatic buffering mode (default)
-x msec      : Maximum buffer size in milliseconds
-i msec      : Minimum (initial) buffer size in m;
-l mode      : Analog emulation mode (0 - Digital, 1 - Coarse, 2 - Accurate, 3 - Oversampled 2x, default: 2)

[314ter]

I am failing to get Midilink to work on my rPi4. Got it to work on an Retropie installation, but I wanted something leaner, so I installed a Dietpi image on the rPi4 which is a lightweight Debian based OS.
https://dietpi.com/downloads/images/tes ... -Buster.7z
Note, I chose the 64bit (ARM v8) version.

When i try to run midilink the output is as follows:

Code: Select all

root@DietPi:/opt# ./midilink UDPFSYNTH
-bash: ./midilink: No such file or directory

After a google search I tried:

Code: Select all

root@DietPi:/opt# readelf -l ./midilink | grep interpreter
      [Requesting program interpreter: /lib/ld-linux-armhf.so.3]

The midilink program is trying to use /lib/ld-linux-armhf.so.3, but I seem to be missing this...
The same is the case for mt32d (which I copied to /usr/bin)

Is there any way to get midilink to run on this (64bit) Dietpi distro?

[Alkadian]

I am failing to get Midilink to work on my rPi4. Got it to work on an Retropie installation, but I wanted something leaner, so I installed a Dietpi image on the rPi4 which is a lightweight Debian based OS.
https://dietpi.com/downloads/images/tes ... -Buster.7z
Note, I chose the 64bit (ARM v8) version.

When i try to run midilink the output is as follows:

Code: Select all

root@DietPi:/opt# ./midilink UDPFSYNTH
-bash: ./midilink: No such file or directory

After a google search I tried:

Code: Select all

root@DietPi:/opt# readelf -l ./midilink | grep interpreter
      [Requesting program interpreter: /lib/ld-linux-armhf.so.3]

The midilink program is trying to use /lib/ld-linux-armhf.so.3, but I seem to be missing this...
The same is the case for mt32d (which I copied to /usr/bin)

Is there any way to get midilink to run on this (64bit) Dietpi distro?

Hi,

I have compiled Midilink optimised for the rpi4. Please see refer to my post below:

https://misterfpga.org/viewtopic.php?p=17150#p17150

[314ter]

Hi,

I have compiled Midilink optimised for the rpi4. Please see refer to my post below:

https://misterfpga.org/viewtopic.php?p=17150#p17150

I know, thanks, but I was the one who asked you for it at that time, and I am using your optimized compile now, to no effect I'm afraid.
I seem to be missing the correct "interpreter" (I don't have /lib/ld-linux-armhf.so.3 on my rPi4, Debian 64bit)

[dwmcqueen]

I figured out the issue - but not sure how to solve. Changing the baud rate in the C64 menu does not change the baud rate in MidiLink.INI and it stays at 2400 baud.

MidiLink.INI no longer defines the baud rate. It is now set by the OSD.

You have to do the update and it works (sort of - having issues changing the baud rate).

With CCGMS I was able to change the modem to 300/1200/2400 BAUDs...

Looking at debug info everything seem to be working properly as far as BAUD rate change as far as I can tell...

Hmmm..maybe I just need to do a clean install. It sort of takes (sometimes) but usually I am just stuck on 2400 baud.

[ericgus09]

Humm

I have done the "linux_img_update.tar.gz" update and I still cant get UART mode to show MODEM .. just defaults to NONE .. userport set to UART

Ive run update and update_all so I am current and this is a brand new SD card with a fresh setup by MrFusion ...

Edit: never mind, I did it for a second time and it finally worked .. (no idea what the deal was)

[cyb4]

I have a RPi3b (running the latest Retropie) and a Mister (everything updated) and I'm stuck exactly with what Alkadian posted (page 1, last post) on the RPi3 side when I try to play Space Quest III on the AtariST core. I get the very same messages on the RPi3 side (Starting --> UDP Synth loop
LCD: MiSTer MidiLink! BB7). Sound from Mister is still no midi and my RPI3 doesn't output anything at all. Could it be related to the USB dac I'm using on my RPi3? It works fine with emulators. Not sure whether I should buy the dac you mentioned @bbond007, just to see if that's solving the problem lol

It's really annoying, I really want to use this feature

[bbond007]

I did the original UDPMIDI.EXE in C# which was perhaps a bad choice as the MIDI API is using a lot of older (unmanaged) API's. As a result the code is pretty hacky.

The simpler approach is to redo the app in c/c++, so I have started to do that and have something working now if anyone wants to give it a try...

screen.png (311.12 KiB) Viewed 8621 times

UDPMIDI22.zip

(11.95 KiB) Downloaded 15 times

EDIT: 2.2 now supports sending.

[Shogun]

Thanks bbond007 this is working great! As a side note it hadn't occured to me to use VSTs with mister. I'll have to look into that.

[HarborSeal]

Thanks to UDPMIDI I'm able to use Virtualmidisynth, which uses the BASSMIDI library. My two preferred soundfonts work best with Virtualmidisynth/BASSMIDI and don't sound correct on fluidsynth for some reason.

[Vaelenthior]

First of all, I would like to thank bbond007 for the MidiLink service. Working with USB MIDI devices from the ao486 core has been pretty much seamless for me so far.

I've been trying for 2 days to get Space Quest 1 VGA or SQ4 to work on my MT32 without generating a "Exc. Checksum Error" message on the MT32 at launch.

I do have "DELAYSYSEX = TRUE" set in /media/fat/linux/MidiLink.INI which I thought was supposed to avoid these presumably speed related issues. I'm using the official Roland USB cable and a first-gen MT32.

Unfortunately my experience was much the same on a Rev.0 MT-32. Looking at the code that is responsible for delaying the messages in MidiLink, the timings seem to be quite different from how e.g. DOSBox implements this.

DELAYSYSEX FALSE in MidiLink.ini. If it’s TRUE then music starts playing late, after the Sierra logo has displayed for a while. So there’s no need to have MidiLink slow down the transmission, disabling L1 cache already seems to do that well enough.

EMM386 MUST be enabled. With just HIMEM, the MT32 checksum error occurs at startup of both SQ1 and SQ4 (regardless of whether DELAYSYSEX is set in SoftMPU or MidiLink.INI, unfortunately).

Currently SoftMPU with DELAYSYSEX actually gets the job done for me, no need to limit the speed of the core or enabled the delay in MidiLink. The line I use to load it is simply:

Code: Select all

SOFTMPU.EXE /MPU:330 /DELAYSYSEX

The game not waiting until all of the patches have been loaded into the MT-32 seems to be an unfortunate side effect of buffering the data on the Linux side instead of in the actual core. When using SoftMPU it displays a waiting icon and the music starts playing as the Sierra logo appears. So with a Rev.0 MT-32 using SoftMPU seems to be the preferred option for now.

[bbond007]

First of all, I would like to thank bbond007 for the MidiLink service
Unfortunately my experience was much the same on a Rev.0 MT-32. Looking at the code that is responsible for delaying the messages in MidiLink, the timings seem to be quite different from how e.g. DOSBox implements this.

I did not look at any existing code before implementing that DELAYSYSEX function. I simply added more delays to the sysex messages until the checksum errors quit occurring on my Rev0.

I have come to realize that my implementation is not without issues and apparently does not even work on all Rev0's.

Anyway, I apologize for that...

I think the SoftMPU MPU-401 implementation is based on the one in DOSBox, so maybe I'll have a look at that code.

[Vaelenthior]

I have come to realize that my implementation is not without issues and apparently does not even work on all Rev0's.

Anyway, I apologize for that...

No need to apologize, I assume you wrote this in your spare time.

I think the SoftMPU MPU-401 implementation is based on the one in DOSBox, so maybe I'll have a look at that code.

I think that's correct. Also, the dosbox-staging source code mentions this original discussion thread on the implementation: https://sourceforge.net/p/dosbox/patches/241/

Unfortunately fixing this will not prevent the issue of games starting before all the SYSEX commands are loaded into the module. It's only really a problem at game startup, but do you think there is any way to propagate the delay back to the core, i.e. have blocking IO there until the SYSEX commands are forward to the MT-32? Is there some sort of ACK message back to the core that could be delayed?

[mahen]

Hi bbond007 !

Sorry for asking this in several threads but I guess the other one is not watched anymore.

Before the update, I used to manually set a higher baudrate for the Minimig core, which did work and was very useful in my use case (I use imp3 to play random mods from the internet). Now my manual changes made to /sbin/uartmode don't seem to be taken in consideration anymore and in the Minimig OSD I only have one baudrate value.

Is there a way to work around this ? I used to be able to get my modules load twice as fast
best regards and thanks so much for your major contributions
mahen

[thorr]

Hi bbond007 - Just quoting to get your attention

I have this installed with the latest version of Raspian on a Pi 3B+ and an HDMI display. The sound is coming out the Pi instead of the display, but the desktop sound is coming out the HDMI device. Is there a way to launch midilink and make it use the HDMI device? Also, is the original tar file in this thread still what I should be using, or is there a newer version? Also, what performance settings for MidiLink do you recommend on the 3B+? This is on a new MiSTer setup using a Waveshare 11.9" screen which has an audio out jack on it that comes from the HDMI. In the Desktop, the audio device is called "HDMI". When I play youtube videos through it, it sounds choppy, so maybe MidiLink will too once it is working, and I might be better off with a DAC hat, but I want to try HDMI first. Thanks!

[bbond007]

The sound is coming out the Pi instead of the display, but the desktop sound is coming out the HDMI device. Is there a way to launch midilink and make it use the HDMI device?

Its really been a while (and I was using RetroArch), but I thought that HDMI could be set it using the raspi-config utility. For my USB Turtle Beach and HiFiBerry I remember having to manually edit a file (maybe /etc/asound.conf)

https://linuxhint.com/configure-sound-raspberry-pi/