Yay! Great news! please let us know when we can unlock the old core and update!
You could do that right now. It’s all set. Only thing missing now is the MIDI support.
1 Like
Just did and finished akumajou dracula to test it out! XD
I guess when Midi will be available I’ll do it again!
5 Likes
Yeah, you can disable lots of features when compiling to make the .exe smaller and require way less .dll files. I have a Github Actions script that I can trigger to compile my minimal builds whenever: https://github.com/Awakened0/RetroArch-Minimal-Builds
I finished it with the updated core too. I was playing the “Akumajou Dracula (1993)(Konami)(Disk 1 of 2)[a]” variant from the TOSEC set, where first stage enemies do 2 damage and later ones do 4. Pretty brutal. The non-[a] variant might have a trainer patched into it, since everything does 1 damage. I think the [a] one is the actual original, since it matches the damage output in Castlevania Chronicles “Original” Mode."
3 Likes
I never played the game but i do know that [a] stands for “alternative version”.
[!] should be the verified good rom.
1 Like
my wip branch with initial midi support is here for those wanting to test: https://github.com/energy-t/px68k-libretro/tree/midi
I have no idea how to setup github actions to easily prep releases to ppl so maybe i’ll figure how to do that next…
relevant options i’ve been using with munt when testing, may or may not apply to u so adjust as necessary:
retroarch.cfg:
video_driver = "gl"
video_vsync = "true"
video_hard_sync = "true"
video_hard_sync_frames = "0"
vrr_runloop_enable = "true"
audio_sync = "false"
midi_driver = "alsa"
midi_output = "Standard"
PX68K.opt:
px68k_adjust_frame_rates = "disabled"
px68k_audio_desync_hack = "enabled"
px68k_cpuspeed = "16Mhz"
px68k_no_wait_mode = "enabled"
px68k_push_video_before_audio = "enabled"
px68k_midi = "enabled"
px68k_midi_type = "LA"
No idea. I’d guess it would depend on how similar the interface code to use it is compared to what’s currently in there rn, which i’m not at all familiar with…
Yep, the tosec [a] variant is the actual version of the game. Last i checked mame also had the easy mode / wrong one in its verified software list as the official version. gotta imagine the ppl curating these lists have never played a castlevania game before b/c how could anyone who has think that the version floating around that results in only a single bar of health being removed per hit for the entire game, including all six subsequent loops, was the official version? Those wacky tosec and mame software list maintainers… /s
gg!
now, just 6 more loops left go! gotta make sure all them loops work right w/musashi and midi support so time to get crackin for us here /s (*just kidding, in case it wasn’t clear already with the /s)
***I want to add/stress that this is all very early work towards getting working midi support in this core. while i was able to get SOMETHING working from what little glue code i put in - that being castlevania works reasonably well using munt now - it’s far from perfect. i’ve seen some issues already and i’m sure there’s loads more i haven’t yet. i don’t want to give ppl false hope here. In the mean time, it would be a good idea to revisit the initial purpose of this thread, that is for ppl to try and get midi working with MAME’s x68k emulator. I’m willing to bet its midi support is in a lot better shape than px68k, and having something to compare to and crib notes from can help a lot going forward.
3 Likes
I wouldn’t worry about it then unless you really feel like messing with it. I’m just happy to have the crashing fixed.
Though apparently Etoile Princess still crashes at the title screen regardless of using the musashi or c68k cores. You still have to use an old build for that game: https://github.com/libretro/px68k-libretro/issues/135#issuecomment-1215629357
Probably if a current archiving group like No-Intro or Redump did x68000 this would be fixed.
Maybe someone will take MAME’s x68k emulation and create a more accuracy focused x68k libretro core someday. I don’t want to bother with the full MAME core just for x68k, personally.
You’re welcome to use my actions recipe as a starting point: https://github.com/hunterk/libretro_builds/blob/master/.github/workflows/win64_px68k.yml
It’s a cross-compile from linux, but all you should need to do is swap out your repo address (and, if needed, add a branch checkout step).
1 Like
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.
1 Like
Regarding Akumajou Dracula, this game was also released on the PS1 in Castlevania Chronicles, are there differences, apart from sound/music?
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.
2 Likes
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
3 Likes
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.
There’s xm6 old source code there too (xm6_205s.zip):
http://yohkai.no-ip.info/x680x0/XM6.htm#download
1 Like
it may be an issue with your munt config
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.
1 Like
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.
1 Like
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.
1 Like
Anybody have any thoughts on this? https://www.reddit.com/r/RetroArch/comments/wqbn0m/comment/ikyf4hf
Copy/pasted here for convenience:
Unfortunately, the latest version (0.15+ 77bfb32) from Aug. 19th seems to re-introduce the bug (it could also be a new bug). “Akumajou Dracula” crashes again during loading. “Street Fighter II Champion Edition” doesn’t crash but gets stuck at this screen: https://i.postimg.cc/6prV8WFZ/Street-Fighter-II-Champion-Edition-Stuck-during-loading.png
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.
