New Documentation: An authoritative reference on the YM2612

[Snake]

Wow, huge post Kind of odd that you would post this right now. I have a ton of SSG-EG samples I did years ago, but I lost the test ROMs that created them, so I didn't know what I was looking at. This weekend I found them and spent most of it looking into this again. I'll read your post properly later and see if it matches what I came up with, a brief look says that some of it does, but there's stuff I didn't get around to yet that you've probably covered. So, all in all, I probably just wasted a weekend

All the other stuff seems to be correct, at first glance anyway.

[edit] ok, so the bits I hadn't gotten to yet seem to be the bits that make the least sense. "Surprising" isn't the word. Given what the thing is supposed to do, you'd have to be on crack to implement it this way. I don't doubt that what you posted does indeed match the output of the real chip - it does seem to explain exactly what I'm seeing (all except one case which I won't be able to confirm without testing). But I do wonder if there is another way of getting the same results from some of this, just because - well - it's pretty insane I'd be interested to hear more about how you came to some of these conclusions and the tests you did to verify.

These aren't bugs, simply areas of undefined behaviour where the result is not specified, because "you're not supposed to do that".

Not that it's important, but I would agree with you that writing to registers while the envelope generator is running is really something you're not supposed to do, and the odd things that can happen when you do this can't really be considered 'bugs'. But I disagree on the oddness that happens when AR!=0x1F. The fact that the documentation tells you to do that just strikes me as a "oops, we didn't test this" from Yamaha. Any sensible implementation of SSG-EG wouldn't have this problem, there should be no reason it's needed, and there's plenty of places where they could have, should have, and probably would have (if they'd thought of it) just forced the attenuation to zero - IF that was how it was originally intended to work. "You must use 0x1F" is a workaround, definitely a bug imo.

Note that existing emulators, including MAME and Kega, get a lot of the above implementation wrong.

Yeah, I thought I'd covered every case that was actually used, and planned to go further later, but then lost the ability to do so. Didn't know about that damn olympics game...

In fact, the envelope generator is updated once every 3 fm update cycles, which was the existing behaviour in the MAME core.

There's something that you could test. Fairly unimportant, but I believe the reason why it's 3 cycles is that the YM2203 updates the envelopes for channel 1 on the first cycle, channel 2 on the second cycle... The YM2612 probably does one channel from each 'half' every cycle.

[edit again] I missed this...

I've also figured out the cause of the different sound in Battletech track 12

I think there are a number of things that cause the difference, but this is I believe the main one.



This is a sample I produced long ago while investigating the detune bug, and the filters. Top is a Genesis model 1, bottom is a Genesis model 2. Throughout the entire test, everything is played at max volume. The large bars you see are a normal note which is in a range which does not get filtered at all, showing you what the actual output volume is supposed to be. Everything else is a note played utilising the detune bug.

All of the frequencies produced are the same on both consoles. But the filter in the Genesis 2 has a fair amount of ripple, whereas the Genesis 1 filter flattens out nicely. As you can see, most of the time the Genesis 2 filters out more than the Genesis 1. But the 4th, 5th and 9th note in this picture show the Genesis 2 letting through significantly more than the Genesis 1 does. The 5th note played is, I believe, the one used by Battletech. The Genesis 1 cuts out most of the high frequency created by using this note as a modulator, the Genesis 2 lets a lot of it through. As a side note, this would be much softer than it actually is on a Genesis 1 if it wasn't for the distortion created at this low volume.

[Snake]

1/ attack rate is set to 62 or 63: you say that the attenuation level is set to 0 but is the next enveloppe update done with Attack or Decay parameters ?

Decay. Attack is skipped immediately in this case.

2/ SL is set to 0: does EG enter the susbtain phase once or does it directly jump to release ?

I believe you mean 'decay' and 'sustain' here... Again, one phase (decay) is skipped and it goes immediately to sustain.

3/ what happen when both conditions are met: AR = 62/63 and SL = 0 ?

level set to zero, followed by sustain.

how is attenuation level generally handled when Key ON occurs , for example, if the "volume" has not reached 0 yet ?

Nothing happens, the level continues from where it was. This is true of all 'real' synth chips, including the good old SID chip. It's closer to how a real instrument works - softly tap a key on a piano and it will get louder each time.

what are default values (internals and registers ) on chip reset ?

I did a bit of testing on that many, many years ago. I don't recall fully, but I believe they are mostly undefined (if you reset the chip while it's playing, I believe the note continues unaffected), with the exception of the registers that control stereo, which seem to be set to allow left and right output for all channels, at least at power on. It's a good question, though...

[Eke]

again, thanks for the clarifications
this helps a lot

[HardWareMan]

I made a record Battletech Track 12 from my Model 1 for compare. Here is it. I keep it in original WAV, so you get lossless.
That high frequences is very interesting.


The amplitude can be distort becouse very small difference with sampling frequency (wich is 48kHz) and frequency of signal. But this signal still interesting.

Next, we have seen good old "ladder" effect on bass:

[Snake]

That's a really good capture of the effect, better than I've seen so far. How did you capture that?

[HardWareMan]

That's a really good capture of the effect, better than I've seen so far. How did you capture that?

Easy. Just connect earphone jack on MD1 to line in of my Audigy. Then set maximum volume on MD1 (to get maximal signal-to-noise ratio) and attenuate it on Audigy mixer. BTW, volume of this track not so loud, so I set all to maximum.

[Eke]

some more bits

I haven't found a neat way to emulate all this behaviour. I currently calculate the effective attack rate immediately when switching to the attack phase, and if the rate is greater than or equal to 62, I force the attenuation level directly to 0. I also have an exclusion in the normal envelope generator update cycle when updating the attack curve. If the attack rate is greater than or equal to 62, I don't advance the attack curve. This emulates the behaviour of the YM2612, but it probably isn't emulating the exact way this special case behaviour is implemented. I'm open to any suggestions about a neater way to emulate this.

What I did is to use the same increment values as when Rate is 0 (infinite rate), in the case Atttack Rate is 62 or 63 when rate values (increment and shift) need to be recalculated. And to immediately jump into Decay phase on Key ON (or SSG-EG loop restart) when Attack Rate is 62 or 63.

More than this, there is an order to the way the SSG-EG update steps during this output cycle interact with the normal envelope generator update cycle. For one of every three output samples, the envelope generator update cycle will occur along with the envelope generator update cycle. When that happens, the operations are performed in the following order:
1. The SSG-EG output cycle update steps are performed
2. The envelope generator update cycle runs
3. The output from the envelope generator is calculated

Can you confirm that output calculation also happen the same way with normal enveloppe ? Meaning that any change to internal attenuation level (for example on Key ON with AR=62,63) or to TL (on register write) will apply to the EG output calculation used for the next sample, even if no EG update was planned ...

Code: Select all

 else if((state->phase == OperatorData::ADSR_RELEASE)
         || !(state->ssgOutputInverted ^ GetSSGAttack(channelNo, operatorNo, accessTarget)))   //If the output is not currently inverted
      {
         //If the output is not currently inverted, and we've reached an
         //internal attenuation level of 0x200 in one of the decay phases
         //(either the decay, sustain, or release phase), but the envelope
         //is not looping back to the attack phase, we need to force the
         //internal attenuation value to 0x3FF. This emulates the behaviour
         //of the YM2612 when entering a low-hold state in SSG-EG mode, and
         //when the release phase reaches 0x200. In both cases, the internal
         //attenuation value is forced directly to 0x3FF. This has been
         //confirmed through hardware tests. Note that this step occurs after
         //the inversion state has been toggled. Performing these steps the
         //wrong way around would break SSG-EG pattern 0xB, where both the
         //hold and alternate bits are set, and the attack bit is clear.

         //Force the internal attenuation value to 0x3FF
         state->attenuation = 0x3FF; 

what happen in this case and more generally during the RELEASE phase for next samples update ? according to your algo, as attenuation level will remain higher than 0x200, this would mean the Invert flag could be swapped (even if output is not inverted during release) or the Phase counter could be reseted for each samples under some conditions...

isn't there a OFF state when attenuation reaches 0x3FF which turn the Enveloppe Generator off ? Or does the SSG-EG update process continue anyway ?

[SmartOne]

Then set maximum volume on MD1 (to get maximal signal-to-noise ratio) and attenuate it on Audigy mixer. BTW, volume of this track not so loud, so I set all to maximum.

Does the Genesis 1 HD max volume really produce the greatest signal-to-noise ratio? I thought about 75% was the most distortion-free...

[TmEE co.(TM)]

Its model dependant, some models have different headphone amp which starts distorting sound at over ~7. The model he has, has no trouble at max. The VA7 MD1 is one model which is very bad at higher volumes.

[Snake]

What I did is to use the same increment values as when Rate is 0 (infinite rate)

Indeed, it makes perfect sense.

Can you confirm that output calculation also happen the same way with normal enveloppe ? Meaning that any change to internal attenuation level (for example on Key ON with AR=62,63)

If what Nemesis says is 100% correct, then it follows that this must indeed be the case, or certain things would get broken.

or to TL (on register write)

TL is done independantly of the env anyway, so, yes, this will happen immediately.

according to your algo, as attenuation level will remain higher than 0x200, this would mean the Invert flag could be swapped

This is one of the parts I'm not yet convinced of. I can see where the thinking comes from because it solves a number of problems - then again, I've got a ton of samples that don't look like that is happening. It's possible that it is but I'd need to write some tests before I can say either way.

isn't there a OFF state when attenuation reaches 0x3FF which turn the Enveloppe Generator off ? Or does the SSG-EG update process continue anyway ?

It's highly probable nothing ever really 'stops'. There'd be no benefit in doing so.

[Nemesis]

Gah, more to say, not enough time. I'll reply to some more comments later.

Seems that YM2612 misses DAC writes or does not output them when the sample rate is too high... it is odd that when you wait for the chip to be ready, things will not sound too good....
32KHz sounds bad (and its around the rate you get when you wait for the chip). 26KHz (~half the YM2612 sample rate) sounds great though

Hmm, that is strange. It looks like the one running at the higher frequency has some additional noise on the output signal. I'll take a look.

what are default values (internals and registers ) on chip reset ?

I can't say I've done very thorough tests on this. I generally ran on the assumption that the registers were initialized to 0 on power-on. I found documentation stating this is the case for other Yamaha FM chips, and the same seems to be true on the YM2612, with the exception of the Left/Right flags, which are initially set as Steve mentioned (and would be on the YM2608 as well, presumably for OPN compatibility reasons). I didn't do any tests with triggering a reset after initializing the registers or anything like that however.

Not that it's important, but I would agree with you that writing to registers while the envelope generator is running is really something you're not supposed to do, and the odd things that can happen when you do this can't really be considered 'bugs'. But I disagree on the oddness that happens when AR!=0x1F. The fact that the documentation tells you to do that just strikes me as a "oops, we didn't test this" from Yamaha. Any sensible implementation of SSG-EG wouldn't have this problem, there should be no reason it's needed, and there's plenty of places where they could have, should have, and probably would have (if they'd thought of it) just forced the attenuation to zero - IF that was how it was originally intended to work. "You must use 0x1F" is a workaround, definitely a bug imo.

That depends on what you think their objectives were. You could say that having the attack phase officially supported and usable with the SSG-EG modes would have been a useful addition, and you're right, it shouldn't have taken a lot of work to do. I honestly don't think they ever planned on allowing the attack phase to be used with SSG-EG modes however, and there is reason behind that line of thinking.

It is important to remember that the SSG-EG mode is only provided in order to emulate the behaviour of the SSG envelope generator. The SSG module itself is based on the older AY-3-8910 produced by General Instruments. From the get-go, the purpose of SSG-EG wasn't to add new functionality, it was to emulate old functionality, and it was approached in that manner.

The AY-3-8910 effectively only had a linear decay cycle. It had a counter which was set to advance at a specified rate, and it progressed in a linear fashion. That was the spec. In this context, the attack phase is superfluous. Allowing an attack phase to be combined with SSG-EG mode was simply not required, and from some points of view, pointless. The designers would have been given the specs saying "we want the FM envelope generator to be able to mimic the behaviour of this chip", and they went off and designed a function that allowed just that, but the designers obviously didn't feel the need to go beyond that spec.

In this context, I would disagree with the statement that the strange behaviour we see when combining an attack phase with SSG-EG should be considered a bug. SSG-EG was built for a purpose, and the attack phase simply wasn't a part of it. They didn't want the attack phase getting in the way of the SSG-EG emulation, so the mandate was to set the attack rate to 0x1F, causing the attack phase to be instantly skipped, getting it out of the way and allowing the decay/sustain phase to emulate the linear counter of the SSG envelope generator without interference. I don't think this was an "oops" at the end, I think it was a conscious decision made early on in the planning stages, and as such, SSG-EG was built without regard for how it would interact with an attack phase.

There's something that you could test. Fairly unimportant, but I believe the reason why it's 3 cycles is that the YM2203 updates the envelopes for channel 1 on the first cycle, channel 2 on the second cycle... The YM2612 probably does one channel from each 'half' every cycle.

Heh, I hadn't thought of that. You're probably right. I'll do some tests for this.

I've also figured out the cause of the different sound in Battletech track 12

I think there are a number of things that cause the difference, but this is I believe the main one.

...

Yep, that's along the right line. The cause of the difference is in the analog domain, and it is triggered by high frequency tones. In the case of Battletech track 12, it's specifically the effect of volume changes on a high frequency tone that cause the problem. The tone effectively becomes a carrier wave for another wave which is generated by the volume changes. The MD2 has an imperfect output which causes these volume changes to produce an audible waveform, when they should in fact not be audible at all. I really need to post pictures and samples in order to explain it properly.

More than this, there is an order to the way the SSG-EG update steps during this output cycle interact with the normal envelope generator update cycle. For one of every three output samples, the envelope generator update cycle will occur along with the envelope generator update cycle. When that happens, the operations are performed in the following order:
1. The SSG-EG output cycle update steps are performed
2. The envelope generator update cycle runs
3. The output from the envelope generator is calculated

Can you confirm that output calculation also happen the same way with normal enveloppe ? Meaning that any change to internal attenuation level (for example on Key ON with AR=62,63) or to TL (on register write) will apply to the EG output calculation used for the next sample, even if no EG update was planned ...

Yes. Try using CSM mode with really quick timer periods (IE, one less than minimum) and you'll see this is true for key on/off changes. I can't say I've tested this for TL changes specifically, but I can say it is true for TL anyway, since TL is applied after output inversion, and I confirmed that output inversion happens every sample, so the envelope generator has to read TL each sample to apply it to the output.

[Snake]

Hmm, that is strange. It looks like the one running at the higher frequency has some additional noise on the output signal. I'll take a look.

It's probably writing to the DAC at around the same time the chip is trying to read it.

I can't say I've done very thorough tests on this. I generally ran on the assumption that the registers were initialized to 0 on power-on. I found documentation stating this is the case for other Yamaha FM chips

Yes, me too, and it's probably correct, at least on power on. I seem to recall hitting the reset line didn't clear things though (maybe it keyed all channels off?) - then again I've done so much of this stuff on different hardware over the last few years I could be thinking of an entirely different system

From the get-go, the purpose of SSG-EG wasn't to add new functionality, it was to emulate old functionality

Absolutely, and it definitely seems like it was tacked on at the end rather than built into the design from the start.

They didn't want the attack phase getting in the way of the SSG-EG emulation, so the mandate was to set the attack rate to 0x1F

Yes, but my point is that if they're already forcing the attenuation to zero when AR is above 62, why didn't they just force that all the time in SSG-EG mode? Or in plenty of other places where they could have done so? Leaving this up to the programmer in this way isn't something you'd usually expect to see.

In any case, the entire chip seems very well designed and logical - except for this bit, which is all a bit "WTF?"

[Nemesis]

[edit] ok, so the bits I hadn't gotten to yet seem to be the bits that make the least sense. "Surprising" isn't the word. Given what the thing is supposed to do, you'd have to be on crack to implement it this way. I don't doubt that what you posted does indeed match the output of the real chip - it does seem to explain exactly what I'm seeing (all except one case which I won't be able to confirm without testing). But I do wonder if there is another way of getting the same results from some of this, just because - well - it's pretty insane I'd be interested to hear more about how you came to some of these conclusions and the tests you did to verify.

Notes on a lot of the important hardware test cases are included in the source I posted. There are a few points which could be implemented differently to get the same result, but not a lot. I simply can't think of another way to implement some of the weirdest stuff.

Consider the way output inversion is tracked for example. A change to the attack bit always causes an immediate inversion of the output, and believe me when I say I tested this under every conceivable circumstance. The YM2612 doesn't reset the inversion state to the attack state on the write, since if you had a wave where ATT=0 and ALT=1, and it had toggled the output inversion state once since the wave began (so the output was currently inverted), and you then changed the ATT bit to set, the wave output would immediately switch to a non-inverted state. With that ruled out, the observed behaviour says to me that the attack bit is being combined with the output inversion state each cycle through an XOR operation, and the internal flag tracks whether the output has been inverted from the starting value, rather than representing the true output inversion state by itself. A slightly unusual choice perhaps, but that's what the evidence indicates, and it's a fairly simple operation by itself.

That has a few flow-on effects however. It simplifies the inversion exclusion for hold mode, since we now only have to test the boolean flag to determine whether the output has been inverted yet (since hold mode only ever allows the ALT bit to toggle the inversion state once), however it now means we have to combine the ALT bit with the inversion bit in 3 places in order to calculate the true, effective inversion state.

There are more impacts as well. Now we have to consider release mode. Output inversion is always disabled during the release phase, regardless of what the current state of the output inversion bit was, and the state of the ATT bit, when the release phase was entered. Ok, so output inversion is disabled during release, but how is it disabled? Since the output inversion flag now represents whether the output inversion state has been toggled from the base value given by the ATT bit, it's not as simple as clearing the output inversion flag when entering the release phase. If you clear the output inversion flag and the ATT bit is set, you still get an inverted output. Do you then load the state of the ATT bit into the output inversion state when entering the release phase? Wrong, since toggling the ATT bit during the release phase doesn't cause output inversion to kick in. This means we now need an extra test where we check the output inversion state. If we're in the release phase, the effective output inversion state is forced to false, so our test for output inversion is now something like this:
(phase != release) && (ATT ^ inversionBit)

Some other interesting choices are having the SSG-EG state updated on the output cycle rather than the update cycle. Perhaps this made the SSG-EG mode easier to integrate with the existing design. All the voodoo with 0x200 makes sense from the point of view of least effort, since they needed some way to hook their SSG-EG update process with the existing envelope generator. Sacrificing one bit of resolution from the attenuation value and using the upper bit of the attenuation as a flag for the SSG-EG update steps in the output cycle was the easiest way to achieve it, and a 9-bit resolution for attenuation was enough for what they were emulating anyway.

what happen in this case and more generally during the RELEASE phase for next samples update ? according to your algo, as attenuation level will remain higher than 0x200, this would mean the Invert flag could be swapped (even if output is not inverted during release) or the Phase counter could be reseted for each samples under some conditions...

There's no way to verify, at least that I can think of. Since the effective output inversion state is always forced to false when the release phase is active, there's no way to sample the current value of the invert flag. All we can say with certainty is that when key-on occurs, the note begins with the invert flag cleared. In my implementation, I only clear it during key-on, and simply allow it to be constantly toggled when the release phase reaches 0x200. Instead of this, you could clear it when key-off occurs, and add an exclusion to the SSG-EG update steps to prevent the invert flag being toggled during the release phase.

As for the phase counter restart, again there's no way to verify, since the internal attenuation level is always forced to 0x3FF when the release phase hits 0x200. The phase counter is theoretically restarted on the same sample as the attenuation is forced to max, but I have no way to sample the output from the phase generator when the attenuation is at max, and the only way to lower the attenuation from a release phase is to trigger a key-on event, which restarts the phase counter anyway.

Of course, seeing as there's no way to verify what the real chip does, it also doesn't matter, since there's no way any of this can have any effect on the output.

isn't there a OFF state when attenuation reaches 0x3FF which turn the Enveloppe Generator off ? Or does the SSG-EG update process continue anyway ?

I'd say there isn't an "off" state, simply because there would be absolutely no point to include one. The decay phases include a limiter on the update step to clamp the maximum attenuation at 0x3FF. This prevents the decay phase from advancing once it reaches maximum attenuation anyway, and since the output during any "off" mode is just going to be 0x3FF, adding an "off" state wouldn't serve any purpose.

according to your algo, as attenuation level will remain higher than 0x200, this would mean the Invert flag could be swapped

This is one of the parts I'm not yet convinced of. I can see where the thinking comes from because it solves a number of problems - then again, I've got a ton of samples that don't look like that is happening. It's possible that it is but I'd need to write some tests before I can say either way.

Do you mean in general, or during the release phase (the source of the quote)? During the release phase it doesn't matter. During the attack/decay/sustain phases, I'm quite confident the invert flag gets toggled each sample once the attenuation reaches 0x200. If you're looking at the recorded output of the chip, remember that high frequency waves (which is what a constantly toggling inversion bit gives you) get pulverized by the output circuitry.

They didn't want the attack phase getting in the way of the SSG-EG emulation, so the mandate was to set the attack rate to 0x1F

Yes, but my point is that if they're already forcing the attenuation to zero when AR is above 62, why didn't they just force that all the time in SSG-EG mode? Or in plenty of other places where they could have done so? Leaving this up to the programmer in this way isn't something you'd usually expect to see.

In any case, the entire chip seems very well designed and logical - except for this bit, which is all a bit "WTF?

Yeah, that's true. Ok, we can agree then that SSG-EG was clearly an afterthought, done quickly, with the least effort possible, requiring the least changes to the existing core, and certainly using some questionable design approaches. In other words, it's dodgy, but they knew it was dodgy.

[Nemesis]

Missed this:

I don't doubt that what you posted does indeed match the output of the real chip - it does seem to explain exactly what I'm seeing (all except one case which I won't be able to confirm without testing).

Care to share? If there are errors in my implementation, I'd like to track them down quickly before I forget all this stuff. In six months time I'm not going to remember a damn thing about this.

[Snake]

Care to share?

Absolutely, happy to.

It's to do with the inverting every cycle thing. I believe my tests were done with AR=0x0A, and one of the inverting patterns. I was looking at what I assume is an inverted attack, and it looks like a perfect sine wave at a constant volume. The samples you provided don't look like that at all.

As I said, I can't rule out it is in fact doing what you suggest without testing. If it matters I think the sample came from an MD2, but I'd be surprised if SSG-EG works any differently there.

I'll look through my samples and post this one when I find it, but you can probably repro it fairly easily.

[edit]Here we go. As you can see it looks like a sine wave at the same frequency as the rest of the wave. I'm not sure your data explains this, or the volume level, but if you can explain it, please do - I've been stupidly busy and haven't had much sleep these last few days, so my brain may just be misfiring

Actually, looking at it now, you can see where the wave switches from decay to sustain - and the level of the 'spike' is suspiciously similar to the sustain level. Hmm.