SysEx ROM Set Switching

[SScorpio00]

I'm not sure if it's already planned, and I'm sorry if I missed it in the documentation but would it be possible to place multiple ROM sets on the SD card and use SysEx messages to switch between them?

The reason for this is there are two revisions of the MT-32 control ROM. The newer version of the ROM corrected some bugs, but there are a few old games that don't play correctly with the newer ROM.

There's also the CM-32L which has extra sound effects some games use. But much like the updated MT-32, there are games that don't work correctly with a CM-32L either.

So my request is to add three additional SysEx commands that would switch the ROM set to MT32-old, MT32-new, or CM32L.

If on the fly ROM switching isn't feasible. Would it be possible to add a switch to mt32-pi.cfg to specify which ROM set to use? The SysEx commands could modify the config and then reboot the Pi.

Thanks

[dwhinham]

Hi! 😃

This is a great idea, and exactly the sort of thing I had in mind for Custom SysEx. Switching on the fly should be possible, albeit probably with the effect of resetting the emulated MT-32 (or CM-32L) state back to power-on state.

I'll have a think about how to do this from a config perspective - your suggestion of the three ROM sets is quite straightforward to implement, but maybe I could allow the user to specify n ROM sets with their paths in the config file, and then we have SysEx to switch to bank n.

If left unconfigured, we could fall back on the current behaviour of looking for MT32_{ CONTROL | PCM }.ROM.

Are old, new and CM-32L the only commonly-used ROM sets, or do people use any of the other more obscure or patched versions too, I wonder?

Cheers!

[SScorpio00]

I'm only personally aware of old, new, and CM-32L. But there's always the possibility some game did some exploit which was patched after a certain ROM revision. That's actually what the old/new split is.

Wikipedia has a nice list of DOS games and identifies them as old, new, or CM-32L. It could be helpful to see the differences between the different ROMs.

https://en.wikipedia.org/wiki/List_of_MT-32-compatible_computer_games#Table_of_compatible_games

There's also a CM-32P and CM-64 which combines both the CM-32L and CM-32P in a single unit. The CM-32P is a completely different beast and wasn't really used in the US. I believe it was mainly used with the Japanese x68000 and I think also the MSX.

Soundfonts would be another nice to have with SysEx switching. It wouldn't sound exactly like original hardware, but you could have Sound Canvas, Yamaha, and Korg. That would allow mt32-pi to replicate most MIDI devices. There's also VST plugins, but again that's a huge rabbit hole, and Soundfonts would be much easier support and get most of the experience.

[dwhinham]

Thanks for the link to this list, I wasn't aware of it!

Soundfonts will happen if I can successfully pull off a FluidSynth port - I was looking at this today, and it'll take some work because it uses some dependencies we don't have under bare metal, but it should be doable.

VST ... probably out of the question; we'd need x86 emulation, a way of loading .DLLs, and a complete emulation of the VST API.

[SScorpio00]

Ya, VST is overkill if the target for this is gamers. Someone composing music wouldn't get a match to real hardware. But someone who great up listening to FM synth and moving to a good Soundfont would see a major difference compared to what they are used to in their favorite games.

[icb-]

You pretty much have to reset the emulated device to change the ROM, unless you run hidden devices for each ROM, and only patch through the sound output of one at a time.

MUNT itself has a list of known ROM files (6 versions of MT-32 control ROMs, 2 versions of CM-32L control ROM, and a PCM ROM for each), and identifies them by the SHA1 hash of the file.

Maybe on boot you could scan a roms directory, with a config setting of the hash of the control ROM to boot into, or if only one is found, boot into that. The PCM ROM to use for a given known control ROM should be obvious.

The "reboot" SysEx could then be extended to "reboot into ROM control ROM with a given hash" if a hash is given, otherwise reboot into the current ROM.

Or, you could add a SysEx message to update the configured "default" ROM hash (either until power cycle, or even updating the config file), and have the "reboot" SysEx reference that.

If you wanted to go all in, you could add support for ROM upload over MIDI SysEx messages, and either save the uploaded ROM to the roms directory, or keep it in memory and restart the emulated device into it. If you're going that far, you could even support uploading new versions of mt32-pi itself.

[SScorpio00]

I don't see a reset of the emulated device being a deal-breaker for most people. The primary use case I see would be to have a batch or shell script to send the SysEx command from the host. This would be done before starting a game that requires a different ROM from the one you configured as a default.

You wouldn't want to switch the ROMs in the middle of a game running. Unless I'm mistaken the MT-32 allows SysEx messages to remap instruments which would be lost if just switching a ROM as the new control wouldn't have those mappings.

Uploading is also massive overkill. It could be nice for something that you have to disassemble to get to socketed or even desolder chips to reflash. But the Pi has a MicroSD card. Maybe networking to allow some form of file transfer, but how many people would be switching new ROMs in, as you said Munt knows about eight of them. The MT-32's PCM ROM is 512KB, CM-32L is 1024KB. And the control ROMs for both are 64KB. You could all eight of the MUNT supports configurations in just over 2MB of space.

If Soundfonts are possible those could be something that changes more. But those can get quite large and I wouldn't want to transfer them over a ~312Kbps serial link.

[dwhinham]

You pretty much have to reset the emulated device to change the ROM, unless you run hidden devices for each ROM, and only patch through the sound output of one at a time.

Yep. I can just close() and open() the device with new ROMs.

MUNT itself has a list of known ROM files (6 versions of MT-32 control ROMs, 2 versions of CM-32L control ROM, and a PCM ROM for each), and identifies them by the SHA1 hash of the file.

Thanks, I'm aware of this and other lists 😃

Maybe on boot you could scan a roms directory, with a config setting of the hash of the control ROM to boot into, or if only one is found, boot into that. The PCM ROM to use for a given known control ROM should be obvious.

Yes, I was thinking of doing a scan for known hashes too. To keep things simple, maybe we just have old, new, and cm32l 'slots' - unless someone can give me a compelling reason to want access to all the ROMs, all the time.

I think the CM32L PCM ROM is identical to the MT32 ROM with the extra sounds concatenated on the end. It might be possible to just use that one PCM ROM for everything, and just swap out control ROMs. Need to do some testing.

The "reboot" SysEx could then be extended to "reboot into ROM control ROM with a given hash" if a hash is given, otherwise reboot into the current ROM.

Or, you could add a SysEx message to update the configured "default" ROM hash (either until power cycle, or even updating the config file), and have the "reboot" SysEx reference that.

I'd prefer a separate command - reboot is intended for restarting the Pi completely from the bootloader. Swapping ROMs can be done quickly at runtime. I'll probably add a way to optionally remember the last used ROM set for those that like to power off their Pi often.

If you wanted to go all in, you could add support for ROM upload over MIDI SysEx messages, and either save the uploaded ROM to the roms directory, or keep it in memory and restart the emulated device into it. If you're going that far, you could even support uploading new versions of mt32-pi itself.

Doable, but even sending just a few hundred KB over MIDI is painfully slow. You could probably whip out the SD card and rewrite it well before a MIDI transfer of a new kernel would be done! 😄 I do want to allow updates over network though (Ethernet/WiFi) and also MIDI itself.

This is written in the project status section of the README already.

Cheers!

[thorr2]

Ok, so in my other issue, I said I had another idea, and it turns out someone beat me to it. This was exactly my idea, but I had a couple of other parts to it that I don't think were mentioned yet, so I will list those here:

• Provide three (or however many variations there are) MIDI files in the installation zip file that include the sysex messages to switch between the roms. On my Mister, I could play the desired MIDI file in a batch file before launching the game. If the MT32-PI needs time to update to the different ROM version, I could add a delay to the batch file as well.

• Show the ROM selected during bootup on the LCD screen for a moment. I see in the latest build you provided me to test that it says (unknown) during the bootup so maybe you already thought of this and that is why that is there. Not sure, lol.

Thanks!

[dwhinham]

@thorr2

I like both of these ideas a lot.

I've been experimenting with MT-32 SysEx data and wrote some simple Python code to generate valid SysEx messages and send them via MIDI or write .SYX files. The .SYX files can be sent using a simple MS-DOS tool - I successfully tried MIDI Data Filer 4.0 and DUMP. MIDI Data Filer is nice as it has configurable delays.

I could also wrap these SysEx messages in Standard MIDI Files (.MID) if desired, though .SYX would be slightly more lightweight.

I'll work on ROM switching soon and then the release package can include a collection of .SYX/.MID files that you can use for controlling mt32-pi, and perhaps some other useful features like remapping the channels.

ROM version being displayed on startup will be easy, I'll add that for sure.

The <unknown> is actually meant to be the version of mt32-pi - test builds will show <unknown>, but release versions will show v0.5.0 instead, for example. It's automatically generated from the Git tags.

[thorr2]

Awesome, thanks Dale! The MIDI Data Filer with the built in delays sounds like a good solution, assuming it can be used via a batch file with no interaction.

Also, I can foresee in the future implementing a radial push-button dial that allows you to have a menu and select rom versions, perform resets, and eventually change MIDI modules when more are implemented in the future. I gotta keep you busy, lol. ;-)

[dwhinham]

I can foresee in the future implementing a radial push-button dial that allows you to have a menu and select rom versions, perform resets, and eventually change MIDI modules when more are implemented in the future. I gotta keep you busy, lol. ;-)

Absolutely, this is all planned. 😄

@everyone I'm struggling to track down a copy of the 2.04 Control ROM (I have all of the other Munt-compatible ones). If anyone can help me find it, please contact me at daleyo@gmail.com (don't attach anything here!).

Thanks! 😄

[dwhinham]

This is now implemented in v0.6.0.

This new section in the README describes how the new ROM manager/SysEx swapping works.

In my testing, ROM swapping is nearly instantaneous and works well - I hope it works well for you too. 😃

@thorr2 I'll create new issues for your suggestions so I don't forget. 😃

[SScorpio00]

Thank you for all the great work.

[thorr2]

Awesome! Thanks! I will definitely check this out!

On Sun, Oct 4, 2020 at 4:44 PM SScorpio00 notifications@github.com wrote:

Thank you for all the great work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dwhinham/mt32-pi/issues/18#issuecomment-703333108, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMVRPLU65E5RU5SWCXU2VGLSJECFXANCNFSM4PZMUBJA .

[thorr2]

Success! Mostly. I am able to switch between old and CM32L. The "new" doesn't work for me and perhaps I have a different ROM version or it is just named differently. I found my roms by googling "MT32 roms google drive". I used MIDI-OX to create my sysex files.

Thanks!

On Sun, Oct 4, 2020 at 9:27 PM Michael Hart mdhart727@gmail.com wrote:

Awesome! Thanks! I will definitely check this out!

On Sun, Oct 4, 2020 at 4:44 PM SScorpio00 notifications@github.com wrote:

Thank you for all the great work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dwhinham/mt32-pi/issues/18#issuecomment-703333108, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMVRPLU65E5RU5SWCXU2VGLSJECFXANCNFSM4PZMUBJA .

[dwhinham]

Great 🙂

Re: "new", I searched very hard and couldn't find any 2.04 ROMs, hence my earlier comment asking if anyone had a copy. It'll work if a copy gets shared - the usual places don't have this ROM.

[thorr2]

What is the MT32_CONTROL.1988-09-30.vX.XX-patched.ROM? This is newer than 1.07.

Thanks!

On Sun, Oct 4, 2020 at 11:47 PM Dale Whinham notifications@github.com wrote:

Great 🙂

Re: "new", I searched very hard and couldn't find any 2.04 ROMs, hence my earlier comment asking if anyone had a copy. It'll work if a copy gets shared - the usual places don't have this ROM.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dwhinham/mt32-pi/issues/18#issuecomment-703434257, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMVRPLQXCWPT6PBTGO3LQMDSJFTXPANCNFSM4PZMUBJA .

[dwhinham]

That's an "old" ROM, it's the Blue Ridge patched version of 1.07: https://reverb.com/uk/item/33040484-roland-mt-32-mt32-version-blue-ridge-enchanced-1-0-7-firmware-memory-fix-mod?locale=en-GB

(The link says "is the latest official released operation system by Roland" - they mean for the old MT-32).

If you do a sha1sum on this ROM, it should be 7b8c2a5ddb42fd0732e2f22b3340dcf5360edf92.

The list of ROMs and hashes can be seen in the Munt sources as mentioned earlier.

[thorr2]

Thanks. When I send "old" to it, which file does it use? 1.07 or the patched 1.07?

On Sun, Oct 4, 2020 at 11:59 PM Dale Whinham notifications@github.com wrote:

That's an "old" ROM, it's the Blue Ridge patched version of 1.07: https://reverb.com/uk/item/33040484-roland-mt-32-mt32-version-blue-ridge-enchanced-1-0-7-firmware-memory-fix-mod?locale=en-GB

If you do a sha1sum on this ROM, it should be 7b8c2a5ddb42fd0732e2f22b3340dcf5360edf92.

The list of ROMs and hashes can be seen in the Munt sources https://github.com/munt/munt/blob/f2bf654695558f93633aef0e8be3110e9a266406/mt32emu/src/ROMInfo.cpp#L26-L55 as mentioned earlier.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dwhinham/mt32-pi/issues/18#issuecomment-703439828, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMVRPLSJYPTSSYVBZUX2JQTSJFVF5ANCNFSM4PZMUBJA .

[thorr2]

I may have found the whole set. What is your email address?

On Mon, Oct 5, 2020 at 12:03 AM Michael Hart mdhart727@gmail.com wrote:

Thanks. When I send "old" to it, which file does it use? 1.07 or the patched 1.07?

On Sun, Oct 4, 2020 at 11:59 PM Dale Whinham notifications@github.com wrote:

That's an "old" ROM, it's the Blue Ridge patched version of 1.07: https://reverb.com/uk/item/33040484-roland-mt-32-mt32-version-blue-ridge-enchanced-1-0-7-firmware-memory-fix-mod?locale=en-GB

If you do a sha1sum on this ROM, it should be 7b8c2a5ddb42fd0732e2f22b3340dcf5360edf92.

The list of ROMs and hashes can be seen in the Munt sources https://github.com/munt/munt/blob/f2bf654695558f93633aef0e8be3110e9a266406/mt32emu/src/ROMInfo.cpp#L26-L55 as mentioned earlier.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dwhinham/mt32-pi/issues/18#issuecomment-703439828, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMVRPLSJYPTSSYVBZUX2JQTSJFVF5ANCNFSM4PZMUBJA .

[dwhinham]

It could be either, depending on what how the filesystem has ordered the files (it's not necessarily alphabetical), and which one mt32-pi encountered first when scanning.

Please see the note about scanning in the README.

You won't notice anything different between the two ROMs you have, so there's no point in having both.

My email's daleyo@gmail.com if you find v2.04, but I searched very hard; I've seen all the usual downloads.

I have a "new" MT-32 actually on its way to me so I'll be dumping the ROM at some point.

[dwhinham]

Thanks for the email - but yes, I've seen this set. I even wrote a quick script to combine the ROM pieces so that they're usable with Munt - none of these are 2.x.

[thorr2]

sent, in case it went to your spam folder.

On Mon, Oct 5, 2020 at 12:13 AM Dale Whinham notifications@github.com wrote:

It could be either, depending on what how the filesystem has ordered the files (it's not necessarily alphabetical), and which one mt32-pi encountered first when scanning.

Please see the note about scanning https://github.com/dwhinham/mt32-pi#rom-scanning in the README.

You won't notice anything different between the two ROMs you have, so there's no point in having both.

My email's daleyo@gmail.com if you find v2.04, but I searched very hard; I've seen all the usual downloads.

I have a "new" MT-32 actually on its way to me so I'll be dumping the ROM at some point.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dwhinham/mt32-pi/issues/18#issuecomment-703446375, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMVRPLUHSBJMDEGPVORWDZLSJFWYXANCNFSM4PZMUBJA .

[thorr2]

OK, bummer. Well at least we can switch between old and CM32L. This is also useful assuming the CM32L sounds wrong some of the time for the older games. Thanks again!

On Mon, Oct 5, 2020 at 12:22 AM Dale Whinham notifications@github.com wrote:

Thanks for the email - but yes, I've seen this set. I even wrote a quick script to combine the ROM pieces so that they're usable with Munt - none of these are 2.x.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dwhinham/mt32-pi/issues/18#issuecomment-703450872, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMVRPLU7MYCC7WZSHTO7QADSJFXZ7ANCNFSM4PZMUBJA .