Megadrive/Paprium

[TheHpman]

Added (partial) support for paprium. MCU core isn't available for emulation, replicated behavior.

[angelosa]

In no way this code should live in the generic MD cart code.

[TheHpman]

Ah, sorry I don't contribute quite often heh.
What would ba a better way to implement this frankenstein monster without the mcu?

[angelosa]

In scripts/src/bus.lua, apply this patch:

diff --git a/scripts/src/bus.lua b/scripts/src/bus.lua
index c454abfeed1..2d2a57adeae 100644
--- a/scripts/src/bus.lua
+++ b/scripts/src/bus.lua
@@ -3797,6 +3797,8 @@ if (BUSES["MEGADRIVE"]~=null) then
 		MAME_DIR .. "src/devices/bus/megadrive/ggenie.h",
 		MAME_DIR .. "src/devices/bus/megadrive/jcart.cpp",
 		MAME_DIR .. "src/devices/bus/megadrive/jcart.h",
+		MAME_DIR .. "src/devices/bus/megadrive/paprium.cpp",
+		MAME_DIR .. "src/devices/bus/megadrive/paprium.h",
 		MAME_DIR .. "src/devices/bus/megadrive/rom.cpp",
 		MAME_DIR .. "src/devices/bus/megadrive/rom.h",
 		MAME_DIR .. "src/devices/bus/megadrive/sk.cpp",

Then, create paprium.cpp / paprium.h in the given folder, and c&p the respective contents.

Your .cpp should be:

// license:<select a SPDX for this>
// copyright-holders:<your handle>
/*
<Paprium header>
*/
#include "emu.h"
#include "md_slot.h"

[.cpp code starts here, from the DEFINE_DEVICE_TYPE]

.h

// license:<same SPDX as above>
// copyright-holders:<your handle>
#ifndef MAME_BUS_MEGADRIVE_PAPRIUM_H
#define MAME_BUS_MEGADRIVE_PAPRIUM_H

#pragma once

#include "md_slot.h"

[header define]

DECLARE_DEVICE_TYPE(MD_ROM_PAPRIUM, md_rom_paprium_device)

#endif

Finally, you need to link md_carts.cpp with the new #include "paprium.h".

[angelosa]

Not an issue, it's part of the game (and afaik some MD HW revisions will get stuck over this minigame too).

[cuavas]

After a very quick skim, in general:

• Avoid polluting the global namespace unnecessarily.
• Avoid macros where possible, especially in headers as they can’t be scoped and pollute everything downstream.
• Use the logmacro.h stuff for configurable logging.
• logmacro, osd_printf_*, etc. are type-safe – there’s no need to cast integer arguments.
• Stuff that’s supposed to happen once after mounting an image should happen in the on load handler, not in device_reset.
• If the game can’t be completely properly or major functionality doesn’t work, that’s supported="no", not "partial".
• Use uppercase for TODO, FIXME, NOTE, etc. in comments so editors and other tools recognise it.
• Please don’t use integer bitfields. They don’t have well-defined behaviour and are unportable.
• You’ll have to implement device_post_load and possibly device_pre_save to restore your internal pointers after loading a saved state.
• If you don’t actually support saved states, please flag the device as such.

But this seems to be high-level simulation of whatever the STM32 microcontroller does. Do we want to take this approach, or wait for a microcontroller dump to surface?

[angelosa]

If the game can’t be completely properly or major functionality doesn’t work, that’s supported="no", not "partial".

Feel like this would be the equivalent of a MACHINE_UNEMULATED_PROTECTION that the SW list can't express explicitly, lacking that I second the supported="no" argument.
This simulation also clearly doesn't have the BGMs that are streamed by the STM32 in some way (as MP3 player?), which on its own doesn't feel like a "working" entry overall.

[cuavas]

This simulation also clearly doesn't have the BGMs that are streamed by the STM32 in some way (as MP3 player?), which on its own doesn't feel like a "working" entry overall.

Yeah, the STM32 does MP3 decoding and adjusts the pitch/speed of playback depending on gameplay.

[TheHpman]

It's not MP3, STM runs a 26(?) channels PCM tracker.

So should I bother or keep it as a fork? lol

[angelosa]

My 2c.:
From what I can tell the 68k to STM32 comms are transparent, which will be replaced eventually if/when a dump of that surfaces. And by then, having an HLE comparison would still be a good thing, considering we already choke from ARM9 onward.

[Miraak88]

The game has an option to play all the music through the MD Yamaha as a compatibility fix for some console models. You could implement Yamaha audio until a STM32 dump surfaces.

[Aurez]

This game also offers a 2 Players "CPU-Coop" option when used with a MegaCD
So it would be cool to get it working like that :)
(and it offers also a 3 players mode using a multitap!)

[superctr]

The game has an option to play all the music through the MD Yamaha as a compatibility fix for some console models. You could implement Yamaha audio until a STM32 dump surfaces.

This will bypass the DAC on the cartridge, but it doesn't actually solve the problem, since the music sequencer and mixing still runs on the STM32.

I noticed that the music data and samples are stored on the external ROM (which is dumped), so technically HLE music playback should be possible. However it would probably take some effort to get it to sound accurate.

[cuavas]

I noticed that the music data and samples are stored on the external ROM (which is dumped), so technically HLE music playback should be possible. However it would probably take some effort to get it to sound accurate.

I really don’t think it’s worth trying to simulate when the entire sequencer runs on the STM32. For comparison, Capcom QSound™ runs the sequence on the Z80 and the DSP16 just does sample playback and filters/effects, so simulating the sample playback part was a lot more viable.

[TheHpman]

Also the music appears to be dynamic depending on game events, it's not a simple recording matter.

[Miraak88]

The game has an option to play all the music through the MD Yamaha as a compatibility fix for some console models. You could implement Yamaha audio until a STM32 dump surfaces.

This will bypass the DAC on the cartridge, but it doesn't actually solve the problem, since the music sequencer and mixing still runs on the STM32.

I noticed that the music data and samples are stored on the external ROM (which is dumped), so technically HLE music playback should be possible. However it would probably take some effort to get it to sound accurate.

So this kind of breaks any hopes of a simple implementation...

[superctr]

I noticed that the music data and samples are stored on the external ROM (which is dumped), so technically HLE music playback should be possible. However it would probably take some effort to get it to sound accurate.

I really don’t think it’s worth trying to simulate when the entire sequencer runs on the STM32. For comparison, Capcom QSound™ runs the sequence on the Z80 and the DSP16 just does sample playback and filters/effects, so simulating the sample playback part was a lot more viable.

There is some precedent in MAME a long time ago with old Namco arcade games with an internal MCU. However, the sound drivers could be reverse engineered from older versions where the code was available. That is not the case here, and I agree that the effort to try and reproduce the sequencer from scratch is probably too much.

[mamehaze]

I noticed that the music data and samples are stored on the external ROM (which is dumped), so technically HLE music playback should be possible. However it would probably take some effort to get it to sound accurate.

I really don’t think it’s worth trying to simulate when the entire sequencer runs on the STM32. For comparison, Capcom QSound™ runs the sequence on the Z80 and the DSP16 just does sample playback and filters/effects, so simulating the sample playback part was a lot more viable.

nmk004 had its sequencer simulated before the internal ROM was dumped, although yeah, it wasn't perfect until then.

if there's no known way to dump the internal ROM then it might just have to be the case, it would be preferable over samples IMHO.

FWIW I'm fine with the current (partial) simulation for now though.

[Miraak88]

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

Music was reverse engineered

[SRC267]

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

Music was reverse engineered

Does this zip file contain the tracks: (redacted, no copyrighted content please)

[JacKc029735]

Indeed this zip file contains the WAV tracks for paprium.

[Miraak88]

Wav files have nothing to do with this. That's for FBNeo core. I'm talking about the custom tracker for the game. Seems to have been reverse engineered. This means no need for external audio files when implemented.

[SRC267]

Indeed this zip file contains the WAV tracks for paprium.

I wonder if these will work when replacing the .mp3 files in the pap folder (with retroarch/genesisgx)

[JacKc029735]

@ Miraak88: Sorry for the misunderstood...Now you're welcome to help for the reverse engeneering.