New Documentation: An authoritative reference on the YM2612

[TmEE co.(TM)]

Heh, that's interesting I guess the hardware doesn't allow you to switch channels that fast. Admittedly something I never tested, because I didn't expect anybody to ever do that. What happens on the real hardware? Do you have a recording?

http://www.hot.ee/tmeeco/MD.HTM - You can get the ROM I will use for the recording here... Warning : the site is VERY outdated.

Also interesting. I remember this game giving me trouble back in the very early days of KGen. One thing it does is spam the living hell out of the YM2612, repeatedly writing registers that haven't changed. I don't remember if it checks the status to see if the chip is busy between writes - but maybe it does, and those writes take a bit longer on the different chip? (or, maybe the newer chip forces a delay if you write to quick?) It's possible it wastes so much time with all this spamming that it misses an interrupt or timer interval. That'd explain why it runs at half speed.

Only thing I can suspect is the busy flag timings to be different on the two implementations as when I overclocked the Z80 to 4.5MHz the music got a little bit faster, but not as fast as it should.
Some things that require longer waits are TL operators and KeyOn/Off. Having too short delays when writing to these registers will have weird sound, possibly because the write got missed or corrupt or notes left playing (Note ONs seem to have no problems). L/R reg seems to require long wait aswell.

When TEST signal of YM2612 would have been used for hardware based delays, my sound engine will probably not be what it is now. Time would get wasted in CPU wait while you could have few more instructions executed... I'm raping YM2612, pushing ~50KB of data through it per second


EDIT:

Recording of "stereo" PCM and the ROM I used :
http://www.fileden.com/files/2008/4/21/ ... STEREO.RAR

System used for recording http://www.hot.ee/tmeeco/MYSMD2.JPG (all new image now )

[Snake]

I must say however, the self-feedback implementation still baffles me. MAME adds the last two samples together to build the self-feedback modulation value. This seems to be correct, but I can't figure out why it's correct, or rather, why the guys at Yamaha chose to implement it this way.

Two answers (well, three.)

One - it's correct.
Two - it's the way Yamaha have always done it (ah, I do miss my old yamaha synths...)
Three - because its a very sensible thing to do.

If you modulate a wave by itself, with no modification, you can very easily end up with a wave that oscillates from positive to negative every other sample, or other undesirable patterns, none of which are very useful. It's always a good idea to modify something before you feed it back in, in any application, not just audio.

I should probably stop wasting time on it and look at something else.

Yep, move along, nothing to see here

[Snake]

Recording of "stereo" PCM and the ROM I used :
http://www.fileden.com/files/2008/4/21/ ... STEREO.RAR

Thanks for that. Shame it doesn't work, but I can see why.

System used for recording http://www.hot.ee/tmeeco/MYSMD2.JPG (all new image now )

That's... insane. Respect

[TmEE co.(TM)]

I've tried many ways, writing more than 1 sample and then switching channel... no go, it will still sound poor

[Stef]

I've tried many ways, writing more than 1 sample and then switching channel... no go, it will still sound poor

I also wrote a stereo sample player some time ago (i probably kept the source somewhere) but it worked only on Kega Fusion. It acted as simple mono sample player on real hardware and produced some bad noises on Gens... very disapointing. I tried severals ways to get the thing working on hardware but all them failed.
I was thinking about playing sample with YM channels by modifying quickly the output slot TL value but that requires more work with the Z80 and i'm not sure it can actually work. That also requires a log conversion on sample with some quality loss...

[Snake]

Yeah, I don't think you can update those registers fast enough anyway.

[AamirM]

Hi,

Has anyone been able to fix Battletech track 12 problem yet? I have made changes to make phase increment value 17-bit but it doesn't work.

stay safe,

AamirM

[Snake]

no, it works correctly (at least, your test ROM works)

initially it didn't work because setting KEY ON then key OFF without updating the enveloppe attenuation level obviously did not work

I fixed that by immediately forcing attenuation level to MAX when Key ON is set and Attack rate is maximum (this was usually done on the next enveloppe update)

I should fix the commentary asap

Yeah, I'm pretty sure this is wrong. It seems too 'hacky'.

What probably happens is that the KEY OFF happens immediately after the next envelope update, rather than immediately after the KEY ON. Note that this won't make any difference to the sound, because the previous KEY ON won't have any effect until the update happens anyway.

[Eke]

Hi,

Has anyone been able to fix Battletech track 12 problem yet? I have made changes to make phase increment value 17-bit but it doesn't work.

stay safe,

AamirM

how is it supposed to sound like btw ?
In kega, even with SuperHQ enabled, I can still hear the noisy & high-frequency cymbal, and in Regen, it sounds more like a "tic tic" ...

In my Genesis Plus implementation, I got it differently from both, the sound seems less noticeable...

Currently I got best results using 48000hz and SINC_FAST setting as the libsamplerate conversion algorithm (iLINEAR has less quality and it's quite noticeable in that specific track)

ALso, regarding MAME implementation, I'm calculating the max value to add when Finc<0 like this:

ym2612.OPN.fn_max = (UINT32)( (double)0x20000 * ym2612.OPN.ST.freqbase * (1<<(FREQ_SH-10)) );

if (finc < 0) finc += ym2612.OPN.fn_max;

this way, and according to what Nemesis found, we indeed got:
-1 = 0x1FFFF

[AamirM]

Hi,

how is it supposed to sound like btw ?

It is supposed to sound like this. You will notice that the detune bug doesn't seems to be happening at all.

Currently I got best results using 48000hz and SINC_FAST setting as the libsamplerate conversion algorithm (iLINEAR has less quality and it's quite noticeable in that specific track)

You are using SRC? Nice . Is it fast enough?

Yeah, I'm pretty sure this is wrong. It seems too 'hacky'.

Yep it was. I think he has since removed it.

stay safe,

AamirM

[Snake]

It is supposed to sound like this

No it isn't.

Where did that come from?

[Eke]

You are using SRC? Nice Smile . Is it fast enough?

anything better than SINC_FAST is too slow but SINC_FAST gives good results at fullspeed on both Wii (729Mhz PPC) & Gamecube (485Mhz PPC)

Sadly, to obtain fullspeed with Virtua Racing or NTSC filters enabled, I have to lower the quality (LINEAR) or even disabled HQ mode

Never thought I would have to optimize the code someday

no, it works correctly (at least, your test ROM works)

initially it didn't work because setting KEY ON then key OFF without updating the enveloppe attenuation level obviously did not work

I fixed that by immediately forcing attenuation level to MAX when Key ON is set and Attack rate is maximum (this was usually done on the next enveloppe update)

I should fix the commentary asap

Yeah, I'm pretty sure this is wrong. It seems too 'hacky'.

What probably happens is that the KEY OFF happens immediately after the next envelope update, rather than immediately after the KEY ON. Note that this won't make any difference to the sound, because the previous KEY ON won't have any effect until the update happens anyway.

well, according to Nemesis

That's their way of eliminating the attack phase. When Rate = 62 or 63 during attack, the attack phase is skipped. MAME use this calculation to immediately force the result to TL, but based on the behaviour I've observed with CSM and SSG-EG, I think it far more likely that the YM2612 doesn't even enter the attack phase, and skips straight to decay when the calculated attack rate is greater than 61. I probably should have written that in as a special case.

but I'm very interested to know how exactly the chip behave is such extreme case, when Key ON/OFF are exactly taken in account (after a new EG cycle or after an enveloppe update ? but what happen in the case of very slow update rates ?) , what happens internally (attenuation level reseted or not ? phase counter reseted ?)

No it isn't.

Where did that come from?

I'm curious also, this definitively sound too weird, no programmers could have leave this that way

[AamirM]

Hi,

No it isn't.

Where did that come from?

Thats a recording from the real hardware sent by a user. He also sent some other recordings which have pointed out bugs in my core. Some recording which are related to SSG-EG aren't emulated correctly by any emulator so he couldn't have made this up. So until and unless someone has some other real proof I am going to believe it sounds like that.

stay safe,

AamirM

[Snake]

Never thought I would have to optimize the code someday

I'd offer, but I don't much like PPC

well, according to Nemesis

That's their way of eliminating the attack phase. When Rate = 62 or 63 during attack, the attack phase is skipped. MAME use this calculation to immediately force the result to TL, but based on the behaviour I've observed with CSM and SSG-EG, I think it far more likely that the YM2612 doesn't even enter the attack phase, and skips straight to decay when the calculated attack rate is greater than 61. I probably should have written that in as a special case.

Nah. Only thing that touches the envelope is the envelope generator. And that doesn't update every cycle.

I'm curious also, this definitively sound too weird, no programmers could have leave this that way

Well, I've heard this plenty of times, so I know it doesn't sound like that. But yeah, I'm curious as to where this came from.

So until and unless someone has some other real proof I am going to believe it sounds like that.

Ok. But it doesn't

[AamirM]

Hi,

I'd offer, but I don't much like PPC Wink

I always wanted to know how Kega resamples. Are you using linear interpolation?

stay safe,

AamirM