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.