[Bounty] Enable MSU-1 packfile support in core

[Sanaki]

Current bounty: $45

Currently snes9x supports MSU-1, but in the core this support functions only with all files named identically to the rom and placed in the same directory. This creates some issues in terms of organization (some games have well over 100 audio tracks), space (over 1GB in some cases), and file naming (the average user doesn't know how to handle bulk renaming correctly).

A .msu1 packfile is a standard for storing these sprawling files, currently supported in upstream (with all of the code seemingly present but nonfunctional in this core as well). The file itself is a zip in either store or deflate mode, containing fixed-name files that don't depend on the external rom's name.

In upstream, the main ways of using a packfile are either to load it directly (homebrew generally, with the rom inside and named program.rom) or to have the rom, bps, and packfile in the same directory, with pcm tracks and/or the data track loading from the packfile on demand. Anything else is mostly irrelevant to the core, since Retroarch handles the softpatching.

Given that all necessary handling code is already present, would it be possible to add support for at least loading tracks from a packfile on demand (rom/bps/msu1 adjacent)? Or are there specifics to libretro that prevent implementation? I did compile the core from upstream just to verify, and the packfiles still can't be detected by the core from there either.

Example MSU-1 packfile: https://kickmeelmo.keybase.pub/MSU-1%20Packfiles/Contra%20III%20-%20The%20Alien%20Wars%20(USA).msu1
MSU-1 chip info: http://helmet.kafuka.org/msu1.htm
Mercurial Magic repo (packfile formatting info in readme): https://github.com/qwertymodo/Mercurial-Magic
Original issue introducing support: snes9xgit#217
Retroarch issue regarding .msu1 softpatching: libretro/RetroArch#5563

[bebess]

any update of this features ?

[Sanaki]

Probably just requires someone fixing the core to compile with zip support, but no one's bitten yet unfortunately.

[bebess]

You should edit the title with [BOUNTY] ^^

[Sanaki]

Fair suggestion. I shied away from doing so to avoid giving the "my issue is more important than yours" implication, but it does help people explicitly looking for bounties to find it.

[bebess]

sorry for the bump
we (i hope more that 2 pepole) need this ^^ :)

[kbrighton]

I've been working with @Sanaki on enabling this. Currently it works on linux with sfc+msu1 file. I don't think that msu1 only will work without some refactoring of how snes9x loads roms, but I'm still looking into this. Also, softpatching is not available, but that's by design. Next step for this is making sure it works on the Windows version of the core.

[bebess]

good news ! :)

[Sanaki]

To be clear, bps and sfc adjacent to msu1 softpatching works fine, it's the bps within the msu1 that doesn't, and it's probably better in general that it doesn't.

[kbrighton]

Yeah, I agree with that completely.

…

On Thu, Sep 23, 2021, 12:16 PM Sanaki ***@***.***> wrote: To be clear, bps and sfc adjacent to msu1 softpatching works fine, it's the bps within the msu1 that doesn't, and it's probably better in general that it doesn't. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#229 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFPXY4KIBWP62TVLY6H43UDNHEDANCNFSM4J7D32IQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[kbrighton]

Made a PR to add the feature. Uses snes9x builtin minizip.

[kbrighton]

This should be correct this time.

[Sanaki]

Since BountySource seems to be experiencing some confusion: Yes, this issue is resolved. Yes, @kbrighton resolved it.