New Documentation: An authoritative reference on the YM2612

Eke · Post by **Eke** » Sat Aug 02, 2008 6:21 pm

Hi. I'm looking to fold all of these fixes into official MAME. I see TFM/MM has a modified MAME core with some fixes and the Flashback fix was posted here. If anyone else has been tinkering with a MAME-derived FM core based on these findings or other tests against real h/w I'd love to see your changes. Please PM me if you'd rather not post them inline.

Thanks in advance!

here is my modified MAME fm.c in genesis plus: http://code.google.com/p/genplus-gx/sou ... sound/fm.c

- added DAC filtering
- fixed internal FM timer emulation
- removed unused multichip support and YMxxx support
- fixed CH3 CSM mode (credits to Nemesis)
- implemented PG overflow, aka "detune bug" (Ariel, Comix Zone, Shaq Fu, Spiderman,...), credits to Nemesis
- implemented sample interpolation, highly based on GENS code (HQ YM2612)
- fixed SSG-EG support, credits to Nemesis and additional fixes from Alone Coder
- modified EG rates and frequency, tested by Nemesis on real hardware
- fixed EG attenuation level on KEY ON (Ecco 2 splash sound)
- fixed LFO phase update for CH3 special mode (Warlock, Alladin), thanks to AamirM

Arbee · Post by **Arbee** » Sat Aug 02, 2008 7:52 pm

Thank you VERY much! I appreciate it

Nemesis · Post by **Nemesis** » Wed Aug 06, 2008 3:03 pm

For the record, I haven't finished working on this chip. Not by a long shot. Since I last posted I've written my own YM2612 core from scratch, and I'm using that as a testing ground to verify my model of the YM2612 internal structure, based on tests and observed behaviour on the hardware. The next info I post will be a complete description of the phase generator, operator unit, accumulator, and DAC. It might take awhile to complete however. I don't have as much spare time right now as I'd like, and I need to make sure I've got all my facts straight.

HardWareMan · Post by **HardWareMan** » Wed Aug 06, 2008 5:16 pm

I will wait for this look!

Eke · Post by **Eke** » Fri Aug 08, 2008 2:21 pm

Arbee wrote:Thank you VERY much! I appreciate it

I saw that you have updated fm.c in MAME, that's cool

anyway, I forgot to notify about this also

** - fixed Attack rate refresh (fix Batman&Robin introduction)

the change is in set_ar_ksr() function: the code assume that if the KSR value is changed, AR will be refreshed during Phase recalculation but even if it is often the case, it seems that under specific condition (if AR and KSR values are changed but kc >> KSR does not change), AR is not refreshed

that's why Attack Rate should ALWAYS be refreshed in set_ar_ksr(), as soon as AR is modified. This fixes intro sound in Batman&Robin.

Arbee · Post by **Arbee** » Fri Aug 08, 2008 4:59 pm

Thanks for the tip, Eke. I'll pick that fix up. Incidentally, submitting those changes woke up Jarek B. I pointed him to this thread so hopefully he'll decide to work with you guys and we can get OPN totally perfect.

In the meantime at least it sounds like Haze is going to work on HazeMD again now that he can do it without people whining that GEMS games sound wrong, so there's some positive results

Nemesis · Post by **Nemesis** » Sat Aug 09, 2008 5:06 am

Nice! I'll have to give the new core a spin.

BTW, I notice that CSM support wasn't implemented in the official source, and you note in your development copy that it wasn't working correctly. Is that an implementation issue, or have you found cases where my description doesn't match the expected behaviour? Let me know if you come across any cases that call my results into question. I'm happy to be proven wrong on something, I just want to make sure the right information is out in the public domain. Feel free to ask me any questions you might have as well, either publically or via IM. The same goes for anyone else trying to apply this information.

Eke · Post by **Eke** » Sat Aug 09, 2008 8:11 am

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

Arbee · Post by **Arbee** » Mon Aug 11, 2008 4:46 pm

Has anyone looked into the proper FM/DAC balance yet? In current MAME the DAC seems to be too loud (I think we just mix the written sample value directly into the chip's output) but I'd love to have a tested value to attenuate it by.

Nemesis · Post by **Nemesis** » Wed Aug 13, 2008 2:58 am

I'm partway through that process now. The key to getting the levels right lies in the accumulator. The accumulator takes an (almost certainly) 13-bit input from the operator unit, and definitely produces a 16-bit output for the embedded YM3015/YM3016 DAC for each channel. When the "DAC Enable" flag in register 0x2B is set, the accumulator simply drops the 13-bit operator output for channel 6, and maps the 8-bit "DAC Data" register contents in register 0x2A to that channel instead. In order to get the levels right, we simply need to know:
1. How the 13-bit operator output from one or more operators are combined into the 16-bit output for that channel. This will include any clipping operations which may or may not occur.
2. How the 8-bit DAC Data is converted into a 16-bit value. The accumulator may directly convert the 8-bit data to 16-bit (probably just by using it as the MSBs of the output), or it might convert the DAC data to a 13-bit input, and latch it several times, as if it was latching the output from several operators.

I haven't done any specific tests yet to determine how the accumulator maps its inputs to the 16-bit DAC output, but I'll be doing them soon. I'm hoping I can use the test register to digitally latch the full 16-bits of data which are being sent directly to the DAC, which would allow a precise calculation to be made. The notes that are out there describing the test register indicate this should be possible, but I haven't attempted it yet.

HardWareMan · Post by **HardWareMan** » Wed Aug 13, 2008 6:13 am

As I already said, YM2612 has time-multiplexed output: 1 DAC and each channel in turn set its current DAC code. And timeslot #6 shared between Ch6 and DAC register (0x2A).

So, IMHO, there are no clipping may occur.

Nemesis · Post by **Nemesis** » Wed Aug 13, 2008 8:52 am

I'm aware of the multiplexed output for the channels themselves. The clipping I was referring to was in relation to the operators. Depending on the algorithm selected for the channel, there may be multiple operators being combined into a single channel, eg, in the case of algorithm 7, you've got 4 13-bit operator outputs being combined into a single 16-bit output. The accumulator might clip the output if you were to try and combine all 4 operators at max volume, depending on how it operates. It should be easy enough to determine how the accumulator is calculating its output, which will answer this question.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Wed Aug 13, 2008 11:44 am

The sine(s) are distorted at low TL values, but not clipped... at least that is what my recordings showed.

Chilly Willy · Post by **Chilly Willy** » Wed Aug 13, 2008 6:24 pm

Nemesis wrote:I'm aware of the multiplexed output for the channels themselves. The clipping I was referring to was in relation to the operators. Depending on the algorithm selected for the channel, there may be multiple operators being combined into a single channel, eg, in the case of algorithm 7, you've got 4 13-bit operator outputs being combined into a single 16-bit output. The accumulator might clip the output if you were to try and combine all 4 operators at max volume, depending on how it operates. It should be easy enough to determine how the accumulator is calculating its output, which will answer this question.

Four 13 bit values cannot clip when combined into a 16 bit value. In fact, a 16 bit value can be the sum of eight 13 bit values w/o clipping. Any more than that might clip.

Nemesis · Post by **Nemesis** » Wed Aug 13, 2008 11:24 pm

If they're simply being added, yeah. That might not be the case however. I personally suspect the 13-bit output is being shifted up by 1 to make each operator a 14-bit output (or the operator unit actually does use 14-bit resolution internally. I'll be testing for that), and then they are simply being added, which would mean there would be no clipping. I'll know for sure once I run some tests though.