A purple PCB with a Raspberry Pi Pico and an MK3870 mask ROM microcontroller

A 1970s Mask ROM MCU Spills Its Secrets

If you buy any kind of electronic gadget today, chances are it’s powered by a microcontroller with a program stored in its internal flash ROM. That program’s code is often jealously guarded by the manufacturer, who will try their best to make sure you can’t just read back the chip’s contents by using lock bits or some sort of encryption. Things were more laid back in the 1970s and ’80s, when code was stored unencrypted in standard EPROM chips, or, for high-volume applications, in mask ROMs integrated in microcontrollers. Reading back the code of such micros was still very difficult because chips simply didn’t have a way of dumping their contents. [Andrew Menadue] ran into this issue when trying to repair an old HP calculator printer, and had to apply a clever hack to dump the contents of its Mostek MK3870 chip.

The main trick [Andrew] used was one discovered by [Sean Riddle] and explained on his website. It makes use of the fact that the MK3870 has a TEST pin that can be used to disable the mask ROM and load alternative program code directly into the micro’s processing core. By setting up a LOAD instruction pointing at a ROM location and briefly disabling test mode while that instruction is executed, the ROM’s contents can be read out by the externally loaded program.

Simple as this hack may seem, actually implementing it was tricky enough because of the strict timing requirements between signals on the clock pins, the data bus, and the TEST pin. [Andrew] got it to work on his Raspberry Pi Pico setup most of the time, but somehow the micro still returned a plainly wrong value every few hundred bytes. Not willing to spend too much time debugging this issue, [Andrew] applied a rather crude hack to his code: instead of reading each byte once, it runs the read cycle 200 times, and only returns a result when all 200 runs return the same value. Dumping the entire 4 kB of ROM now takes several minutes, but this isn’t much of an issue since [Andrew] only has one chip to read out.

If you do have a bucketload of MK3870 chips that you need to dump, you might want to try and optimize the code on [Andrew]’s GitHub page. It’s a lucky coincidence that the ‘3870 has the exploitable TEST feature; often, the only way to get inside mask ROM code is by decapping the chip and optically reading the bits one by one. Mask ROMs are great for very long term data storage, however.

Continue reading “A 1970s Mask ROM MCU Spills Its Secrets”

Game Cartridges And The Technology To Make Data Last Forever

Game cartridges are perhaps the hardiest of all common storage schemes. Short of blunt traumatic force or application of electrical surges to the cartridge’s edge connectors, damaging a game cartridge is hard to do by accident. The same is also true for the data on them, whether one talks about an Atari 2006 cartridge from the late 1970s or a 1990s Nintendo 64 cartridge.

The secret sauce here are mask ROMs (MROM), which are read-only memory chips that literally have the software turned into a hardware memory device. A mask layer unique to each data set is used when metalizing the interconnects during chip fabrication. This means that the data stored on them is as durable as the processor in the game console itself. Yet this is not a technology that we can use in our own hobby projects, and it’s not available for personal long-term data storage due to the costs associated with manufacturing what is essentially a custom chip.

Despite its value as truly persistent storage, MROM has fallen out of favor over the decades. You may be surprised to find a lot of what’s currently used in the consumer market is prone to data corruption over time spans as short as one year to one decade depending on environmental conditions.

So what are we to do if we need to have read-only data that should remain readable for the coming decades?

Continue reading “Game Cartridges And The Technology To Make Data Last Forever”

The ESP: A New 1kB Contender Appears

The ESP8266 is officially checking into the Hackaday 1kB Challenge. Doing something meaningful in 1kB of compiled code is tricky; modern SDKs like the ones often used for ESP8266 compile even the simplest programs to nearly that size. If you want to use this hardware in your 1kB Challenge entry, I have a solution for you!

The ESP8266 now has a barebones build environment focused on minimizing code size, as little as 131 bytes to boot up and blink an LED. It also “supports” some new, insane clock rates (like 346 MHz) and crazy development cycle speeds. The WiFi is stuck in “airplane mode,” but it will be worth your time to consider the ESP for the next non-WiFi project you’ll be doing.

Far too often, we follow design patterns that ‘just work’ instead of looking for the ones that are optimal because we’re afraid of wasting time. The benefits of keeping code tight and small are frequently overlooked. When code is small and environments minimal, RAM and FLASH become easier to come by, compiled binaries shrink and time wasted by compiling and flashing can decrease by an order of magnitude! We rarely see just how much value is added when we become a good engineer: being done only when there’s nothing left to remove from a design. Nosdk8266 will let you see what it’s like to test out code changes several times a minute.

Just a month ago, when preparing the ESP8266 for a USB bootloader, I had to make a stripped-down environment for it. It’s not based on the Official Non-OS SDK or the RTOS sdk, but an environment that can boot up and blink an LED. Not just blink an LED, but tweak the clock in some totally unexpected ways and even run the I2S bus (used for espthernet and Color NTSC Broadcast Video). If you’re not at the submission phase for your 1kB challenge, you can even use the mask ROM for printf! Now you can tweak your code and — in under 2 seconds — see what the new code does!

Even in PICO mode, the part still has to use the mask ROM to be loaded, but thankfully, the 1kB Challenge has added an exception for unavoidable bootloaders. No longer bound by the shackles of WiFi, I can’t wait to see what you’ll do with the ESP8266. Just beware that the processor may not work reliably when overclocked at 346 MHz (332.5%,) and you’ll certainly be voiding any warranties you may have. Sounds like fun, right?

Editorial Note: This is a guest article from Charles Lohr, aka [CNLohr]. Although he has written a few other guest articles, he is not a regular contributor to Hackaday and therefore, this article does not disqualify him from entering the 1kB Challenge. We felt it more fair to publish this article which shares the tools he’s using to make code smaller, rather than to keep them to himself for fear of disqualification. While we have your attention, we wanted to mention one of Charles’ articles which was published on April 1st — we still think there’s a lot of people who don’t realize it wasn’t a prank.