TechyMagThings

Noise cancelling headphones are a great way to insulate yourself from the bustle of the city, but due to their power requirements, continuous use means frequent recharging. [Alessandro Sgarzi] has an elegant and unique solution — powering the noise cancelling electronics by harvesting energy from the ambient noise of the city via a sheet of piezoelectric film.

This impressive feat is achieved using a LTC3588-1 power harvesting IC and a pair of supercapacitors, while an STM32L011K4T6 microcontroller processes the input from a MEMS microphone and feeds a low-power class D amplifier. This circuit consumes an astounding 1.7 nW, a power that a noisy city is amply able to supply. Audio meanwhile comes via a traditional 3.5 mm connector, which we are told is the cool kids’ choice nowadays anyway.

We like this project, and since it’s part of our 2026 Green Powered Challenge, it’s very much in the spirit of the thing. You’ve just got time to get your own entry in, so get a move on!

Capacitive displacement sensors span a wide range of resolution, from the touchscreen sensors which can only detect displacement as a binary state, all the way to the sensors in semiconductor fabs which measure down to nanometers. The sensor [Matthias Wandel] built with a Raspberry Pi Pico lands somewhere in the middle, providing both sensitive measurements and an absolute scale.

The idea is that the amount of overlap between two metal plates should be detectable by measuring the capacitance between them. Reaching any kind of usable resolution would require a very precise measure of capacitance, around the picofarad range. [Matthias] realized that the Pico’s GPIO pins have an inherent capacitance, and can have a pull-down resistor set, essentially creating an RC circuit. [Matthias] would set a pin to a high-level output, then switch it to an input. The amount of time the pin takes to switch from high to low indicates the RC constant, which includes the capacitance attached to the pin.

When attached to a metal plate, the Pico was sensitive enough to detect the plate’s capacitive coupling to [Matthias]’s hand through a thick wooden floor. To measure capacitance between two metal plates, the Pico measured how well a voltage signal applied to one plate was coupled to the other plate. This was sensitive enough to measure the slight change in the dielectric constant when [Matthias] waved a piece of ABS pipe between the two capacitor plates. Making actual position measurements was tricky, since capacitance changed with both X- and Z-axis shifts in the plates.

Digital calipers use similar capacitive sensors to make their measurements, as [Matthias] knows from his experiments in hacking them. If you’re interested in more details, check out this teardown of some cheap digital calipers.

Thanks to [H Hack] for the tip!

The Unity game development platform was first released in 2005, long after the PlayStation had ceased to be a relevant part of the console market. And yet, you could use Unity to develop for the platform, if you so desire, thanks to the efforts of [Bandwidth] and the team behind psxsplash. 

Yes, it really is possible to design games for the original PlayStation using Unity and Lua. Using a tool called SplashEdit, you can whip up scenes, handle scripting, loading screens, create UIs, and do all the other little bits required to lash a game together. You can then run your creation via the psxsplash engine, deploying to emulator or even real hardware with a single click. Currently, development requires a Windows or Linux machine and Unity 6000.0+, but other than that, it’s pretty straightforward to start making games with a modern toolset for one of the most popular consoles of all time. Just remember, you’ve only got 33 MHz and 2MB of RAM to play with.

We still love to see the legendary grey machine get used and hacked in new and inventive ways, so many decades after release.

Thanks to [Nick] for the tip!

Ever encountered a minor annoying bug in a video game? How about one dating back to 2018? Usually, you have no hope of fixing it, but this time is different. [Joey Cheerio] shows the first-time programmer approach to (with great difficulty) fixing a bouncy ball prop turning invisible when shot in Team Fortress 2.

It starts with a band-aid solution that hides the problem: just turn off jiggle physics! While that works, it also affects many other models in the game, and doesn’t tackle the root cause. Time to investigate. Because this ball often goes overlooked, [Joey Cheerio] didn’t even realize that it was supposed to have jiggle physics, accidentally removing it. Turns out, after scouring the internet for old footage, it’s supposed to jiggle after all.

Back to square one, [Joey Cheerio] infers that the jiggle bone accidentally removed was related to the problem, eventually figuring out that the specific type of jiggle bone used (is_boing) caused the issue. Time to dig in the code. Tracking down the problem is no small feat for someone who’s never programmed before, even with the help of LLMs, but eventually, at 4 in the morning, a breakthrough! The ball no longer turned invisible but retained the intended jiggle.

At the limits of his knowledge on the subject, [Joey Cheerio] posts his partial progress so far to GitHub, where [ficool2] tracks down the real problem and turns this second band-aid into a proper fix. [Joey Cheerio] finishes up by explaining the math of what exactly went wrong.

When Ridge Racer hit the arcades in the early 1990s, it came in a few different versions. The last variant used three large CRTs to create a wraparound display for the player. Incredibly rare, it’s believed that only a single-digit number of machines remain in existence. [beaumotplage] has secured a remaining example, and been working to preserve this historical artifact.

The first mission when it comes to this machine was to dump the ROMs, which have thus far not been preserved in any major archive. With that done, [beaumotplage] worked to hack a version of MAME that could emulate the Three Monitor Version’s unique mode of operation. As it turns out, each screen is driven by its own arcade board, with the three boards linked via C139 serial links. To emulate this, the trick was simply to write some C139 linkup code and run three versions of MAME all at once, letting them communicate with each other as the original boards would have. It’s a little janky in operation right now, but it does work!

You can download the hacked version of MAME for three-monitor operation here, though note that this does not include the ROM dumps from the machine itself. We look forward to seeing if the hardware ends up getting a full restoration back to operational standard, too.

Overall, this work goes to show that arcade preservation and archival work sometimes requires getting deep into the nitty-gritty technical stuff.

Generally when a game console with an optical drive stops reading discs the first thing that people do is crank on the potentiometer that controls the power to the laser diode to ramp up its output. While this can be a necessary solution to eke out a bit more life out of a clearly dying laser diode, this can actually massively shorten the lifespan of a good diode that’s just held back by bad capacitors. This is demonstrated by [Skawo] with a fix on a GameCube that stopped reading discs.

While it’s absolutely true that laser diodes have a limited lifespan, so do the capacitors and other components in the system. Thus, after tearing down this Japanese GameCube, [Skawo] accesses the optical PCB for some delicate plier-based capacitor surgery. One can absolutely question such violence, as well as the replacement mix of MLCC ceramics and a stray THT electrolytic capacitor, but the results after reassembly are obvious.

Without having to adjust the laser diode’s potentiometer, the game console now happily reads the game disc while the laser diode breathes a sigh of relief. Although all GameCube consoles will face the inevitable demise of their optical drives – barring a replacement optical pickup solution appearing – with this capacitor replacement solution it’s at least possible to stave off that undesirable time for a bit longer.

Those who have worked on a hobby operating system for x86 will have interacted with its rather complex and confusing interrupt model. [Evalyn] shows us why and how to use Flexible Return and Event Delivery (FRED), a new standard by the x86 Ecosystem Advisory Group.

Of course, it would be silly to omit the fact that Linux received patches first. But that isn’t the interesting part; after all, Linux is often the first place to have support for this kind of thing. No, what’s interesting is [Evalyn]’s implementation, to our knowledge among — if not the first — non-Linux operating system to support it.

To know why we should switch to FRED, we must first understand what it replaces. The Interrupt Descriptor Table (IDT) tells the CPU what code to run when certain interrupts or faults happen. The big problem that the IDT has is inconsistency, most egregiously the fact that the stack layout depends on which interrupt happened. To solve the issues with the IDT, FRED was created.

[Evalyn] shows us the process, starting at the documentation, then finding an emulator capable of it and culminating in a demo where DOOM runs in EvalynOS with FRED enabled.

Pentium II die shot. Martijn Boer, Public domain.