Paprium support shared on MediaFire

[MAVProxyUser]

This issue has been long standing open for years: #275

A recent release on Mediafire added "Full Source" to enable Paprium:
https://www.mediafire.com/file/yd7c2ekx9e2uru6/Paprium_%2528ROM%252BCore%252BOST%2529.7z/file

Please massage this into an official, refined addition to LibRetro.

"Big salute to that brazen individual, or those individuals that picked up the long ago dropped torch (aka our dump work), and gifted everyone with a July 4th libretro liberation from watermelongames. You da real MVP whoever you are"
https://x.com/LittleManDumps/status/1941936388380758059

[carmiker]

I recommend creating an issue at the upstream repo: https://github.com/ekeeke/Genesis-Plus-GX

There may be changes done that upstream doesn't find palatable, or break things. For something of this magnitude it is best if the core dev behind the emu is the one to review it, and downstream forks like this one can later pick up the changes once properly vetted.

[MAVProxyUser]

I recommend creating an issue at the upstream repo: https://github.com/ekeeke/Genesis-Plus-GX

There may be changes done that upstream doesn't find palatable, or break things. For something of this magnitude it is best if the core dev behind the emu is the one to review it, and downstream forks like this one can later pick up the changes once properly vetted.

This is non trivial because: "This branch is 530 commits ahead of ekeeke/Genesis-Plus-GX:master."

[carmiker]

The core emulation code is largely the same. It would be preferable to keep things as compatible as possible between the forks, and this means using code the upstream author deems acceptable. Taking a quick glance at this PR, I can already see some problems, like a big block of code disabled by #if 0, and other random debug code, libretro-specific code added to the core, and changes to the palette. Then we have a vendored library, and a bunch of headers for audio filtering. Yeah, I would say this is of large enough magnitude that it shouldn't just be arbitrarily merged as is. Furthermore, looking at the issue quoted here, it seems there has been some rather heated discussion already. @ekeeke, do you have any thoughts?

[MAVProxyUser]

it seems there has been some rather heated discussion already. @ekeeke, do you have any thoughts?

Aye hence my "Please massage this into an official, refined addition to LibRetro."

[hotker79]

genesis plus gx.dol for retroarch wii please

[ekeeke]

Looking briefly at the code changes, i agree this can not be merged as is and there is no point submitting a pull request upstream as there is lot of cleanup to do and lot of stuff that seem unrelated to Paprium support that could be discarded or done differently ar first glance.

That said, this is still very useful to have these code changes and the amount of reverse-engineering and debugging work that was surely needed to get there is impressive. The most interesting stuff in my opinion are in md_cart.c and paprium.h, where the mapper is implemented.

Some other stuff i noted:

• the mp3 decoding library could maybe be discarded if the mp3 files were converted to wav or some other format already supported by the core ?
• I am not sure about the huge changes to blip_buf library that only seem done to support higher samplerate interpolation but seem unnecessary to me as the original material seems to be 48kHz audio (but maybe i'm wrong) ?
• there is a vdp dma hack that seems to have been introduced for this game especially, this is something you want to get ride of if possible
• the change in cdd.c is likely a leftover from initial code changes that did not work as expected but should be reverted as it breaks CD audio emulation)
• save support seems to be missing as i see the initialization of SPI EEPROM chip (like the one used in Pier Solar) but no interface to it in current mapper implementation so there are probably still stuff to reverse-engineer ?
  EDIT: save support is there actually, EEPROM chip does not need to be emulated as it is fully handled by the MCU in real cartridge and the game only send command to save/load EEPROM content from/in on-board RAM, which can easily be emulated by writing/reading SRAM at once as if it was normal SRAM.

[MAVProxyUser]

The audio is a complete hack... it is not utilizing the musical assets in the ROM itself. They are literally using the OST from archive.org here: https://archive.org/details/paprium-ost

The Md5's are a 1:1 match.

The included "paprium.wav" appears to be our unpacked Extracted/audio/UnpackedWavePack.wav possibly resampled cuz the MD5 differs. Original work for that here: ArcadeHustle/WatermelonPapriumDump@7bb6f22

Game Sounds are originally encoded with WavePack BTW. https://www.wavpack.com/wavpack-4.80.0.tar.bz2

[Miraak88]

You have the mapper, so I think the best and fastest approach is to use the yamaha for the music (there is an in-game option to enable this), at least for now until someone manages to dump the STM32 chip. It is unknown to me if some of the sound effects also use the STM32 too.

[MAVProxyUser]

re: "there is no point submitting a pull request upstream as there is lot of cleanup to do and lot of stuff that seem unrelated to Paprium support that could be discarded or done differently ar first glance"

Someone will have to pick this torch up, it won't be me. The main reason for this PR was so people could easily reference what made the game playable. Likewise the new mame PR below is a good reference point to how the original Mame vs Wild proof of concept worked. That example code is now public here:
mamedev/mame#13939

I wish everyone the best of luck in getting this working. I know many people are relying on a "supported" release for this in LibRetro and its landscape. Don't hesitate to ask @TheHpman or I questions if you need technical assistance getting things going. I would NOT expect HPMan to write a patch for you, or commit a PR here. That's gonna be on someone in the community to take that initiative.

[niuus]

• the mp3 decoding library could maybe be discarded if the mp3 files were converted to wav or some other format already supported by the core ?
• I am not sure about the huge changes to blip_buf library that only seem done to support higher samplerate interpolation but seem unnecessary to me as the original material seems to be 48kHz audio (but maybe i'm wrong) ?

Sample code for OGG usage (for a Wii version or low powered devices?) can be found here. Sample update here.

Sample code for WAV usage can be found here.

[Miraak88]

https://x.com/The_Hpman/status/1946547840953565671?t=YXV9hU9svVX_25kXgxMBzA&s=19

Music was reverse engineered

[dinkc64]

Miraak88 "was" and "is being" are 2 different things

[Miraak88]

Miraak88 "was" and "is being" are 2 different things

Sorry.

Ask Hpman for all the info on how the game works.