New Documentation: An authoritative reference on the YM2612

Lord Nightmare · Post by **Lord Nightmare** » Fri Nov 21, 2008 4:14 am

I did top-illumination using a 1940's binocular scope (my mom used it in medical school in the 1970s) by taking one eyepiece lens out and sticking a flashlight in the hole (being sure it didn't fall in and scratch something). It DOES work, but only so-so; you get a lot of light from the second eye directly back up the remaining one without hitting the die at all. I don't know what the maximum magnification possible is, but it is probably somewhere around 400x-500x, or maybe more with oil immersion.

LN

Jorge Nuno · Post by **Jorge Nuno** » Tue Jan 27, 2009 3:54 am

bump!

I'm quite interested to know what pin #10 on the 2612 is..., It says in wikipedia that it's a not connected pin, the genesis1 VA0 schematics don't mention it, but! It has internal resistance to both +V e Gnd (around 90kOhm, depends slightly on the measure polarity when it's powered off).

Powered on and playing stuff gives 4.85V (not sure if it's steady, or if has some AC on top)

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

IIRC, this pin is tied to the ReadyBit of chip, useful for hardware based timings (which I would not like, as I can do something useful while I wait for the chip to become ready).

Jorge Nuno · Post by **Jorge Nuno** » Tue Jan 27, 2009 12:13 pm

Humm? Maybe you are talking about the IRQ pin. That is #13. Pin #10 is nowhere mentioned about.

It could be apparently the not-so-important /Test pin, like the one in the 2608 translated pdf, (It says it has an internal pullup).

Nemesis · Post by **Nemesis** » Wed Jan 28, 2009 6:18 am

I've seen some references which do in fact refer to pin 10 as the "Test" pin. I think I mentioned it in passing somewhere in this thread. TmEE is right about its function. What it does is return the real-time state of the "busy" flag from the status register. It's an output line which is asserted when the YM2612 is busy, and negated when the YM2612 is ready to receive a write. You could use it in a circuit to detect when the YM2612 is ready to receive the next write, without having to read and decode the status register.

Nemesis · Post by **Nemesis** » Wed Jan 28, 2009 6:53 am

Oh, and seeing as I was going to bump this thread myself soon, I might as well mention that I've got another round of info coming up, including a lot of fixes for the envelope generator. I'm very close to completing some extremely comprehensive testing which I'm using to build a binary-accurate envelope generator. When I carried out my original tests on the envelope generator, I didn't know enough about the rest of the chip to digitally sample the output from the envelope generator, but the process of fully breaking down the operator unit and the phase generator, as well as more experimentation with the test register, now allow me to perform tests where I can determine the exact digital output from the envelope generator easily. As a result, I've started from scratch with the envelope generator and re-tested everything, plus gone much further and tested a lot of stuff I wasn't able to test before.

I've spent the last few weeks running an extremely comprehensive tests designed to determine exactly how, where, and when the envelope generator carries out all of its operations, and as a result, I'm very close to building a perfect YM2612 envelope generator. By that, I mean an envelope generator which perfectly emulates the YM2612 envelope generator output under every operating condition, including when any register change occurs at any point, and when those register changes are combined with all the 1001 strange cases that can occur in SSG-EG mode, including when an attack phase is used.

And yeah, the MAME core will require a lot of fixes to incorporate these changes. I had to rewrite my own envelope generator from scratch to accomodate them. Virtually everything about my SSG-EG implementation was wrong, and the way a lot of it is implemented is surprising. The payoff is worth it though. I know enough about the envelope generator now to contruct some truly evil tests, and I know how to make them all pass. You won't have to worry about any games having envelope-related issues after this. In fact, when I release my core, I dare anyone to find any case in which my YM2612 doesn't produce a binary accurate output.

Eke · Post by **Eke** » Wed Jan 28, 2009 9:19 am

Nemesis wrote: And yeah, the MAME core will require a lot of fixes to incorporate these changes.

can't wait for it

everything seems very promising, huge thanks for your effort Nemesis

Christuserloeser · Post by **Christuserloeser** » Wed Jan 28, 2009 10:29 am

I would like to thank you as well, your work means a lot to me.

dr. apocalipsis · Post by **dr. apocalipsis** » Wed Jan 28, 2009 9:14 pm

Can't wait to see it fully implemented in current emus ^^

Snake · Post by **Snake** » Thu Jan 29, 2009 2:17 am

Nemesis wrote:Virtually everything about my SSG-EG implementation was wrong, and the way a lot of it is implemented is surprising.

It's definitely the strangest part of the chip, and as I said before, doesn't do what you'd expect in a lot of situations. You've nailed all cases now though? That's pretty cool. I ended up testing just the ones I knew were used because the only way I had of testing was (convert rom to SMD, copy to floppy, load floppy in SMD device) and it was taking me DAYS to get through all this stuff

But I don't even have that anymore so I'm looking forward to your findings. AFAIK it's the last bit of the chip that I don't have 100%. Well, ignoring the DAC distortion.

GManiac · Post by **GManiac** » Thu Jan 29, 2009 3:12 am

Hi all. I hope next information will be useful.
Many years ago I noticed that music of After Burner sounds poorly in emulators. I didn't know about this great research on YM2612. It seems that the latest versions of Fusion or Regen are made with a glance of new info from this research, but it didn't affect sound in After Burner.
There is some instrument(s) that doesn't play in emulators. Simply listen to song "Super Stripe" on real hardware and you'll feel the difference.

Snake · Post by **Snake** » Thu Jan 29, 2009 10:19 am

GManiac wrote:It seems that the latest versions of Fusion or Regen are made with a glance of new info from this research

No, in fact I was going to suggest that this topic gets renamed once Nemesis is ready to post his new info, because as he has now stated, most of the stuff in here is completely wrong.

GManiac wrote:There is some instrument(s) that doesn't play in emulators. Simply listen to song "Super Stripe" on real hardware and you'll feel the difference.

If true this is very odd.

GManiac · Post by **GManiac** » Thu Jan 29, 2009 3:12 pm

Here is the recording from my chinese MD2 clone (for some reason it sounds better than even MD1 HD).
http://shedevr.org.ru/ghost/After_Burner_II_-_SS.ogg

Snake · Post by **Snake** » Thu Jan 29, 2009 7:33 pm

Thanks - I know this tune very well (second cart I bought

) and briefly listened to it in Fusion last night. The sounds are all there, but yes, one or two of them are barely audible. The music in this game is mixed at a very low volume so that the PSG samples can be heard at a decent volume. At first glance it looks like some of these sounds are louder on the real thing simply because of the distortion that occurs in the real chip. That really does need to be figured out...

GManiac · Post by **GManiac** » Thu Jan 29, 2009 10:35 pm

I noticed that those "instruments" are very quiet too, and I listened to only them, turning off other channels in Winamp plugin. But when I listened to hardware, its sound was more wealthy, that's why I thought that something is not playing in emulators. Although all channels are present in emulators and some of them are quiet, the main reason of poorness is not in their loudness.
At this time I cut PSG (drums) and channels 1, 2 from VGM file and recorded its playback.
Here's the files:
http://shedevr.org.ru/ghost/After_Burner_SS_Cut.zip
Seconds from 2 to 16 in Kega's playback were amplified by 3 to normalize loudness. As you see, these seconds differ sufficiently from hardware playback. Even if this all is tricks of incorrect loudnesses

(of course, no, sounds are too different) it should be corrected.