Add support for OPLL Chip(YM2413) and YM2151
Issue #10
new
It would be nice if GME supported the YM2151 and YM2413 chip.
Comments (28)
-
-
I was the one who created this issue, but I agree, both repos should be merged into one, since that fork support other stuff that this don't currently.
-
repo owner
Volunteers would be great indeed. I'm more than willing to pass the baton over to someone who actually knows what they're doing, at least as far as the emulation parts go. I've been maintaining this mostly to ensure it can build on Linux but I have no objections to going back to maintaining the build system while overall maintenance is headed up by someone else.
-
repo owner
With that said I don't mind cherry-picking from suitable code bases that are compatible to the overall structure of the current code base in the meantime.
-
Sounds great! Whenever you can do it is fine.
-
How hard would it be to add OKIMSM6258, 32X PWM, and SEGACD PCM support also? the fork Tom linked earlier has support for that too.
-
I didnt even had time to figure out how "hard" it would be. It probably gets done when merging kode54's fork with this, whenever this might happen...
-
Pardon me for bringing this up, but I found a fork of kode54's fork that uses the Cmake build system, Yet aims to be abi compatible with 0.6.2, well including support for other formats. https://github.com/wyatt8740/Game_Music_Emu So this would be even better to use as a base.
-
Account Deactivated
Can you say, which chip-tune files are needs for this chip? I would to try implement this as that must not be hard. Recently I have replaced GENS emulator with much more accurate MAME and CPU loyal emulator and sent a pull request on that.
-
repo owner
So I suppose wishing for volunteers to pass the baton too doesn't actually make it happen. :)
I did take a look at kode54's fork hoping that we'd have a central commit of Blargg's that we both descend from, to make it easier to port some of the improvements over. But it looks like his code descends from at least 2006, being used in foobar2000 as well.
The git diff of all differences (origin/master...kode54/master) isn't reassuring either:
318 files changed, 25082 insertions(+), 62574 deletions(-)I think we'll just have to take each potential chip to emulate at a time, and see about finding the best emulator to use for each one.
-
If we will do then we should start with something that is needed more, PWM support, which is used by 32X games.
-
I'm interested in this as well. I spent a couple minutes trying to backport the YM2413 support from kode54's stuff but quickly gave up as it's not a simple job.
Lots of music on vgmrips.net would benefit from these chips.
-
repo owner
@mattmontag I'm happy to help you or others with trying to integrate existing chip emulator support. I'm very time-limited myself (only really get to check on weekends) but within that constraint I can chip in.
The only catch is I'm not actually any good at writing emulators! I'm only "repo owner" here because Blargg left me the whole thing when I contributed the cmake buildsystem.
-
@mpyne I've completely replaced my game-music-emu source with kode54's fork.
That wasn't much work (it has the same public interface) except I had to reapply some modifications I made for my project, such as adding a tempo-invariant seek method. And of course, I lost all the Cmake stuff.Just FYI, my compiled library size went from about 500 KB to 850 KB in the process. All those chips add a significant weight to the codebase.
Anyway, I'm afraid I'm not quite up to this task, either... The proper way forward would probably be to ping Christopher (kode54) to get his thoughts on merging back into this project. I'm afraid there's no way around this one: https://github.com/kode54/Game_Music_Emu/commit/8e8d82b1a0f85fa859f0499b74aed0fb7ea0fda9
He's made a lot of other structural changes that appeared to me as improvements. Big question for you though, what are the most significant improvements that have been made in this repository since his 2008 branch point?
-
Ping @kode54
-
Don't forget, there's a big ol' nasty branch called vgmplay, which imports yet another project for even more restrictive license and almost all of the requisite chips. It's still behind, because I'm waiting on libvgm to be feature complete.
-
repo owner
@mattmontag There's been a few comparatively minor feature requests, things like:
- multichannel support in the SPC emulator
- support for transparently decompressing audio
- An improved GYM emulator (very accurate but heavy on CPU usage)
Probably the largest change was some hardening measures taken in response to security vulnerabilities that landed this library and gstreamer on the frontpage of Ars Technica :( Of course that's probably not too hard to cherry pick if @kode54 hasn't gotten around to that yet.
It seems to me a lot more work has happened on @kode54's side so it would seem the logical host for a merge. It would be really good to retain a way to generate an actual shared library with a set API though, instead of requiring the inlining of game-music-emu into an application code base.
This change alone brought a surprising amount of popularity to this project (VLC and GStreamer both distribute plugins that can tie to this, the Gentoo Linux distro has "gme" USE flags to pull in this library, etc.). It's not the only way to do it but it does help IMHO.
I'm willing to help with that, just as I'd helped with blargg's original game-music-emu.
-
It would probably be better to start with official 0.6 than my repository. Most of my changes are plain garbage.
-
@kode54
well. While you're here - I was spot checking some measurements on your fork and the SPC rendering is about 10x more expensive than others:GME Format Time to Render 2048 Frames SPC 10.5 ms VGM (Sega Megadrive) 1.5 ms VGM (Neo Geo) 1.5 ms NSF 0.2 ms VGM (Sega Master System) 0.1 ms Is this because it's using the "higan" SPC700 emulation?
-
That would be correct. You're welcome to replace that, but it will definitely break the SFM format, which relies on cycle accurate behavior for the log replay to work properly. Of course, you could just convert the whole thing into a pure SMP register log and RAM writes (only want ones which are relevant to sample decoding), but I have no idea how that would work.
-
Ok, thanks. I don't think I've come across an SFM file...
-
That's because the format never took off. It was much easier just for everyone to continue using the existing SNSF rips, which don't require that accurate of an emulator to work properly. All of the SFMs I made, I logged from SNSF rips running under the special ripping build of Higan. Then I had to find a redundancy in the log, manually loop it, and tweak the loop until it produces a continuous run of music that can play forever.
Byuu didn't like the changes I made to the format he proposed, changes needed to initialize all the state registers, so it would be possible to actually fast forward a log past the initial boot up of the system to any arbitrary point in time, delete the already-played log, and save the state again.
-
@kode54 thanks for that background info. I'd like to use the original SPC engine on top of your fork, but it's getting messy because of changes in Gme_File (i.e. Gme_Loader didn't exist when original Spc_Emu was written). Should I give up on this? I was hoping you could (generously) explain what changes you made to the architecture so I can get my bearings between the two forks and have some opinion on what's good and bad.
-
There's an older Spc_Emu and company in my repository before I added the Higan one, it should still work with 0.6 series. I think. Check the blame list, I guess.
-
Not to revive a dead issue, but I’ve also been looking into doing this with no luck so far. Kode54s branch has a lot of improvements made to the GME library, but it’s worth noting that some are probably worth skipping over.
I think a good approach to achieve parity with Kode54 would be to enumerate the specific emulation formats that are missing. For instance, it would be nice to simply get the VGM format to support a more modern version of the format standard (with more Arcade chip support for things such as QSound and more…)
The difficulty for me now (and, granted, I’m also not an emulator dev but have dabbled in audio programming) is really scrutinizing the changes I actually need from Kode54s fork and to re-integrate those changes that are a) friendly to linux machines and b) support cmake optional build flags to a reasonable degree.
-
You may wish to ignore my fork’s inclusion of VGMPlay in the vgmplay branch, as libvgm is a much improved and probably better designed alternative, and doesn’t necessitate massive changes to support reentrancy, as it already has that. The licensing may also be clearer on the chip emulators, but I’m not entirely sure.
-
One area of concern for me is duplication of work. It seems like libvgm is potentially a good alternative for the VGM format going forward as a dependency, but including it in its current state seems error prone (moving target api, rocky foundational c api atm.)
@Christopher Snowhill Thanks for taking the time to address issues here too, btw. I’m not as experienced in this whole emulation thing as you are, but at this point I’ll do anything I can to not have to use foobar2000 through wine on my linux machine.
I think one of these days where I get the time, I will try to really delve into this and try to improve the lackluster areas of the current GME. I’m just happy to see this repository with more activity than it had before, it gives me some hope for better chiptune playback on linux.
-
Account Deactivated
Continue at new repo: https://github.com/libgme/game-music-emu/issues/12
- Log in to comment
kode54's fork has implemented them, among several others: https://github.com/kode54/Game_Music_Emu
however, it would be really great if these two repos could be re-united. any volunteers?