Thursday, July 4, 2019

Rainbow Islands (Extra Version) C-Chip

Rainbow Islands (Extra Version) is a variant of the original Rainbow Islands game with tweaked enemies and music. While this game was well enough understood that it was playable in MAME, it had some hacks to get around differences between the classic and extra version. While we've been interested to dump it from the beginning, our c-chip dumping process is destructive and unfortunately this game is relatively rare. However, Kevin Eshbach donated a chip in the spirit of faithfully preserving this game for generations to come. Thank you!

Originally we hoped to experiment with a tungsten probe card and/or pogo pin PCB to make dumping quicker and/or maybe even keep the chip alive. However, it's been sitting in inventory for a few months now and we decided to do the existing method in the interest of progress. After all, there would be nothing worse than sacrificing a rare game to get nothing at all!

So the traditional procedure was done and successfully gave us a dump!

So what did we learn from the dump? First, some details about existing MAME workarounds. MAME devs observed enemy attribute and world structure differences that could be explained by simple table changes from the classic c-chip firmware. Additionally, some tables needed to be reordered due to level order changes. MAME developers then wrote a new extra edition ROM that behaved like the Taito extra edition ROM by tweaking the table data and adding code to swap table order.

However, it was expected that the real Rainbow Islands Extra c-chip ROM would reorder ROM tables according to the order expected by the game. To our surprise, Taito instead modified the pointer table.  Data structure aside, the table data itself matches the predicted values. Finally, the dump confirmed no fundamentally new features were added.

Enjoy this post? Please support us on Patreon! Note: with the Indiegogo campaign over we unfortunately don't currently have a way to accept one time donations.


Saturday, June 1, 2019

Mosaic (Space) PIC16C5X

The PCB for this game has this curious chip:

Chip markings have been shaved off leaving just "A" visible on top and "357" on the bottom.

However, it was suspected to be a PIC16C57. Looking at this table, based on package, it could also be  PIC16C55:

We stuck it in our programmer and successfully dumped it as a PIC16C57 protected/truncated binary.  Unfortunately the programmer didn't recognize a device ID for PIC16C55 vs PIC16C57, so still not sure.

It was then decapped:

Which looks more like a PIC16C55 like we saw before on High Seas Havoc:


Which was successfully unlocked! When dumped as a PIC16C57 (2K words) we get two identical dumps, noting that half of it looked like reserved / internal PIC data. So really only one unique 512 word code section. With all of this we are pretty sure its PIC16C55.

Finally, we briefly compared it to the existing workaround in mosaic.cpp:

Now compare this to some Ghidra disassembly:

And we see the same table!

Enjoy this post? Please support us on Patreon! Note: with the Indiegogo campaign over we unfortunately don't currently have a way to accept one time donations.

Thursday, August 30, 2018

Operation Wolf c-chip c-omplete!

Our quest to acquire the Operation Wolf c-chip EPROM content was the most exciting. Since they are relatively common we used a few Operation Wolf c-chips for some early dump attempts. For example, we milled just above the EPROM, cut the wires, and tried to patch in. However, this was deemed too risky with the time and equipment we were willing to put into it.

Next, we explored a badly damaged Bonze Adventure c-chip:

We were able to patch onto the busted EPROM pads and verify the chip was still alive. This inspired us repackage an Operation Wolf die:

This gave us more room to work and resulted in a partial dump. For example, we got this string:


However, the setup was flaky and we decided it would be better to try something else than improve this method.

We analyzed the c-chip further and came up with a plan to replace the ASIC with external EPROM hookups:

This successfully dumped various c-chips. However, we used all of our Operation Wolf chips during initial testing, and needed another. So someone donated this c-chip:

We soldered it up:

...but it didn't resemble the original Operation Wolf dump! The ROM was much shorter and lacked the "By_TAITO_Copration" (sic) string. We checked our archives and discovered it matched the existing Superman dump! This board was in unknown condition and we suspect someone (unsuccessfully) swapped parts trying to fix one. With the sticker worn off we didn't have a way to verify contents without doing our extraction procedure.

Fortunately our donor had another chip, this time with an intact sticker:

Soldered up:

And got a good dump!

This makes a total of 7 c-chips wired up:

for a total of 6 EPROM dumps.

Enjoy this post? Please support us on Patreon! Note: with the Indiegogo campaign over we unfortunately don't currently have a way to accept one time donations.

Wednesday, May 23, 2018

8751 close shave

In the previous post we discussed dumping a lot of mostly PIC16C57s. These also came with a pair of 8751 chips. The first being F-1 Dream (C014):

And the second being Breywood (C015):

The Breywood gold top packages are rather easy to decap as the package is simply heated up and the steel cap is lifted off:

This was then masked and dumped with a masked UV attack as done in previous posts:

The F-1 Dream is a glass frit CERDIP which is a little trickier to decap. Glossing over details, the best technique we've come up with is to strongly heat the top to release it. This melts the glass holding it on without melting the glass holding the pins in place. However, this is a delicate operation that can go wrong in many ways.

Here's the die after decap:

Which was masked like on Breywood:

However, the chip did not dump. Closer inspection revealed the leadframe had shifted a bit and had caused some minor bond wire damage, notably one had completely snapped. This is very hard to see in the pictures, but was easily found with a continuity test and some probing. So it was patched with some epoxy:

Even after this, dumps were very flaky. We got a few decent looking dumps but they started getting worse. We suspected bad pin connections and tried to clean up the chip a bit more. However, on closer inspection we noticed microfractures on the die:

So, it seems that we narrowly got this chip dumped before it stopped working. We could have potentially patched some of these up, but this would have gotten complicated quickly.

What happened? In the past we had pre-heated the chip / workholder for longer, but this time didn't wait quite as long. We suspect that the chip was cooled faster than expected, causing the microfractures. Suppose all is well that ends well, but a lesson for the future to be more conservative on these parts.

Enjoy this post? Please support us on Patreon! Note: with the Indiegogo campaign over we unfortunately don't currently have a way to accept one time donations.

Monday, May 7, 2018

Mostly PIC16C57

We were recently sent 8 "PIC16C57s" from:

  • High Seas Havoc (403/C013)
  • Wargods (U69, C020)
  • MACE (U96, C021)
  • Carnevil (U96, C022)
  • BioFreaks (C023)
  • Gauntlet Dark Legacy (C024)
  • Gauntlet (U37, C025)
  • Blitz 99 (U96, C026)

  • Here are the packages:

    First, note the upper left chip (BioFreaks):

    Hmm, that's not a PIC16C57 but rather a PIC16F57. We decapped a sample and its much finer technology than we've dealt with so far. This one's been shelved for now in lieu of easier targets.

    Next, note the lower left chip (High Seas Havoc (HSH)):

    The marking has been removed, but this is allegedly a PIC16C57. We popped it into a reader and it spit back a scrambled (protected) dump, so this was plausible.

    Here are most (Gauntlet Dark Legacy not shown) of the PIC16C57s after decapping and masking:

    These were dumped as done in previous posts. Here's Wargods close up:

    Next, you'll notice there are only 6 chips left of the original 8. In addition to BioFreaks, HSH was in fact not a PIC16C57. Additionally, its wires were a bit higher and got trimmed during decap:

    While its not a PIC16C57, it does look close, basically just with a smaller EPROM. It looks to be about 1/4 the size of PIC16C57 (2K), so lets say its probably 512 words. There are two members of the PIC16C5X family with 512 words: PIC16C54 and PIC16C55. PIC16C54 doesn't come in DIP28, so its probably PIC16C55.

    Fortunately we had a PIC16C55 on hand:

    Here's the identifying info on HSH:

    And here's a PIC16C55 sample:

    Odd...the die ID matches but the masks don't completely match.  After some discussion, we decided this was close enough to proceed. The main concern is that PIC16C55A has some more sophisticated protection that might be problematic if we tried a simple UV attack. However, HSH has a 1988 copyright, and the sample has a 1988 copyright as well. Additionally, we know that PIC16C57C was a big redesign over PIC16C57. So all evidence points that this really is a PIC16C55 despite the different masks.

    We secured a sample and applied a mask:

    Which after 15 minute or so of UV erasing had lost protection but retained the original data.

    Next we mended the broken wires. When we fixed similar chips in the past, we installed new wires. However, there are mostly wires intact, they just need some bridging. So instead of adding wires, we just carefully added conductive epoxy tracks to bridges them back together:

    Here the nail polish is being used to strengthen the wires from breaking as they get pushed around and also from having the epoxy short out against the edge of the die (see the lower left connection for example). This passed continuity and gave out the scrambled output we saw before decap.

    We then added additional masking to fully cover the EPROM;

    After 15 minutes of UV erasing we were able to retrieve the ROM.

    Finally, a few small updates on works in progress:

    • Taito C-Chip: we've dumped all samples we have except Operation Wolf (partial dump only). We have a spare chip in hand but we'd like to try a bit more to extract one of the existing decaps first
    • Contact mask ROMs (TGP + MCS48 such as Great Swordsman): general consensus is that the TGP captures are mostly acceptable, but the MCS48 captures are too noisy. We've briefly explored a few alternate capture techniques to improve accuracy, but haven't found something we are satisfied with yet
    • Altera FPGAs: we've been unable to identify the specific chip used for 79/80 based on samples we've procured. Reach out if you have interest in this / think you might have something to contribute
    • As the chips that can be trivially dumped dwindles, we are evaluating new analysis techniques. Some of these updates may be less frequent, but the write ups should be more involved

    Enjoy this post? Please support us on Patreon! Note: with the Indiegogo campaign over we unfortunately don't currently have a way to accept one time donations.

    Saturday, March 10, 2018

    Taito C-Chip: data by lobotomy

    In a previous post we described some early attempts to analyze the Taito C-Chip. See Haze's forum post for some background on the C-Chip itself.

    In particular we're interested in the EPROM. Previous efforts focused on less invasive techniques with the goal of keeping the C-Chip alive after dumping. Unfortunately, we've been unable to successfully send an unlock command and efforts to rebond the EPROM die have been difficult with the equipment we have on hand.

    With this in mind, we took a break to regroup. If we remove the ASIC we can solder to PCB traces shared with the EPROM. Traces are documented in our wiring diagram:

    Which allows us to make an attack (soldering) plan:

    The basic idea is to mill and etch away the purple masked area to expose the PCB. Then, solder wires as indicated by the green dots.

    A few issues, but nothing too bad. First, this implies requires removing the ASIC to have enough room to work. As there is not a reliable way to safely remove it (or easily put it back for that matter), this means killing the module. Second, the PCB traces are roughly 6 mil (ie 0.006" => 0.15 mm) width and roughly 12 mil (0.3 mm) pitch. These are non-trivial to solder, although doesn't require as much precision as hand wire bonding (roughly 0.1 mm pads at 0.2 mm pitch). Sort of like soldering a bunch of "0201" size resistors in close proximity.

    Lets get started. First, take a c-chip:

    Mill it to near PCB:

    We went about 2.5 mils down at a time until the ASIC paddle just starts to show. You can see bits of shattered die clinging to the paddle corners.

    Then use acid to fully expose PCB:

    Next tin areas where we'll make connections:

    Now mount to protoboard:

    And wire up:

    Which successfully dumped the EPROM!

    A little hard to measure, but it takes roughly 3 hours per module using this technique. Definitely better at soldering since starting this project.

    To date we've dumped Volfied, Superman, and Bonze Adventure (not shown):

    Volfied (top) was our first attempt and has the CPU removed due to some early issues getting a dump. We thought the CPU might have been driving some control lines, but it turned out to actually be some solder debris shorting out the power rails. Surprisingly our programmer didn't generate any error messages (over current, continuity, etc).

    We have a few more chips in the pipeline that we expect to finish over the next couple of weeks. We're still figuring out which chips, if any, we still need to source to cover all known games.

    We've also continued to think about the best ways to keep the module alive. There are still a few options like decapping the area between the dies and using a laser cutter to isolate the EPROM control lines from the ASIC. This is a littler riskier though as we might accidentally sever a bond wire or corrode EPROM pads. For example, if any solder crept to the bond wire it would dissolve the gold, severing the connection.

    Finally, what about keeping the PCBs alive after the C-Chip lobotomy? At this point we're thinking the best option is to design a C-Chip compatible module. We know the CPU, have the firmware, and have a reasonable understanding about how the ASIC works. We suspect with a little fiddling one should be able to figure out the remaining details. That said, we'd like to focus on the extracting data rather than repairing PCBs. So this may be left as an exercise to the reader.

    Enjoy this post? Please support us on Patreon! Note: with the Indiegogo campaign over we unfortunately don't currently have a way to accept one time donations.

    EDIT: Rainbow Islands dumped!