Behavior of MT-32/CM-32 ROM detection

[keenanweaver]

For the unversioned ROMs, I drop them in from an 'exulted' source. So far, so good:

Using MAME 0.251 sets for versioned ROMs (mt32.zip, cm32l.zip) yields this detection from Staging 0.80.1 (Note: mt32_2.0.4.ic28 had to be renamed to mt32_2.0.4.ic28.bin to be detected--looks to be an issue with the MAME set):

However, there is a bit of a name conflict for Windows users, as the unversioned CM32 is named 'CM32L_CONTROL.ROM'/'CM32L_PCM.ROM' while the versioned CM 102 is named 'cm32l_control.rom'/'cm32l_pcm.rom'. Renaming the _pcm file to something else leads to detection, but haven't tested functionality.

Here's a fully working MT-32/CM-32 setup filelist with SHA256 hashes:

My question is are Windows users expected to rename the versioned 102 PCM file if they also want to use the unversioned ROMs, or is this a potential improvement for Staging? First solution that pops up in my head is a recursive search for these files in designated directories: 'versioned', 'unversioned', or something similar. I doubt the MAME folks will adjust anything, but maybe they would. Just wanted to point it out here.

[johnnovak]

The expected ROM filenames with their hashes are listed here:
https://github.com/dosbox-staging/dosbox-staging/wiki/MIDI#mt32emu

Answering your question, there's no "expectation"; everybody can do whatever they want 😎 We never said "go unzip the MAME ROM zip files, and it will work" — the user needs to ensure the correct ROMs are present in the ROM folder with the appropriate filenames, as described on the wiki.

Just to clear things up: "unversioned" ROM support is only there for compatibility with other ports, older pre-made game packs, and projects like eXoDOS that use a variety of DOSBox forks, so they need to take a least common denominator approach. If you're setting up games from scratch yourself and don't care about game packs made by others, there's no good reason to use unversioned ROMs at all.

[keenanweaver]

Got it! I presumed it was meant to be a drag-and-drop scenario from 'places.'

[kcgen]

It would have been nice; but I'd rather have a consistently named set of ROMs (for our own uses), instead of "propagating" an inconsistently named file (inconsistent even by MAME's own pattern).

Maybe drop a bug in their github? - it's worth it; I think they would prefer to have things named right!

[kcgen]

@keenanweaver , maybe mention this slightly miss-named ROM in the MT-32 wiki page, incase users don't catch it?

On the code side, it was pretty tedious to add handling for the versioned ROMs, because it involves pairs of files that make up the control ROM and even sometimes high and low file parts for the PCM ROM.

The good news is that getting a "checkbox" in the /list means that all the files making up that given version have not only passed checksum tests, but MT32emu has also validated them for use. So there is zero risk of having mangled/partial/mixed ROMs.

[kcgen]

👍
Yes - it's very robust. Try changing just one byte in a file :-)

[johnnovak]

Btw, a better approach would be to completely disregard the filenames; just scan the ROM paths and calculate the checksums of all files found there. Then known-good files would be picked up for the appropriate versions, and that's it. Completely automatic and the users can't screw it up if they managed to get hold of the correct ROM files. The only requirement is that they should be able to copy them into one of the ROM locations 😄

This approach to ROM file detection is what a certain emulator does... can you guess which one? WinUAE! 🎉 🎊 😎 🤘🏻

(I think I fully qualify for claiming my well-deserved "WinUAE fanboy" badge at this point, wouldn't you guys agree? 🤣)

It's a very handy feature: you download a bunch of Amiga Kickstart ROMs from a variety of places, shovel them into the ROMs folder, then just press "autodetect" on the GUI. The program will politely inform you of the list of ROMs that it managed to identify at the end of the process.

Of course, this complicates the implementation side of things, e.g. we'd need to maintain a valid ROMs cache (we really don't want to scan all these files on every single startup... there's a slight delay even when you use MIXER /LIST). Plus it's a manual step—unless you also store hashes of the ROM dirs' contents (a hash of all filenames concatenated with their sizes and timestamps would be probably good enough).

[johnnovak]

Though I'm not sure how many people actually use the 2.04 ROM for anything. It's probably more of a completionist's problem.

There's even more: 2.06 and 2.07 I think. Completely unnecessary in actual practice, AFAIK. I couldn't hunt them down when I tried, but I can't be bothered, to be honest...

[kcgen]

Same here - I also lamented having to tweak the layout 🤦‍♂️ to fit even more columns in the output! Maybe if there's actual audible differences.. but I think we're covered having MT32 old, new, and CM-32L.

[johnnovak]

Same here - I also lamented having to tweak the layout 🤦‍♂️ to fit even more columns in the output! Maybe if there's actual audible differences.. but I think we're covered having MT32 old, new, and CM-32L.

Maybe there are in 0.00001% of titles :) I wouldn't worry about it. Yes we could tweak the layout, but I want to see some compelling evidence first why these versions are indeed needed in practice...

[kcgen]

Btw, a better approach would be to completely disregard the filenames; just scan the ROM paths and calculate the checksums of all files found there.

I originally tried it; it meant having to duplicate the checksum test from MT32's code into our own code, but it's also could generate a lot of disk reads for disorganized users that toss their ROMs locally in the same directory as their game -- so it would scan CDROM image and such. On the other hand, that's one way to get the entire game into the read cache :-)

[johnnovak]

Yeah, I would never scan the game folders with this approach, only the designated ROM folders.

[kcgen]

Yeah, I would never scan the game folders with this approach, only the designated ROM folders.

(never underestimate some users' ability to set the ROM folder to the same as the game folder "junk drawer style", or just .! 😆 )

But we could warn loudly about excessive junk files, and also could have sane cutoffs for file sizes.

[johnnovak]

In any case, there's bigger fish to fry—this is a rather low-priority enhancement, even if we decided to do it.

[kcgen]

💯

[johnnovak]

We've revamped our MT-32 handling in 0.81.1. This is no longer an issue, I think.

More info:
https://dosbox-staging.github.io/releases/release-notes/0.81.0/#roland-mt-32-rom-handling-improvements