TMS7xxx dumper

This is a really interesting method for identifying and dumping the internal ROM contents from the TMS7000 series of processor/microcontrollers. I’m gonna skip the story behind it because I wasn’t there and start with the variety of chips that this works on.

We, to the best of our ability, support the TMS7000 lineup, the re-labeled PIC7000 lineup, and any remarked chips that may be out there like the CTS256. This includes a couple 77xx chips that are UV erasable EPROM versions (as far as I know that’s the 7742, 77c42, and 77c82). There are PLCC versions of some of the chips in this series, and they should work with a simple passive adapter to our DIP socket. We do not support the 16K piggy-back version of these chips that was meant for development, partly because I don’t know how that memory map worked and partly because you can just pull the standard rom and dump it that way. This project is for pulling the mask rom contents out of the chips you can’t otherwise dump.

The naming convention for these chips is pretty reasonable as well, with a couple edge cases (not all permutations exist).

7abcde decodes like this:

• a – 0 for not reprogrammable / 7 for UV window
• b – C for CMOS, nothing present means NMOS
• c – P for piggyback (only followed by a 16), T for low power (I think), neither or both are also options
• d – size of internal ROM (or piggyback capable ROM) in kilobytes, available in 0, 2, 4, 8, 12, and 16
• e – 0 for 128 bytes of RAM and no serial port, 1 for 128 bytes of RAM with a serial port, 2 for 256 bytes of RAM with a serial port, 8 for 256 bytes of ram, a serial port, and WAY more I/O

This comes largely from the bitsavers manuals, but also for random fishing with google terms like “TMS70c82” and “TMS70CT82” to turn up strange references elsewhere. There’s also some combinations that the manuals make clear did not last the whole life cycle of the product line. With the lineup launching in 1981, by 1986 TI was trying to get people off the 7xx1 variation with less RAM and simplify their lineup, and ones like the 12k variants only appear in earlier versions of the family data manual that do not yet include CMOS versions.

Now, how does it work? The process is quite interesting. We boot up the TMS7000 chip in Microprocessor mode which has all the code running from outside the chip. To do this we pull up on the MC line with a resistor. While in this mode we can execute whatever code we like from our external ROM such as checking for the presence of the full 256 bytes of RAM in the 7xx2 variants, and checking for the presence of the serial port in the 7xx1 or 7xx2 variants (the 7xx2 also comes with an additional timer). This serial check has to be performed twice because the CMOS chips have the registers for serial control in a different location (no idea why). Once that’s done we can copy a bunch of code to the internal 128 bytes of RAM and finally pull down on the MC line to flip into ‘full expansion’ mode.

When in ‘full expansion’ mode all memory above the internal ROM maps outside (except the 12K version has a chunk missing, probably for ease of address decoding) so once we are executing our code from inside this mode we can probe to see if we’re leaving the chip by reading from these regions. We do this by mapping a 2764 from 0xE000 to 0xFFFF with certain bytes set in different areas that we can check. If we see our string of magic bytes then we know our memory reads exited the chip and the internal ROM is smaller than that. Once we’ve determined the size of the internal ROM we can then report the chip stats (RAM, ROM size, and presence of serial port) to the arduino and proceed to dump the internal ROM. With some feature creep we ended up hacking in exceptions for the 12K/8K variants. With only an 8K ROM chip we can’t actually test for the difference between an 8K and 12K chip, the fix for this would be to use a 27128 and map in 16K of external ROM and check more areas to determine how big the internal ROM actually is. That would require some more bodging on the boards I made and the trojan program is already almost as big as it can be. The solution was to treat any chip with bigger than 4K of internal space as a 12K chip and dump that area of memory. On the arduino side we know if the chip is NMOS or CMOS and if it’s CMOS we ignore the first 0x1000 bytes of data before communicating the dump to the user.

This chip identifies as a TMS70C42 with 4K of internal ROM, it’s unclear if TI remarked it for use in microprocessor mode only or if a chinese reseller did

Speaking of the arduino, that’s the final key to making this project easy to use. We are manually clocking the TMS7000 with the arduino as well as receiving data from the chip over a hardware SPI interface. This lets us clock the chip until it loads the trojan and report the detected parameters. Once we’re at that point we can pause clocking and display that data to the user. We also use this opportunity to read a line held high by the TMS7000 with our analog input. By sensing how hard of a pull up the chip acts with we determine whether it is NMOS or CMOS. Once we’ve reported the chip status to the user we then allow them to dump the chip in s19 format to the serial terminal.

There is a slightly cheaper method for doing this trojan attack, because the arduino is clocking the tms7000 we can also act as the EPROM presenting whatever data the TMS7000 is requesting instead of using a ROM. We don’t have to operate very fast because while we are fetching the data that a ROM would present we aren’t clocking the TMS7000. That makes development significantly harder however, so we opted for a ROM chip. One of the limitations using the ROM is that the TMS7000 identifies the ROM size itself, then dumps either 2K, 4K, or 12K. If the check is wrong, or other variants that we don’t detect properly are found then it may require an update to the assembled TMS7000 code as well as the arduino code.

The bodge to add CMOS/NMOS detection, it’s already fixed in the kicad project on github

The original project done by Frank years ago used a battery backed SRAM and a different processor board to clock and recieve the data from the chip. That was used to dump the coco speech sound pak and the CTS256. Since then some french enthusiasts have used this idea to dump some Exelvision computers. Odd note, while researching these chips I found that a company made equivalents as late as 2008.

The whole project is hosted on github for anyone to replicate. We include the assembler too if you need to change the assembly code in the future. We also have some spare boards to populate and send out to people with these chips that need dumping. Anyone want one?