Image of an elf projected by the laser scanner

2026 Frikkin Lasers Contest: Glow Engine Is Like An Open Air Slow Scan CRT

Slow-scan CRTs were never exactly common compared to their faster cousins, but given the popularity of Slow Scan TV (SSTV) amongst hams and NASA broadcasts, many of you are probably familiar with them. The slow scan rate of SSTV meant it required much less bandwidth, but in the early days you needed a CRT with a long-persistence phosphor to hold onto the image. [AJRussell]’s Glow Engine works much the same, with one key difference — instead of cathode rays, he’s using a frikkin laser beam.

In this case, the phosphor is Strontium Aluminate, the same stuff that gives most glow-in-the-dark toys and filament its kick. Energized by a 405 nm laser of questionable wattage, the phosphor will glow for several seconds, allowing the creation of an image. So while this is a laser projector, it works more like a CRT than most galvo projectors, which rely on Persistence of Vision to create an image. Here it’s persistence of fluorescence.

Continue reading “2026 Frikkin Lasers Contest: Glow Engine Is Like An Open Air Slow Scan CRT”

8087's 4-bit adder block. (Credit: Ken Shirriff)

The Adder At The Heart Of Intel’s 8087 FPU

As simple as the concept of adding two numbers appears at first glance, doing it in the 1970s in Intel’s 8087 FPU with its 69-bit adder was still a tall order. This is namely the core feature that many features like tangents, cosines and exponentiation rely on, so it had to be basically perfect. In a recent die-level analysis of the 8087 [Ken Shirrif] dives into the structure, layout and functioning of this ‘beating heart’ of this piece of semiconductor history.

The Intel 8087 adder and associated registers. (Credit: Intel)
The Intel 8087 adder and associated registers. (Credit: Intel)

Although anyone can build a simple binary adder out of off-the-shelf parts including 74-series logic ICs, the problem is to make it fast so that the 69th bit doesn’t have to wait for e.g. a carry to trickle all the way through the preceding bits. The main way that this is solved is by breaking addition into 4-bit blocks, reducing the problem by a factor of four, along with an optimized Manchester carry-chain carry-lookahead implementation.

The main advantage of this variation of a carry-lookahead is that it reduces the number of required transistors, without sacrificing too much performance. Later on Intel would switch to the faster, but more transistor-intensive Kogge-Stone adder.

Implementing this entire adder with NMOS technology and wiring it all up to the rest of the die required a lot of ingenuity on the side of the Intel engineers, as previously noted this adder is effectively always used in any operation at some stage. This necessitates many surrounding registers and in turn circuitry to manage these, with part of the complexity handled in microcode and part in silicon.

A Brief History Of Unix Commands On Windows: CoreUtils (Again)

If you use Windows today and type ls, cat, grep, or awk in a terminal, there is a good chance something useful will happen. That was not always true. For most of the history of personal computing, Unix/Linux and Windows lived on opposite sides of a cultural border. Unix people had pipes, small composable tools, shell scripts, make, sed, awk, grep, tar, and the idea that everything was a file. Windows people had drive letters, backslashes, COMMAND.COM or cmd.exe, and an API that did not care much about what POSIX thought.

Yet there has always been a demand for Unix tools on Windows. Some of it came from programmers who wanted the same build scripts everywhere. Some came from administrators who missed grep and awk. Some came from companies trying to port big Unix applications to NT without rewriting them all. The result is a long, strange history of Unix-on-Windows layers, toolkits, compromises, and almost-but-not-quite compatibility.

Easy?

The simplest version of the problem sounds trivial. How hard can cat be? Open a file, copy bytes to standard output, done. Writing ls is a little more work, but Windows has directory APIs. Common commands like cp, mv, rm, mkdir are not very mysterious. Even pipes are not foreign to Windows. A lot of the everyday Unix command set can be ported as ordinary Win32 console programs with some path handling and enough patience.

But not all of Unix or Linux translates cleanly to Windows. The big issue is fork(). On Unix, a process can clone itself. The child gets a copy of the parent’s address space, open file descriptors, environment, signal state, and so on. Modern kernels make this efficient with copy-on-write memory, but the programming model is old and deeply baked into Unix. Shells use it constantly. Servers use it. Build systems use it. Scripting languages assume it exists, or at least that the surrounding environment behaves as though it does.

Windows process creation is different. Windows has CreateProcess(), which starts a new program. That is a perfectly reasonable model, but it is not fork() (more like fork()+exec()). If you are just launching notepad.exe, no problem. If you are trying to implement a POSIX shell that forks, redirects file descriptors, adjusts the environment, and then starts another program, the mismatch is extreme and you’ll have to do some strange things to fake things out.

One of the early commercial answers was the MKS Toolkit, originally from Mortice Kern Systems. MKS gave Windows users a pile of familiar commands, shells, and development tools. It was not just ls and friends; it included things like ksh, vi, grep, find, awk, make, and many of the utilities needed to move scripts and build procedures between Unix and Windows. The current PTC MKS documentation still describes it in exactly that spirit: Unix shells and hundreds of commands for interoperability with Windows.

MKS was attractive because it treated Windows as Windows. You were not necessarily pretending your machine was a Unix workstation. You were getting a Unix-flavored toolbox that could operate in a Windows environment. For many people, that was enough. You could write scripts, process text, drive builds, and avoid learning three different syntaxes for the same job.

Continue reading “A Brief History Of Unix Commands On Windows: CoreUtils (Again)”

Honda Civics And Installing Software With Android Test Keys

As more and more of the ‘smart’ infotainment systems in cars begin to age out of support, it becomes increasingly more relevant to figure out how to do something with that lump of computer-and-display sitting prominently in the dashboard.

Here [Eric McDonald]’s reverse-engineering of the 2012-era Android-based infotainment system in a 2021 Honda Civic is an interesting case study, with recently the discovery made that the head unit of these infotainment systems can be updated via USB by using standard Android Open Source Project (AOSP) test keys as these were left on the file system.

This is a nice update to his initial reverse-engineering back in the innocent days of 2023, when such a facepalm-worthy exploit seemed unimaginable, but then the ‘s’ in ‘infotainment’ has always stood for ‘security’. In this exploit that [Eric] calls the EvilValet attack, it means that anyone with physical access to the USB port inside the car can theoretically run arbitrary code signed with these test keys, as documented in the GitHub project.

So far this rather foolish security issue has only been confirmed on [Eric]’s 2021 Honda Civic, but considering how those – often third-party – infotainment systems tend to get reused and recycled across generations and car variants, it’s quite possible that more Android-based infotainment systems have this vulnerability.

This exploit is obviously a double-edged sword, as on one hand it’s great that an owner of one of these cars can now basically do whatever they want with said infotainment system, but on the other hand it means that anyone who slides into your car with a USB stick can do the same.

Bike-Powered Shredder Makes Short Work Of 3D Printer Waste

[Brogan M Pratt] and his students do a lot of 3D printing, and as such found themselves producing a lot of plastic waste. Seeing an opportunity, they built a bike-powered plastic shredder that turns a little human exercise into the power needed to transform waste plastic into small bits. Shredding plastic is a necessary first step for any sort of processing, so getting this part working reliably is as important as it is educational.

Shredding is a necessary first step to processing plastic waste.

Being in the Netherlands, using a bike makes perfect sense. But it turns out there’s a lot more to making a human-powered plastic shredder than simply bolting a sprocket to a shredder, looping the bike chain over it, then climbing on and working up a sweat.

In between the bike and the shredder is a large gear reduction, a fifteen kilogram flywheel, and a heavy-duty frame to anchor everything in the face of so much mass and torque. Add some covers and safety guards and the result is a stationary bike with a hopper for waste, a bin for output, and enough rotational torque and inertia to chew through stubborn bits without stalling.

Now that the shredder works, what’s the plan for all the little plastic shreds? The goal is to turn it back into usable filament which is obviously very useful, but we’ve also seen that compression molding plastic waste can work pretty well, too.

Being an educator, [Brogan] makes it clear that a bike-powered shredder, while pretty cool, is not the only missing link in sustainability. There is currently no easy way to recycle plastic at scale. But the shredder is a critical part of demonstrating the whole process in a hands-on way, and learning why recycling plastic at scale is a genuinely difficult job.

Continue reading “Bike-Powered Shredder Makes Short Work Of 3D Printer Waste”

Learning About Ground Loop Isolators Thanks To A Scam Product

When [Denki Otaku] bought a ¥1,200 (roughly €6.5) XLR ground loop isolator off Japanese Amazon, he initially didn’t suspect that anything was off. Since they’re fairly simple devices, with basically a 1:1 transformer per channel in some kind of enclosure, the price wasn’t unreasonable.

That’s before a teardown showed that this ‘ground loop isolator’ actually contains direct wiring between the XLR sockets, but that doesn’t mean that you cannot still make an educational video about the real devices.

First the basic theory is explained, before the fake ground loop isolator is subjected to an analysis, showing why you’d want to use the real deal. Of course, detecting a fake one is pretty easy, as a simple continuity test with a multimeter  or similar will show that DC passes right through the fake isolator.

Next a real ground loop isolator was designed with a custom PCB and a high-pass filter added to the feature list. Here rather than a very basic filter with cheapo parts there was definitely some gold-plating going on, but it does show what you can do in addition to just adding a few simple transformers for ground isolation purposes.

The finished ground loop isolator device is pretty large, and would definitely require a larger enclosure than the homeopathic device, but it makes for an easy test bed with convenient access during the subsequent analysis.

Here each of the two channels has its own transformer and filter, with an initial test just by ear making the injected 2 kHz noise signal appear to go completely away.

Next, an oscilloscope is used to visualize the functionality, with the non-isolated 440 Hz test signal first shown with and without the injected noise, showing the clear impact of the noise and subsequently the isolator.

Of course, high-frequency noises will still pass through the transformer via parasitic capacitance leakage between the windings, so it’s not a silver bullet. Here the analysis at the end of the video shows the noise-rejection characteristics of these isolators, and why adding a high-pass filter makes a lot of sense. Finally, the scam device’s XLR connectors were reused in an enclosure for this custom board, giving it some purpose after all.

Continue reading “Learning About Ground Loop Isolators Thanks To A Scam Product”

This Alarm Clock Has The Capacity To Wake You

Every now and then a project comes into the Hackaday feed that has so many levels of wrong about it that you really shouldn’t do it at home, but is amusing enough to feature anyway with a warning. So it is with [ArcaEge]’s Capacitor Alarm Clock, which wakes up its unfortunate owner by blowing up electrolytic capacitors with reverse voltage. If you survive, you’ll certainly be awake!

It’s inspired unsurprisingly by an [ElectroBoom] video, and the premise is simple enough. An ESP32 serves as the clock, and triggers a relay for the alarm, which in turn overloads a suitably low-voltage electrolytic capacitor in a socket. The resulting explosion which appears in a video we’ve placed below the break, wakes the slumberer.

We don’t have to tell you that this is not the safest of hacks, and is presented here only for your entertainment. But it does provide a few points of interest, for example in identifying the difference between capacitors with a vent, and those without.

This isn’t the first time we’ve seen a project based around exploding capacitors, and that one maybe was a don’t-do-this-at-home too.

Continue reading “This Alarm Clock Has The Capacity To Wake You”