![Crying or Very sad :cry:](./images/smilies/icon_cry.gif)
![Smile :)](./images/smilies/icon_smile.gif)
Moderator: BigEvilCorporation
Yep, I can explain what's happening. The recording you've taken is at 44100Hz. The native output of the YM2612 in the Mega Drive is around 52847Hz. With the output being inverted each sample, that creates a wave with a frequency of around 26423.5Hz, but since you need to be able to capture at least two full samples in order to record a wave at that frequency, the sampling rate you're recording at simply isn't high enough to capture the inversion. The samples are averaging together, which is why you're being left with a regular sine wave at mid-level. You'll also note the strange distortion on the sine waves you posted as the phase of the output causes the output to approach 0. That's because the difference between the normal and inverted output samples is being reduced by the attenuation from the phase generator, so your sound card is able to more accurately observe the true slope of the carrier wave as the output approaches 0.Snake wrote:[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
I can see one thing that might be a problem, if I'm following your code correctly. When SSG-EG is active and the envelope is in the release phase, the attenuation level is still forced directly to 0x3FF when the release phase reaches 0x200. It looks like you're excluding all SSG-EG update steps when release phase is active, which would also exclude this behaviour.Eke wrote:Nemesis, if you want to have a look and doublecheck it (I tried to optimize it a little bit and avoid unecessary recalculation as most as I could), please check here for fm.c... any advice/corrections appreciated
I did consider that, but since the sample rate is not divisible by the hardware output rate, I would have expected to see some clear distortion rather than an almost perfect wave - I can see this in other samples. Also - granted, inverted 0x200 will give you 0x000, but every value above 0x200 will also give you a value above 0x200 - I would have expected something much quieter than mid level if the two were just being averaged.Nemesis wrote:The samples are averaging together, which is why you're being left with a regular sine wave at mid-level.
Ahh, but remember that the attenuation isn't moving past 0x200 during a repeating SSG-EG wave. In the pattern you posted, the attenuation decays until it reaches 0x200. When this happens, if AR was 0x1F, the attenuation would be forced back to 0. Since this isn't the case, what happens is the attenuation sits on 0x200 until the attack phase advances. When it does advance, it will drop the attenuation to 0x1DF. From this point on, you get a valid, advancing attack phase, but all the samples that were generated while the attenuation value was sitting on 0x200 will be inverting each sample.Snake wrote:Also - granted, inverted 0x200 will give you 0x000, but every value above 0x200 will also give you a value above 0x200 - I would have expected something much quieter than mid level if the two were just being averaged.
If you're in the market for a new sound card, this is the one I use for my tests:But as I said, it's not clear from this sample alone and I'd have to do more tests.
I do know that a lot of the info you posted is correct, because I confirmed some of it myself a long time ago. But back then 44KHz was "the business", and I knew it wasn't good enough. I paid a lot of money for a true 96KHz card right before I lost all my equipment anyway :-/
I understand exactly what you mean. I'm definitely interested in hearing about any simplified, more logical implementations.I'd love to be able to confirm all this stuff for myself, and see it we can't come up with a simpler or more logical way of implementing it. Not that it's complicated, just... odd. In my experience, odd usually means wrong, but I'm prepared to accept that in this case, it is probably just a strange piece of hardware hackery. Would like to be sure, though, because that's just "how I roll"
I can quite confidently say they do absolutely nothing. Most of my test roms that iterated through patterns, including the test ROM I just posted, use an incrementing counter which allows the upper bits of the SSG-EG mode register to be set. I left some of these roms recording for a very long time (over a day once) to generate large blocks of reference data, and I never saw any change in behaviour based on what these upper bits would have been set to. I also did do some specific tests awhile back on forcing all the upper bits of the SSG-EG mode register to set, and it had no effect.[edit] oh - while I'm here - a lot of games write to the upper 4 bits of the SSG-EG registers. I'm not sure what the programmers think they were doing this for, and I didn't test extensively, but I believe they don't do anything. Did you test this?
Ah, this is what I meant, but I didn't explain it very wellNemesis wrote:Ahh, but remember that the attenuation isn't moving past 0x200 during a repeating SSG-EG wave.
Right. So the very first time after key on, it should look different. I'll check that again.Nemesis wrote:what happens is the attenuation sits on 0x200 until the attack phase advances.
Ah, I see we are actually on the same pageNemesis wrote:One point where you do get an attenuation level over 0x200 being toggled each sample is when you first key-on an SSG-EG envelope with an attack rate less than 0x1F, if the current attenuation level is over 0x200 that is.
Exactly what I thought, thanks.Nemesis wrote:I can quite confidently say they do absolutely nothing.
Ouch. Yeah, that cuts down the options somewhat. Personally, I use an old crappy P4 box for all this stuff. I do most of my work on my laptop, and just use the test rig to transfer ROM data to the flashcart, or capture audio/video from the console. I think that's the best way to go. If you don't have an old PC lying around, you could pick one up really cheap if you look in the right place.As for sound cards and tototek flash cards - I'm pretty stuck at the moment. Don't have anything with PCI slots nor anything with a parallel port, so I need to find something decent in USB flavour.
well, the attenuation level is forced to max during EG update and I considered that, in RELEASE phase, once the attenuation level has reached 0x200 and been forced to max, there is no need to check for SSG-EG update anymore until next KEY ON event...I can see one thing that might be a problem, if I'm following your code correctly. When SSG-EG is active and the envelope is in the release phase, the attenuation level is still forced directly to 0x3FF when the release phase reaches 0x200. It looks like you're excluding all SSG-EG update steps when release phase is active, which would also exclude this behaviour.
Code: Select all
if (SLOT->volume >= 0x200)
{
SLOT->volume = MAX_ATT_INDEX;
SLOT->state = EG_OFF;
}
I think that the attack phase simply doesn't happen at all when the rate is >=62, it's just skipped over. So when you force it to stay inside the attack state with a rate of 62, by modifying registers afterwards, it just does nothing, and has no way of getting out of the attack state.Nemesis wrote:Personally, the think that irks me the most is the behaviour when the effective attack rate is 62 or 63. If it was just a matter of forcing the attenuation directly to 0 when the attack phase is entered with these rate values, well, that's one thing, but the "stalling" behaviour when changing to this rate during the attack phase bothers me. It just doesn't make any sense for that to occur.
I don't know if this document will tell us anything we didn't already know, but it does indeed appear to be hardware and software 100% identical to the YM2612. So this is a very nice thing to have, regardless. Thanksvedge wrote:Now, this is another PDF that requires translation
Kind of awesome since thats the CMOS version of the 2612!
Are you sure about this? An accumulator is mentioned on page 33 (page 35 of the PDF):Nemesis wrote:For one thing, it confirms what Steve suspected; they've removed the accumulator.