Definitely a lot closer than mame so far.

but s-yxg50 still seesm to have much better performance

that said, there's still stuff wrong.

https://www.youtube.com/watch?v=n8MGLBfrRAs (real mu2000ex)

https://gifx.co/music/Game%20MIDI%2FFin ... ghting.mid

the midi file has the square wave go quite out of tune when it kicks in.

okay, it's fixed now.

I'm liaising with tarboh and sharing MUXG2K's debugging findings and data with him, and he's doing the same from his side. We made a few bug fixes today that benefit both S-MU2000 and MUXG2K.
Regarding performance, a genuine emulator is never going to match the performance of a dedicated synth engine compiled in C++. It can be faithful, but there's inevitably a fair amount of CPU overhead from the emulation layer.
That's primarily why I started MUXG2K: to try to recreate Yamaha's synth engine directly rather than emulate it through the original firmware and a hardware emulator. It's very slow going, obviously, but that's the goal.

I've noticed. i'm happy for the collaboration.

When this is all doen we will have the following ioptions.
1) Mame. wont' go ionto a daw withotu extra work, but peopel have doen it.
2) s-mu2000, which syncs better with daw,s but still emulates.
3)MUXG2K. non emulations version which can integrate with stuff.

There is also work on reversing the S-yxg50 engine, which may provide even greater performance, being a 32 bit native pc AWM2 engine capable of using 16 bit samples, though it doesn't actually come with any of them. I'm not sure waht the holdup is there.

FYI this emulator doesn't use the EX firmware. The verify script packages up the v1.01 ROMs, not the v2.01 or EX ones. I don't know if it even works with the EX dumps yet.

I also am taking the initiative to port this to macOS for my own personal use and testing, also using the same bot. I don't know how I can submit any of it properly, since the bot apparently decided to take the initiative, and seeing that the code was already commented thoroughly in Japanese, continued authoring new comments, also in Japanese. I would need a translator to read any of it. I did not ask it to do any of that, either.

S-YXG50 is guaranteed to have better performance than this, no matter what.

Primarily owing to native code and SIMD optimized mixing functions, versus full hardware emulation and a CPU emulation loop.

S-MU2000 most definitely runs the 2.01 EX firmware. the script grabs the control rom straight from the yamaha 2.01 EX update. I used the mame 2.01 EX rom, and as you can see during the bootup...

And when you play a GS midi you get the GS logo on the display. so yes, it's the EX.

i guess you are referring to the other project?

My bad. I was mistaken about what the verify_roms.py script did, which was packaging a mu2000.zip with the v1.01 ROMs.

zaphod77 wrote on 2026-09-14, 22:41:

I've noticed. i'm happy for the collaboration. […]
Show full quote

I've noticed. i'm happy for the collaboration.

When this is all doen we will have the following ioptions.
1) Mame. wont' go ionto a daw withotu extra work, but peopel have doen it.
2) s-mu2000, which syncs better with daw,s but still emulates.
3)MUXG2K. non emulations version which can integrate with stuff.

There is also work on reversing the S-yxg50 engine, which may provide even greater performance, being a 32 bit native pc AWM2 engine capable of using 16 bit samples, though it doesn't actually come with any of them. I'm not sure waht the holdup is there.

MUXG2K is almost ready for the next build and another round of public beta testing. This week I've completed a long slog of work recreating each effect as efficient, native DSP that sounds like the hardware. These will replace the placeholder FX used in the earlier beta, so that's a big step forward.

Once refinement of the re-imagined AWM2 engine is complete, there should be more opportunity to replace some of the emulation-style code with pure C++ DSP and get closer to the efficiency of the S-YXG50 engine. Although, S-YXG50 only uses 8-bit PCM, so it's inherently lighter than the hardware DPCM we're dealing with.

I did initially look at reverse-engineering the S-YXG50 engine, but it's a big challenge. It's limited to a maximum of two elements, so I think it would need significant development to support anything beyond the standard XG/MU50 ROM voices. It also doesn't really share much with the MU50 hardware at all.

It would be a cool pure .DLL reverse-engineering project if they can complete it, though. The code is crazily efficient from what I saw of it before deciding that it wasn't the right route for getting to the full MU2000 voice capabilities and covering everything from the earlier XG generation.

kode54 wrote on 2026-09-15, 11:55:

My bad. I was mistaken about what the verify_roms.py script did, which was packaging a mu2000.zip with the v1.01 ROMs.

Yeah MU1000, MU2000 and MU20000EX are all the same tone generator + same samples. MU1000 and MU2000 both use the SWP30 with the same 32 MB wave ROM (4×8 MB: xv364/xv365/xw848/xw849). Any EX voice, FX etc is just a new parameter combination over existing samples and logic.

It's practically indistinguishable from my MU2000 now, from the past 72+ hours of A/B-ing various examples over the years.

Some of us have waited for this to exist for over 20 years and it's finally here! 🤣

But yeah, definitely emulating a full CPU, even with optimizations, is always gonna be heavier. But it's basically a substitute at this point. Was thinking of attempting to do a WASM build but after seeing the interpreter performance first-hand with the VST2 experiment, I'll leave that to someone else more willing to waste time 😁

Hey folks. I have a MU50 and MU80 converter to S-YXG50 up and running but it needs testing
github.com/Soundshock/SXG-Create

The data tables for MU50 and S-YXG50 are essentially the same. MU80 tables contain all the same information as MU50 ones, but packed differently, so they should work well too
It creates a custom table that can be used with Veg's version. After all the sample conversions, the waveroms come out at 6.5 MB and 12.5 MB, respectively

Seems to work, but i get loop too long errors with the mu80 roms. so it seems only the mu50 roms are 100%?

Some of the MU80's pads don't quite fit, so they have a slight click when they loop. Though the Halo pad takes like 4 seconds to loop and the click is not too bad when it happens. It could be improved with a little hand-adjustment, and moving the loop point forward would allow for more of the overall sample to be played because of the weird way it works

Targeting one of the bootleg Russian engines would likely fix it properly

I suggest targetting ymf-754 Hi-end as that one still has working GS support. TyRUS and Vampire broke gs bankswitch.

i can provide it if needed, send a PM.

What yamaha seesm to have doen is drop everythgin tht was 16 bti donw to 8 bit. stuff that wqas already 8 bit was unchanged.

so all you need to do is upgrade the samples that are 16 bit in mu 50 but 8 bit in syxg50, and keep the ones that were always 8 bit to start with unless you can find clear differences, as they should be correct. This may restore the DOC stuff.

I'll look for that one, I have a bootleg called the "YMF724 44100" but the engine is stock as far as I know, I think it just upsampled everything by two and then edited the existing 4.1MB table in place to make it work

The MU80 is the one with the most 16 bit samples, those super long pads are all 16-bit PCM. The later MUs would never be that wasteful of valuable ROM space again, the MU90 crams a lot more into the same 8MB.

The DOC stuff I purposefully left alone, if there's interest I can try to preserve it but I'm not sure I can reuse the original mapping. I'm not sure I know even what it is? Some sort of pre-GM thing?

If you've confirmed that none of the gs, mt32, or xg patches actually use it, then i suspect it's just leftovers.

My question is were there any patches in the mu80 that were 16 bit while the same patch in the mu50 was 8 bit to save space? pretty sure the pads would be 16 bit already even in mu50

the important thing is that this is the same engine used by tyrus. the 754 hi-end. that means it WILL take even bigger samples. so it should be able to take the entire mu80, or even mu-90, though it won't support the newer effects.

zaphod77 wrote on Today, 03:28:

My question is were there any patches in the mu80 that were 16 bit while the same patch in the mu50 was 8 bit to save space? pretty sure the pads would be 16 bit already even in mu50

The samples have been greatly reworked between the MU80 and MU50 so it's a little bit apples to oranges, but yes in some cases. The MU50 doesn't use 16-bit samples at all, it uses 12 bit or 8 bit instead

Seriously? Then how come when I ran an extractor on the mu 50 I got some 16 bit wav files? some of which go clear to the top. is there a fault in the extractor i used?

It does use 16 bit samples. But also a lot of 8 bit samples. The software synthesizer doesn't even support 12 bit samples.