New Documentation: An authoritative reference on the YM2612

andlabs · Post by **andlabs** » Wed Oct 12, 2011 4:57 pm

Thanks; I'll take a look into these since they look like they would be more effective in understand the chip =P However I think I misstated my first question: I meant what was the calculation for the array itself?

EDIT wait I see, it's the "Where Block is the 3-bit block data, and N4/N3 are built from fnumber as follows: " part. Thanks anyway =P

andlabs · Post by **andlabs** » Wed Oct 19, 2011 2:39 am

This is what I can gather/guess about what happens on each YM2612 cycle, am I correct?

Code: Select all

if current channel is channel 6 in PCM mode
	output PCM byte to DAC
	if 4*NCYCLES_PER_OPERATOR cycles passed
		move to next channel
else
	run SSG-EG for current channel
	if NCYCLES_PER_EGUPDATE cycles passed
		update EG for current channel
	output EG for current channel
	run phase generator for current operator
	run LFO for current operator
	run output generator for current operator
	if current operator is output
		send current operator output to DAC
	else
		send silence (is that what the low outputs shown in the image in post 7516 means?)
	if NCYCLES_PER_OPERATOR cycles passed
		move to next operator
		if finished with this channel
			move to next channel

with post 7516 being this one? Thanks.

Chilly Willy · Post by **Chilly Willy** » Wed Oct 19, 2011 10:22 pm

andlabs wrote:This is what I can gather/guess about what happens on each YM2612 cycle, am I correct?

Code: Select all

if current channel is channel 6 in PCM mode
	output PCM byte to DAC
	if 4*NCYCLES_PER_OPERATOR cycles passed
		move to next channel
else
	run SSG-EG for current channel
	if NCYCLES_PER_EGUPDATE cycles passed
		update EG for current channel
	output EG for current channel
	run phase generator for current operator
	run LFO for current operator
	run output generator for current operator
	if current operator is output
		send current operator output to DAC
	else
		send silence (is that what the low outputs shown in the image in post 7516 means?)
	if NCYCLES_PER_OPERATOR cycles passed
		move to next operator
		if finished with this channel
			move to next channel

with post 7516 being this one? Thanks.

Hmm - does the FM channel still update even if it is set to PCM? It seems to me that the PCM enable would only effect whether the FM out or the PCM out gets added to the sum. It's POSSIBLE some game might rely on the channel being updated even if it's not enabled for output.

GManiac · Post by **GManiac** » Fri Oct 21, 2011 4:21 pm

Chilly Willy wrote:Hmm - does the FM channel still update even if it is set to PCM?

Yes, it does. FM Channel 6 and Reg $2A are independent of each other. "DAC mode" (Reg $2B) only chose output of one of them. If it is in "FM Mode" it outputs Channel 6 output. If it is in "DAC Mode", it outputs value stored in Reg $2A and normalized to scale of DAC (-512 to + 512). Normalization formula is
(v - $80) * 4
where v = ($2A).

I tested in on HW.

andlabs · Post by **andlabs** » Sat Oct 22, 2011 4:48 am

Good to know, thanks.

Thinking about it some more, wouldn't the EG also run independently of the phase and output generators? The MAME source code implies that the global cycle counter is global to all channels, is this really the case? If so there's really no other way to have the EG work... as far as I can tell anyway :/

andlabs · Post by **andlabs** » Fri Nov 11, 2011 1:17 am

In addition to the questions I asked above, I have a few others:

With regards to the SSG-EG register, the YM2149 datasheet and Neo-Geo manual (YM2610) all list inverted normal output for any combination 01xx (that is, 01xx behaves like 1111), but that's not what we have down for YM2612, and the YM3438 APL doesn't list any 0xxx values. Is the YM2612 a special case or does it work just like the YM2149 and YM2610?

In Nemesis's SSG-EG implementation, key off has "state->attenuation = Data(attenuationBitCount, 0x200) - state->attenuation; ". What is the Data call? The MAME code just subtracts from 0x200...

When does the EG first run — on the first cycle, the second cycle, or the third cycle of the entire system execution?

I probably will have more questions but I don't remember them now... Thanks anyway!

Nemesis · Post by **Nemesis** » Sun Nov 13, 2011 10:44 pm

With regards to the SSG-EG register, the YM2149 datasheet and Neo-Geo manual (YM2610) all list inverted normal output for any combination 01xx (that is, 01xx behaves like 1111), but that's not what we have down for YM2612, and the YM3438 APL doesn't list any 0xxx values. Is the YM2612 a special case or does it work just like the YM2149 and YM2610?

A setting of 0xxx appears to have no effect on the YM2612. When figuring out SSG-EG, I ran a test on all 256 possible values for the SSG-EG register. The upper 4 bits had no observable effect, and unless bit 3 was set to 1, there was also no observable effect either.

In Nemesis's SSG-EG implementation, key off has "state->attenuation = Data(attenuationBitCount, 0x200) - state->attenuation; ". What is the Data call? The MAME code just subtracts from 0x200...

Nothing too important. "Data" is a container class in my emulator I use to simplify otherwise messy operations. It gives me handy function calls to do things like get/set individual bits or segments of a data value, rather than having to use things like masks and shifts everywhere in my code, which I found were very difficult to read, too easy to make a typo or error in, and hard to spot when there was an error. In this case, the fact I'm using the "Data" class to perform the subtraction means that the result will be masked to the size of "attenuationBitCount", or in other words, 10 bits. Equivalent code without the Data class would be something like this:
"state->attenuation = ((unsigned int)0x200 - state->attenuation) & ((1 << attenuationBitCount) - 1);"

When does the EG first run — on the first cycle, the second cycle, or the third cycle of the entire system execution?

Good question. I have absolutely no idea, and no real idea how I could test that either. If the YM2612 uses some kind of volatile internal register to track what cycle it's on, it might not bother initializing it, since it's not really that important. It will power up outputting silence due to the way the other registers are initialized, so it might not care what internal cycle it starts at on power-up. I've seen other devices which behave in this way. The VDP for example can start rendering from any point in a frame, it doesn't begin at any particular point when it is first powered on. The YM2612 might be the same. If this is the case, there isn't really a concept of a "first" cycle.

HardWareMan · Post by **HardWareMan** » Sat Mar 31, 2012 2:51 pm

Boom! Shake-shake-shake the room!
Hallelujah! I started a project of decap those chips! Let me introduce to you: YM2612

And it's clone: TA-07

These chips have different technology, but it still shows that the clone is made almost by copy-paste technique. For example, you may look at it here. So, very soon we can know almost all about YM2612 and it's clones. Soon I will provide you photos with enough quality. Feel free to use it as you wish. Wish me luck to finish this project. You can start to search peoples, which can read these photos, or learn it yourself.
Tic-tic-tic-tic Boom!

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Mar 31, 2012 9:14 pm

That is really awesome

Nice to see the clones are close to original, and probably work exactly like originals

HardWareMan · Post by **HardWareMan** » Sun Apr 01, 2012 10:21 am

I already get YM2612 photos at 400x zoom, now I must stitch them together. All 268 of them. :3 Check this out!

Stef · Post by **Stef** » Sun Apr 01, 2012 11:35 am

Hehe excellent !

Nemesis · Post by **Nemesis** » Tue Apr 03, 2012 12:59 am

Haha! This is beyond awesome, I'm looking forward to taking a close look at these die shots! We have such a good understanding of the main internal pipeline for this chip already, that we might be able to make some real discoveries from looking at the die in the less well known areas, in particular from examining the DAC implementation.

HardWareMan, do you have any plans to decap other Mega Drive related chips? I think it would be very beneficial to get the VDP in particular decapped, with the bus arbiter and I/O controller being next on the list. Once the decapped shots are out there for anyone to see, I think they'll be a source of new information for a long time into the future. I've been amazed at the work that's been done with the 6502 recently ( http://www.visual6502.org ), where they've managed to build a full transistor-level emulation of the chip from analysis of the die shots. This may never happen for the Mega Drive, but it just goes to show how much information these images can yeild.

HardWareMan · Post by **HardWareMan** » Tue Apr 03, 2012 3:00 am

Nemesis wrote:HardWareMan, do you have any plans to decap other Mega Drive related chips?

It may very well be. I recently discovered this opportunity decapsulation with a good zoom and good speed of get the result and I don't intend to throw in the near future. While I do stitch Yamaha pics, I have already started to recieve pics TA-07.

Chilly Willy · Post by **Chilly Willy** » Tue Apr 03, 2012 7:06 pm

One of the things I'm hopeful about is that each new bit of info about these old FM chips show how simple the design is when you actually know what is it is. Emulations of the FM chips have always consumed a lot more power than they need because they work in a more idealized manner rather than how the chips actually work. Once the 2612 is understood, an exact emulation should work on lesser systems, like the GBA or PSP or NDS, without consuming so much time that it slows the rest of the emulation. Then you won't need to cut back on the FM emulation to run games full speed on such systems.

Nemesis · Post by **Nemesis** » Tue Apr 03, 2012 11:43 pm

That would be nice. You can tell when you're missing something when writing an emulation core, if it takes a massive number of calculations to perform some trivial operation. That said, I think one of the big problems with emulating hardware devices like the YM2612, VDP, etc, is that something can be extremely simple to build using transistor logic, and run extremely fast, but extremely difficult and slow to write code to emulate.

There are two main issues: bit manipulation, and parallellism. You've got to remember, these raw circuits can just take a 16-bit input, and break it up into half a dozen peices purely by where the data lines are connected, which then get sent to half a dozen different circuits, in parallel. Each circuit can then work with its own bit of data to produce some result, and often, this can happen in a single clock cycle for that chip. Emulating that in code often requires a lot of AND's, OR's, and bitshifts just to break apart the data, and then you've usually got to run each operation in series, since you can't parallellize in software for a 50-cycle peice of code and get a performance win.

Here's a good example of some of these difficulties, from my VDP core:

Code: Select all

unsigned int screenSizeModeV = ((vszState & 0x1) & ((~hszState & 0x02) >> 1)) | ((vszState & 0x02) & ((~hszState & 0x01) << 1));

This code correctly limits the vertical screen playfield size, based on the specified horizontal and vertical screen modes. I know exactly what that is in hardware: it's two NAND gates. In my code, I need a big comment above it just to explain what it's doing.

Of course, this kind of stuff can often be made faster using pre-calculated conversion tables and the like, but on the whole, you're still a lot slower than the real hardware. This can all mean what was a trivial circuit taking some data, splitting it up, running bits of it through a few logic operations, and outputting a few other numbers at the end, can end up taking hundreds of cycles to emulate, while the hardware device did it in one cycle. That's just the nature of emulation sometimes.