One of the joys of browsing secondhand shops is the possibility of finding old, perhaps restorable or hackable, electronics at low prices. Admittedly, they usually seem to be old flat-screen TVs, cheap speakers, and Blu-ray players, but sometimes you find something like the Dash, an educational toy robot. When [Jonathan] came across one of these, he decided to use it as a turtle robot. However, he found the available Python libraries insufficient, and improving on them required some reverse-engineering.

While [Jonathan] was rather impressed with the robot as it was – it had a good set of features, and thought had clearly been put into the design – he wanted a more open way to control it. There was already a quite useful, official Python program to control the robot over a BLE connection, but it only worked with Python 2 on OS X ([Jonathan] theorizes that it might have been written as a development tool, open-sourced, and not diligently supported afterwards). There were also a few third-party libraries ported to Python 3, but they all seemed to be missing some important features.

All the newer libraries were limited because the official library passed commands to an OS X binary, which handled the actual communication, so anyone wanting to do everything in Python would have to reverse-engineer the communications protocol. [Jonathan] therefore used Ghidra to decompile the binary. He first found the JSON structure used for message data, followed by a function that reads command information and sets up packets, and a mapping between Python command names and command IDs. Once he found the section that creates packets from data, he was able to port the program to Python 3. Interestingly, examining the binary revealed some previously unknown commands that appear to be capable of defining autonomous behavior.

We’ve previously seen Ghidra used on devices ranging from a camera to a router; if you’d like to learn more, there’s a HackadayU course on it.

hackaday.com/2026/02/14/revers…

Are you in the mood for a retrocomputing deep dive into the Scriptovision Super Micro Script? It was a Canadian-made vintage video titler from the 80s, and [Cameron Kaiser] has written up a journey of repair and reverse-engineering for it. But his work is far more than just a refurbish job; [Cameron] transforms the device into something not unlike 8-bit homebrew computers of the era, able to upload and run custom programs with a limited blister keypad for input, and displaying output on a composite video monitor.

Hardware-wise, the Super Micro Script is almost a home computer, so [Cameron] got it accepting and running custom code.A video titler like the Super Micro Script gave people the ability to display bitmapped images (like text or simple graphics) onto a video stream electronically. A standalone device, under the hood, it uses a 6502 as CPU and a Motorola 6847 VDG video chip. [Cameron] observes that architecture-wise, it actually had a lot in common with early 8-bit home computers. Sure, it performed only one “job” but that really had more to do with its restrictive firmware than anything else.

[Cameron] obtained a used unit and repaired it, reverse-engineered the scrambled address and data lines (an anti-cloning and anti-tampering measure), and converted it into something for which he could write his own software and run his own programs. As for uploading those programs? A bit-banged serial port on I/O borrowed from the blister keypad, running at a frankly quite respectable 19.2 kbps.

We hope you’re intrigued, because [Cameron] has one more surprise: he created a MAME emulator for the Super Micro Script called SMSBUG. Originally created to make software development easier, its existence also means anyone can join in on the vintage computing fun. The emulator, along with other handy utilities and info, is available on GitHub.

hackaday.com/2026/02/14/vintag…

The lovely thing about the x86 architecture is its decades of backwards compatibility, which makes it possible to run 1990s operating systems on modern-day hardware, with relatively few obstacles in the way. Recently [Yeo Kheng Meng] did just that with Windows 98 SE on a 2020 ThinkPad P12s Gen 1, booting it alongside Windows 11 and Linux from the same NVMe drive.

Naturally, after previously getting MS-DOS 6.22 from 1994 running on a 2020 ThinkPad X13, the step to doing the same with Windows 98 SE wasn’t that large. The main obstacles that you face come in the form of UEFI and hardware driver support.

Both ThinkPad laptops have in common that they support UEFI-CSM mode, also known as ‘classical BIOS’, as UEFI boot wasn’t even a glimmer yet in some drunk engineer’s eye when Win98 was released. After this everything is about getting as many hardware drivers scrounged together as possible.

[Yeo] ended up having to bodge on a USB 2.0 expansion card via a Thunderbolt dock as Win98 doesn’t have xHCI (USB 3.0) support. With that issue successfully bodged around using a veritable tower of adapters, installing Windows 98 was as easy as nuking Secure Boot in the BIOS, enabling UEFI-CSM along with Thunderbolt BIOS assist mode and disable Kernel DMA protection.

Because UEFI-CSM implementations tend to be buggy, the CREGFIX DOS driver was used to smooth things over. Another issue is the same that we chuckled about back in the day, as Windows 98 cannot address more than 512 MB of RAM by default. Fortunately patches by [Rudolph Loew] helped to fix this and some other smaller issues.

Unfortunately neither Intel nor NVIDIA have released Win98 drivers for quite some time, so there’s no graphics acceleration beyond basic VESA support and the SoftGPU driver. Disk access goes via the BIOS too rather than using an NVMe driver, so it’s not as zippy as it could be, but for Win9x it’s quite usable.

Finally ACPI wasn’t recognized by Win98, but it’s only fair to blame that on the complete flaming train wreck that is ACPI rather than anything to do with Windows. This particular issue was worked around by configuring the BIOS to support S3 power state and with that making Win98 happy again.

It’s honestly quite a shame that UEFI-CSM is largely ignored by new systems, as it makes installing even Windows 7 basically impossible, and thus creating probably the largest split within the x86 ecosystem since the arrival of AMD64/x86_64.

hackaday.com/2026/02/14/window…

Musician Brian Eno’s Oblique Strategies are like a Tarot card deck full of whimsical ideas meant to break up a creative-block situation, particularly in the recording studio. They’re loads of fun to pick one at random and actually try to follow the advice, as intended, but some of them are just plain good advice for creatives.

One that keeps haunting me is “Honor thy error as a hidden intention”, which basically boils down to taking a “mistake” and seeing where it leads you if you had meant to do it. I was just now putting the finishing touches on this week’s Hackaday Podcast, and noticed that we have been honoring a mistake for the past 350-something shows. Here’s how it happened.

When Mike and I recorded the first-ever podcast, I had no idea how to go about doing it. But I grew up in Nashville, and know my way around the inside of a music studio, and I’ve also got more 1990s-era music equipment than I probably need. So rather than do the reasonable thing, like edit the recording on the computer, we recorded to an archaic Roland VS-880 “Digital Studio” which is basically the glorified descendant of those old four-track cassette Portastudios.

If you edit audio in hardware, you can’t really see what you’re doing – you have to listen to it. And so, when I failed to notice that Mike and I were saying “OK, are you ready?” and “Sure, let’s go!”, it got mixed in with the lead-in music before we started the show off for real. But somehow, we said it exactly in time with the music, and it actually sounded good. So we had a short laugh about it and kept it.

And that’s why, eight years later, we toss random snippets of conversations into the intro music to spice it up. It was a mistake that worked. Had we been editing on the computer, we would have noticed the extra audio and erased it with a swift click of the mouse, but because we had to go back and listen to it, we invented a new tradition. Honor thy error indeed.

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

hackaday.com/2026/02/14/honor-…

There are many applications where you have limits on how much you can cram into a particular space. There are also many applications where you need as much battery as you can get. At the intersection of those applications, you may soon be able to 3D print custom batteries to fit into oddly shaped spaces that might otherwise go to waste.

Commercial batteries are typically cylindrical or rectangular. In theory, you could build tooling to make batteries of any size or shape you want, but it’s an expensive process in small quantities. [Lawrence Ulrich] on Spectrum talks about a new process, developed by [Gabe Elias], that can print anodes, cathodes, separators, and casings for custom battery shapes with no costly tooling.

As an example, consider an unmanned aerial vehicle crammed with avionics. You could put off-the-shelf batteries in the wings, but you’ll end up wasting a lot of space. A custom battery could fill the wing’s interior completely. The post also mentions batteries shaped like the earpieces of a pair of smart glasses.

A prototype showed that in the space of 48 cylindrical cells, the new process could deliver a printed battery that uses 35% more of the available volume and a 50% boost in energy density.

Could you do this yourself? Maybe, but it won’t be trivial. The current process requires a liquid electrolyte and the ability to produce thin layers of exotic materials. What oddly-shaped battery would you like to see? Us? We’d like to have a battery for a laptop that was spread uniformly so there wasn’t a heavy side that has the battery.

hackaday.com/2026/02/14/theres…

Although [Jamie’s Brick Jams] has made many far more complicated motor design in the past, it’s nice to go back to the basics and make a motor that uses as few parts as possible. This particular design starts off with a driver coil and a magnetic rotor that uses two neodymium magnets. By balancing these magnets on both sides of an axis just right it should spin smoothly.
The circuit for the simple motor. (Credit: Jamie’s Brick Jams, YouTube)
First this driver coil is energized with a 9 V battery to confirm that it does in fact spin when briefly applying power, though this means that you need to constantly apply pulses of power to make it keep spinning. To this end a second coil is added, which senses when a magnet passes by.

This sense coil is connected to a small circuit containing a TIP31C NPN power transistor and a LED. While the transistor is probably overkill here, it’ll definitely work. The circuit is shown in the image, with the transistor pins from left to right being Base-Collector-Emitter. This means that the sensor coil being triggered by a passing magnet turns the transistor on for a brief moment, which sends a surge of power through the driver coil, thus pushing the rotor in a typical kicker configuration.

Obviously, the polarity matters here, so switching the leads of one of the coils may be needed if it doesn’t want to spin. The LED is technically optional as well, but it provides an indicator of activity. From this basic design a larger LEGO motor is also built that contains many more magnets in a disc along with two circular coils, but even the first version turns out to be more than powerful enough to drive a little car around.

youtube.com/embed/sX7x0XwtlKQ?…

hackaday.com/2026/02/14/buildi…

[Michigan Rocks] says he avoided making rock spheres for a long time on account of the time and cost he imagined was involved. Well, all that is in the past in light of the fabulous results from his self-built Rock Sphere Machine! Turns out that it’s neither costly to make such a machine, nor particularly time-consuming to create the spheres once things are dialed in. The video is a journey of the very first run of the machine, and it’s a great tour.
The resulting sphere? Super satisfying to hold and handle. The surface is beyond smooth, with an oil-like glossy shine that is utterly dry to the touch.
The basic concept — that of three cordless drills in tension — is adapted from existing designs, but the implementation is all his own. First a rough-cut rock is held between three diamond bits. The drills turn at 100 RPM while a simple water reservoir drips from above. After two hours, there’s a fair bit of slurry and the rock has definitely changed.

[Michigan Rocks] moves on to polishing, which uses the same setup but with progressively-finer grinding pads in place of the cutting bits. This part is also really clever, because the DIY polishing pads are great hacks in and of themselves. They’re made from little more than PVC pipe end caps with hex bolts as shafts. The end caps are filled with epoxy and topped with a slightly concave surface of hook-and-loop fastener. By doing this, he can cut up larger fuzzy-backed polishing pads and stick the pieces to his drill-mounted holders as needed, all the way down to 6000 grit. He shows everything about the pads at the 11:55 mark, and it’s an approach worth keeping in mind.

What is the end result like? See for yourself, but we think [Michigan Rocks] sums it up when he says “I wish you could feel this thing, it feels so smooth. It’s so satisfying to roll around in your hands. I’m so happy I made this machine. This is awesome.”

We’ve seen machines for making wooden spheres but this one makes fantastic use of repurposed stuff like inexpensive cordless drills, and the sort of wood structures anyone with access to hand tools can make.

youtube.com/embed/FSE1GE1mz2k?…

Thanks to [AloofPenny] for the tip.

hackaday.com/2026/02/13/rock-s…

Many things about diamonds seem eternal, including the many engineering problems related to making them work as a silicon replacement in semiconductor technology. Yet much like a diamond exposed to a stream of oxygen-rich air and a roughly 750°C heat source, time will eventually erase all of them. As detailed in a recent [Asianometry] video, over the decades the challenges with creating diamond wafers and finding the right way to dope pure diamond have been slowly solved, even if some challenges still remain today.

Diamond is basically the exact opposite as silicon when it comes to suitability as a semiconductor material, with a large bandgap (5.5 eV vs the 1.2 of silicon), and excellent thermal conductivity characteristics. This means that diamond transistors are very reliable, albeit harder to switch, and heat produced during switching is rapidly carried away instead of risking a meltdown as with silicon semiconductors.

Unlike silicon, however, diamond is much harder to turn into wafers as you cannot simply melt graphite and draw perfectly crystallized diamond out of said molten puddle. The journey of getting to the state-of-the art soon-to-be-4″ wafers grown on iridium alongside the current mosaic method is a good indication of the complete pain in the neck that just this challenge already is.

Mosaic method of growing a diamond wafer, as filmed by Asianometry.
Doping with silicon semiconductors is done using ion implantation, but diamond has to be special and cannot just have phosphorus and boron implanted like its sibling. The main challenge here is that of availability of charge carriers from this doping, with diamond greedily hanging on to these charge carriers unless you run the transistor at very high temperatures.

Since you can only add so much dopant to a material before it stops being that material, a more subtle solution was sought. At this point we know that ion implantation causes damage to the diamond lattice, so delta-doping – which sandwiches heavily doped diamond between non-doped diamond – was developed instead. This got P-type transistors using boron, but only after we pacified dangling carbon electron bonds with hydrogen atoms and later more stable oxygen.

State-of-the art switching with diamond transistors is currently done with MESFETs, which are metal-semiconductor field-effect transistors, and research is ongoing to improve the design. Much like with silicon carbide it can take a while before all the engineering and production scaling issues have been worked out. It’s quite possible that we’ll see diamond integrated into silicon semiconductors as heatsinks long before that.

Assuming we can make diamond work for semiconductor transistors, it should allow us to pack more and smaller transistors together than even before, opening up many options that are not possible with silicon, especially in more hostile environments like space.

youtube.com/embed/NLmd5vL0zmk?…

hackaday.com/2026/02/13/why-di…

While it is fun to get toys that look like your favorite science fiction props, it is less fun when the electronics in them don’t measure up to the physical design. [Steve Gibbs] took a Hasbro R2D2 toy robot and decided to give it a brain upgrade along with enhanced sensors. You can see a video of the robot doing its thing and some build details below.

In this case, the toy from Hasbro was not working at all, so [Steve] saved it from the dumpster. Instead of a repair, he decided to just gut it and rebuild it with modern electronics. The ultrasonic sensor on the forward toe is a dead giveaway.

The robot responds to voice commands better than the original and can play sound effects and clips from Star Wars. You can also control the robot with a phone app. The new or upgraded sensors include microphones, a PIR sensor, a photoresistor to sense light, a smoke and CO₂ sensor, a computer vision camera, and, of course, the ultrasonic range finder.

Some motors and the original speaker are in use, but R2 now sports additional LEDs and servos. All the extras required some surgery on the plastic body. Instead of regular batteries, the ‘bot now uses a LiPo battery, so the old battery compartment was cut out to make more room.

Even if you aren’t a die-hard Star Wars fan, this is a fantastic project, and May the 4th is right around the corner. These toys aren’t cheap, but if you can score one with bad electronics, you might be able to find something cheap or — like Steve — even free.

These toys are popular hacking targets. Now [Steve] needs a pit droid.

youtube.com/embed/9G0J15jvJCM?…

hackaday.com/2026/02/13/r2d2-g…