SCUMMVM

[SpotAnime]

Curious how you did this. If I edit the sh file I can only change SCUMMVM_HOME_DIR, which would impact where the ScummVM files are located, right? How would I just point the games folder to my NAS?

SCUMMVM_HOME_DIR specifies where the scummvm bin and libs are installed. You don't need to change it.

ScummVM games can be located anywhere you want. When you add a game, just navigate to wherever the NAS is mounted within the filesystem...

ie. /media/fat/NAS/Games/ScummVM

If you wanted to relocate all your existing games to the NAS without readding, you could use a symlink. https://linuxize.com/post/how-to-create ... n-command/

Code: Select all

ln -s /media/fat/NAS/Games/ScummVM /media/fat/ScummVM/GAMES

Hope that helps...

Oh yeah, totally. Thanks! It turned out my ScummVM directory on my NAS wasn't getting mounted, but then a restart of my MiSTer got it to show up. Turned out after that, when I went to rerun the installer, all files got installed on the NAS without me realizing, causing all sorts of different issues until I realized what had happened. Folks, let this be a cautionary tale of creating a NAS directory of the same name as local. I though this directory mapping only applied to official cores, but apparently it's for all same-named directories.

I encountered another problem when I was deleting the ScummVM directory from local to reinstall (I was just trying to ensure I had a clean local install of all ScummVM files on my SD card) - there are some hidden files in the pulse subdirectory which are .runtime files preventing me from deleting the directory, even after hard reboot. Does the ScummVM installer add anything to user-startup.sh?

Now I have to figure out the best resolution for full screen. My stupid TV either windowboxes ScummVM at 720p+ resolutions, or automatically stretches to fullscreen at 640x480. What does the -r option do in video mode?

[bbond007]

Does the ScummVM installer add anything to user-startup.sh?

(MiSTer) ScummVM does not install anything outside the ScummVM directory with the exception being launch Scripts.

To remove ScummVM completely from MiSTer (assuming you installed it to the default location) issue the command:

Code: Select all

rm -rf  /media/fat/ScummVM  /media/fat/Scripts/ScummVM_*

What does the -r option do in video mode?

Code: Select all

vmode -r 640 480 rgb16

(r)esolution

[HerrBerzerk]

Can someone please sum up the steps needed to get PI-MT32 sound working with scummVM? What do I have to install and what do I have to select in the options of scummvm?

I once had it running some months ago but it is not working anymore and I really tried and did search but I don't get it anymore...

[bbond007]

I once had it running some months ago but it is not working anymore and I really tried and did search but I don't get it anymore...

viewtopic.php?p=47169#p47169

skip the replacement of menu.rbf as that is no longer necessary...

[Malor]

One good reason not to do MIDI on the FPGA itself is because real MIDI devices are generally driven serially and aren't that latency-sensitive. They're effectively separate little boxes (even as a plugin daughterboard like the Waveblaster modules), so doing it on the MT32-Pi makes a great deal of sense. And then, unlike with real synths, integrating the audio output back into the overall audio stream is trivial. It's even sent digitally so that it's perfect.

If you're running ScummVM in software on the Linux side, then the FPGA is going spare and probably could be a MIDI device, but someone has to be interested enough to actually make one. With the MT32-Pi already being there, and with the primary consumer of MIDI being the AO486 core, which has no room left, that doesn't seem like a very attractive project for most FPGA devs.

[roc]

First of all, thanks for the scummVM implementation on the MiSTer, which is a lot of fun.

Only if feasible, would it be possible to compile the 2.6 version?

I am asking this, because the ScummVM team somehow "improved" the saves format on the 2.6 and the upcoming 2.7.

The result is that savefiles on the 2.6, cannot be used on 2.5.1 or earlier. They return a "Invalid version" when trying to load the savefile.

Only if feasible and when time allows

[bbond007]

The result is that savefiles on the 2.6, cannot be used on 2.5.1 or earlier. They return a "Invalid version" when trying to load the savefile.

Well, that is a bummer... Hope they don't find it necessary to do that again...

I have updated the repo to include:

• ScummVM 2.6.0

• ScummVM 2.6.1

• ScummVM 2.6 (pre 2.7.0)

• ScummVM 2.6.0 Unstable

• ScummVM 2.6.1 Unstable

• ScummVM 2.6 Unstable (pre 2.7.0)

I also redid the builds of the following (with a newer cross-compiler toolchain than I previously used):

• ScummVM 2.5.0

• ScummVM 2.5.1

• ScummVM 2.5 (pre 2.6.0)

• ScummVM 2.5.0 Unstable

• ScummVM 2.5.1 Unstable

• ScummVM 2.5 Unstable (pre 2.6.0)

I decided just to rebuild all these branches today, which took a while even on my 10th gen i7. I did have the CPU set not to turbo so the the laptop did not sound like a Harrier jump jet landing on the roof.

MIDIMiester (mt32-pi) support will now be installed to /media/fat/linux/MIDIMiester by default.

It is only 8k, so I did not bother to make it an optional thing.

So, anyway, hope that works for you...

[roc]

Thanks a lot !

[bbond007]

just FYI:

A user opened a issue on Github (https://github.com/bbond007/MiSTer_ScummVM/issues/28) concerning Longest Journey & Zork Nemesis regression on the compiles I did with the new toolchain.

Anyway, support for a few engines were excluded because freetype2 was failing to be detected by the configure script.

While I think the ResidualVM engine (Longest Journey) runs too slowly on the HPS to be enjoyable, I went ahead and fixed the problem...

So EXEs 2.5.x - 2.6.x (including unstable) were all updated today...

Still, I think it might be a good idea to exclude engines (like ResidualVM) that perform poorly in the future.

Zork Nemesis locks up on me using the old 2.5x builds as well as these... Perhaps I should source a new copy as this person claims it did work

[held]

Code: Select all

vmode -r 640 480 rgb16

This command seems to hang for me every time I run it... any idea whats up?

[bbond007]

Code: Select all

vmode -r 640 480 rgb16

This command seems to hang for me every time I run it... any idea whats up?

do you have

Code: Select all

fb_terminal=1

set in MiSTer.INI?

[Neocaron]

just FYI:

A user opened a issue on Github (https://github.com/bbond007/MiSTer_ScummVM/issues/28) concerning Longest Journey & Zork Nemesis regression on the compiles I did with the new toolchain.

Anyway, support for a few engines were excluded because freetype2 was failing to be detected by the configure script.

While I think the ResidualVM engine (Longest Journey) runs too slowly on the HPS to be enjoyable, I went ahead and fixed the problem...

So EXEs 2.5.x - 2.6.x (including unstable) were all updated today...

Still, I think it might be a good idea to exclude engines (like ResidualVM) that perform poorly in the future.

Zork Nemesis locks up on me using the old 2.5x builds as well as these... Perhaps I should source a new copy as this person claims it did work

I haven't tried SCUMMVM with the OC options yet, I'm pretty sure it would boost significantly performances in these cases no?

[held]

Code: Select all

vmode -r 640 480 rgb16

This command seems to hang for me every time I run it... any idea whats up?

do you have

Code: Select all

fb_terminal=1

set in MiSTer.INI?

Thanks, but it was Linux Image corruption on my part

However Bluetooth controllers seem flaky in ScummVM.
Mouse-pointer and menu buttons do not work after a reconnect.

[bbond007]

However Bluetooth controllers seem flaky in ScummVM.
Mouse-pointer and menu buttons do not work after a reconnect.

And I assume this does not happen in the OSD menu or cores?

I don't have a bluetooth adapter for my MiSTer to test.

Does anyone else use Bluetooth with the ScummVM builds and have the same issue - or no issue?

[held]

Correct, the controller works fine in all other cases.

Some more info:
Some buttons work, it think its only the action button.
One button (the 'x') works and it does pause/unpause.
Other buttons work but do not have the desired effect, or do nothing when pressed.
Other buttons don't do anything,so nothing happens when pressing them.

So I think the mouse/key mapping for ScummVM has to be reapplied after a reconnect.

edit: ^^

[held]

I don't have a bluetooth adapter for my MiSTer to test.

You can also trigger it with a wired controller, these are the steps to reproduce for both:

Wired controller:

Code: Select all

1. Start ScummVM, wait until its loaded.
2. Disconnect wired controller
3. Wait a couple of seconds, just in case.
4. Reconnect cable
5. Push some buttons and try to navigate cross-hair

Wireless controller:

Code: Select all

1. Start ScummVM, wait until its loaded.
2. Wait until Bluetooth timeout occurs (in my case 2m)
3. Reconnect wireless controller
4. Push some buttons and try to navigate cross-hair

[held]

Is it possible to hardcode the buttons for the MiSTer?
It does gets its default values from somewhere, and would solve this problem.

[bbond007]

Is it possible to hardcode the buttons for the MiSTer?
It does gets its default values from somewhere, and would solve this problem.

Maybe here? "keymap_"
https://docs.scummvm.org/en/v2.6.1/adva ... _file.html

Honestly, its never even occurred to me to use anything other than the mouse/kb with ScummVM...

[Akuma]

I use a PS5 controller for all point and click games and they work fine until the Bluetooth times out. So I think its ScummVM that is the problem, not bbond007's builds. (and I've tested a few).

@held:
Only the left analog stick and the gui/menu button don't work, the rest of the keys seem to work fine.

[bbond007]

I use a PS5 controller for all point and click games and they work fine until the Bluetooth times out. So I think its ScummVM that is the problem, not bbond007's builds. (and I've tested a few).

So, you seen this behavior (with ScummVM) on other platforms too and not just MiSTer?

[Akuma]

No not beyond the MiSTer, I think I jumped to a conclusion too soon. Just tested on a Linux rig and it would not accept the controller at all. One of the similarities is the left analog stick on the PlayStation controllers. Did anyone test any other controllers? because that might bring more clarity to this issue.

[Schlummi99]

Hello everyone! I don't have a sound in any of the games. I am using a digital board with an HMDI to VGA converter. Have tried many different settings. Can anyone help me With another core, the sound goes.

[HerrBerzerk]

Hi, I please need help with the sound output for a mt32-pi device. I fiddled around with it the whole evenening and don't get it working with Scum. It is working fine with DOS300 games.

I downloaded "Install_ScummVM.sh" from Github and executed it --> Scumm 2_6_1 was installed.

I added a bunch of games that are on an USB-HD connected to Mister directly.

I tried mostly with both Indiana Jones adventures and Larry 5 but I did not get mt32 or general-midi to work. I did not see data going from the mister to the external PI-device. Speach and FM-Sound worked fine.

I tried every setting under Audio, Midi and MT32 I could think of, mostly selecting MidiMeister (Alsa) in dozens of combinations but without success.
Maybe it is just a settings thing on ScummVM? What are the exact settings I need to select for external MT32-Pi to work?

Or any other ideas? Everything working for you?

Thank you very much!

[HerrBerzerk]

Today I reinstalled the SD-Card of the PI with the MT32 install script on Mister. Still no Sound on Scumm No idea left...

[bbond007]

Today I reinstalled the SD-Card of the PI with the MT32 install script on Mister. Still no Sound on Scumm No idea left...

I can help you debug it....

First question, the mt32-pi is connected via the USER port? (short USB3 cable) is the only case you'd use MIDIMeister.

If your mt32-pi was connected via USB MIDI you'd use the device for that - for example UM-ONE.

So if that is not the issue, then we need to verify MIDIMeister is getting data. We already know its loaded as it appears in the ScummVM menu as you have stated.

First step, and this seems counter-intuative, but we'll disable MIDIMeister by going into /media/fat/linux and renaming it to something like _ MIDIMeister. Then launching it over SSH manually so we can monitor the output debug info. Your MiSTer must be connected to your home network.

Before launching ScummVM, SSH into your MiSTer HPS Linux and type:

Code: Select all

mv /media/fat/linux/MIDIMeister /media/fat/linux/_MIDIMeister
/media/fat/linux/_MIDIMeister

If you have never used SSH and use Windows then get Putty.exe. The MiSTer default username is root and the super secret password is "1".

Launch ScummVM from the OSD menu.

Ideally you'll see some raw MIDI data from _MIDIMeister. Should look like long stream of hexadecimal digits.

If not then it could still be ScummVM options - or potentially the game you sourced. For example FM Towns versions of Lucasfilm games don't support MIDI.

[HerrBerzerk]

I can help you debug it....

That's very nice of you, thank you.

First question, the mt32-pi is connected via the USER port? (short USB3 cable) is the only case you'd use MIDIMiester.

So if that is not the issue, then we need to verify MidiMiester is getting data. We already know its loaded as it appears in the ScummVM menu as you have stated.

My Hardware is the Antonio Villena version with the DB 9 Port. I have two different MT32-pi versions, the first one is a Pi3b connected with a short USB-Cable to an USB-DB9 adapter, the second one is a PiZero with a DB9 Cable to DB9 Port.

Let me state that both Mt32-Pi are working fine with the PC486 Core, e.g. with the Dos version of Indina Jones: Fate of Atlantis.

Also, the Pi3b with usb to db9 was working in the past with scummVM 5.1. That must have been around April or May last year, short after the release. I was just not using it for a period of time and now I don't get it to work anymore.

First step, and this seems counter-intuative, but we'll disable MIDIMiester by going into /media/fat/linux and renaming it to something like MIDIMiester. Then launching it over SSH manually so we can monitor the output debug info. Your MiSTer must be connected to your home network.
Before launching ScummVM, SSH into your MiSTer HPS Linux and type:

Code: Select all

mv /media/fat/linux/MIDIMiester /media/fat/linux/_MIDIMiester
/media/fat/linux/_MIDIMiester

If you have never used SSH and use Windows then get Putty.exe. The MiSTer default username is root and the super secret password is "1".
Launch ScummVM from the OSD menu.
Ideally you'll see some raw MIDI data from _MIDIMiester. Should look like long stream of hexadecimal digits.
If not then it could still be ScummVM options - or potentially the game you sourced. For example FM Towns versions of Lucasfilm games don't support MIDI.

Well, I renamed it to _MIDIMeister (I'm a little bit confused that you type midimIEster, I guess typo) and started it over SSH while staying connected.

Then I started ScummVM 6.1 and tried MI2 and Fate of Atlantis, but I did not see any data. MidiMeister was selected in all three audo settins (audio, midi, mt32).

I did not see any Data in the SSH-Session:

Code: Select all

/media/fat/linux# ls
7za		  glow	     MidiLink.INI   pdfviewer	 soundfonts  u-boot.txt_example  _wpa_supplicant.conf
bluetooth	  lesskey    _MIDIMeister   ppp_options  uboot.img   updateboot		 wpa_supplicant.conf
gamecontrollerdb  linux.img  mt32-rom-data  _samba.sh	 u-boot.txt  _user-startup.sh	 zImage_dtb
/media/fat/linux# _MIDIMeister 
_MIDIMeister: /lib/libasound.so.2: no version information available (required by _MIDIMeister)
MIDIMeister $0004h BBond007
Setting task priority --> -20
Setting /dev/ttyS1 to 31250 baud.
Entering main loop...

That was all I got... Problems with this Version number?

Thanks for your help,
Frank

PS: This is shown when I quit ScummVM:

Code: Select all

Connected to Alsa sequencer client [128:01
ALSA client initialized (130:01
User picked target 'k6-de' (engine ID 'sci', game ID 'k96')...
Looking for a plugin supporting this target... SCI [all games]
Running King's Quest VI: Heir Today, Gone Tomorrow (DOS/German) resource.000: 267753992c56a0c7a08d6a5077c895, 7863324 butes. resource. nap: a362063318eebe?6423b1a9dc6213e1, 8703 butes. resource.msg: 75629762155d6943621c6f6fb763c3, 282822 bytes.
Patching 106. TEX failed
- resource tupe mismatch
Patching 107. TEX failed - resource tupe mismatch
Connected to Alsa sequencer client [128:01
ALSA client initialized 130:01
Killing MIDIMeister.
Exiting program signal --› "Terminated
Press any key to continue

[bbond007]

Well, I renamed it to _MIDIMeister (I'm a little bit confused that you type midimIEster, I guess typo) and started it over SSH while staying connected.

My mistake. I'll correct that. MIDIMeister is correct.

Code: Select all

/media/fat/linux# _MIDIMeister 
_MIDIMeister: /lib/libasound.so.2: no version information available (required by _MIDIMeister)
MIDIMeister $0004h BBond007
Setting task priority --> -20
Setting /dev/ttyS1 to 31250 baud.
Entering main loop...

That was all I got... Problems with this Version number?

No, that all looks good except for the missing raw MIDI output...

The problem must be with the game itself or ScummVM global or per-game config settings...

Let me state that both Mt32-Pi are working fine with the PC486 Core, e.g. with the Dos version of Indina Jones: Fate of Atlantis.

Also, the Pi3b with usb to db9 was working in the past with scummVM 5.1. That must have been around April or May last year, short after the release. I was just not using it for a period of time and now I don't get it to work anymore.

And when you had it working before that was with MIDIMeister? Why not try it with that same version of Dos version of Fate of Atlantis and see if that works?

[HerrBerzerk]

No, that all looks good except for the missing raw MIDI output...

The problem must be with the game itself or ScummVM global or per-game config settings...

And when you had it working before that was with MIDIMeister? Why not try it with that same version of Dos version of Fate of Atlantis and see if that works?

Yes, that was with MidiMeister. When you released MidiMeister, shortly after the release, I installed ScummVM and tested it with MidiMeister. That time around where we still had to copy menu.rbf manually. At that point, everything was working fine.

Now I did a complete fresh install of everything and nothing is working anymore.

To test the FOA version of DOS 300 i have to get this game from the DOS VHD to Scumm, I'm not sure how to do that. But I tried around 10 different games on scumm, like LSL5, MI2, FOA, KQ6... I think they all should have mt32 support, so I'm not sure the problem is the game. But you can tell me what game you want me to test, I have a lot installed. Also what version of Scumm do you want me to use?

Some Questions:

• When I start MidiMeister on SSH. At what point should I see this Data Stream? As soon as I start a game in Scumm I guess?

• Is this data stream somehow related to the Mt32-Pi or should I see the data stream also with no Mt32-Pi device connected?

• Why do I have to rename MidiMeister to check? What is the difference between renaming MidiMeister first or start it with the real name?

Anything else I can test?

Thanks

[bbond007]

Some Questions:

• When I start MidiMeister on SSH. At what point should I see this Data Stream? As soon as I start a game in Scumm I guess?

• Is this data stream somehow related to the Mt32-Pi or should I see the data stream also with no Mt32-Pi device connected?

• Why do I have to rename MidiMeister to check? What is the difference between renaming MidiMeister first or start it with the real name?

1. You should start seeing data once the MIDI music starts playing or starts sending sysex data. It's real-time raw MIDI data.

2. You should see data even if no mt32-pi. MidiMeister has absolutely no idea if there is a mt32-device connected. Obviously you won't hear any MIDI music

3. The ScummVM script normally starts/restarts MIDIMiester bin in "quiet" mode, meaning no debug output. The propose of renaming the MIDIMeister bin is to prevent it from being relaunched(in quiet mode) when ScummVM is launched. The script looks specifically for a file called "/media/fat/linux/MIDIMeister". Once done testing, the bin should be renamed back to MIDIMiester for normal operation.

[HerrBerzerk]

1. You should start seeing data once the MIDI music starts playing or starts sending sysex data. It's real-time raw MIDI data.

2. You should see data even if no mt32-pi. MidiMeister has absolutely no idea if there is a mt32-device connected. Obviously you won't hear any MIDI music

3. The ScummVM script normally starts/restarts MIDIMiester bin in "quiet" mode, meaning no debug output. The propose of renaming the MIDIMeister bin is to prevent it from being relaunched(in quiet mode) when ScummVM is launched. The script looks specifically for a file called "/media/fat/linux/MIDIMeister". Once done testing, the bin should be renamed back to MIDIMiester for normal operation.

Thank you for the Information. Trying to understand everything.

I did a lot of tests today and found some games showing me some sysex data, but only about half a screen of them, then it always stopped. It looked like this:

/media/fat/linux# NMIDIMeister
NMIDIMeister: /lib/libasound.so.2: no version information available (required by NMIDIMeister)
MIDIMeister $0004h BBond007
Setting task priority --> -20
Setting /dev/ttyS1 to 31250 baud.
Entering main loop...
SND_SEQ_EVENT_SYSEX # = 000C --> SND_SEQ_EVENT_SYSEX # = 001E --> SND_SEQ_EVENT_SYSEX # = 000B --> SND_SEQ_EVENT_SYSEX # = 010A --> SND_SEQ_EVENT_SYSEX # = 008A --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSEX # = 0100 --> SND_SEQ_EVENT_SYSE

Nothing more, nothing less.... does this look normal to you?

Thank you.

Frank