Talk has began already in XG Emulation thread. You are supposed to dump your own rom.

SuperDeadite wrote on Yesterday, 11:50:

Talk has began already in XG Emulation thread. You are supposed to dump your own rom.

thats going to be impossible, im not able to do that at all, with needing to dump a personal rom, that thing is only hiding with collector's..

Nic-93 wrote on Yesterday, 12:13:

SuperDeadite wrote on Yesterday, 11:50:

Talk has began already in XG Emulation thread. You are supposed to dump your own rom.

thats going to be impossible, im not able to do that at all, with needing to dump a personal rom, that thing is only hiding with collector's..

have a look here https://mdk.cab/game/mu2000

google is your friend!

zapbuzz wrote on Yesterday, 12:18:

Nic-93 wrote on Yesterday, 12:13:

SuperDeadite wrote on Yesterday, 11:50:

Talk has began already in XG Emulation thread. You are supposed to dump your own rom.

thats going to be impossible, im not able to do that at all, with needing to dump a personal rom, that thing is only hiding with collector's..

have a look here https://mdk.cab/game/mu2000

google is your friend!

actually, i was suspecting those could be used as well.

You can dump the control rom from the 2000ex firmware updater. they provide a python script. Said firmware updater is hosted as an attachment in a mu2000 thread on here.

They also expect you to actually flash custom firmware using that same updater to your device to dump the PCM rom from your own unit over USB or midi cable, then reflash the 2000ex firmware update.

The other rom files are grabbable from the mame romset.

The emu author deliberately does not provide a tool to turn the mame control rom into their expected format. you are supposed to dump it yourself.

compiler i used to compile this.

https://github.com/skeeto/w64devkit/releases/ … 64-2.9.1.7z.exe

extract. add the bin directory to system path. run make in a command prompt inside the project directory.

creates static binaries.

you also need to install python to use the rom tools.

The issue i opened revealed by the final fantasy vii soundtrack has been fixed, and the patches should make their way back into mame.

this guy is good.

also, i will not distribute the reconstructed flash rom required to use this, as per the emulator authors wishes, and no one else here should either. you must find your own copy of the firmware update, and use the python tool.

I can help with the firmware updater, though. Official download here.

https://jp.yamaha.com/support/updates/mu2r1_uw.html

Note that you can actually install python through the windows store on windows 10/11.

to run the emulator, place the roms in a rom subdirectory, and run gui.exe <roms directory name> from a command prompt. You can bind it to virtual midi ports by clicking on the midi in a circle. the built in midi player doesn't handle dual port midi files (yet). you need to use a player that does to play them back.

I build the emulator succesfully. using the devkit linked above.
At least, only the x64 devkit made all the binaries, and the x86 devkit made it until it tripped at rec.exe.
Prepared the roms: 4MB flash (MD5: ab2837aedbe40b853ff13382e2edecfb ) / 4x8MB Wave / LCD files. And pass the "roms" folder parameter were required.
But I hear no sound at all regardless. On Windows 7 x64.
Gui.exe LCD says: "Didn't start" in japanese. on an otherwise black LCD background.
Annoying that the program gives no reason, or no reason that I can practically translate.

Guess I will just be patient....

you have to place stuff in the proper subdirectories.

the four wave roms need to be in dump subfolder, and the sine_table.bin needs to be in standin subfolder.

i have a converter that converts the standalone wave rom properly written in python. it also makes the subfolders and copies the roms to them.

If allowed to, i will post it. 😀

zaphod77 wrote on Yesterday, 17:16:

you have to place stuff in the proper subdirectories.

Directories are proper, see below.
If the MD5 checksums are the same as yours, then we can assume the files are identical
https://emn178.github.io/online-tools/md5_checksum.html

1FILE---------------SIZE-------MD5-HASH------------------------
2\S-MU2000dev-x64\build
3blocktime.exe      3.158.177
4boot.exe           3.116.267
5gui.exe            3.704.463
6live.exe           3.287.848
7midisend.exe         540.646
8panel.exe          3.153.130
9rec.exe            1.100.137
10render.exe         3.152.008
11statetest.exe      3.155.766
12verify.exe         3.009.157
13vst3probe.exe        738.801
14
15\S-MU2000dev-x64\build\roms
16mu2000_flash.bin   4.194.304  557c7535d156084995821fea2229d5ae
17hd44780u_b04.bin       4.096  5c78e97050847f710a6d409294670166 (Mame archives)
18- or - 
19hd44780u_b04.bin       4.096  d6286ca7f3a367a9111b67d69335f518 (Standin supplied with source)
20
21\S-MU2000dev-x64\build\roms\dump
22xv364a0.ic49       8.388.608  f48fc84f53954a8dc5558c6c7fa1b9ce
23xv365a0.ic50       8.388.608  94e5be3a59d8a284f2861c81623cda2a
24xw848a0.ic53       8.388.608  6de970b27ed9ea8ccf0872aa5a118b09
25xw849a0.ic54       8.388.608  fde667737179c1b5d754635efa4827fa
26
27\S-MU2000dev-x64\build\roms\standin
28sin-table.bin         65.536  3598bbe31f9e7fcff8916e78747d035a

Edit: Corrected hd44780u_b04.bin location / removed mulcd.svg / used two known-to-work hashes stated by zaphod77

hd44780u_b04.bin does NOT go in standin

it goes in roms

zaphod77 wrote on Yesterday, 18:57:

hd44780u_b04.bin does NOT go in standin
it goes in roms

I see, You are correct of course. Thanks!
"roms/hd44780u_b04.bin` | LCD character data (use stand-in if missing)"
In practice though, it makes no difference here, still "Didn't start"

wrong files.

correct hashes

C:\mu2k\roms>certutil -hashfile mu2000_flash.bin MD5
MD5 hash of mu2000_flash.bin:
557c7535d156084995821fea2229d5ae
CertUtil: -hashfile command completed successfully.

C:\mu2k\roms>certutil -hashfile hd44780u_b04.bin MD5
MD5 hash of hd44780u_b04.bin:
5c78e97050847f710a6d409294670166
CertUtil: -hashfile command completed successfully.

zaphod77 wrote on Yesterday, 19:16:

MD5 hash of mu2000_flash.bin:
557c7535d156084995821fea2229d5ae

That is the problem right there. Thanks. Why did the Python script give me a different file? I will try again.
I edited my listing above to reflect what it should be.

that is very strange.

will sent a tool that worsk with the mame roms.

zaphod77 wrote on Yesterday, 19:39:

that is very strange.

will sent a tool that worsk with the mame roms.

i see it now, I initially only fed the 4MB file to the python script, but not the small 50kB one.
EDIT: I am in business. LCD comes up and midi-goodness is heard!

yeah, you have to feed it both of the YDL files.

as for the other oen you are probably usign a standin. the hash i posted is for the mame rom font.

The 64-bit build sounds very good.
Though in case someone was thinking of trying it in older OS'es: The 32 bit build sounds wrong. Then, Live.exe and GUI.exe interface with AVRT.dll, which is a Vista+ component.

Given the CPU usage I doubt an era-accurate PC from WinXP or earlier days would be able to play music with S-MU2000 in real-time 😁