MoonSound YRW-801 ROM samples/instruments ripped to files?

Champion (444)

13-10-2013, 17:52

I got hold of a MoonSound cartridge recently (thanks Marq!) and was quite surprised by the quality of some of the music disks. I thought, I'd like to try making some tunes myself, but I'd like to use some other tools than just a General MIDI sequencer + sampler, or Moonblaster wave. The thing I have in mind, is to be able to use a tracker like MilkyTracker, but so that I'd be able to use the Moonsound's ROM sounds as well as my own custom samples, then save the song as a 24-channel MOD and write some kind of a converter and player. Seems like a long project...

But anyway, the first thing I need to do is to extract the samples from the ROM into something that MilkyTracker can read. I found usable-looking stuff in the OPL4 sound driver module in the Linux kernel
https://github.com/torvalds/linux/blob/b3a3a9c441e2c8f6b6760... (sound/drivers/opl4/yrw801.c)
https://github.com/torvalds/linux/blob/b3a3a9c441e2c8f6b6760... (sound/drivers/opl4/opl4_local.h)
The idea is to take the opl4_region structs regions_xx from yrw801.c and then write out an instrument+samples definition file for each struct, and extract the sample data from the actual ROM file.

I have some questions:
1. Has someone already done this, and has the instruments extracted as individual files or a sound bank that could be loaded into a music application? Or does anyone have other ideas?
2. Is anyone interested in creating new music for the MoonSound, using a method like I explained above?
3. How big is the MoonSound installed base... ;) I mean, how many people are able to listen to this stuff anyway.

Por mars2000you

Enlighted (6481)

13-10-2013, 17:57

As MoonSound is (almost) perfectly emulated in blueMSX and openMSX, everybody can enjoy these great musics !

Por yzi

Champion (444)

13-10-2013, 18:08

Yes, I know. But based on my quick comparison, the real thing sounds nicer, somehow a bit more rounded and pleasant, and the emulated sound is harsh. Something to do with the D/A conversion and other analog circuitry obviously.

I also don't like to do stuff for the "emulator scene", so to speak. I mean, of course I could make something for some totally obscure piece of hardware that nobody actually has, but for which there's an emulator... but I don't think that would make any sense. That would remind me of a recent demoparty where a group had made a demo for "Amiga"... The organizers couldn't get it to run, and it turned out they had used a WinUAE setup with an 060 and 1 _GIGABYTE_ of RAM. I think the reason WinUAE even allows to create something as ridiculous as that is because it might have been theoretically possible to build a system like that from an Amiga 4000 and stuffing it full of memory expansion Zorro cards. They ended up showing the demo with WinUAE.

Por yzi

Champion (444)

13-10-2013, 18:40

Hmm. It looks like the Linux module doesn't contain the memory offsets. Maybe I'm better off stripping this stuff from OpenMSX.

Por mars2000you

Enlighted (6481)

13-10-2013, 18:49

If you use openMSX, the sound is indeed less pleasant than on blueMSX and if you compare blueMSX to the real thing, there are still some differences due to the things you've mentioned, but blueMSX is closer to the real thing.

Por yzi

Champion (444)

13-10-2013, 19:35

Apparently, some of the patches ("sounds") like for example "Honky-Tonk Piano" as defined in regions_03 in the Linux kernel module, use two simultaneous voices (channels) per MIDI note, and this has been done by specifying multiple overlapping note regions... I guess such sounds have to be converted to two separate MilkyTracker instruments. My idea is to keep a one-to-one mapping between the tracker's channels and MoonSound voices.

I wonder where the Linux instrument definitions come from. Are they original work by the kernel module author, or copied from some Yamaha stuff? I think it's said somewhere in the Moonsound documentation that there's no documentation available for the ROM chip. I'm still looking for corresponding definitions in OpenMSX's sources.

Por yzi

Champion (444)

13-10-2013, 20:05

(Hack log continues.) Maybe what I want can be taken from OpenMSX's YMF278 (=OPL4) emulation code, from the YMF278::Impl::writeRegDirect() method's case 0 in switch ((reg - 8) / 24), starting from how the "base" variable is calculated.
http://sourceforge.net/p/openmsx/openmsx/ci/master/tree/src/...

And actually the wave data is explained here ("WAVE DATA IN EXTERNAL MEMORY")
http://www.msxarchive.nl/pub/msx/docs/programming/opl4tech.txt

Por meits

Scribe (6543)

13-10-2013, 21:54

Not too much of a coder myself, but I'd like to leave my two cents here...
The Moonsound has a 2MB ROM with samples on it. Of course all those samples are very short fragments which need an envelope to get the sound of the end product.
That being said, here's a thing that got me thinking:
Way back in the nineties I used a little tool called -midi.com, two MSXes with a Philips Music Module connected MIDI-out to MIDI-in. The MSX with the MIDI-out connected running a MID player and the MSX with the MIDI-in connected -midi.com running.
The sound generated with -midi.com while playing a MID file was so totally different than what comes out of each of the two Moonblasters...
So I kind of guess it depends quite much on how you use the ROM sounds in your tracker/replayer to get anywhere near the sound you get out of Moonblaster and its replayer...
msd could tell you more about this as he maintains those Moonblasters since Moonsoft quit the scene.

Por yzi

Champion (444)

13-10-2013, 22:11

Thanks. I think I figured out the thing for the most part now. The Linux kernel module's GM patch definitions contain pointers to the ROM's contents, and each GM patch uses a number of "tones". A tone is one piece of a larger multi-sample program. There's a 12-byte header for each tone in the ROM, and the header contains pointers (memory offsets) to sample data in the ROM (including start/stop and loop begin/end points), and ADSR envelope values.

What I still don't know is, where did those definitions in the Linux kernel module come from. And how does the MoonSound software work - did someone have to dig through the ROM file and figure out how to use the hundreds of "tones"? It would be weird if Yamaha had just sold the ROM chips without any accompanying documentation, or a pre-made General MIDI mapping of the tones.

Tomorrow I'll write a program which dumps out the individual tones, so I can see which parts of the sample data are used for what. According to the documentation, the ROM file is supposed to contain ADSR envelopes and everything for each tone. So why does the Linux kernel module have its own ADSR data? And is the data the same as what can be found in the ROM file. We'll see.

Por Manuel

Ascended (19465)

14-10-2013, 09:51

(Getting off topic and taking the "bait"...)

mars2000you wrote:

Interesting remark. As far as I know the implementation is practically identical. And, as far as I know, blueMSX has no code to emulate a DAC or filtering due to analog circuits. In other words, I don't see a reason why it would sound different.

So:
- Are you sure about this?
- Can you quantify this with a recorded sample?
- Do other people also think this is the case?

Por mars2000you

Enlighted (6481)

14-10-2013, 09:56

Already discussed here :

http://www.msx.org/news/en/msxdev-compo-2012-3-no-pressure

Jorito wrote:

Manuel, you can compare the music's demo here:

In general the OpenMSX version sounds a bit more sharp, harsh than the BlueMSX one, that sounds more rounded.

The BlueMSX version sounds more pleasing to me and closer to the real sound I got through my Bose Companion II speakers while composing it on a real MSX.

snout wrote:

@Manuel - apparently there is a difference between theory and the actual experience, because to my ears blueMSX is also a lot closer to the real thing than openMSX.