Decapping more Genesis chips
Decapping more Genesis chips
This is a continuation of discussion about decapping from the YM2612 thread at viewtopic.php?f=24&t=386&start=750
I am a post-bac electrical engineering student at a major university in the US, and for my independent study research this semester I've been reverse engineering the YM2612 (some results at the link above). For various reasons (differences between YM2612/YM3438/integrated versions), the subject of decapping more Genesis chips came up. I have access to a professional microscope with micron resolution used for optoelectronics work in the department, and I MAY have access to a lab where I can do chemical decapping (lots of details are up in the air for now). If I end up not having access to this lab, I'm willing to pay to have one chip professionally decapped, and then do the photography. (Also, if anyone wants to send me decapped chips, I can photograph them as well.)
If I am able to do chemical decapping, I will want to do a batch at once of a whole bunch of different chips that are relevant. In this case, I will need recommendations for what chips to do, and preferably people willing to send me some of them (I have a non-reparable US Genesis II VA1.8 with the chip 315-5660-02 which I can sacrifice, as well as discrete YM2612 and YM3438).
If I have to only pick one, which one is best? Nemesis has suggested the ASIC from the VA2 Genesis 3--could someone explain how this is different from the ASIC in any other Genesis 3 (VA1?). Also, since everyone knows how the 68000 and Z80 work, and this chip is just the Genesis 2 plus those CPUs, what's the benefit to using this over a Genesis 2 ASIC?
As my particular interest is in the OPN2 versions, I happen to know there exists a die shot of YM2612 and YM3438. The former is usable but not great quality, and the latter is pretty good. I'm under the impression that the VDP, bus arbiter, and I/O have never been done (but I'm unclear on whether they were every separate chips).
Please try to keep the information here organized!
I am a post-bac electrical engineering student at a major university in the US, and for my independent study research this semester I've been reverse engineering the YM2612 (some results at the link above). For various reasons (differences between YM2612/YM3438/integrated versions), the subject of decapping more Genesis chips came up. I have access to a professional microscope with micron resolution used for optoelectronics work in the department, and I MAY have access to a lab where I can do chemical decapping (lots of details are up in the air for now). If I end up not having access to this lab, I'm willing to pay to have one chip professionally decapped, and then do the photography. (Also, if anyone wants to send me decapped chips, I can photograph them as well.)
If I am able to do chemical decapping, I will want to do a batch at once of a whole bunch of different chips that are relevant. In this case, I will need recommendations for what chips to do, and preferably people willing to send me some of them (I have a non-reparable US Genesis II VA1.8 with the chip 315-5660-02 which I can sacrifice, as well as discrete YM2612 and YM3438).
If I have to only pick one, which one is best? Nemesis has suggested the ASIC from the VA2 Genesis 3--could someone explain how this is different from the ASIC in any other Genesis 3 (VA1?). Also, since everyone knows how the 68000 and Z80 work, and this chip is just the Genesis 2 plus those CPUs, what's the benefit to using this over a Genesis 2 ASIC?
As my particular interest is in the OPN2 versions, I happen to know there exists a die shot of YM2612 and YM3438. The former is usable but not great quality, and the latter is pretty good. I'm under the impression that the VDP, bus arbiter, and I/O have never been done (but I'm unclear on whether they were every separate chips).
Please try to keep the information here organized!
Re: Decapping more Genesis chips
This page gives a pretty good overview on the various chips, integrated and discrete, that have been used in the Mega Drive:
http://wiki.megadrive.org/index.php?tit ... gory:Chips
Obviously you'll be wanting to do the YM2612 again at better quality for your project. Apart from that, the big three to do which have never been done would be:
315-5308 - Bus arbiter
315-5309 - Port IO
315-5313 - VDP
If you could only do one, I suggested the 315-6123 simply because it contains everything, and we know there were at least some differences between the previous 315-5960 chip, because reportedly the M68000 TAS opcode only functions correctly on this system. Decapping the original, discrete versions would be much better if possible though. Not only were some external pins removed when devices were integrated (including probably some potentially useful test pins), the original hardware with the discrete chips is usually what emulators are aiming to reproduce.
Of course, if you are able to do "lots" of chips, the Saturn has plenty to do:
https://upload.wikimedia.org/wikipedia/ ... rboard.jpg
One of the chips here is the YMF292-F, which might even be of interest for you in your project.
http://wiki.megadrive.org/index.php?tit ... gory:Chips
Obviously you'll be wanting to do the YM2612 again at better quality for your project. Apart from that, the big three to do which have never been done would be:
315-5308 - Bus arbiter
315-5309 - Port IO
315-5313 - VDP
If you could only do one, I suggested the 315-6123 simply because it contains everything, and we know there were at least some differences between the previous 315-5960 chip, because reportedly the M68000 TAS opcode only functions correctly on this system. Decapping the original, discrete versions would be much better if possible though. Not only were some external pins removed when devices were integrated (including probably some potentially useful test pins), the original hardware with the discrete chips is usually what emulators are aiming to reproduce.
Of course, if you are able to do "lots" of chips, the Saturn has plenty to do:
https://upload.wikimedia.org/wikipedia/ ... rboard.jpg
One of the chips here is the YMF292-F, which might even be of interest for you in your project.
Re: Decapping more Genesis chips
For what matters, register $A11000 (the one that makes the console output a refresh signal on the cartridge slot) only works on early revisions, being a no-op on later versions (also early revisions hang on accesses to $A14xxx, which later was used for the TMSS registers - this is why games check for the version in $A10001 first).Nemesis wrote:Decapping the original, discrete versions would be much better if possible though. Not only were some external pins removed when devices were integrated (including probably some potentially useful test pins), the original hardware with the discrete chips is usually what emulators are aiming to reproduce.
Sik is pronounced as "seek", not as "sick".
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Re: Decapping more Genesis chips
There's some fun stuff with the 315-5402 (bus + IO + TMSS) too. This is the MD1 VA5 ASIC, and there seems to be two versions of it, both with same marking. One has no TMSS at all (I got one of those) and one shows TMSS only when the machine is in EN/overseas mode (which is what the chip is supposed to be doing and what one friend has seen it always doing).
And the kicker here is that while both give 1 from the version register, access of the TMSS control register $A14100 will hang the machine on the funny version I got that doesn't show TMSS at all. I discovered that when I tried to dump the TMSS ROM from the machine to see if it differentiates the behaviour using hardware or it is done with software.
TMSS ROMs have been same on all other versions (except on SE-9x super clone ASIC, it has couple bits changed in the ROM so it always passes the checks).
And the kicker here is that while both give 1 from the version register, access of the TMSS control register $A14100 will hang the machine on the funny version I got that doesn't show TMSS at all. I discovered that when I tried to dump the TMSS ROM from the machine to see if it differentiates the behaviour using hardware or it is done with software.
TMSS ROMs have been same on all other versions (except on SE-9x super clone ASIC, it has couple bits changed in the ROM so it always passes the checks).
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: 292
- Joined: Sat Apr 21, 2007 1:14 am
Re: Decapping more Genesis chips
Aha, I never knew that and was wondering why my second-revision Megadrive was doing nothing special when using $A11000.For what matters, register $A11000 (the one that makes the console output a refresh signal on the cartridge slot) only works on early revisions, being a no-op on later versions.
Is there any comprehensive list about which Genesis models / chips support this feature and which ones don't?
Re: Decapping more Genesis chips
Not really, it was just the result of some quick testing because I wanted to see if we could use it to refresh DRAM on cartridges ¯\(º_o)/¯ Tough luck. (what does Game Toshokan do, anyway? the only custom hardware in it is 128KB of RAM as far as I know)
Sik is pronounced as "seek", not as "sick".
Re: Decapping more Genesis chips
Did you know http://zeptobars.ru/ ?
They decap at least a chip per week
perhaps they explain their method somewhere...to compare with yours....
They decap at least a chip per week
perhaps they explain their method somewhere...to compare with yours....
-
- Very interested
- Posts: 75
- Joined: Sun Jan 04, 2015 10:27 pm
- Location: Pennsylvania
- Contact:
Re: Decapping more Genesis chips
(Cool site! They briefly explain their method at here and here. They even decapped a PS1 MIPS R3k chip for a group of Russian hackers upon request, but no Sega chips.)KanedaFr wrote: perhaps they explain their method somewhere...to compare with yours....
SGDK homebrew dev and Unity3D Indie dev.
Sega does what Nintendont!
Sega does what Nintendont!
Re: Decapping more Genesis chips
On that topic, I have a bunch of broken saturns, so I can supply chips for decapping. I was told that the big unknowns would be the SCU (the DSP has incomplete documentation), the VDP1 (timing), and the VDP2 (sprite priorities). Maybe the OCU as well. Apparently, the YMF292-F has proper documentation available straight from Yamaha, so decapping that is not as important, though I do not have seen those documents myself.Nemesis wrote:Of course, if you are able to do "lots" of chips, the Saturn has plenty to do:
https://upload.wikimedia.org/wikipedia/ ... rboard.jpg
One of the chips here is the YMF292-F, which might even be of interest for you in your project.
edit: there was also the YMF713-S, which was a YMF292-F plus a 68EC000 on the same chip. It also had the TAS bug fixed, as well as the RESET command, and early prints of at least two games ended up broken due to this.
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am
Re: Decapping more Genesis chips
Decapping can be useful when the chip has ROM inside it. The SMPC and SH-1 from the Saturn would be good candidates for this as we don't have dumps of the internal ROM from either one. I think somebody tried and failed to do it with the SH-1 in the past, likely due to the complexity. But the SMPC would be ideal as (IIRC) it is a 4-bit microcontroller based on older technology.
Devices without ROM (like the VDPs, SCSP, etc.) are less useful to decap as there's no data to extract, and examining the images to determine their inner workings is difficult enough to be nearly impossible. Now projects like Visual6502 which did exactly that, but it required a lot of effort for 80's chips with transistor counts in the tens of thousands. You can imagine how hard it is for mid-90's chips where the transistor counts broke the one million mark. But who knows, there could be some interesting things in there like small look-up tables related to video rendering or sound production that could be extracted without too much effort.
From memory I think the the SCU DSP has OK documentation but there's no tools to assemble SCU programs for testing, so not much can be done in terms of experimenting. The SCSP DSP is very poorly documented but a suite of Macintosh software exists from the SDK that can be used in an emulated environment to build DSP programs. I guess these are solvable problems, but finding people that have sufficient interest to do endless experimenting on these parts to fill in the gaps in our knowledge is probably the tough part. Maybe having modernized tools would help.
Kaneda, I think moving the Game Toshokan stuff to its own thread is a good idea.
Devices without ROM (like the VDPs, SCSP, etc.) are less useful to decap as there's no data to extract, and examining the images to determine their inner workings is difficult enough to be nearly impossible. Now projects like Visual6502 which did exactly that, but it required a lot of effort for 80's chips with transistor counts in the tens of thousands. You can imagine how hard it is for mid-90's chips where the transistor counts broke the one million mark. But who knows, there could be some interesting things in there like small look-up tables related to video rendering or sound production that could be extracted without too much effort.
From memory I think the the SCU DSP has OK documentation but there's no tools to assemble SCU programs for testing, so not much can be done in terms of experimenting. The SCSP DSP is very poorly documented but a suite of Macintosh software exists from the SDK that can be used in an emulated environment to build DSP programs. I guess these are solvable problems, but finding people that have sufficient interest to do endless experimenting on these parts to fill in the gaps in our knowledge is probably the tough part. Maybe having modernized tools would help.
Kaneda, I think moving the Game Toshokan stuff to its own thread is a good idea.
Re: Decapping more Genesis chips
Well, I was mostly mentioning what I was told by other developers.
MAMEDEV is always crying about not having info on VDP1 timings. The SCSP DSP, I don't have much documents on that, but according to Steve there are docs by Yamaha about the SCSP which I'd assume include the DSP as well. EDIT: nope, we only have the Sega docs (which do come from Yamaha, but have no info on the DSP).
The SCU DSP definitely has a few things off in the documentation, Virtua Fighter supposedly already uses an instruction that isn't known. I recall the development tools having a DSP code debugger and a compiler as well.
The SH1 ROM was dumped a while ago, and reverse engineered to create a cart slot based launcher for backups, called Pseudo Saturn. I'm in contact with person who dumped it and I'm waiting on him to finish the dumping hardware, so all the different CDB versions can be dumped and released. Funny story, that... mamedev spent all the money and time trying to decap that thing so they can read the ROM out, and then this guy cracks it open in a few weeks using a Gameboy.
MAMEDEV is always crying about not having info on VDP1 timings. The SCSP DSP, I don't have much documents on that, but according to Steve there are docs by Yamaha about the SCSP which I'd assume include the DSP as well. EDIT: nope, we only have the Sega docs (which do come from Yamaha, but have no info on the DSP).
The SCU DSP definitely has a few things off in the documentation, Virtua Fighter supposedly already uses an instruction that isn't known. I recall the development tools having a DSP code debugger and a compiler as well.
The SH1 ROM was dumped a while ago, and reverse engineered to create a cart slot based launcher for backups, called Pseudo Saturn. I'm in contact with person who dumped it and I'm waiting on him to finish the dumping hardware, so all the different CDB versions can be dumped and released. Funny story, that... mamedev spent all the money and time trying to decap that thing so they can read the ROM out, and then this guy cracks it open in a few weeks using a Gameboy.
Last edited by Huge on Thu Dec 03, 2015 2:17 am, edited 1 time in total.
Re: Decapping more Genesis chips
about SCSP DSP docs - there (almost) none of it. if I not mistaken, most of info comes from Dreamcast AICA docs, there is some brief explanation what its opcode bits means and how its workflow is. but it lacks of details.
mentioned Macintosh software is almost useless, its like somewhat building kit, which have ready to use 'blocks' producing various sound effects, but none real info about its internal design.
mentioned Macintosh software is almost useless, its like somewhat building kit, which have ready to use 'blocks' producing various sound effects, but none real info about its internal design.
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am
Re: Decapping more Genesis chips
That's too bad. What would approach would you suggest for figuring out how the SCSP DSP works? Is decapping the only solution left?MetalliC wrote:about SCSP DSP docs - there (almost) none of it. if I not mistaken, most of info comes from Dreamcast AICA docs, there is some brief explanation what its opcode bits means and how its workflow is. but it lacks of details.
Re: Decapping more Genesis chips
On the topic of chips with internal ROMs, the DCC possibly has one as well. Although that chip only handled DRAM and Boot ROM access, so it's not that interesting. It got the task of multiplexing digital audio as well on later models.
-
- Newbie
- Posts: 3
- Joined: Sat Feb 09, 2019 9:52 am
Re: Decapping more Genesis chips
Hello everyone. I will resurrect the topic.
On the open spaces of the network I found a photo of the opened chip 315-5313 :
Here: www.grafik-feti.de/ftp/Die-Shots/Archiv ... e/MD1/VDP/. Picture did not open at maximum resolution. I don’t know it will give us something ....
There are still many interesting things on this site.
On the open spaces of the network I found a photo of the opened chip 315-5313 :
Here: www.grafik-feti.de/ftp/Die-Shots/Archiv ... e/MD1/VDP/. Picture did not open at maximum resolution. I don’t know it will give us something ....
There are still many interesting things on this site.