Ripping YM2612 Instruments

superjoebob · Post by **superjoebob** » Tue Sep 18, 2012 2:30 am

Hey Guys!
I'm working on writing a tool that logs the chip writes in a VGM file so that I can plug them into my VST and essentially rip instruments from VGMs. The problem I'm having, is that the instrument doesn't sound much like the one it should. In particular, I'm logging the first major set of writes to channel 0 in Sonic 3's Icecap Zone 1 tune. I get a nice list of writes, but when I plug them into my VST they sound ridiculous. Is there something I could be missing? Does the 2612 have a particular initial state I should have it in to bring VGM instruments in?

foobat · Post by **foobat** » Tue Sep 18, 2012 4:08 am

I'm also working on this and have noticed some of the same behaviour. Do you get the same if you dump the state of that channel to .ym12 or similar with Gens kmod?

I have been trying (and failing) to parse the .ym12 format for a couple hours, does anyone know if there's a spec somewhere or an alternative?

Post by **KanedaFr** » Tue Sep 18, 2012 7:56 am

from GensKMod source :

Code: Select all

struct oper {
	unsigned char op_data[8];
	long op_padding[2];
};

struct voice {
	struct oper op[4];
	unsigned char	algo;
	unsigned char	fback;		
	unsigned char 	padding[14];
};

struct ym2612_KMod {
	struct 		voice ym;
	unsigned char	name[16];
	unsigned char	dumper[16];
	unsigned char	game[16];
}KM2612;

with

Code: Select all


/* operators data */
	for (op=0; op<4; op++)
	{
		KM2612.ym.op[op].op_data[0] = (UCHAR) (YM2612.REG[part][0x30 + chan + 4*op])&0xFF;
		KM2612.ym.op[op].op_data[1] = (UCHAR) (YM2612.REG[part][0x40 + chan + 4*op])&0xFF;
		KM2612.ym.op[op].op_data[2] = (UCHAR) (YM2612.REG[part][0x50 + chan + 4*op])&0xFF;
		KM2612.ym.op[op].op_data[3] = (UCHAR) (YM2612.REG[part][0x60 + chan + 4*op])&0xFF;
		KM2612.ym.op[op].op_data[4] = (UCHAR) (YM2612.REG[part][0x70 + chan + 4*op])&0xFF;
		KM2612.ym.op[op].op_data[5] = (UCHAR) (YM2612.REG[part][0x80 + chan + 4*op])&0xFF;
		KM2612.ym.op[op].op_data[6] = (UCHAR) (YM2612.REG[part][0x90 + chan + 4*op])&0xFF;
	}

	/* channel data */
	KM2612.ym.algo = (UCHAR) (YM2612.REG[part][0xB0 + chan])&0x07;
	KM2612.ym.fback = (UCHAR) (YM2612.REG[part][0xB0 + chan])&0x38;
	KM2612.ym.fback >>=3;

hope this help, I wrote it 5 years ago

don't ask me why I used padding (I'll say "for future use ?")

TmEE co.(TM) · Post by **TmEE co.(TM)** » Tue Sep 18, 2012 9:27 am

it is exactly like TYI format I use in my sound system haha, including the padding, except I fill it with "TYI"

Charles MacDonald · Post by **Charles MacDonald** » Wed Sep 19, 2012 4:58 am

I always thought one of the problems with ripping instruments was that games with more complex music drivers manipulate a lot of the register settings in real time.

This is opposed to older games that only touched the total level (volume)/frequency registers and kept the other settings nearly constant. Sounding more like a FM synth in that regard.

Maybe that's not actually the case though? It would be interesting to isolate a particular channel and see what registers change before and after a key-on event until key-off when a particular instrument is used.

Might be easier to rip instruments from something old and crappy (any Electronic Arts game) first before trying a modern game like Sonic 3.

neologix · Post by **neologix** » Wed Sep 19, 2012 6:15 pm

Charles MacDonald wrote:It would be interesting to isolate a particular channel and see what registers change before and after a key-on event until key-off when a particular instrument is used.

That's been my plan for the instrument ripping in my upcoming VGMTool update, but a few months back I was informed that there do exist a couple other registers besides Total Level that can modify the sound during playback instead of waiting until the next Key On after a Key Off. I don't have the list in front of me, tho. I do still intend on handling those cases even if I save them for the end.

superjoebob · Post by **superjoebob** » Wed Sep 19, 2012 8:32 pm

Charles MacDonald wrote:I always thought one of the problems with ripping instruments was that games with more complex music drivers manipulate a lot of the register settings in real time.

This is opposed to older games that only touched the total level (volume)/frequency registers and kept the other settings nearly constant. Sounding more like a FM synth in that regard.

Maybe that's not actually the case though? It would be interesting to isolate a particular channel and see what registers change before and after a key-on event until key-off when a particular instrument is used.

Might be easier to rip instruments from something old and crappy (any Electronic Arts game) first before trying a modern game like Sonic 3.

I actually want to provide a tool in my VST to play back VGM files and filter out which channel you want. When the channel sounds the way you want it, you could push a button to rip the instrument as it is. Obviously nice wavering effects from register writes and stuff like that wont come through this way but that's not too big a deal. Ripping from a simpler game is probably a good idea, I notice a lot of frequency writes happening constantly in the VGM file for the bass instrument. The good news is I ALMOST have the exact same sound now, just missing a bit of treble for some reason, still trying to figure that one.

I suppose its worth noting that the clock value written to the VGM file is pretty important for getting the same sound as well. Or is there some way to avoid this altogether? I found the Icecap zone file had a really weird clock rate, like 2,500,000 or something low like that.

superjoebob · Post by **superjoebob** » Thu Sep 20, 2012 6:24 pm

Update! I got the instruments reading faithfully, only a few instruments I've tried to rip so far have behaved strangely. The main issue is I had a "& 14" instead of an "& 15" on the unpacking of my MUL parameter. Yeah I know

. Doesn't seem like the clock value in the VGM made any real difference either, though I'm still playing with it so who knows. Any luck with yours foobat?

foobat · Post by **foobat** » Fri Sep 21, 2012 4:06 am

I got distracted by implementing midi support and connecting some EEPROM to my circuit so I can actually store ripped instruments, so I haven't made any progress yet.

I didn't notice the clock value in the VGM file having any effect either. I can't imagine what it's for.

edit: I started thinking about it and I found this post: viewtopic.php?t=125&postdays=0&postorder=asc&start=58
I got vgm2tfi to make instrument dumps from VGMs. This looks like the easiest way to do it, no work involved. .y12 and .ins would be just as easy.

foobat · Post by **foobat** » Sun Sep 23, 2012 1:26 pm

vgm2tfi turned out to be a giant PITA so I scrapped that idea and just made my synth work via packed .opm files. It was only dumping the first 44 bytes of any vgm and not the operator registers. Luckily someone made OPM files out of just about every single Megadrive game already on project2612.org so that means I have way more instruments than I can possibly fit on my eeprom.

vext01 · Post by **vext01** » Thu Sep 27, 2012 8:38 pm

On a related note: I wrote some code in dgen-sdl that allows you to dump the OPN parameters of the sounds chip in it's current state. It is in the git head version.