New Documentation: An authoritative reference on the YM2612
Moderator: BigEvilCorporation
koilazka: it's a sum for one chips to be decapped and throughoutly photographed by a professional using a microscope.
Check pages 20-22 of this very thread to read on what and how could be done thanks to such an operation.
(viewtopic.php?t=386&postdays=0&postorder=asc&start=300)
Here's original doc from the guys who decapped OPL2 and OPL3 YMFs and extracted rom table contents from the images, and that way cleared/confirmed out a lot of things for the emulation community.
http://docs.google.com/View?docid=dd8kqn9f_13cqjkf4gp
AamirM: I think that donation gathering will not happen rapidly and instantly - it will likely stretch for several months, so no need to worry
Check pages 20-22 of this very thread to read on what and how could be done thanks to such an operation.
(viewtopic.php?t=386&postdays=0&postorder=asc&start=300)
Here's original doc from the guys who decapped OPL2 and OPL3 YMFs and extracted rom table contents from the images, and that way cleared/confirmed out a lot of things for the emulation community.
http://docs.google.com/View?docid=dd8kqn9f_13cqjkf4gp
AamirM: I think that donation gathering will not happen rapidly and instantly - it will likely stretch for several months, so no need to worry
_____________
www.dtech.lv
www.dtech.lv
For more appetising fun, here are three versions of beloved SID decapped and micrographed:
http://www.digital-circuits.org/sid/CSG%20Micrographs/
Guys even reversed some analog circuits (you can dig up there somewhere some sketches reversed from the layers)
http://www.digital-circuits.org/sid/CSG%20Micrographs/
Guys even reversed some analog circuits (you can dig up there somewhere some sketches reversed from the layers)
_____________
www.dtech.lv
www.dtech.lv
I was told about this company, located in US also which seems to do some good quality decapping and provide good quality photos, could be a cheaper alternative:
http://www.flylogic.net/
http://www.flylogic.net/
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
The Flylogic guys seem good. I looked at their blog and how they crack different security measures etc. in chips, lol
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: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
I saw the result of Chinese crackers. They make decap of chip, find the position security fuse bit and clear it with laser. Then just read the firmware by programmer. Simply brilliant.TmEE co.(TM) wrote:The Flylogic guys seem good. I looked at their blog and how they crack different security measures etc. in chips, lol
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am
Could somebody explain exactly what the goal with decapping is? What thing(s) are we trying to get?
1.) I know the YM2612 has an internal ROM with a sine wave. This has been read out with other FM chips using the test mode, and the YM2612 has a test mode too. Couldn't we use that or at least attempt to?
2.) Are there other tables in the YM2612 we need to read? If so, what?
3.) What ROM data is in the VDP that we intend to recover by decapping?
One concern is that typically ROM data is not stored in an obvious way so it could be very difficult to find the ordering of the binary data. If you know what the data should be, it's easier to find the ordering. If the contents of a table are completely unknown then it is very difficult. E.g. If you think of the ROM as a matrix of bits the rows and columns are all interleaved and transposed and shuffled around, nothing is in linear order on the die.
Another concern is that simply having a photograph of the chip will not (in an obvious way) reveal anything about how it works, to the point that we can solve (say) FM or VDP emulation issues that still persist.
For example the NES PPU has been around since the 80s, and nobody has copied it. There have been reverse-engineered implementations, but in terms of figuring out how it works at the gate level, it has never been done based on die photographs. That's one of the reasons the Famiclones are so terrible. Now in comparison the Genesis VDP is several orders of magnitude more complex.
Not trying to rain on the parade, just trying to be realistic about what the goals are and if we can accomplish them.
1.) I know the YM2612 has an internal ROM with a sine wave. This has been read out with other FM chips using the test mode, and the YM2612 has a test mode too. Couldn't we use that or at least attempt to?
2.) Are there other tables in the YM2612 we need to read? If so, what?
3.) What ROM data is in the VDP that we intend to recover by decapping?
One concern is that typically ROM data is not stored in an obvious way so it could be very difficult to find the ordering of the binary data. If you know what the data should be, it's easier to find the ordering. If the contents of a table are completely unknown then it is very difficult. E.g. If you think of the ROM as a matrix of bits the rows and columns are all interleaved and transposed and shuffled around, nothing is in linear order on the die.
Another concern is that simply having a photograph of the chip will not (in an obvious way) reveal anything about how it works, to the point that we can solve (say) FM or VDP emulation issues that still persist.
For example the NES PPU has been around since the 80s, and nobody has copied it. There have been reverse-engineered implementations, but in terms of figuring out how it works at the gate level, it has never been done based on die photographs. That's one of the reasons the Famiclones are so terrible. Now in comparison the Genesis VDP is several orders of magnitude more complex.
Not trying to rain on the parade, just trying to be realistic about what the goals are and if we can accomplish them.
Already done. That's how I derived the algorithm I provided in this thread to re-create the bit-accurate sine table.1.) I know the YM2612 has an internal ROM with a sine wave. This has been read out with other FM chips using the test mode, and the YM2612 has a test mode too. Couldn't we use that or at least attempt to?
Well, none I know of that we need to read. The tables I know about are:2.) Are there other tables in the YM2612 we need to read? If so, what?
-Sine table
-Pow table
-Detune table
-Phase modulation increment table
-Attenuation increment table (may be largely "generated" rather than stored.
-Envelope generator counter shift table (may be entirely generated)
-LFO increment table (probably part of the circuit path)
-Amplitude modulation shift table (probably part of the circuit path)
I've already reverse engineered the contents of all these tables to my satisfaction, as in, I'm confident I have them 100% correct, perhaps with the exception of the attenuation increment table for which I haven't directly verified every single entry, so maybe 95% confident for that one.
I don't think there's any data of note in there other than the tables.3.) What ROM data is in the VDP that we intend to recover by decapping?
I suppose the interest in decapping the YM2612 is more of a curiosity thing for me than anything else. It would be interesting to get a look at the inner workings of the chip, and perhaps try and reverse some of the more curious logic pathways of the YM2612 by analysing the real implementation on the die, if such a thing is actually possible. We might also be able to gather some more information on the embedded DAC, in particular on now many bits of input it accepts, and any precision issues it might have, which it is very difficult to perform accurate tests on due to the fact the only output we get from it is analog.
Technically speaking though, we don't really need to decap the YM2612. It might lead to some improvements in emulation, but probably not any that anyone is going to actually hear a difference from. The VDP would be an interesting project though, I'd love to take a peek inside that chip. As you say though, staring at shots of the die might not yeild any useful information in and of itself. I think it would help to direct reverse-engineering attempts on the right path though. I think it should be possible to at least block out what parts of the die manage what "units" of functionality. Simply getting a look at what units connect to what can help to better understand how the device operates internally.
At any rate, a die shot is just another form of documentation, and hey, the more documentation the better. Payoffs from this kind of thing are probably going to be very long term though. Maybe in 10 years time they'll attract the interest of some guru who's got a background in failure analysis or design/reverse engineering of hardware devices, and he'll be able to look at these shots and read them like code. If I can stare at a random binary and make sense out of it (IE, what's code, what's data, whether its little endian or big endian, CISC or RISC, register width, etc) and then start reversing it, I don't see why someone can't do the same with a die shot. It doesn't have to hold all the answers, just enough to get someone started, or compliment the documentation we already have.
I think this is still the biggest, unresolved issue concerning correct YM2612 emulation. When I got my first Mega Drive (which was after I used Genecyst and KGEN), I immediately noticed this strange bias in the audio output in quiet passages.HardWareMan wrote:I confirm that! A very noticeable ladder effect is exist.Nemesis wrote:I was going to look at the DAC last, once I've finished examining the other components of the YM2612. I've also noticed the extreme jump between low volume and silence though. I'm sure the answer to that behaviour lies in the DAC.
To me, it looks like an offset is somehow added to the digital data before the sign conversion takes place, which results in a noticeable gap in the positive and negative interval around the zero mark. When I first heard this effect on the real hardware, I thought it was due to the lower precision of the YM2612 DAC. But after seeing these waveforms, I agree with Steve Snake that the there seems to be a bug before the digital data reaches the DAC.
What might shed some light onto the nature of this bug would be the question if the DAC mode of channel 6 exposes the same kind of distortion than the native FM data. For example, when generating a sawtooth by writing incrementing values into the DAC, is there the same gap around the zero mark? If yes, is it a flaw of the DAC itself, and can the results be used to reverse-engineer what range of values is affected? If no, is this a confirmation that the DAC is fine and that the bug seems to occur only during the 14 Bit-> 9 Bit conversion of the FM data?
Anyway, I think no YM2612 emulator can be considered complete unless this characteristic of the real chip is emulated. It has quite some effect on the way how the original Mega Drive/Genesis sounds.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Here's some fragments of a recording form my MD2 I took long ago,
Only PCM here, the gap is the point where my sound engine is doing something else than playing PCM samples :
http://www.fileden.com/files/2008/4/21/ ... CM_MD2.png
Here's a FM waveform in action too with samples. Gap is same as before.
http://www.fileden.com/files/2008/4/21/ ... FM_MD2.png
I cannot see that sudden jump. You can see a bit of "staircase" on the FM in the gap though... if one could count all the gaps, one could get to know the real output res of the MD2 YM implementation... I don't have precise enough equipment for that.
EDIT: I'm not very zoomed in there...
Only PCM here, the gap is the point where my sound engine is doing something else than playing PCM samples :
http://www.fileden.com/files/2008/4/21/ ... CM_MD2.png
Here's a FM waveform in action too with samples. Gap is same as before.
http://www.fileden.com/files/2008/4/21/ ... FM_MD2.png
I cannot see that sudden jump. You can see a bit of "staircase" on the FM in the gap though... if one could count all the gaps, one could get to know the real output res of the MD2 YM implementation... I don't have precise enough equipment for that.
EDIT: I'm not very zoomed in there...
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
Thank you, but... isn't the "ladder effect" supposed to occur on the real YM2612 only? Does your MD2 have the external YM2612 and not the integrated one?TmEE co.(TM) wrote:Here's some fragments of a recording form my MD2 I took long ago,
I guess we need a recording from an early MD1. I have one, but no possibility to run code.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
This was just for comparsion. MD2 is different form MD1.
I have several MD1s around, I need to get some time to do some recording...
I have several MD1s around, I need to get some time to do some recording...
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: 145
- Joined: Sun Jan 28, 2007 2:01 am
- Location: DCEvolution.net
- Contact:
@Eke: I posted a request at romhacking.net and Paul Jensen replied with a basic translation of these:
http://www.romhacking.net/forum/index.p ... 422.0.html
http://www.romhacking.net/forum/index.p ... 422.0.html
Eke wrote:Here are some extracted text from the previously posted YM3438 manual that is mentionning the DAC, it would be nice if someone could translate them:
Eke wrote:On that topic, some other part of the YM3438 manual I would be curious to have translated (i.e info that are not already covered by YM2608 translated manual):
Something about the read mode (when reading FM address 1,2,3):
An article about differences between Yamaha OPN chips:
Paul Jensen wrote: Didn't I already post translations for some of this stuff in the Spritesmind forums?
I can post a more thorough translation later, but here are some basics:
HTH
- 1. Each slot/carrier is output as a 9-bit value.
- 2.The DAC is 9-bit.
- 3. The chip has a 96 dB dynamic range internally/theoretically, but the DAC is only 9-bit, so the effective dynamic range is 54 dB.
- 4. Due to the lower dynamic range of the DAC, overflows can occur if you set attenuation (TL) too low.
- 5. The minimum wait time between writes to addresses $21 through $B6 is 17 clock cycles.