Software Hacks

858 Articles

Lock-In Thermography On A Cheap IR Camera

October 28, 2024 by 16 Comments

Seeing the unseen is one of the great things about using an infrared (IR) camera, and even the cheap-ish ones that plug into a smartphone can dramatically improve your hardware debugging game. But even fancy and expensive IR cameras have their limits, and may miss subtle temperature changes that indicate a problem. Luckily, there’s a trick that improves the thermal resolution of even the lowliest IR camera, and all it takes is a little tweak to the device under test and some simple math.

According to [Dmytro], “lock-in thermography” is so simple that his exploration of the topic was just a side quest in a larger project that delved into the innards of a Xinfrared Xtherm II T2S+ camera. The idea is to periodically modulate the heat produced by the device under test, typically by ramping the power supply voltage up and down. IR images are taken in synch with the modulation, with each frame having a sine and cosine scaling factor applied to each pixel. The frames are averaged together over an integration period to create both in-phase and out-of-phase images, which can reveal thermal details that were previously unseen.

With some primary literature in hand, [Dmytro] cobbled together some simple code to automate the entire lock-in process. His first test subject was a de-capped AD9042 ADC, with power to the chip modulated by a MOSFET attached to a Raspberry Pi Pico. Integrating the images over just ten seconds provided remarkably detailed images of the die of the chip, far more detailed than the live view. He also pointed the camera at the Pico itself, programmed it to blink the LED slowly, and was clearly able to see heating in the LED and onboard DC-DC converter.

The potential of lock-in thermography for die-level debugging is pretty exciting, especially given how accessible it seems to be. The process reminds us a little of other “seeing the unseeable” techniques, like those neat acoustic cameras that make diagnosing machine vibrations easier, or even measuring blood pressure by watching the subtle change in color of someone’s skin as the capillaries fill.

Seven New Street Fighter 2 Arcade Rom Hacks

October 23, 2024 by 2 Comments

[Sebastian Mihai] is a prolific programmer and hacker with a particular focus on retrocomputing and period games, and this latest hack, adding new gameplay elements to Capcom’s Street Fighter II – Champion Edition, is another great one. [Sebastian] was careful to resist changing the game physics, as that’s part of what makes this game ‘feel’ the way it does, but added some fun extra elements, such as the ability to catch birds, lob barrels at the other player, and dodge fire.

The title screen was updated for each of the different versions, so there is no doubt about which was being played. This work was based on their previous hacks to Knights of the Round. Since both games shared the same Capcom CPS-1 hardware, the existing 68000 toolchain could be reused, reducing the overhead for this new series of hacks. Continue reading “Seven New Street Fighter 2 Arcade Rom Hacks” →

Behold A First-Person 3D Maze, Vintage Atari Style

October 20, 2024 by 15 Comments

[Joe Musashi] was inspired by discussions about 3D engines and decided to create a first-person 3D maze of his own. The really neat part? It could have been done on vintage Atari hardware. Well, mostly.

He does admit he had to do a little cheating to make this work; he relies on code for the ARM processor in the modern Atari VCS do the ray casting work, and the 6507 chip just handles the display kernel. Still, running his demo on a vintage Atari 2600 console could be possible, but would definitely require a Melody or Harmony cartridge, which are special reprogrammable cartridges popular for development and homebrew.

Ray casting is a conceptually simple method of generating a 3D view from given perspective, and here’s a tutorial that will tell you all you need to know about how it works, and how to implement your own.

[Joe]’s demo is just a navigable 3D maze rather than a game, but it’s pretty wild to see what could in theory have run on such an old platform, even if a few modern cheats are needed to pull it off. And if you agree that it’s neat, then hold onto your hats because a full 3D ray casting game — complete with a micro physics engine — was perfectly doable on the Commodore PET, which even had the additional limitation of a monochrome character-based display.

Winamp Taken Down: Too Good For This Open Source World

October 16, 2024 by 58 Comments

If you picked today in your hackerspace’s sweepstake on when Winamp would pull their code repository, congratulations! You’re a winner! The source for the Windows version of the venerable music player was released on GitHub three weeks ago, and after some derision over its licence terms, a bunch of possible open source violations, and the inadvertent release of some proprietary third-party code, it’s been taken down. We’re sure that if you still have a burning desire to look at it then it won’t be too difficult to find a copy through your favorite search engine, leaving the question of what really just happened.

It’s fairly obvious that the owners of the code lacked some level of understanding of just what open source really is, based on their not-really-open licence and all those code leaks. They did back down on not allowing people to create forks, but it’s evident that they didn’t anticipate the reaction they got. So were they merely a bit clueless, or was it all just a publicity stunt involving a piece of software that’s now of more historical than practical interest? It’s possible we’ll never know, but the story has provided those of us sitting on the fence eating popcorn with some entertainment.

ANTIRTOS: No RTOS Needed

October 15, 2024 by 53 Comments

Embedded programming is a tricky task that looks straightforward to the uninitiated, but those with a few decades of experience know differently. Getting what you want to work predictably or even fit into the target can be challenging. When you get to a certain level of complexity, breaking code down into multiple tasks can become necessary, and then most of us will reach for a real-time operating system (RTOS), and the real fun begins. [Aleksei Tertychnyi] clearly understands such issues but instead came up with an alternative they call ANTIRTOS.

The idea behind the project is not to use an RTOS at all but to manage tasks deterministically by utilizing multiple queues of function pointers. The work results in an ultra-lightweight task management library targeting embedded platforms, whether Arduino-based or otherwise. It’s pure C++, so it generally doesn’t matter. The emphasis is on rapid interrupt response, which is, we know, critical to a good embedded design. Implemented as a single header file that is less than 350 lines long, it is not hard to understand (provided you know C++ templates!) and easy to extend to add needed features as they arise. A small code base also makes debugging easier. A vital point of the project is the management of delay routines. Instead of a plain delay(), you write a custom version that executes your short execution task queue, so no time is wasted. Of course, you have to plan how the tasks are grouped and scheduled and all the data flow issues, but that’s all the stuff you’d be doing anyway.

The GitHub project page has some clear examples and is the place to grab that header file to try it yourself. When you really need an RTOS, you have a lot of choices, mostly costing money, but here’s our guide to two popular open source projects: FreeRTOS and ChibiOS. Sometimes, an RTOS isn’t enough, so we design our own full OS from scratch — sort of.

A RISC-V LISP Compiler…Written In Lisp

October 14, 2024 by 15 Comments

Ah, Lisp, the archaic language that just keeps on giving. You either love or hate it, but you’ll never stop it. [David Johnson-Davies] is clearly in the love it camp and, to that end, has produced a fair number of tools wedging this language into all kinds of nooks and crannies. The particular nook in question is the RISC-V ISA, with their Lisp-to-RISC-V compiler. This project leads on from their RISC-V assembler by allowing a Lisp function to be compiled directly to assembly and then deployed as callable, provided you stick to the supported language subset, that is!

The fun thing is—you guessed it—it’s written in Lisp. In fact, both projects are pure Lisp and can be run on the uLisp core and deployed onto your microcontroller of choice. Because who wouldn’t want to compile Lisp on a Lisp machine? To add to the fun, [David] created a previous project targeting ARM, so you’ve got even fewer excuses for not being able to access this. If you’ve managed to get your paws on the new Raspberry Pi Pico-2, then you can take your pick and run Lisp on either core type and still compile to native.

The Lisp-Risc-V project can be found in this GitHub repo, with the other tools easy enough to locate.

We see a fair few Lisp projects on these pages. Here’s another bare metal Lisp implementation using AVR. And how many lines of code does it take to implement Lisp anyway? The answer is 42 200 lines of C, to be exact.

A stylized image of Haskell code from the article

Alphabet Soup: Haskell’s Single-Letter Naming Quirks

October 14, 2024 by 14 Comments

When you used punch cards or tape to write a computer program, brief variable names were the norm. Your compiler or assembler probably only allowed six letters, anyway. But times change, and people who, by habit, give array indices variable names like I, J, or K get a lot of grief. But [Jack Kelly] points out that for highly polymorphic languages like Haskell, you often don’t know what that variable represents anyway. So how are you supposed to name it? He provides a guide to one-letter variable names commonly used by Haskell developers and, sometimes, others.

Haskell’s conventions are particularly interesting, especially with i, j, and k, which are borrowed from mathematical tradition to signify indices or integers and passed on via Fortran. The article also highlights how m often refers to Monads and Monoidal values, while t can represent both traversables and text values. Perhaps more obscurely, p can denote profunctors and predicates, giving a glimpse into Haskell’s complex yet efficient type system. These naming conventions are not formal standards but have evolved into a grass-roots lexicon.

Of course, you can go too far. We see a lot of interesting and strange things written in Haskell, including this OpenSCAD competitor.