New Documentation: An authoritative reference on the YM2612
Moderator: BigEvilCorporation
Re: New Documentation: An authoritative reference on the YM2612
I did some research on laser decapping, and found some very interesting info.
http://hackaday.com/2015/08/24/using-a- ... decap-ics/
Seems this is an up and coming method. You might want to read it over and follow the links, and show it to your buddy. Looks like laser decapping is possible, might just be a matter of getting the technique and power levels right?
EDIT: Just noticed this article is actually dealing with a die covered in a blob of epoxy, not a typical plastic package. I think this is a very different beast, so maybe none of this applies.
http://hackaday.com/2015/08/24/using-a- ... decap-ics/
Seems this is an up and coming method. You might want to read it over and follow the links, and show it to your buddy. Looks like laser decapping is possible, might just be a matter of getting the technique and power levels right?
EDIT: Just noticed this article is actually dealing with a die covered in a blob of epoxy, not a typical plastic package. I think this is a very different beast, so maybe none of this applies.
Re: New Documentation: An authoritative reference on the YM2612
I've done a little more research since my last post, and I'm pretty much on the same page. The wiki at siliconpr0n lists a technique using concentrated sulfuric acid only, and it looks like this may be possible with the facilities I have access to. I will have more information in the coming weeks.
Would it be helpful to everyone if a single VDP/IO/arbiter/OPN2/PSG ASIC was decapped and photographed, even if this meant multiple revisions were not documented? If so, I'll just forget about the manual method and go to EAG/MEFAS.
As far as the laser, that's exactly the article my buddy saw and got him going--but those "glop tops" are epoxy only, no glass. He's going to try something with the laser and a powerful air jet next, to see if he can do something about the glass.
Would it be helpful to everyone if a single VDP/IO/arbiter/OPN2/PSG ASIC was decapped and photographed, even if this meant multiple revisions were not documented? If so, I'll just forget about the manual method and go to EAG/MEFAS.
As far as the laser, that's exactly the article my buddy saw and got him going--but those "glop tops" are epoxy only, no glass. He's going to try something with the laser and a powerful air jet next, to see if he can do something about the glass.
-
- Very interested
- Posts: 86
- Joined: Fri Sep 25, 2015 4:16 pm
Re: New Documentation: An authoritative reference on the YM2612
I'd actually love to see a decapping of the Genesis 3 all-in-1 ASIC, if that's available.
Re: New Documentation: An authoritative reference on the YM2612
You want to donate one?mikejmoffitt wrote:I'd actually love to see a decapping of the Genesis 3 all-in-1 ASIC, if that's available.
-
- Very interested
- Posts: 86
- Joined: Fri Sep 25, 2015 4:16 pm
Re: New Documentation: An authoritative reference on the YM2612
I would, but mine isn't available since I'm not anywhere near it. If you can give me a few months, then yeah, that should be possible.Sauraen wrote:You want to donate one?mikejmoffitt wrote:I'd actually love to see a decapping of the Genesis 3 all-in-1 ASIC, if that's available.
Re: New Documentation: An authoritative reference on the YM2612
Eventually we'd want both, but only one chip could be done right now, doing the all-in-one would be a pretty good idea. That at least gives us a peek into all the chips in one hit. Most likely the ASIC is little more than each of the original discrete chips glued together on the one die. Although we do know there are some internal differences with some of the components like the VDP, it's a great starting place, and we can always decap the discrete versions later on. The other advantage is that if we decap the discrete versions later, we'll get the first revisions of them done, while the ASIC effectively has the last revisions of them, so it'll be able to highlight internal differences that have occurred between the versions.Sauraen wrote:Would it be helpful to everyone if a single VDP/IO/arbiter/OPN2/PSG ASIC was decapped and photographed, even if this meant multiple revisions were not documented? If so, I'll just forget about the manual method and go to EAG/MEFAS.
They're actually pretty easy to get, any VA2 Genesis 3, which you can identify by a serial number beginning with "AG82", has the very last revision of that chip. The system isn't really considered a collector's item, so they're usually cheap as chips. Here's one on ebay right now for $16: http://www.ebay.com/itm/252116959245Sauraen wrote:You want to donate one?mikejmoffitt wrote:I'd actually love to see a decapping of the Genesis 3 all-in-1 ASIC, if that's available.
Pretty hard to beat that price.
EDIT:
Since that one is sold as untested, and you're going to invest quite a bit of time and effort into this, you may only want to go ahead with the decapping of that system if you're able to test it before you proceed. Almost certainly there's absolutely nothing wrong with it (after all, this is the board: http://segaretro.org/File:PC_BD_MD3_VA2_USA.jpg ), but better to check before proceeding IMO. If you just want to buy one that's listed as working, there are plenty of other systems going, but unfortunately a lot of ebay sellers don't show the serial numbers in their pictures. This was the cheapest one I could find listed as known working which showed an AG82 serial: http://www.ebay.com/itm/161864280729
There are other cheaper systems (and even a cheaper bundle of 3 systems) you could look at If you're willing to message the sellers to check the serial numbers. I'd strongly suggest sticking to the VA2 board, since we already know it contains some important internal changes in this chip revision that have been noticed in software.
Re: New Documentation: An authoritative reference on the YM2612
If we go with requests for decaps we could try the TCT-6705 as well. Yes, it's a clone, but I checked it against Overdrive and the whole demo behaves as expected so I imagine it's some sort of superclone. The thing that catches my attention is that the Mega 3 (the clone I tested with) has 48* of the pins unconnected (out of 128), and I don't think there are that many connections under the chip since there really isn't much room (there's nothing on the other side of the board so there's no way to dodge crosses). With that many pins unconnected I imagine there must be something going on.
*Actually 49, but one has a trace going nowhere, so I assume it's just some toggle e.g. Master System or TMSS.
We should probably discuss which chips to decap in another thread though (so we can keep discussion about the YM2612 separate from the rest of the stuff, and make it easier to go back and see what we want to decap =P).
*Actually 49, but one has a trace going nowhere, so I assume it's just some toggle e.g. Master System or TMSS.
We should probably discuss which chips to decap in another thread though (so we can keep discussion about the YM2612 separate from the rest of the stuff, and make it easier to go back and see what we want to decap =P).
Sik is pronounced as "seek", not as "sick".
Re: New Documentation: An authoritative reference on the YM2612
Okay, here's a thread about the decapping: viewtopic.php?f=13&t=2191
Re: New Documentation: An authoritative reference on the YM2612
maybe you have some dll of YM2612 for using in another programm languages? i mean send command like:
SendToYM2612(register, value) like OPN.dll, that give me ValleyBell... i see full code, but i think i cant to port this to my language...
SendToYM2612(register, value) like OPN.dll, that give me ValleyBell... i see full code, but i think i cant to port this to my language...
Re: New Documentation: An authoritative reference on the YM2612
checkout any opensource emulator, then separate its YM2612 into external DLLSeregaZ wrote:maybe you have some dll of YM2612 for using in another programm languages? i mean send command like:
SendToYM2612(register, value) like OPN.dll, that give me ValleyBell... i see full code, but i think i cant to port this to my language...
for example here is genplus-gx YM2612 and SN76489 (PSG): https://github.com/ekeeke/Genesis-Plus- ... core/sound
here is gens-rerecording YM2612: https://github.com/TASVideos/gens-rerec ... c/ym2612.c
and here is YM2612 from MESS: http://git.redump.net/mame/tree/src/dev ... fm2612.cpp
Don't forget to check license for compatibility
Re: New Documentation: An authoritative reference on the YM2612
Yeah that tends to be quite the issue, either it's something based on the MAME core which has an explicit "no commercial use" clause (this can become an issue for composing music for homebrew which would be otherwise legal) or it's based on the Gens core which is not exactly the greatest out there (although at least it allows commercial use since it's GPL... or is that part of the emulator not covered by it?).r57shell wrote:Don't forget to check license for compatibility
Sik is pronounced as "seek", not as "sick".
Re: New Documentation: An authoritative reference on the YM2612
currently MAME in process of relicensing, so in most parts it is BSD-3 or/and GPL already.Sik wrote:either it's something based on the MAME core which has an explicit "no commercial use" clause
but not in the case of FM OPL/OPN cores, its commercial usage was explicit forbidden by its author (Jarek Burczynski).
Re: New Documentation: An authoritative reference on the YM2612
And that wouldn't have helped with the derivative code either (see: Genesis Plus GX), since you can't change licenses retroactively.
Nice to see that there's an attempt to relicense MAME's code though. I can see where they come from with "no commercial use" but technically the way copyright works already would forbid it anyway for starters (having permission to use MAME commercially doesn't mean you have permission to run the games =P)
Nice to see that there's an attempt to relicense MAME's code though. I can see where they come from with "no commercial use" but technically the way copyright works already would forbid it anyway for starters (having permission to use MAME commercially doesn't mean you have permission to run the games =P)
Sik is pronounced as "seek", not as "sick".
Re: New Documentation: An authoritative reference on the YM2612
I don't see trouble here. If you testing commercial song playback for example in MESS, does it violate its license? If no, then obviously you can make other freeware composer thing based on its source and test songs there again. Or you can't? I'm not familar with law so close But you made me confused.Sik wrote:Yeah that tends to be quite the issue, either it's something based on the MAME core which has an explicit "no commercial use" clause (this can become an issue for composing music for homebrew which would be otherwise legal) or it's based on the Gens core which is not exactly the greatest out there (although at least it allows commercial use since it's GPL... or is that part of the emulator not covered by it?).r57shell wrote:Don't forget to check license for compatibility
But obviously you can't use its core as sound engine for commercial PC game for example. That's true.
And, in the end. It's always better to test music straightforward on console itself (sega genesis I mean), via JOYPAD port or stuff like UMDK etc...
Re: New Documentation: An authoritative reference on the YM2612
The problem being most licenses just say "non-commercial use" without giving any specifics on what counts as commercial use so in practice it's up to how angry is the lawyer =P
Sik is pronounced as "seek", not as "sick".