Includes:
- 19: Vimana HD647180 QFP80
- 58: Teki Paki HD647180X QFP80
- 102: Fire Shark HD647180X QFP80
Here's a sample package:
The HD647180X is a ZTAT microcontroller incorporating the following on a single chip: an instruction set compatible with the HD64180, 16-kbyte of programmable ROM, 512-byte of RAM, memory management unit (MMU), DMA controller, timer, asynchronous serial communication interface (ASCI), clock synchronous serial 1/0 port (CSl/O), analog comparator, and parallel 1/0 pins.
Decapping revealed an unknown film covering the die:
Sometimes chips have polymide or silicone passivation. However, this material is white clear (not yellow polymide) and a dry film (not silicone). While decapping did not remove the film, it did loosen it.
Several test chips were cleaned up by carefully pulling it off with tweezers. While this works, we were ideally looking for a solution that minimized poking near fragile bond wires.
Another experiment showed that hot sulfuric acid removes the film. As the decap solution contains some sufuric acid (mostly white fuming nitric acid with a touch of sulfuric acid), it was suspected that letting it cook a bit longer would remove the film. This proved successful and we successfully cleaned a test die:
Now that we finally have a clean die it was imaged for analysis. The dark area in the lower section of the die is our target: EPROM.
The die image provides a good guess as to the location of the fuse lock bits. Upon closer inspection we learn the layout is similar to other previously deprotected Hitachi parts (not shown). Here it is on the HD647180:
ROM is masked to protect our data, while leaving the fuse bits exposed during UV erasure:
The helpful arcade community let us know someone had previously designed a breakout PCB for experimenting with HD647180 MCU. Very helpful!
Success! To be sure, we masked basically everything but the suspected fuse:
Which also worked.
While PLCCs are great for early development (easy swap on dev board), the real chips are QFP (we don't have a socket). So basically went through the same decap process on QFP:
And masked it to successfully read out the chip. After several successful QFP dumps it was time to move onto the real chips.
Here's #56 decapped and masked:
Deprotection succeeded, but the dumper hardware detected a continuity fault and the ROM was missing data bits D0, D1, and D3. Impedance check to ground verified we had a problem on those pins: while other D's read ~20k those were open. Closer visual inspection revealed a bond wire defect:
Some gentle probing verifies D3 is in fact broken:
After weighing options we repaired them with conductive epoxy:
Success! We proceeded to decap and deprotect the rest of the HD647180s:
Both #19 and #58 required repair. #102 failed continuity but dump seems okay. Interestingly enough, while all three Toaplan samples had serious bond wire defects, none of the test PLCC nor test QFP samples did (although harmless marks are barely visible).
We suspect these defects are tooling marks from the bonding machine used to build the packages. We have been told this MCU is commonly found failed on Toaplan games, perhaps this is the reason.
Absolutely fantastic.
ReplyDeleteRemarkable work. Thank you.
ReplyDeleteAwesome
ReplyDeleteincredible work!
ReplyDeleteGreat Work guys :)
ReplyDeleteAmazing!
ReplyDeleteVery impressive and exciting work.
ReplyDeleteI have a working Ghox PCB I am willing to donate if they will dump the mcu. That would complete all the Toaplan games.
ReplyDeleteincledible work!
ReplyDeleteFinally we can emulate Fantastic Vimana and Fire Shark Music!
fascinante!
ReplyDeleteHi caps0ff team!
ReplyDeleteI'm making an effort to obtain a scan of the GP9001 custom VDP, part of Toaplan V2 hardware. The initial impetus to do so came from research over the past few months about a bug in the Hsync signal output by the GP9001 (see this forum thread for the whole story: https://shmups.system11.org/viewtopic.php?f=6&t=65035). I eventually figured that the best solution would be to transcribe the silicon - after all, that work would have to be done anyway at some point for projects like the MiSTer and MAME.
Would it be possible for you to decap and image such a chip? If yes, two more questions: would you be willing to accept one or two exemplars for putting them into your backlog queue, and what magnification factor(s) could you offer?
Your work is invaluable for game preservation. Thank you for doing this.
If you're interested, you can contact me via shmups (at) 6t8k (dot) de
Regards,
6t8k