Driving a YM2151 FM synth chip


alex

Recommended Posts

Or Vdd*2-17, haha, go math! No, I see it clearly now, "amplitude" means swing, so when considering "amplitude" one must consider the swing from a given minimum value to another maximum value within a time interval. I was making the mistake of only looking at a single point which is not "amplitude" by definition.

Link to comment
Share on other sites

Idle hands are the devil's playthings they say... I wonder how hard it might be to go all out Borg and assimilate the YM2151 into the FPGA, I mean the FPGA has eaten all the other parts already, resistance may well be futile. Is anyone aware of, or can they get their hands on an implementation of the YM2151 in either VHDL or Verilog? My google-fu was not strong enough to find any. I'd hate to try and make sense of the datasheet if I don't have to, looks pretty scary :)

Link to comment
Share on other sites

As far as I can tell, all of the random devices are here: https://svn.pacedev.net/repos/pace/sw/src/component/

 

As for licensing, the code bits are pulled from all over the place. Some stuff is from fpgaarcade and some is from other places, so you'd have to look at the individual files on a case by case basis.

 

I poked around on pacedev a while back and had a hard time making sense of what they're doing. It seems the goal is to synthesize arcade games on a few specific boards, mostly Altera stuff and then the fpgaarcade Replay board. The individual components are fragmented though and I couldn't see an easy way to determine which parts are needed to synthesize a particular hardware platform without being very familiar with the hardware in the first place. Also they are doing things like rotating vertical games to play on a horizontal monitor, and resolution scaling. I don't really get the point of using an FPGA to authentically synthesize the hardware and then mucking with the results, it'd be easier to just run MAME if you just want to play the games and don't care about absolute authenticity.

Link to comment
Share on other sites

I'll venture a guess that PACE is something built out of of passion for old arcade hardware, not

to accurately represent all of it.

 

It has been around quite a while and deserves it's place just like fpgaarcade.com does.

 

The PACE svn archive really is quite a treasure for anyone interested in old arcade games.

 

br,

-V

Link to comment
Share on other sites

I would love to get the pacedev working on the Papilio, but when I took a look at the code I never really made heads or tails or where to even start... I tried to contact the developers but their forum is closed to new registrations... It seems like it would be really cool, and it should run on a PPro with Arcade MegaWing...

 

You are right about the copyrights, they are all over the place... It took me several days of googling and digging to figure out who the author of the SID core was. It originally came from pacedev but I had no idea what the copyright was. I finally found a really old commit message that had a name, I was able to contact the guy who confirmed he wrote the core, it was GPL, and he was ok with us using it with the Papilio and retrocade... Was a very nice guy, but man it was tough to track him down.

 

Jack.

Link to comment
Share on other sites

I did a bit of detectivework. The PACE forum admin is Mark McDougall with a page http://members.iinet.net.au/~msmcdoug/ that lists his email address. In his post about disabling new registrations due to excessive spammer requests he mentions contacting him if you'd like to join. There is some other interesting stuff on Mark's page too.

 

I tend to assume that if code is out there, it's probably ok to use. I'm not making any sort of commercial products though.

 

Anyway if you want to work on porting this stuff to the Papilio, my suggestion would be to rip out all the PACE framework and cpllect the necessary components for each hardware platform together in one place. It will result in some redundancy of course but vhdl files are tiny and that's a small price to pay for not having to hunt down all the bits and pieces needed to assemble a particular platform. Another advantage is that changes to one platform won't break all the rest.

Link to comment
Share on other sites

Well after finishing this mini project I was very sad because the Double Dragon only has a handful of (not really that great) songs it can play over the YM2151 chip. I started looking around "teh nets" for more YM2151 music and eventually I arrived in Japan so to speak. I guess since Yamaha is a Japanese company it makes sense that it was adopted as the chip of choice on local computer systems. One such very popular system is the Sharp X68000 which as the name suggests, is based on a 68000 CPU.

 

The cool thing about this system is that it has vast amounts of music created for it, here is a hard disk image with over thirty thousand music files on it. The music is in an MML (Music Macro Language) format and typically has an extension of .MDX

 

In fact there are two types of files, .MDX and .PDX and after a fair amount of looking into these formats it turns out that while the MDX files are the Music Macro files, the PDX files contains sampled sounds that can accompany the melodies produced via FM modulation through the MDX files. In fact the PDX files contain 4 bit ADPCM data and they could be directly feed into a chip such as the MSM5205.

 

Another cool thing is that some very nice people have written and open sourced an MML parser that can read MDX/PDX file combos and play them via a software implementation of the YM2151 chip and some generic ADPCM decoder. It is at this point that my other post comes in.

 

With such vast amounts of YM2151 music it was only fair to find a way to play them, so I took the source of the MML player and carved out the software YM2151 implementation (which was in fact copied from MAME's implementation of the YM2151) and only left the calls to initialize the chip and write to the registers. I then had the initialization call simply pulse the reset line to the chip while the write register calls the FTDI functions to transfer the register data to the FPGA which in turn writes it to the real chip.

 

The result can be seen in this 4 minute video. Hope you enjoy it! If the embedded video shows in portrait mode (tall and narrow) click on the youtube logo in the bottom right corner of the video and it will show properly in landscape mode.

 

Link to comment
Share on other sites

I saw thasega99 posted a youtube update a couple of weeks ago, so I left a comment asking him to share the verilog source. I'm really not holding my breath though, he doesn't seem like a sharing kind of person.

 

Meanwhile you could just compile mdxplay and just listen to them on your PC. I used the mdxmini source code from here which was very straightforward to compile but if you have issues shout out and I can help.

Link to comment
Share on other sites

  • 11 months later...

I have been working for a while in a reverse engineering board of the YM2151 in order to make a verilog clone of the chip. So far, I have a board with the YM2151, voltage-level translators to 3V and a Spartan 3A board connected to a PC via a serial wire. I can control the YM2151 from the PC but when I tried last weekend to get sound out of it I only got nonsense.

 

Having a look at the dac3012.v file of Tatsuyuki Satoh, I see that his DAC implementation is different from mine in two fundamental ways:

 

1. YM2151 SH1/SH2 outputs mark the latch event, not the start of data output as I had interpreted (actually, the data sheet is confusing because the text explains his point of view but figure 3 shows mine)

2. bit D9 is inverted in his implementation. I cannot see any justification for this in the YM3012 data sheet. This is a very important difference as it is reversing the sign of the code.

 

He also makes the bit shift of digital data in a dynamic way (with flip flops) rather than with the static way (digital gates) I had chosen. But this is really minor. More imporant is that he is extending down the MSB with his implementation, whereas I was filling it with zeros.

 

I still have not tried his implementation on the actual board so I do not know if it does sound good or not. I'll post about it later.

 

Alex, if you are still interested in doing the verilog clone of YM2151 I will be happy to join our forces.

Link to comment
Share on other sites

  • 11 months later...

Was there ever any further progress on this? I've been busy recreating sound boards for most of the late 70s-early 80s pinball machines and now I've come across the late 80s Data East boards which use the YM2151.

 

Ironically, I have a VHDL module for the MSM5205 speech decoder IC used in this one, speech is the stumbling point blocking completion of most of the other fancier 80s boards and they all use a different technique for the speech. Phonemic syntheis, CVSD, LPC and ADPCM.

Link to comment
Share on other sites

  • 5 months later...

Over one year has past since my previous post. Things like this happen in home projects, I guess.

I was able back then to sort out the mistery of the YM3012 by measuring the actual device. The verilog implementations that were published back then were indeed slightly mistaken. I published an entry on my blog about it (mostly in Spanish).

I have started to dump the output of the real chip in order to reproduce it as accurately as possible in the Verilog implementation I am working on. I read the digital data directly, before going through the DAC. The attached image is a sample sound of my first note out (read this blog entry for details).

I have also found the exact algorithm used to generate noise in the YM2151, again in a different blog entry.

I hope nothing will disturb me this time and I will complete the new verilog implementation of the YM2151/YM3012. I will release it to opencores when done, with English documentation and comments.

basic-c7.png

Link to comment
Share on other sites

  • 3 weeks later...

Archived

This topic is now archived and is closed to further replies.