Undocumented YM2612 register $2C

[Oerg866]

Hi,

I will now present my notes on the previously undocumented register $2C on the YM2612.

A little backstory:

Back in 2008 I was working on a Sonic 1 hack called "Sonic 1 Oergomized". I was porting music from Columns III to the Sonic 1 sound driver. Because I wasn't able to do it manually because I was too incompetent I used a program called "Music Pointer Fixer" that would do the work for me to fix all these little flags in the file. It seemed to work, so I didn't bother more about it. Around that time I got the idea to try hacks on real hardware, so naturally I flashed mine to the cartridge and tried it. It worked fine, mostly, but one thing was broken. The music from Columns III I had ported only worked correctly in part. At first it played correctly, but then I noticed the PCM samples became really loud and the rest of the song was not hearable anymore. I recorded that and posted it on youtube for reference so I could get someone with real knowledge to fix it for me. Puto, a member of Sonic Retro and quite knowledgeable about the SMPS music format used in the Sonic games at the time, went ahead and scanned the file for broken flags. It turned out that there was one flag that didn't belong where it was and he took it out and that fixed it. I didn't think much of it at first, but then I noticed, every source said that you cannot control volume of the PCM channel. As the PCM sound was really loud with the buggy version of the music, something could not be right. I told people like Tweaker and other regulars about it, but they all went like "Nah, u crazy" and so it was forgotten. This is the youtube video in question:

http://www.youtube.com/watch?v=RHen85SQs4o#t=25s

Recently I talked to MarkeyJester in the SSRG IRC channel. I don't know what we were talking about (probably MD development stuff), but we got into talking about such subjects like undocumented features, and I mentioned it on the side that I once found something really weird, meaning the stuff that had happened almost 4 years ago. MarkeyJester, for some reason, showed some real interest in this and decided that, if I could find the ROM back, he would investigate it.

I looked everywhere, and in the darkest corners of my hard drive, I found the beta version of my hack that still had this bug. I gave it to MarkeyJester and he ran it on hardware to verify it happened.

Code: Select all

<MarkeyJester> shit
<MarkeyJester> it happens on the MD 2
<MarkeyJester> happens on MD 1
<MarkeyJester> that's pretty fucking loud too
<MarkeyJester> Also on NoMad


<MarkeyJester> sorry to do this Oerg, but it's time to break your rom open
<Oerg866> You may proceed 


<MarkeyJester> it can't be
<MarkeyJester> how does that even work
<MarkeyJester> it's not 24
<MarkeyJester> it must be two of them


<TmEE> I knew about the lound PCM thing for quite a few years and at one point I tried to enable it through software but never succeeded... I only could get it by glithching YM on real HW haha
<TmEE> loud*

<TmEE> it would make PCM at FM TL 0 instead of 16


<MarkeyJester> so that's YM2612 address 2C
<MarkeyJester> now to find out what's being written to it


<MarkeyJester> I just checked one of the manuals
<Jorge> well, I have a test reg here on this pdf
<TmEE> which allows you to do fun things
<MarkeyJester> doesn't exist
<TmEE> woo, another test reg
<Jorge> at 21 and 2C
<TmEE> I am excited hahaha
<Oerg866> ASS reg
<Jorge> it just says LSI Test data
<Jorge> its interesting it comes after the DAC regs, maybe it has something todo with the DAC, heh

As I did not know at the time how to really interface with the YM2612, I could not test stuff myself. MarkeyJester found out that if you set Bit 5 in YM register $2C to 1, this odd behaviour occured. What it was for, we didn't know.

TmEE did some research on his part to kind-of figure out why FM was muted and what everything does. He came up with these assumptions:

• FM waveforms affect PCM panning
• The more complex and loud the waveforms playing on either side, the more the panning would be dragged in either direction
• This way you can achieve very smooth PCM panning.

With the recent development of my setup that allows realtime code testing on real hardware, I decided to learn how to talk to the YM chip and I wrote some code:

• A routine that loads an FM instrument
• A routine that sets YM registers
• A routine that keys on an FM instrument
• A routine that plays a loop of PCM data over and over

What I came up with is a program that does this: sets the undocumented test bit $2C as follows:

Code: Select all

        move.b #$2C, ($A04000)
        move.b #$20, ($A04001) ; Set bit 5 (this is the relevant bit)

And then plays some stuff on the FM channels while constantly playing a loop of PCM data.

My immediate findings were the following:

• PCM gets set to FM TL 0 instead of the set value of FM TL 16 (this cannot be changed in any way as far as we know, the only bit that does it is this one)
• FM gets muted.

To verify that FM stuff affects panning in any shape or form, I used the FM code I wrote to gradually play some stuff in a certain pattern.

My first test of that were a test instrument that used algorithm 7 (all operators produce a simple sine wave, all of which get added together in the end), a decline of 0 (no decline) and a TL of 00 on all operators. I loaded this instrument to all channels when the program started. Or so I thought.

Every time the loop starts, I flip between left or right side on all FM channels, key on all operators on all channels and then gradually turn off the FM channels one after another as the sample is playing. The result was this:

http://www.mdscene.net/~pvt/MDsmoothpanning.mp3

At last! I verified that FM panning gets dragged in either direction using the FM channels. Now what interested me was making my FM code more easy to work with. I tested the code out in an emulator and it turns out that due to a bug in my code, 4 of the 5 channels did not even have the instrument loaded. Upon further investigation I came to the following conclusion:

The waveform does not matter. You can load whatever instrument and it will behave the same.

Quite interesting so far, but what about frequency? To test that, I slided the frequency around a bit on every channel while playing the sample. This did not affect the output either.

The only thing left that I could imagine that could possibly do anything is this:

The YM has 4 key on bits for every channel. Every key on bit turns on an operator. What if we gradually enable them?

Bupkis. It still sounds the same.

Now I just said "screw it" and did not even key on any operators.... It still affected the panning like usual! So we can conclude that the only thing that affects panning is how many FM channels have that particular side turned on/off.

To verify that definitely, I removed everything to do with FM except setting the parameter that turns on/off the sides (For FM channel 0 that would be $B4 in $A04000 set to 0x80 for the left side and 0x40 for the right side. That still worked as before.

Another interesting thing is that it gets affected by every FM channel *except* FM5, meaning FM1,2,3,4 and FM6.

That means ultimately we can describe the register $2C of the YM2612 as follows:

When Bit 5 of YM Register $2C is set to 1, Panning gets affected by the L/R part of the L/R/AMS/FMS reg of these channels:

$B4 in Bank 1 of the YM2612 for Channel FM1
$B5 in Bank 1 of the YM2612 for Channel FM2
$B6 in Bank 1 of the YM2612 for Channel FM3
$B4 in Bank 2 of the YM2612 for Channel FM4
$B6 in Bank 2 of the YM2612 for Channel FM6

With the following conclusions related to other claims mentioned above:

• FM Waveform does not matter. The FM channel can be empty for all it cares.
• FM Total level does not matter (!)
• FM Key on does not matter (all key on bits can be set to 0 and it will still work)
• The only thing that actually affects PCM panning is how many FM channels have either the L or R bit set to 1

I have a picture that illustrates the affection of panning on the left channel according to how many channels are set:



Corresponding recording can be found here

It can also be seen that when all the channels are turned off but the register $2C set, PCM is still roughly four times as loud as without:



This concludes my research and documentation of this previously undocumented register. I hope it was an entertaining read and helpful to some emulator developers out there. It would probably require some more testing to get a really good approximation formula for it, but at least we have something now.

And now, for something fun ;D

26KHz test with super-smooth panning

http://www.mdscene.net/~pvt/bestpanning.mp3

Want to try it on your Mega Drive / Genesis?

ROM download!


Cheers,
Oerg866

[djcouchycouch]

Tried it out and it seems to work.

[Chilly Willy]

Wow, neat find! Works nice on my CDX.

[Eke]

Nice find.
Although I didn't get some of the explanation and conclusions.
Especially these ones

PCM gets set to FM TL 0 instead of the set value of FM TL 16 (this cannot be changed in any way as far as we know, the only bit that does it is this one)

channel 6 when in PCM mode ? I don't get what you mean by "PCM gets set to FM TL 0"
and I thought that this was not related to TL at all and that the 8-bit register $2B value was simply shifted to MSB of channel 6 14-bit output ?
as refered here: viewtopic.php?t=386&postdays=0&postorder=asc&start=136

FM gets muted.

how did you verified that ? could it be that channel 6 is so loud that you can't hear other channels ? have you tried with channels 1-5 keyed ON and DAC register value set to zero ?

FM Waveform does not matter. The FM channel can be empty for all it cares.
FM Total level does not matter (!)
FM Key on does not matter (all key on bits can be set to 0 and it will still work)

I think that's quite logical considering how the chip is producing sound, this bit probably affects the output of operator units, not Envelope generator or Phase generator. It has probably nothing to do with TL, just that channel 6 output is being maxed out, maybe something like this :

normal: xxxxxxxx000000

test mode: xxxxxxxx111111 ?

The only thing that actually affects PCM panning is how many FM channels have either the L or R bit set to 1
I have a picture that illustrates the affection of panning on the left channel according to how many channels are set:

I don't get it, you mean channel 6 is muted in the first steps but PCM is still output ? are you sure the channels you are enabling one after one are not keyed ON and does not produce sound ?

[Oerg866]

Nice find.
Although I didn't get some of the explanation and conclusions.
Especially these ones

PCM gets set to FM TL 0 instead of the set value of FM TL 16 (this cannot be changed in any way as far as we know, the only bit that does it is this one)

channel 6 when in PCM mode ? I don't get what you mean by "PCM gets set to FM TL 0"
and I thought that this was not related to TL at all and that the 8-bit register $2B value was simply shifted to MSB of channel 6 14-bit output ?
as refered here: viewtopic.php?t=386&postdays=0&postorder=asc&start=136

Don't you mean $2A ?
And:
This information was given by tiido. It might be your way that it works internally, but I'm not sure. Atleast we can say it's really loud

FM gets muted.

how did you verified that ? could it be that channel 6 is so loud that you can't hear other channels ? have you tried with channels 1-5 keyed ON and DAC register value set to zero ?

I Verified it by writing $80 constantly to the DAC register ($2A) and Keying off and then immediatly on all operators on all channels with a loud instrument loaded to all FM channels (verified that the code for this works) in ~half a second interval. FM was not heard.

DAC register set to zero is interesting. I have not tested that, and decided to do so after I read your post.

PCM output still works when DAC is turned off but $2C is turned on (!!)

FM Waveform does not matter. The FM channel can be empty for all it cares.
FM Total level does not matter (!)
FM Key on does not matter (all key on bits can be set to 0 and it will still work)

I think that's quite logical considering how the chip is producing sound, this bit probably affects the output of operator units, not Envelope generator or Phase generator. It has probably nothing to do with TL, just that channel 6 output is being maxed out, maybe something like this :

normal: xxxxxxxx000000

test mode: xxxxxxxx111111 ?

No, all channels influence it equally. PCM is in this test mode not bound to FM6. For some reason as noted above, FM5 does not influence it at all.

The only thing that actually affects PCM panning is how many FM channels have either the L or R bit set to 1
I have a picture that illustrates the affection of panning on the left channel according to how many channels are set:

I don't get it, you mean channel 6 is muted in the first steps but PCM is still output ?

Yes. FM6 turned off will not mute PCM.

are you sure the channels you are enabling one after one are not keyed ON and does not produce sound ?

Yes of course I made 100% sure of that. Key on bits are all set to 0 and no FM instrument is loaded.

[Eke]

PCM output still works when DAC is turned off but $2C is turned on (!!)

ok, I think I get it, probably this is a "special" DAC mode: $2B enables DAC on channel 6 and $2C on all channels.

you should try with all channels being muted except channel 6 and see if there is any differences with $2C bit or $2B being set to see if data in $2A is handled differently

I would also try with different values in $2A (zero included) and from 1 to 6 channels enabled

[Oerg866]

PCM output still works when DAC is turned off but $2C is turned on (!!)

ok, I think I get it, probably this is a "special" DAC mode: $2B enables DAC on channel 6 and $2C on all channels.

you should try with all channels being muted except channel 6 and see if there is any differences with $2C bit or $2B being set to see if data in $2A is handled differently

Actually with FM6 turned on and fm6 turned of f theres, as you can see in the first picture, a difference in volume.

I already noted above that $2C with all fm channels off is 4x louder than $2B.

[Chilly Willy]

I would also guess that all the FM channels are still working like normal - only their output is being ignored in favor of the DAC. You could test that by setting $2C, keying on an instrument, waiting a bit, then turn off $2C and see if the instrument is well along in its output (say in the sustain or release phase).

[Nemesis]

Hah, I didn't spot that new test register when the YM3438 documentation was discovered. I'll have to test it out in hardware and see what I can make it do. If bit 5 has an effect, it stands to reason a few other bits probably have an effect too. The FM test register at 0x21 has the upper 6 bits with a known function, with the lower 2 bits with no know function. It stands to reason the DAC test register is probably similar, with bits 7 and 6 at least probably having some kind of effect. It's possible this test register will allow us to perform more precise tests on the YM2612 DAC.

[GManiac]

Heh, in my tests I discovered that bit 5 in $2C makes channels silent. I tested Channel 1 in Alg 7. I didn't guess to test DAC mode

The FM test register at 0x21 has the upper 6 bits with a known function, with the lower 2 bits with no know function.

What are these functions excatly? I made tests on Channel 1, and my discoveries are:
- bit 3 turns off Phase Generator. All operators stay in their phase. You can change TL and see changes of output.
- bit 4 turns off all operators except operator 4, even in Alg 7. Sine wave consists of two half-periods:
1) negative half of sine
2) when operator output reaches 0 from negative half, real output jumps to the bottom (level -256) independently of sine amplitude. When operator output reaches 0 back from positive half, we have p. 1)
Interestingly, bit 4 changes to -256 output values that are GREATER OR EQUAL 0. For example, we have silence (all operators are turned off and their output is 0). If we set bit 4, we'll observe strong jump to -256, and then if we clear bit 4, jump to 0 will occur.

- bit 5 turns on all operators on MAX amplitude according to their TL. It doesn't change TL and Algorithm.

[Nemesis]

I haven't done comprehensive tests on it myself, but I've seen other documentation out there, in particular, this one:
http://www.msxarchive.nl/pub/msx/mirror ... ym2612.txt

A lot of what's written in that document is wrong or very incomplete, IE, for bits 3, 4 and 5, but it sounds like you've got those ones figured out anyway. Bits 6 and 7 are very useful, as they allow the internal 14-bit output data from the operator unit to be read out over the status register. This feature was crucial for the YM2612 testing I performed. My notes on these bits are as follows:
"bit 7 - Select upper/lower bits of 14-bit output from operator unit to the accumulator. If set, lower bits are read, otherwise upper bits are read. Note that when the upper bits are selected, the lower 6 bits of the 8-bit result contain the upper 6 bits of the 14-bit operator output. The upper 2 bits of the result do return data, but the meaning of that data is currently unknown.
bit 6 - Enable output of operator data to status register"

The rest of the bits in the test register I haven't comprehensively tested. There are some notes on the YM2151 test register which are quite comprehensive:
http://www.msxarchive.nl/pub/msx/mirror ... ym2151.txt
A lot of what's in there might not apply to the YM2612, but the YM2151 does have bits in the test register which affect the LFO. I wouldn't be surprised if the YM2612 has similar features in bits 0 and 1.

[GManiac]

Bits 6 and 7 are very useful, as they allow the internal 14-bit output data from the operator unit to be read out over the status register

Awesome! I would like to know this in 2009 Regretfully, now I'm not very interested in all this stuff about YM.

Your links don't work...

[HardWareMan]

Your links don't work...

Everything okay:

Code: Select all

Here's the format of the YM2612 test register ($21), as best as I can
tell:

bit 7 - If bit 6 set, select 0=LSB, 1=MSB of serial data
bit 6 - If set, reading status returns serial data LSB or MSB instead of
status flags
bit 5 - If set, only the attack phase and possibly decay occur, there is
no sustain o release. It sounds like each channel was keyed-on rapidly.
When the bit is cleared, the channels resume their original position
within the envelope so this bit doesn't have any lasting change on
them.       
bit 4 - Data sent to DAC is inverted - this is *really* loud, so turn
down the volume before using this bit. ;)
bit 3 - Audio output is muted, (the PSG still works of course) bits 4,5
will make sound faintly audible when set in conjunction.
bit 2 - Timer A and B run 24 times faster. 
bits 1,0 - No effect.

Bits 7, 6 allow you to read the serial data sent from the YM2612 to the
DAC. (the other chip, YM3012 - not the DAC at $2A/$2B) I'm unsure of the
exact format, it's probably similar to the YM2151. Bit 4 inverts the
data sent to the DAC, but not the data read from the status register.
Compared to the YM2151 test register documented in MAME, the last 3 bits
may have something to do with the LFO. And I'm also not entirely sure
about the MSB/LSB order for bit 6. Other than that the two work in a
mostly identical way.

[GManiac]

Everything okay:

When I wrote this they really didn't work