If at first you don't succeed boil it in acid

In a previous post we discussed extracting TMS32010 ROMs optically. This information helps the arcade community better understand these cabinets for repairs and historical reference. In this post we investigate later generation TMS320 using a combination of electrical test interfaces and microscope images.

The first generation Digital Signal Processor (DSP) chips in the first post were succeeded by the TMS320C10 and then the TMS320C25 as seen above. This is Namco Winning Run's TMS320C25FNL (decap G82) which was extracted via a similar decapping and imaging process as TMS32010. It's part of Namco System 21 where it accelerates 3D graphics operations. Additional analysis will give the community a much deeper understanding of how the graphics engine works. Special thanks to Nathan Gilbert for converting microscope images into firmware!

TMS320C25 was then succeeded by TMS320C5X which is the focus of this article.

Source

The origin of the TMS320C5X project is a TMS320BC53PQ80 found on Taito Operation Tiger. Similar to the Winning Run TMS320, Operation Tiger uses TMS320 as part of it's graphics engine and detailed analysis will help the community understand how it works. This was thought to possibly be a straightforward project as these chips have several digital interfaces that might be used to quickly extract firmware.

To make things easy we got a TMS320C5X DSP Starter Kit (DSK) development board with matching software. It has a very similar part (TMS320C50 vs TMS320BC53) in the same footprint which should allow us to run some tests and then transplant the target chip onto the DSK board.

This is roughly our understanding of how the intended development flow works:

• Tiny mask ROM firmware loads an external PROM
• External PROM knows how to talk to serial port
• DOS system downloads debug kernel over serial port
• Debug kernel can load additional programs

We can omit the last step since we just need to send simple commands to the debug kernel. Let's see if we can get that running.

The big catch is that the software runs on DOS with unusual serial port settings (ex: 2 stop bits) which caused some setup issues. The DSK uses this to automatically detect baud rate based on timing between the first command data bits and the stop bits. In the end, VMWare with an FTDI adapter did the job.

Once the software is up it's relatively straightforward as there are commands to dump memory to files. The only catch is that they have a bug/feature where address 0 can't be saved, but can be seen in the visual display. So we save most of the data and then manually patched the word at address 0. And so we have the TMS320C50 bootloader!

Now to try the same thing but with TMS320BC53.

Source

However we weren't sure if this would work as the external PROM firmware was written for TMS320C50 which has a different address layout than TMS320C53.

We swapped the chips and unfortunately it's not working. We put a logic analyzer on and are able to show that DOS is communicating with the board but then something goes wrong. Specifically above shows PROM memory fetches changing in response to serial port data. We can possibly adjust the PROM firmware but there are a few more options to explore.

What about JTAG support? Even if this works we have a few chips that support JTAG but not the bootloader (ex: Winning Run). So seems like a good excuse to investigate that.

Unfortunately while these chips attempted to support JTAG there are several major issues. First, their JTAG implementation is non-compliant, making it incompatible with many adapters. Second, when it does work it's very bare bones and doesn't even support common instructions like IDCODE.

Most importantly though even with the right adapter the software is very difficult to setup. The only reference we could find involved patching a very specific version of Code Composer Studio version 3. And even then this probably only gave you TMS320C25 support which we'd then have to extrapolate to TMS30C50.

Source

We tried to find some older DOS software that might support some form of XDS510 (such as the original ISA card above) but were unsuccessful. Since completing this project we have received additional software that might help if we encounter more TMS320. That said, if you have more TMS320 software, especially related to JTAG, we'd love to hear from you.

Anyway this means JTAG is not going to be easy. In the spirit of moving forward we begrudgingly decapped the chip and imaged the ROM.  While somewhat labor intensive this has a relatively straightforward path to completion.

Official designation is TMS320C53CS programmed with ROM D17336.

Zooming in on the ROM you can see it's very sparsely populated: there are a few bits at the top middle, and a few at the bottom. This makes sense as it only has a minimal bootloader and the vast majority of the code is in the external PROM.

A few puzzles though. First, why do the empty areas alternate 1's and 0's? Second, why is code split between the top and bottom? Fortunately we have the ROM from the TMS320C50 which significantly accelerates decoding. Take this section after the initial firmware:

00000270  be 4d bf b0 00 ff 6d 68  90 68 be 1f a7 68 b8 01  |.M....mh.h...h..|

00000280  be 1e 7b 90 01 31 69 66  be 20 be 4d e0 00 01 46  |..{..1if. .M...F|

00000290  be 4c ec 00 79 80 01 49  ff ff ff ff ff ff ff ff  |.L..y..I........|

000002a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

000002b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

000002c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

000002d0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

000002e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

000002f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

00000300  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

00000310  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

We can see the transition from normal firmware to an alternating 1/0 fill pattern. While it's unclear why they do this, it's likely this is the actual ROM pattern as opposed to say obfuscation. Our best guess why they do this is that it plays a similar role to CMP fill on planarized ICs. That is, if it was filled with one polarity it would deviate a lot more from normal data and could cause yield issues. We couldn’t find an introductory article to link, but check out something like this for more information.

Anyway, also note our TMS320C50 dump has a footer:

00000f00  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

00000f10  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

00000f20  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

00000f30  00 00 00 00 00 00 00 00  00 00 bc 00 5d 07 00 30  |............]..0|

00000f40  ae 11 00 00 8b 8d bf 0d  80 00 bb 02 a5 a0 07 fd  |................|

00000f50  f4 00 5d 6a 80 00 5d 26  02 f0 5e 26 ff ef b9 f8  |..]j..]&..^&....|

00000f60  88 22 88 32 ae 21 a5 96  ae 31 59 a3 b4 01 be c5  |.".2.!...1Y.....|

Sometimes chip memory gets divided into pages to break up memory into small sections. It looks like TMS320C50 has one page and TMS320BC53 has four pages, so we think these might be page footers.

With this in mind Nathan Gilbert did the heavy lifting here. First he decoded the four pages separately and munged until they roughly resembled the TMS320C50 data. We then compared footers between pages and found bits to order the pages as labeled above. These bits are believed to be an absolute address as part of an assembly routine but significant analysis has not been done.

Now with the ROM decoded we can compare TMS320C50 and TMS320BC53. While the main firmware is identical the footer has a number of differences. We don't believe anyone has yet looked into specifics.

Finally, there was a brief effort to decode an unknown TMS320C52 wafer with a large amount of firmware. Someone attempted to use computer vision to automatically extract the bits but it was ultimately abandoned due to some combination of insufficient data quality and low perceived impact of having a successful decode.

That about wraps it up. Lots of people helped complete this project! Special thanks to the following:

• Nathan Gilbert: decoding, bit typing
• jordigahan: board purchase
• ClawGrip: board purchase
• Montornés Solé: board purchase
• Philip Åkesson: bit typing
• James Sun: bit typing

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