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.