If the idea of reading a physical book sounds like hard work, [Nick Bild’s] latest project, the PageParrot, might be for you. While AI gets a lot of flak these days, one thing modern multimodal models do exceptionally well is image interpretation, and PageParrot demonstrates just how accessible that’s become.

[Nick] demonstrates quite clearly how little code is needed to get from those cryptic black and white glyphs to sounds the average human can understand, specifically a paltry 80 lines of Python. Admittedly, many of those lines are pulling in libraries, and some are just blank, so functionally speaking, it’s even shorter than that. Of course, the whole application is mostly glue code, stitching together other people’s hard work, but it’s still instructive and fun to play with.

The hardware required is a Raspberry Pi Zero 2 W, a camera (in this case, a USB webcam), and something to hold it above the book. Any Pi with the ability to connect to a camera should also work, however, with just a little configuration.

On the software side, [Nick] pulls in the CV2 library (which is the interface to OpenCV) to handle the camera interfacing, programming it to full HD resolution. Google’s GenAI is used to interface the Gemini 2.5 Flash LLM via an API endpoint. This takes a captured image and a trivial prompt, and returns the whole page of text, quick as a flash.

Finally, the script hands that text over to Piper, which turns that into a speech file in WAV format. This can then be played to an audio device with a call out to the console aplay tool. It’s all very simple at this level of abstraction.

Yes, we know it’s essentially just doing the same thing OCR software has been doing for decades. Still, the AI version is remarkably low-effort and surprisingly accurate, especially when handling unusual layouts that confound traditional OCR algorithms. Extensions to this tool would be trivial; for example, adjusting the prompt to ask it to translate the text to a different language could open up a whole new world to some people.

If you want to play along at home, then head on over to the PageParrot GitHub page and download the script.

If this setup feels familiar, you’d be quite correct. We covered something similar a couple of years back, which used Tesseract OCR, feeding text to Festvox’s CMU Flite tool. Whilst we’re talking about text-to-speech, here’s a fun ESP32-based software phoneme synthesiser to recreate that distinctive 1980s Speak & Spell voice.

If you’re a regular GitHub user you’ll be familiar with the website’s graphical calendar display of activity as a grid. For some of you it will show a hive of activity, while for others it will be a bit spotty. If you’re proud of your graph though, you’ll want to show it off to the world, and that’s where [HarryHighPants]’ Git Contributions E-Ink Display comes in. It’s a small desktop appliance with a persistent display, that shows the current version of your GitHub graph.

At its heart is an all-in-one board with the display and an ESP32 on the back, with a small Li-Po cell. It’s all put in a smart 3D printed case. The software is the real trick, with a handy web interface from which you can configure your GitHub details.

It’s a simple enough project, but it joins a growing collection which use an ESP32 as a static information display. The chip is capable of more though, as shown by this much more configurable device.

Like many of us of a certain vintage, [Dillan Stock] at The Stock Pot is nostalgic for VHS tapes. It’s not so much the fuzzy picture or the tracking issues we miss, but the physical experience the physical medium brought to movie night. To recreate that magic, [Dillan] made a Modern VHS with NFC and ESPHome.

NFC tags are contained in handsomely designed 3D printed cartridges. You can tell [Dillan] put quite a bit of thought into the industrial design of these: there’s something delightfully Atari-like about them, but they have the correct aspect ratio to hold a miniaturized movie poster as a label. They’re designed to print in two pieces (no plastic wasted on supports) and snap together without glue. The printed reader is equally well thought out, with print-in-place springs for that all important analog clunk.

Electronically, the reader is almost as simple as the cartridge: it holds the NFC reader board and an ESP32. This is very similar to NFC-based audio players we’ve featured before, but it differs in the programming. Here, the ESP32 does nothing related directly to playing media: it is simply programmed to forward the NFC tag id to ESPHome. Based on that tag ID, ESPHome can turn on the TV, cue the appropriate media from a Plex server (or elsewhere), or do… well, literally anything. It’s ESPHome; if you wanted to make this and have a cartridge to start your coffee maker, you could.

If this tickles your nostalgia bone, [Dillan] has links to all the code, 3D files and even the label templates on his site. If you’re not sold yet, check out the video below and you might just change your mind. We’ve seen hacks from The Stock Pot before, everything from a rebuilt lamp to an elegant downspout and a universal remote.

How many times do you have to forget your keys before you start hacking on the problem? For [Binh], the answer was 5 in the last month, and his hack was to make a gesture-based door unlocker. Which leads to the amusing image of [Binh] in a hallway throwing gang signs until he is let in.

The system itself is fairly simple in its execution: the existing deadbolt is actuated by a NEMA 17 stepper turning a 3D printed bevel gear. It runs 50 steps to lock or unlock, apparently, then the motor turns off, so it’s power-efficient and won’t burn down [Binh]’s room.

The software is equally simple; mediapipe is an ML library that can already do finger detection and be accessed via Python. Apparently gesture recognition is fairly unreliable, so [Binh] just has it counting the number of fingers flashed right now. In this case, it’s running on a Rasberry Pi 5 with a webcam for image input. The Pi connects via USB serial to an ESP32 that is connected to the stepper driver. [Binh] had another project ready to be taken apart that had the ESP32/stepper combo ready to go so this was the quickest option. As was mounting everything with double-sided tape, but that also plays into a design constraint: it’s not [Binh]’s door.

[Binh] is staying in a Hacker Hotel, and as you might imagine, there’s been more penetration testing on this than you might get elsewhere. It turns out it’s relatively straightforward to brute force (as you might expect, given it is only counting fingers), so [Binh] is planning on implementing some kind of 2FA. Perhaps a secret knock? Of course he could use his phone, but what’s the fun in that?

Whatever the second factor is, hopefully it’s something that cannot be forgotten in the room. If this project tickles your fancy, it’s open source on GitHub, and you can check it out in action and the build process in the video embedded below.

After offering thanks to [Binh] for the tip, the remaining words of this article will be spent requesting that you, the brilliant and learned hackaday audience, provide us with additional tips.

When you hear “PS2” and “Windows 95,” you probably think someone forgot a slash and are talking about peripherals, but no — this hack is very much about the Sony PlayStation 2, the best-selling game console of all time. [MeraByte] walks us through the possibly ridiculous task of installing Windows 95 on the last hardware anyone at Microsoft would ever endorse in a video you can watch below.

Obviously, the MIPS-based Emotion Engine at the heart of the PS2 is not going to be able to handle x86 instructions Win95 is expecting, but that’s all solved by the magic of emulation. [MeraByte] is running a version of Bochs, an x86 emulator that has been built for PS/2 after trying and failing to install Windows (both 3.1 and 95) to an experimental DOSBox build.

As expected, it is not a smooth journey for [MeraByte], but the flailing about and troubleshooting make for entertaining viewing. Once loaded, it works surprisingly well, in that anything works at all. Unfortunately, neither the mouse nor Ultimate Doom 95 worked. We suppose that ultimately means that this hack fails since even Doom can run Doom. The mouse thing is also important, probably.

If you have a PlayStation 2, maybe skip Windows 95 and try running GoLang.  If you do have DOOM running on the PlayStation 2, send us a tip. There was never an official release for PS2, but after 26 years, someone must have done it by now.

Old hardware tends to get less support as the years go by, from both manufacturers and the open-source community alike. And yet, every now and then, we hear about fresh attention for an ancient device. Consider the ancient SoundBlaster sound card that first hit the market 31 years ago. [Mark] noticed that a recent update squashed a new bug on an old piece of gear.

Jump over to the Linux kernel archive, and you’ll find a pull request for v6.16-rc3 from [Takashi Iwai]. The update featured fixes for a number of sound devices, but one stands out amongst the rest. It’s the SoundBlaster AWE32 ISA sound card, with [Iwai] noting “we still got a bug report after 25 years.” The bug in question appears to have been reported in 2023 by a user running Fedora 39 on a 120 MHz Pentium-based machine.

The fixes themselves are not particularly interesting. They merely concern minutiae about the DMA modes used with the old hardware. The new updates ensure that DMA modes cannot be changed while the AWE32 is playing a PCM audio stream, and that DMA setups are disabled when changing modes. This helps avoid system lockups and/or ugly noises emanating from the output of the soundcard.

It’s incredibly unlikely this update will affect you, unless you’re one of a handful of users still using an ISA soundcard in 2025. Still, if you are — and good on you — you’ll be pleased someone still cares about your user experience. Meanwhile, if you’re aware of any other obscure old-school driver updates going on out there, don’t hesitate to let us know on the tips line. Want to relive your ISA card’s glory days? Plug it into USB.

Image credit: Gona.eu, CC BY-SA 3.0

[Thanks to Meek Mark for the tip!]

At one point in time mechanical seven segment displays were ubiquitous, over time many places have replaced them with other types of displays. [Sebastian] has a soft spot for these old mechanically actuated displays and has built an open-source 7-segment display with some very nice features.

We’ve seen a good number of DIY 7-segment displays on this site before, the way [Sebastian] went about it resulted in a beautiful well thought out result. The case is 3D printed, and although there are two colors used it doesn’t require a multicolor 3d printer to make your own. The real magic in this build revolves around the custom PCB he designed. Instead of using a separate electromagnets to move each flap, the PCB has coil traces used to toggle the flaps. The smart placement of a few small screws allows the small magnets in each flap to hold the flap in that position even when the coils are off, greatly cutting down the power needed for this display. He also used a modular design where one block has the ESP32 and RTC, but for the additional blocks those components can remain unpopulated.

The work he put into this project didn’t stop at the hardware, the software also has a great number of thoughtful features. The ESP32 running the display hosts a website which allows you to configure some of the many features: the real-time clock, MQTT support, timer, custom API functions, firmware updates. The end result is a highly customizable, display that sounds awesome every time it updates. Be sure to check out the video below as well as his site to see this awesome display in action. Also check out some of the other 7-segment displays we’ve featured before.

Look out of a window, ask yourself the question, “Has a nuke gone off?”. Maybe, maybe not, and all of us here at Hackaday need to know the answer to these important questions! Introducing the hasanukegoneoff.com Indicator from [bigcrimping] to answer our cries.

An ESP32 running a MicroPython script handles the critical checks from hasanukegoneoff.com for any notification of nuclear mayhem. This will either power the INS-1 neon bulb, indicating “no” or “yes” in the unfortunate case of a blast. Of course, there is also the button required for testing the notification lights; no chance of failure can be left. All of this is fitted onto a custom dual-sided PCB and placed inside a custom 3D-printed enclosure.

Hasanukegoneoff.com’s detection system, covered before here, relies on an HSN-1000L Nuclear Event Detector to check for neutrons coming from the blast zone. [bigcrimping] also provides the project plans for your own blast detector to answer the critical question of “has a nuke gone off” from anywhere other than the website’s Chippenham, England location.

This entire project is open sourced, so keep sure to check out [bigcrimping]’s GitHub for both portions of this project on the detector and receiver. While this project provides some needed dark humor, nukes are still scary and especially so when disarming them with nothing but a hacksaw and testing equipment.

Thanks to [Daniel Gooch] for the tip.

If you’ve worked on a project with small LEDs, you know the frustration of determining their polarity. This ingenious LED Probe from [David] packs a lot of useful features into a simple, easy-to-implement circuit.

Most multimeters have a diode test function that can be used to check LEDs; however, this goes a step further. Not only will the probe light up an LED, it will light up no matter which side of the LED the leads are touching. A  Red/Green LED on the probe will indicate if the probe tip is on the anode or cathode.

The probe is powered by a single CR2032 battery, and you may notice there’s no on/off switch. That’s because the probe enters a very low-current sleep mode between uses. The testing intelligence is handled by either an ATtiny85 or, in the newest version, an ATtiny202, though the basic concept and design are compatible with several other chips. All the design files for the PCB, the ATtiny code, a parts list, and a detailed explanation of how it works are available on [David]’s site, so be sure to check them out. Once you build one of these probes, you’ll want something to test it on, so explore some of the LED projects we’ve featured in the past.

The Portal games were revolutionary not only for their puzzle-based, narrative-driven gameplay, but also for their unique physics engine, which let players open portals anywhere and conserve momentum and direction through them. They’re widely regarded as some of the best video games ever made, but even beyond that they have some extra features that aren’t talked about as much. Namely, there are a number of level editors and mods that allow the in-game components to be used to build things like logic gates and computers, and this project goes even further by building a working NES emulator, all within Portal 2.

The main limitation here is that Portal 2 can only support a certain number of in-game objects without crashing, far lower than what would be needed to directly emulate NES hardware. The creator of the project, [PortalRunner], instead turned to Squirrel, the Portal 2 scripting language, and set about porting an existing NES emulator called smolnes to this scripting language. This is easier said than done, as everything in the code needs to be converted eight bits and then all of the pointers in smolnes need to be converted to use arrays, since Squirrel doesn’t support pointers at all. As can be easily imagined, this led to a number of bugs that needed to be sorted out before the game would run at all.

For those interested in code golfing, porting, or cross-compatibility, this project is a master class not only in the intricacies of the Portal 2 scripting language but in the way the NES behaves as well, not to mention the coding skill needed to recognize unique behaviors of the C language and the Squirrel scripting language. But eventually [PortalRunner] is able to get Super Mario Bros. running in Portal 2, albeit with low resolution and frame rate. Since we heard you like games within games, someone else put DOOM inside DOOM so you can DOOM while you DOOM.

Thanks to [Mahdi] for the tip!

Despite the repeated warnings of system administrators, IT personnel, and anyone moderately aware of operational security, there are still quite a few people who will gladly plug a mysterious flash drive into their computers to see what’s on it. Devices which take advantage of this well-known behavioral vulnerability have a long history, the most famous of which is Hak5’s USB Rubber Ducky. That emulates a USB input device to rapidly execute attacker-defined commands on the target computer.

The main disadvantage of these keystroke injection attacks, from the attacker’s point of view, is that they’re not particularly subtle. It’s usually fairly obvious when something starts typing thousands of words per minute on your computer, and the victim’s next move is probably a call to IT. This is where [Krzysztof Witek]’s open-source Rubber Ducky clone has an advantage: it uses a signal detected by a SYN480R1 RF receiver to trigger the deployment of its payload. This does require the penetration tester who uses this to be on the site of the attack, but unlike with an always-on or timer-delayed Rubber Ducky, the attacker can trigger the payload when the victim is distracted or away from the computer.

This project is based around the ATmega16U2, and runs a firmware based on microdevt, a C framework for embedded development which [Krzysztof] also wrote. The project includes a custom compiler for a reduced form of Hak5’s payload programming language, so at least some of the available DuckyScript programs should be compatible with this. All of the project’s files are available on GitHub.

Perhaps due to the simplicity of the underlying concept, we’ve seen a few open source implementations of malicious input devices. One was even built into a USB cable.

What do you do when you’re a starving student and you need a 400 MHz logic analyzer for your digital circuit investigations? As [nanofix] shows in a recent video, you find one that’s available as an open hardware project and build it yourself.

The project, aptly named LogicAnalyzer was developed by [Dr. Gusman] a few years back, and has actually graced these pages in the past. In the video below, [nanofix] concentrates on the mechanics of actually putting the board together with a focus on soldering. The back of the build is the Raspberry Pi Pico 2 and the TXU0104 level shifters.

If you’d like to follow along at home, all the build instructions and design files are  available on GitHub. For your convenience the Gerber files have been shared at PCBWay

Of course we have heaps of material here at Hackaday covering logic analyzers. If you’re interested in budget options check out $13 Scope And Logic Analyzer Hits 18 Msps or how to build one using a ZX Spectrum! If you’re just getting started with logic analyzers (or if you’re not sure why you should) check out Logic Analyzers: Tapping Into Raspberry Pi Secrets.

Regular ding-dong doorbells are fun and all, but it can be nice to put something a little more special by your front door. To that end, [Arpan Mondal] built this neat little piano doorbell to make visiting his home just a touch more fun.

The heart of the build is an ESP32 microcontroller. It’s responsible for reading the state of five 3D printed piano keys: three white, two black. It’s nowhere near a full octave, but for a doorbell, it’s enough. When a key is pressed, the ESP32 plays a short audio sample embedded within the program code itself. This is done with the help of a PAM8403 audio amplifier module, which jacks up the output to drive the doorbell speaker loud enough to be heard throughout the home. It’s not exactly studio quality audio, but for a doorbell, it sounds pretty solid.

If you’re looking for a fun and easy build to make your home just a little bit more whimsical, it’s hard to beat something like this. Your musical friends will love it—they might even develop an intro riff of their very own. We’ve featured some other fun doorbell builds before, too—the best of which are the Halloween projects.

[Moby Pixel] wanted to build a fun MIDI controller. In the end, he didn’t build it just once, but twice—with the aim of finding out which microcontroller was most fit for this musical purpose. Pitted against each other? The ESP32 and Raspberry Pi Pico.

The MIDI controller itself is quite fetching. It’s built with a 4 x 4 array of arcade buttons to act as triggers for MIDI notes or events. They’re assembled in a nice wooden case with a lovely graphic wrap on it. The buttons themselves are wired to a microcontroller, which is then responsible for sending MIDI data to other devices.

At this point, the project diverges. Originally, [Moby Pixel] set the device up to work with an ESP32 using wireless MIDI over Bluetooth. However, he soon found a problem. Musical performance is all about timing, and the ESP32 setup was struggling with intermittent latency spikes that would ruin the performance. Enter the Raspberry Pi Pico using MIDI over USB. The hardwired solution eliminated the latency problems and made the controller far more satisfying to use.

There may be solutions to the latency issue with the wireless ESP32 setup, be they in code, hardware configuration, or otherwise. But if you want to play with the most accuracy and the minimum fuss, you’ll probably prefer the hardwired setup.

Latency is a vibe killer in music as we’ve explored previously.

If you have never heard of the Bellmac-32, you aren’t alone. But it is a good bet that most, if not all, of the CPUs in your devices today use technology pioneered by this early 32-bit CPU. The chip was honored with the IEEE Milestone award, and [Willie Jones] explains why in a recent post in Spectrum.

The chip dates from the late 1970s. AT&T’s Bell Labs had a virtual monopoly on phones in the United States, but that was changing, and the government was pressing for divestiture. However, regulators finally allowed Bell to enter the computing market. There was only one problem: everyone else had a huge head start.

There was only one thing to do. There was no point in trying to catch the leaders. Bell decided to leap ahead of the pack. In a time when 8-bit processors were the norm and there were nascent 16-bit processors, they produced a 32-bit processor that ran at a — for the time — snappy 2 MHz.

At the time (1978), most chips used PMOS or NMOS transistors, but Bellmac-32 used CMOS and was made to host compiled C programs. Problems with CMOS were often addressed using dynamic logic, but Bell used a different technique, domino logic, to meet their goals.

Domino logic lets devices cascade like falling dominoes in between clock pulses. By 1980, the device reached 2 MHz, and a second generation could reach speeds of up to 9 MHz. For contrast, the Intel 8088 from 1981 ran at 4.77 MHz and handled, at most, half the data in a given time period as the Bellmac-32. Of course, the 68000 was out a year earlier, but you could argue it was a 16-bit CPU, despite some 32-bit features.

It is fun to imagine what life would be like today if we had fast 32-bit Unix machines widely available in the early 1980s. History has shown that many of Bellmac’s decisions were correct. CMOS was the future. Many of the design and testing techniques would go on to become standard operating procedure across the industry. But, as for the Bellmac-32, it didn’t really get the attention it deserved. It did go on in the AT&T 3B computers as the WE 32×00 family of CPUs.

You can check out a 1982 promo video about the CPU below, which also explains domino logic. Instruction sets have changed a bit since then. You can see a 68000 and 8086 face off, and imagine how the Bellmac would have done in comparison.

Over on Hackaday.io there’s a fun and playful write-up for a fun and playful project — the Piko, an ESP32 powered smartwatch.

Our hackers [Iloke Alusala], [Lulama Lingela], and [Rafael Cardoso] teamed up to design and manufacture this wrist-worn fitness wearable. Made from an ESP32 Beetle C6 and using an attached accelerometer with simple thresholds the Piko can detect if you’re idle, walking, jogging, or sprinting; and at the same time count your steps.

The team 3D printed the requisite parts in PLA using the printer in their university makerspace. In addition to the ESP32 and printed parts, the bill of materials includes a 240×240 IPS TFT LCD display, a LIS331HH triple-axis accelerometer, a 200 mAh battery, and of course, a watch strap.

Demonstrating splendid attention to detail, and inspired by the aesthetic of the Tamagotchi and pixel art, the Piko mimics your current activity with a delightful array of hand-drawn animations on its display. Should you want to bring a similar charm to your own projects, all the source is available under the MIT license.

If you’re interested in smartwatch technology be sure to check out our recent articles: Smartwatches Could Flatten The Curve Of The Next Pandemic and Custom Smartwatch Makes Diabetes Monitoring Easier For Kids.

The advent of affordable computing over the last few decades has certainly been a boon for many people with disabilities, making it easier to access things like text-to-speech technology, automation, or mobility devices, and even going as far as making it easier to work in general by making remote work possible. Some things still lag behind, though, like user interfaces that don’t take the colorblind into account, or appliances that only use an audio cue to signal to their users. This doorbell, for example, is one such device and [ydiaeresis] is adding features to it to help their mother with some hearing issues.

The first thing up for this off-the-shelf remote doorbell is a “brain transplant” since the built-in microcontroller couldn’t be identified. There are only a few signals on this board though so an ATtiny412 made for a suitable replacement. A logic analyzer was able to decode the signals being fed to the original microcontroller, and with that the push of the doorbell can be programmed to do whatever one likes, including integrating it with home automation systems or other assistive technology. In [ydiaeresis]’s case there’s an existing LED lighting system that illuminates whenever the phone rings.

Although it would be nice if these inexpensive electronics came with the adaptive features everyone might need from them, it’s often not too hard to add it in as was the case with this set of digital calipers. To go even further, some other common technology can be used to help those with disabilities like this hoverboard modified to help those with mobility issues.

Thanks to [buttim] for the tip!

Some hacks just tickle the brain in a very particular way. They’re, for a change, not overly engineered; they’re just elegant, anachronistic, and full of mischief. That’s exactly what [Frans] pulls off with A Gentleman’s Orrery, a tiny, simple clockwork solar system. Composed of shiny brass and the poise of 18th-century craftsmanship, it hides a modern secret: there’s barely any clockwork inside. You can build it yourself.

Peek behind the polished face and you’ll find a mechanical sleight of hand. This isn’t your grandfather’s gear-laden planetarium. Instead of that, it operates on a pared-down system that relies on a stepper motor, driving planetary movement through a 0.8 mm axle nested inside a 1 mm brass tube. That micro-mechanical coupling, aided by a couple of bevel gears, manages to rotate the Moon just right, including its orientation. Most of the movement relies on clever design, not gear cascades. The real wizardry happens under the hood: a 3D-printed chassis cradles an ESP32-C6, a TTP223 capacitive touch module, STSPIN220 driver, and even a reed switch with magnetic charging.

You can even swap out the brass for a stone shell where the full moon acts as the touch control. It’s tactile, it’s poetic, and therefore, a nice hack for a weekend project. To build it yourself, read [Frans]’ Instructable.

You can buy all sorts of RC cars off the shelf, but doing so won’t teach you a whole lot. Alternatively, you could follow [TRDB]’s example, and design your own from scratch.

The Lizard, as it is known, is a fun little RC car. It’s got a vaguely Formula 1-inspired aesthetic, and looks fetching with the aid of two-tone 3D printed parts. It’s designed for speed and handling, with a rear-wheel-drive layout and sprung suspension at all four corners to soak up the bumps. The majority of the vehicle is 3D printed in PETG, including the body and the gearbox and differential. However, some suspension components are made in TPU for greater flexibility and resistance to impact. [TRDB] specified commercial off-the-shelf wheels to provide good grip that couldn’t easily be achieved with 3D-printed tires. An ESP32 is responsible for receiving commands from [TRDB’s] custom RC controller running the same microcontroller. It sends commands to the speed controller that runs the Lizard’s brushed DC motor from a 3S lithium-polymer battery.

The final product looks sleek and handles well. It also achieved a GPS-verified top speed of 48 km/h as per [TRDB’s] testing. We’ve seen some other great DIY RC cars over the years, too, like this example that focuses on performance fundamentals. Video after the break.