SpritesMind.Net

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!

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.

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

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

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.
Is there any comprehensive list about which Genesis models / chips support this feature and which ones don't?

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)

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

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

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.

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.

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.

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.

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?

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.

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.