Follow me down the optimization rabbit hole

Intro In a previous life I was paid to emulate coin-op games, lots of games. In total, I worked on more than 300 titles. The games were for closed source products and were unrelated to my open source projects and had nothing to do with more recognizable game emulators like MAME. They were sold in commercial game systems such as Chicago Gaming's " Ultimate Arcade 2 ", some mobile devices such as Microsoft's Pocket PC launch ( PocketPak's ) and Turner's GameTap system. I made my living by writing these game emulators for a period of about 10 years. Much of the code I wrote back then had to be very efficient because most of our platforms were embedded Arm devices. This same code can find new life on today's Arduino/embedded microcontrollers. As a starting project, I decided to port my Space Invaders emulator to run on moderately spec'd 32-bit MCUs. Taito's Space Invaders was one of the first raster graphics video games to exist and was composed of r...

Intro I wrote my own imaging codecs many years ago for all of the 'standard' file formats available. Over the last couple of years I've been dusting off that code to give it a new life as open source libraries for embedded/Arduino. I wrote blog posts about my JPEG and GIF decoders so I thought it would be useful to write about my new PNG decoding library . What is PNG? The (Portable Network Graphic) specification was created not too long after Unisys started enforcing their LZW patent to collect licensing fees from the use of GIF images. PNG was specifically designed to not infringe any patents and offered the benefit of supporting many more pixel types and an alpha channel. This offered a new feature not found in JPEG and much more functional than GIF's single transparent color. PNG uses the ZIP/FLATE compression scheme which is open source and without any patents attached to it. The FLATE compression by itself isn't drastically better than the LZW compression ...

Intro Much of the open source software that we all use daily is not optimized, or at least not well optimized. I've talked about this before because it's an issue I feel very strongly about. Code that is run billions of times a day shouldn't be inefficient. In the last 10 years (especially in the last year), more of our lives are spent in front of a computer than ever. Computers have a non-trivial environmental impact. Recently Bitcoin's environmental impact has popped up in the news, but the overall energy use of everyday software in both server farms and homes and offices is significant and steadily rising. There are plenty of people working diligently to make sure the code which runs the world is efficient, but what if some wrong assumptions were holding them back? SIMD  instructions are the key to unlocking efficient software on both PCs and mobile devices, but the problem is that it's not used everywhere that it needs to be. You can find SIMD code in many popu...

Intro In a previous article, I wrote about my low memory GIF decoder and how I optimized it to run on embedded/Arduino devices. For this article, we're going in the opposite direction. What if you had all the memory you needed, what could be done to speed up LZW decoding? I asked myself this question many years ago and found some ideas that I refined and then optimized further. The Traditional Way The basis of LZW compression is that a dictionary of repeated strings is built dynamically as you encode and decode the code stream. In the traditional implementation, this dictionary is a data structure with a linked-list connecting each color/symbol to the previous in order to represent the different repeating patterns that are compressed in the data stream. When a codeword is encountered that represents a 'string' of colors/symbols, the output is generating by walking down the linked-list. The list is generated in reverse order (the last entry points to the previous), so the p...

Intro I believe Arduino's software development IDE has been one of the biggest reasons for their success. Combined with their core API that "just works" across multiple MCU architectures, these two elements have made embedded software development accessible to everyone. If you've ever ventured outside of the Arduino 'bubble' and tried to do embedded software development on other vendor's IDEs, then you know what I mean. They routinely involve complex setup procedures, poor documentation, custom APIs, external interface hardware, and sometimes even licensing fees. For my work, one of the most valuable features of the Arduino system is the homogeneity of working with different target processors. I use a wide selection of boards and switching between radically different MCUs usually just involves selecting the target and recompiling. One thing that was missing from the Arduino IDE was the ability to do 'live debugging' of embedded boards. On our PCs w...

Intro MakerFocus was kind of enough to send me a M5Stack Core2 to review. This is the latest ESP32 based 'core' product in their ever growing lineup. I'm not a big fan of unboxing videos, so I'm not going to spend time on this subject except to say that the packaging of the Core2 is well made. After cutting a small piece of adhesive, you can slide the plastic sleeve off of the box. Inside is the Core2 along with a short USB-A to USB-C cable. The box you'll want to keep because it's perfect to protect the Core2 when not in use.  For those not familiar with Espressif System's ESP32, it's a line of highly capable MCUs based on a pair of Tensilica LX6 CPUs along with various amount of RAM, optional PSRAM and FLASH memory. The ESP32 has found its way into a large number of products mainly due to its WiFi and Bluetooth support. Many products use it as a subordinate processor just for its wireless support, but with 2 240Mhz CPUs, and 520K of RAM it's very...