New Documentation: An authoritative reference on the YM2612
Moderator: BigEvilCorporation
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
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
This is what I can gather/guess about what happens on each YM2612 cycle, am I correct?
with post 7516 being this one? Thanks.
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
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.andlabs wrote:This is what I can gather/guess about what happens on each YM2612 cycle, am I correct?
with post 7516 being this one? Thanks.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
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 isChilly Willy wrote:Hmm - does the FM channel still update even if it is set to PCM?
(v - $80) * 4
where v = ($2A).
I tested in on HW.
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 :/
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 :/
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!
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!
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.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?
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: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...
"state->attenuation = ((unsigned int)0x200 - state->attenuation) & ((1 << attenuationBitCount) - 1);"
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.When does the EG first run — on the first cycle, the second cycle, or the third cycle of the entire system execution?
-
- Very interested
- Posts: 746
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
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!
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!
-
- Very interested
- Posts: 2443
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
That is really awesome
Nice to see the clones are close to original, and probably work exactly like originals
Nice to see the clones are close to original, and probably work exactly like originals
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 746
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
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, 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.
-
- Very interested
- Posts: 746
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
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.Nemesis wrote:HardWareMan, do you have any plans to decap other Mega Drive related chips?
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 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.
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:
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.
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));
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.