Did some testing using both Munt (MT-32 & CM-32L) and SC-VA in SC-55 GS mode. Results:
For MT-32, I of course put the core in ‘LA’ mode. Both synths produced sound, but with a lot of incorrect instruments. No matter which one I used, or however I fiddled with Munt settings the outcome was identical.
For SC-55, I used the ‘GS’ mode and got perfectly acceptable results. Initially. In many places, for example when entering the title screen from the ‘Black Mass’ cutscene, I came upon the ‘infinite sustain’ problem where notes drone on indefinitely. In addition, all songs in the sound test play out of tune and sound very strange indeed. The same ‘Vampire Killer’ sounds OK if you just start a game, though.
The music sounded less tight than it’s supposed to, like some notes dragged. This could be my system, I wouldn’t know. But I’m on a 5950X and use these synths for a bunch of games. Might fiddle with this some more tonight, but here’s a start.
Edit Disregard, the dragging was on me. Vsync Swap Interval = 2, specifically.
Got it, I’m assuming the second screenshot is from the PS1 version.
It seems to me they fixed the original assets, or maybe the X68000 emulator isn’t displaying the game properly as shown in the first screenshot, as it does seem stretched, while in the second, it looks more natural overall, a bit warmer colors too. The PS1 version is also a bit zoomed out and the top black bar clearly shows as the adornments atop the tall windows are covered in the first one.
So they took the smaller black bar from the original Sharp version and made it bigger, while also displaying more details with its increased resolution.
I’m assuming the second screenshot is from the PS1 version
Incorrect. The image file names are giveaways if you can’t tell between versions. I would agree that the X68k original is quite a bit livelier in it’s presentation. I suppose one could argue the transparent status bar is a nice touch, but that’s about it for me.
Yes, in this case, I think the Sharp X68000 looks better then.
Similar cases often occurred in games released between Genesis/SNES, the latter often having the same stretching like the comparisons above.
bumping this post to both point out and say thank the libretro team for their recent work they’ve been doing over the past few days in cleaning up this core. wow, thank you so much!
i actually have a couple experiments/fixes in a git branch locally for various things, some of them have already been addressed by the flurry of recent work being done, but one is a proper fix for what audio desync hack option currently handles. i adapted the same method neocd_libretro uses, which keeps an accumulator that persists across frames in order to accurately determine how many samples to send out per frame in a way that keeps it in balance. however, it currently only works with the actual system framerates and not the compatible/fake ones that are set as the default so /shrug?
that said i’m not well versed on how retroarch itself handles the audio it accepts from a core. it might also be ok to (and after testing this it actually SEEMS to be ok to) just hand off all available samples on hand per frame and let the frontend figure it all out.
that said i don’t feel confident with either atm to push them out let alone pull request…
also, i noticed c68k was set back to the default cpu core after it was fixed (presumably by this commit here: https://github.com/libretro/px68k-libretro/commit/6e7e0b75cc65ad578bebcb4cfcab1aa9b1340789 i was expecting the worst thinking the offending cast that was truncating the upper address bits was buried somewhere in the core’s sea of macros…) i’m not at all opposed to the switch but i do bring it up just to point out that due to c68k’s less accurate timings it does break one of the platforms most popular games under default settings, that being castlevania. for anyone who wants to play castlevania you will need to bump the base clock speed up from 10mhz to at least 16 if you don’t want to encounter some game breaking bugs later on, namely the raft on stage 2 from disappearing out from under you randomly (more often than not) after breaking the lions head and killing you instantly. the game runs perfectly at 16 and above though, thankfully
huh, it works fine on my end. even on my slightly outdated branch that doesn’t include the flurry of recent care and attention the core is getting. maybe check again?
i haven’t checked in with mame’s x68k core in a while, probably over a year at this point, but last i did px68k was actually in better shape in some ways, particularly in terms of graphical accuracy. mame just definitely had the upperhand when it came to audio though, hence why i suggest using it to compare against in this aspect.
you see the thing about midi in px68k rn is, while i know i need to make adjustments to the current system/host interface code, namely getting proper time/syncing of playback in order, it’s probably going to be hard to know exactly where issues exist as from what i can tell px68k never had working os interface code for midi hooked up (not talking about libretro, just in general), meaning i imagine the actual core/emu code isn’t well tested and may be buggy or incomplete. again, if mame’s midi support is in good order then it’ll be a good reference to help fix up px68k’s
thank you, i’ll certainly look into this
oops, ya i forgot to mention i was using video_swap_interval = “1” in my list of options that i was using to get the results i got in my recorded footage. i’m pretty sure getting the timing stuff in order i previously mentioned will take care of this particular problem
how does it sound compared to the footage i posted earlier in this thread? if it’s drastically different then it may be an issue with your munt config. also, thank you for your work testing
We went back to C68K as it’s quite faster:
-920fps musashi vs 1030fps C68K on akumajou stage2 at 10MHz, ryzen 5600X
-380fps vs 680fps at 100MHz
So it can be maybe twice faster on slow platforms.
As it’s a kinda hacky core made for speed it makes sense to go with C68K as default.
But maybe we can have both compiled and a core option to switch between them?
I’m not a qualified coder myself to do it though, a bit clueless about a lot of compilation stuff.
The crash with Etoile Princesse is happening for me as well on win10 x64, it could be about how it’s compiled/unsafe memory allocation.
This build from here is running the game fine (older gcc?): https://github.com/hunterk/libretro_builds
If you checked mame a year ago, it didn’t change at all for x68k.
I was just checking how Gardis Light 2.10, which has a strong screen refresh issue on px68k, was running with it. It’s not even booting.
I did the x68k snapshot collection for progettosnaps.net, and I quickly stopped using mame for it as its compatibility is still a lot weaker than px68k.
It can do midi though and it was working fine in akumajou iirc. Make sure the license allows it before directly porting any code.
You may have a point. Been at it like crazy though and can’t find a working setup, despite using both standalone latest Munt and Falcosoft’s MuntVSTi through Midiplayer. At that point it seems the only thing in common would be the MT-32 ROMs which should be all right. Will keep fiddling though.
Edit I’ve had this suspicion since last night, but now that I’ve thought about it I’m sure it must be SysEx messages not getting handled correctly. MT-32 sounds excellent coming through DOSBox-core where Munt is built-in, and the same Munt setup which fails me with px68k exhibits the same problems using np2kai. Must be loopMIDI dropping the ball as it routes the input to a custom port.
Etoile Princess crashes for me as well after the first title screen.
I tried dim and the 2 [a] versions and also a hdf, same results.
Also tried to change ram and cpu speeds with no luck.
That bug always drove me nuts in px68k, so I was happy I didn’t run into it when testing musashi. Good to know why it happens now and how to fix it in c68k
I’m not too interested in playing that game myself, but I’d seen @Tatsuya79 post about it elsewhere so I brought it up. Looks like it’s still an issue from his post and @Hari-82 's above.
Huh, well good to know px68k is better graphically and compatibility wise. I bet MAME has better FM synth if it’s audio is generally better.
The version from Aug. 18th (0.15+ d2a4248) doesn’t have any of these problem. So I guess it’s likely caused by changes from yesterday.
Update: I did more tests with the latest core on Android, which has the same crash or freeze issue as the Windows core. Pretty sure this is a new bug, not the old Windows-only bug.
the issue with etoile princess sounds like another improper type/cast issue truncating higher address bits, but at least we know now that it’s (most likely) not in the cpu core this time since it affects both c68k and musashi.
oh, that’s a really good idea. i’ll look into the feasibility of it. would be nice to have a selectable core option with something like - CPU Core: C68K (Fast) || Musashi (Accurate)
@DukeSkinny if it helps here’s md5 hashes for the rom files i’ve been using:
hey @e-tank, any chance you can pop onto our discord server? Twinaphex reverted that big commit that re-broke stuff but I think he’s wanting to ask you some stuff about the core.
Oh boy. With the latest changes from the official repo the infinite sustain of the SC-VA synth is gone, but now both it and the MT-32 produce wildly inaccurate and comical sounds.
If the problem is on my end, it seems strange that the SC-55 mode sounded accurate last I checked, the infinite sustain issue notwithstanding. The MT-32 also produces different sounds than before. In addition, DosBox-pure gives me the correct SC-VA sounds (though with infinite sustain on choice notes), and standalone emulators such as PCem have no problems with my synth setups… likewise for Np2kai in RA. So it doesn’t seem to be a case of the communication between my RA setup and external synths breaking down, though I should try a clean RA setup just in case.
