Decapping more Genesis chips

For hardware talk only (please avoid ROM dumper stuff)
Post Reply
User avatar
Sauraen
Interested
Posts: 46
Joined: Sat Sep 19, 2015 2:44 pm
Contact:

Decapping more Genesis chips

Post by Sauraen » Fri Oct 23, 2015 3:03 pm

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!

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

Re: Decapping more Genesis chips

Post by Nemesis » Fri Oct 23, 2015 8:26 pm

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.

User avatar
Sik
Very interested
Posts: 673
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Decapping more Genesis chips

Post by Sik » Fri Oct 23, 2015 11:06 pm

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.
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).
Sik is pronounced as "seek", not as "sick".

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

Re: Decapping more Genesis chips

Post by TmEE co.(TM) » Sat Oct 24, 2015 3:22 am

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

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

Re: Decapping more Genesis chips

Post by Charles MacDonald » Sun Oct 25, 2015 9:09 pm

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.
Aha, I never knew that and was wondering why my second-revision Megadrive was doing nothing special when using $A11000. :D
Is there any comprehensive list about which Genesis models / chips support this feature and which ones don't?

User avatar
Sik
Very interested
Posts: 673
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Decapping more Genesis chips

Post by Sik » Sun Oct 25, 2015 11:15 pm

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

User avatar
KanedaFr
Administrateur
Posts: 1114
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Re: Decapping more Genesis chips

Post by KanedaFr » Thu Oct 29, 2015 9:29 pm

Did you know http://zeptobars.ru/ ?
They decap at least a chip per week
perhaps they explain their method somewhere...to compare with yours....

User avatar
MrTamk1s
Very interested
Posts: 75
Joined: Sun Jan 04, 2015 10:27 pm
Location: Pennsylvania
Contact:

Re: Decapping more Genesis chips

Post by MrTamk1s » Sat Oct 31, 2015 1:08 am

KanedaFr wrote: perhaps they explain their method somewhere...to compare with yours....
(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.)
SGDK homebrew dev and Unity3D Indie dev.
Sega does what Nintendont!

User avatar
Huge
Very interested
Posts: 178
Joined: Sat Dec 13, 2008 11:50 pm

Re: Decapping more Genesis chips

Post by Huge » Sat Nov 28, 2015 5:35 pm

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

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.

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

Re: Decapping more Genesis chips

Post by Charles MacDonald » Tue Dec 01, 2015 9:31 am

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.

User avatar
Huge
Very interested
Posts: 178
Joined: Sat Dec 13, 2008 11:50 pm

Re: Decapping more Genesis chips

Post by Huge » Tue Dec 01, 2015 6:31 pm

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.
Last edited by Huge on Thu Dec 03, 2015 2:17 am, edited 1 time in total.

MetalliC
Interested
Posts: 25
Joined: Sat Aug 25, 2012 12:45 pm
Location: UA

Re: Decapping more Genesis chips

Post by MetalliC » Tue Dec 01, 2015 6:51 pm

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.

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

Re: Decapping more Genesis chips

Post by Charles MacDonald » Wed Dec 02, 2015 2:10 am

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.
That's too bad. What would approach would you suggest for figuring out how the SCSP DSP works? Is decapping the only solution left?

User avatar
Huge
Very interested
Posts: 178
Joined: Sat Dec 13, 2008 11:50 pm

Re: Decapping more Genesis chips

Post by Huge » Wed Dec 02, 2015 2:19 am

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest