My YM2612 Observations.

Discussion in 'Discussion & Q&A' started by MarkeyJester, Jul 2, 2019.

  1. MarkeyJester

    MarkeyJester ! % # @ Member

    Joined:
    Jun 27, 2009
    Messages:
    2,761
    For some time I've wanted to write a series of tools for Mega Drive audio creation/editing, ones that involve actual audio, over the years I've never had the time to actually sit down and do that as I am frequently busy with things. Recently I've taken the time to make a stab at something audio related, so the opportunity of time has flown my way.

    The YM2612 and the Mega Drive's audio has been well documented in various places, and I've known a great deal about the chip and how frequency modulation synthesis works for many years, so programming code to emulate one is a real cinch.

    There are some tidbits however which don't appear to be mentioned, or if they are mentioned, they're quite vague, hidden, or use somewhat complex terminology. So I've taken the time to make some hardware recordings from my model 1 Mega Drive, and make some visual observations on the resulting waves, and I had found some answers for many of these minor tidbits.

    Natsumi suggested I should share this, I was in two minds about it, because it's always my luck that I share a bit of information and it then turns out it's already documented somewhere and just isn't quite visible. I figured though I could just share my observations as a type of... shall we say, "diary", or "blog" if you will, all shared under the assumption that many of you might already know the information, or the information is already available in some form, these are just my findings, and nothing more. It's not meant for bragging or public discovery, it is simply here for those that might be interested.

    So far I've observed the following...

    Sinewaves generated by the operators are always reset when the operator is key'd on, though not when key'd off. This might be obvious, but it does explain why keying on an instrument that has a gradual release rate tends "pop" the audio:

    [​IMG]

    As you can see in the same image above, sinewaves start initially going downwards, I was quite surprised by this one, I was expecting the sinewave to go upwards first, not that this makes much of a major audio difference mind, but there is a slight difference when an operator modulates a sinewave, it can produce slightly different audio. I was debating on whether or not my computer's sound card has the polarities in reverse, or perhaps the polarities are shoved out in reverse from the console's jack itself.

    A modulator operator's sinewave will push the frequency upwards first, then down. This too was surprising in that the sinewaves goes down into negative first, I would've expected the frequency to drop downwards, and the carrier's frequency to go in reverse. But the opposite happens:

    [​IMG]

    Not a major thing, but it was something I wanted to be 100% sure on, I expected this to be the case and it was. The amplitude of the carriers are capped to the maximum audio range of the channel, but the amplitude of the modulators are not capped when they are modulating the frequency of a carrier.

    Four operators as carriers:

    [​IMG]

    Two operators individually modulating a carrier at the same time:

    [​IMG]

    I was surprised to find that even if a speaker is disabled via panning, that the sinewave's position still affects the filter/DC correction mechanism. The audio was panned to one speaker, and the other speaker still had an affect:

    [​IMG]

    The amplitude of the YM2612 is logarithmic (or exponential depending on which way you view it), which is a known fact of course, but I was surprised to find the attack rate didn't flow in the same manner:

    [​IMG]

    What's more interesting about this attack rate, is that on closer inspection, unlike the decay rates, this isn't smooth and is actually a series of steps:

    [​IMG]

    Very jarring steps too, and at equal times too, I therefore suspected the chip had some sort of prefixed procedure in place for producing it, I wasn't sure if this was intentional, I suspect so and perhaps it's to prevent a too sudden pop from attack to decay, but that sounds somewhat silly to me.

    While I'm not entire sure what calculation is going on here, I have had some pretty accurate success with this by taking the distance the amplitude has to reach to get to maximum, and adding a fraction of that to the amplitude every width of each step:

    [​IMG]

    Not 100% but it is close, so I suspect either this is what's going on, or there's a reversed logarithmic amplitude mechanism involved which is enough to counter the logarithm of the volume near it's extreme curve. But again, no idea.

    Decay and Sustain rates yield identical fade outs:

    [​IMG]

    Release rate is the same calculation, except only the odd slots you see above. These are linear fade outs, but of course the logarithmic volume causes the curves, each step is a step up in "to the power of" from what I've been picking up while trying to emulate it.

    Here is a volume comparison between FM, PSG tone/noise and DAC random output:

    [​IMG]

    Unfortunately the filters are interfering with the tests, even if the frequencies/tones are matched between say an operator's sinewave and a tone channel's squarewave, the filter will still portray their actual amplitudes incorrectly, as an example, here is the entire frequency range of the YM2612:

    [​IMG]

    I apologies it's a screenshot from a fair far distance, but a close up would resemble an image perhaps too large to store, sorry about that. Recording every frequency from 0000 to 3FFF (every octave/frequency) with an operator set to MUL of 1 (which should be x1 the frequency), every frequency was played for a single second, with the attack/release rates at really high keying off and rekeying on for every frequency, this took around nearly 5 hours to record... But you get the idea, because of the filter, obtaining the actual amplitude is quite tricky, but it does show the low-pass cut-off point to some degree.

    I'm still doing some observational recordings as and when I need the information, so if you are interested in what's here so far, then I'll be happy to share more info and shots as and when I collect them. Much of the FM stuff I need I've almost got, but I have yet to look at PSG more closely, what I would like to do is obtain the PSG white noise pattern, I think I might be able to obtain it with some high degree of accuracy if the frequency is low enough but the volume is high, might be able to write a program to average out the wave and find the exact steps involved, but we'll see.
     
  2. ValleyBell

    ValleyBell Well-Known Member Member

    Joined:
    Dec 23, 2011
    Messages:
    150
    The PSG noise is explained pretty nicely in the Development section of the SMSPower! wiki. This includes details about the noise pattern.

    The noise pattern should be the same on the MegaDrive and the Master System.
     
    MarkeyJester, FохConED and Ozaleto like this.
  3. MarkeyJester

    MarkeyJester ! % # @ Member

    Joined:
    Jun 27, 2009
    Messages:
    2,761
    I've made some more observations which I want to share before I forget them.

    I haven't looked at the PSG noise quite yet, however, I have made some recordings of white noise from hardware in a variety of different frequencies, I did have a read of the link you provided, though I wasn't sure if this shift register was constantly running regardless of the noise channel's status, as a precaution I attempted the recordings from a model 1 non-TMSS machine. This saves the TMSS ROM running and having to spend instructions sending "SEGA" to it.

    So hopefully, I have the quickest instance of nabbing the noise. Unfortunately the flashcart's software does take up some time. But like I said, it's just a precaution, when I do eventually get around to analysing it, and if I happen to find a matching pattern anywhere via the details from the SMS, then I'll be able to conclude the verification of that.

    Thanks very much for sharing that though~

    OK so, firstly, regarding the sinewave direction, turns out it does actually go upwards first, the output is reversed polarity for some reason, however, I think it's the console itself, the FM is reversed polarity but the DAC appears right way up, so I assume the polarity is reversed by the chip itself internally. You can see near the end of a decay/release the way the wave is longest below the DC 0 than above, indicating the 0 is heading downwards instead of up.

    Another thing I've found (which wasn't obvious at first), is the frequency octave controls the operator rate even when rate scaling is at 0, but it's done via the highest bit of the frequency (i.e. the octave bits):

    [​IMG]

    Each one is an octave from highest to lowest, top four octaves 7 to 4, and the bottom ones 3 to 0. The operator envelopes run at a different rate on the lower octaves than they do on the upper octaves. I've only checked decay, but I'll check attack and get back to you all on that.

    Another thing to note, it looks as though the sinewaves which are used for modulation appear to be logarithmic too, though I think I need more data to conclude that for sure, so I'm reminding myself to come back to you all on that one.

    This next one is less of a discovery and more of a shared interest, not a lot of emulation out there emulates the DC correction mechanism, by that I mean the wave bending towards 0 as much as possible. Now, a-lot of analogue hardware has this, even my Bop-It device had it when I hi-jacked the speaker wires into a jack and recorded from that, here's a sample of the DAC being forced to one side and kept there:

    [​IMG]

    The first one is from hardware, the second one is a quick emulation test. I only made some quick code to try and replicate it a bit to make programming the other aspects a little more easier so it needs a lot of refining:

    Code:
        Wave += Offset >> 0x0B;
       Speed += ((Prev - Wave) << 0x0B) / 0x1E0;
       Offset += Speed;
       Speed -= (Wave << 0x03) / 0x800;
       Prev = Wave;
    However, I was very surprised to find that even a quick and terrible construction like the above started emulating almost exactly other quirks, for example, very low frequency waves (top is hardware, bottom is emulated):

    [​IMG]

    The amplitude of low frequency waves are reduced because of[ the DC correction mechanism, but as you can see, mine is also reduce amplitude to roughly the right amount, which I suspected to happen but wasn't intentionally going out to test at the time, so it came as a shock to me. But the biggest shock was when I went to amplify it:

    [​IMG]

    The bends are caused by the filter and the noise is more visible due to amplifying it, but the spikes were caused by the DC correction mechanism, and as you can see, my temporary code (out of almost sheer dumb luck) replicated the spikes at almost the exact same spots. This blew my mind as I wasn't even trying to replicate anything of this at the time and was simply looking at calibrating the frequency rate, so I am very pleased with it. Of course, with more refinements I'll be able to better replicate the DAC curve from above with better accuracy. Maybe by that time I'll have the low-pass filter programmed and some intentional noise shoved in, and the image I'll show will have the waves looking identical.

    More to come...
     
    ProjectFM and AkumaYin like this.
  4. nineko

    nineko I am the Holy Cat Member

    Joined:
    Mar 24, 2008
    Messages:
    1,772
    Location:
    italy
    I like both music and technical things (which shouldn't be a surprise at this point), but I understand, like, a billionth of what's going on. Either way, the last picture alone makes me believe that you're doing something amazing, not that I expected less from you, you're like king Midas, except with awesomeness instead of gold, no matter what you touch, music, sprites, assembly, the outcome is always beyond great.