New Documentation: An authoritative reference on the YM2612

For anything related to sound (YM2612, PSG, Z80, PCM...)

Moderator: BigEvilCorporation

AamirM
Very interested
Posts: 472
Joined: Mon Feb 18, 2008 8:23 am
Contact:

Post by AamirM » Sat Jun 19, 2010 8:45 am

I wish I could donate some money. But I am totally broke right now :cry: . If the donations are accepted for a month or two, I may throw something in.

dtech
Interested
Posts: 33
Joined: Tue Jan 19, 2010 2:56 pm
Location: Latvia, EU
Contact:

Post by dtech » Sat Jun 19, 2010 2:04 pm

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 :)
_____________
www.dtech.lv

dtech
Interested
Posts: 33
Joined: Tue Jan 19, 2010 2:56 pm
Location: Latvia, EU
Contact:

Post by dtech » Sat Jun 19, 2010 2:39 pm

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)
_____________
www.dtech.lv

koilazka
Interested
Posts: 30
Joined: Mon Nov 30, 2009 1:51 am

Post by koilazka » Sun Jun 20, 2010 9:55 am

Image
That is awesome.

Eke
Very interested
Posts: 859
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Thu Jul 01, 2010 9:02 am

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/

TmEE co.(TM)
Very interested
Posts: 2392
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Thu Jul 01, 2010 12:03 pm

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

HardWareMan
Very interested
Posts: 732
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Fri Jul 02, 2010 3:34 am

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
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.

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Sat Jul 03, 2010 3:57 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.

Nemesis
Very interested
Posts: 773
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Fri Jul 16, 2010 3:41 am

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?
Already done. That's how I derived the algorithm I provided in this thread to re-create the bit-accurate sine table.
2.) Are there other tables in the YM2612 we need to read? If so, what?
Well, none I know of that we need to read. The tables I know about are:
-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.
3.) What ROM data is in the VDP that we intend to recover by decapping?
I don't think there's any data of note in there other than the tables.

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.

Richter X
Newbie
Posts: 8
Joined: Thu Sep 11, 2008 9:06 pm
Location: Hagan, Georgia, USA

Post by Richter X » Mon Aug 16, 2010 8:45 am

Would be nice for someone to reverse engineer the chips from the 32X and SegaCD as well, just to be able to finally make something like the unreleased Sega Neptune.

Oliver_A
Newbie
Posts: 7
Joined: Sun Nov 02, 2008 9:32 pm

Post by Oliver_A » Tue Aug 31, 2010 1:02 pm

HardWareMan wrote:
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.
I confirm that! A very noticeable ladder effect is exist.
Image
Image
Image
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.

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.

TmEE co.(TM)
Very interested
Posts: 2392
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Tue Aug 31, 2010 4:51 pm

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...
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

Oliver_A
Newbie
Posts: 7
Joined: Sun Nov 02, 2008 9:32 pm

Post by Oliver_A » Wed Sep 01, 2010 8:03 am

TmEE co.(TM) wrote:Here's some fragments of a recording form my MD2 I took long ago,
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?

I guess we need a recording from an early MD1. I have one, but no possibility to run code.

TmEE co.(TM)
Very interested
Posts: 2392
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Wed Sep 01, 2010 11:06 am

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...
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

Christuserloeser
Very interested
Posts: 145
Joined: Sun Jan 28, 2007 2:01 am
Location: DCEvolution.net
Contact:

Post by Christuserloeser » Mon Sep 13, 2010 9:25 pm

@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
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:

Image

Image

Image

Image
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):

Image

Image


An article about differences between Yamaha OPN chips:

Image
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:
  • 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.
HTH
http://www.DCEvolution.net - Gigabytes of free Dreamcast software for you

Image

Post Reply