Yesterday’s Technology, Re-engineered Today

July 4, 2026 by Elliot Williams 12 Comments

Watching [sprite_tm]’s build of a handheld 486-based gaming computer, we got to thinking about retro computers and the eternal questions of how much of the computer needs to be actually “old” for it it be retro. Where is the soul of a retro computer? The CPU? The old yellowing plastic case? Maybe it depends on what you’re trying to get out of the hobby.

There is of course a spectrum of people playing around with old computers. For some people, let’s call them “vintage computer enthusiasts”, half of the fun is in keeping the actual old hardware running. This group tends to know what teletype lubricant smells like, and how to tell which capacitors need replacing.

For others, “team retro”, the joy is in using the machine itself, whether that be teaching the old dogs new tricks, or simply loading up nostalgic video games. Team retro is more content with emulations or emulations that are wrapped up neatly in hardware workalikes. They know which registers need POKEing, and whether or not Commander Keen is running at the right framerate.

I think [sprite_tm]’s project falls in with yet another camp, the retro-reengineers. Here, the idea is to step through the engineering lessons of the past by re-designing something from a bygone era. So when [sprite_tm] went with a period 486 CPU backed up by a modern FPGA, perhaps ironically borrowing code from the modern MiSTer project, it makes sense for his goals. Retro-reengineers know the bus architecture and the memory timings, and they are reinventing the wheel as a learning experience. Or in the case of [Voja Antonic]’s imaginary four-bit machine, it’s a teaching experience.

How you work often reflects what you’d like to get out of the project, and at Hackaday, of course, we love all of the above! We’ve identified at least three broad schools of fooling around with old computers. Are we missing any?

Hacking Routers Like It’s 2008

June 27, 2026 by Elliot Williams 19 Comments

How long have we been hacking routers? To some of you who’ve been in the Hackaday audience for a while, the answer is “nearly forever”. In the early 2000s, they were one of the few consumer gadgets that had the trifecta of hackability: WiFi and networking built in, a user-friendly Linux operating system, and a few spare GPIOs that could control from the OS. Back when the Linksys WRT54GL was the king of the hill, we saw some pretty absurd hacks.

Take this example robot from October 2008. Link-rot hasn’t been kind to the original project, but from what we can tell, it used the GPIOs to drive servo motors hacked for continuous rotation, and features the equally anachronistic CD-ROM wheels. Where would you even get those today?

But the OS that this 18-year-old hack uses is still around: OpenWRT Linux. Although it still takes its name from the lovable purple router of old, it hasn’t supported that particular model in over a decade because of growing memory requirements. But it’s still the go-to distro for any modern router hacks, and it provides a lot more general-purpose Linux than you might expect on otherwise constrained platforms. As Tom pointed out in the podcast, if you see a used router for cheap, see if it’s supported by OpenWRT, and if it is, buy it.

While the project that got us thinking about routers again, Al’s recent networking hack, basically uses the router as a souped-up router, that’s by no means a given. OpenWRT is a real Linux OS, and can make use of most peripherals that your router find has available. Networking? Of course. USB? No problem. If you find a serial port and some GPIOs, you’re most of the way to a Linux SBC, although very likely a headless one.

There are a lot of hacks we see go in and out of style, and we see software projects come and go. But here we tip our hat to the router hacks, and to the plucky Linux OS that’s been ported to them all. Long may it keep old devices out of the landfill!

Featured image: My old baby, about a year or so before something in the radio modem finally gave up the ghost.

Home Automation: Simple Vs Easy

June 20, 2026 by Elliot Williams 39 Comments

We’ve been talking a bunch of home automation on the Podcast lately, and this week, in the Mailbag segment, a reader asked us about our setups. Neither Kristina nor I are poster children for the home automation movement: she has absolutely no smart anything because she didn’t want her data up in “the cloud”, and I have an entirely local system that’s really nothing more than a bunch of ad-hoc scripts that talk to an MQTT broker, everything fully DIY but held together with metaphorical duct tape. Neither of us are doing it right, but we’re doing it wrong in interestingly different ways.

Kristina thought, probably because of the range of commercial devices out there that tie you into using their remote data storage services, that giving up control of her data was necessary to use it. And it might be, if you insist that setting up the system be as easy as possible. But the tradeoff for this ease is a drastic reduction in simplicity. You shouldn’t need a remote server in some foreign country to turn your lights on and off. Adding “the cloud” into the mix brings a lot of complexity, mostly in the form of servers that have to be paid for somehow by whatever company is providing the service. It needs to be secure. You might even have to create accounts, remember passwords, and manage that whole deal. Sure, that’s easy enough, but it’s a lot of moving parts, and you can’t blame her for rejecting that complexity.

My system is hosted on a now-ancient OrangePi in the corner, and the network in question is an old WiFi router that it sits on. Nothing needs to leave my four walls, but actually some of it does – I bridge some of the MQTT topics out to an external server for my own amusement. There is no protocol, and no real “system” frankly. Each device in the network has its own topic, and I’m responsible for knowing what it means. The thermometer in the basement has an ESP8266 that transmits on the home/basement/temperature topic, and it puts out its temperature in degrees Celsius. It was the simplest system I could think of, but I have to write whatever software I want to log, display, or act on the data. Of course, that’s simple if you can write some four-liner scripts on the OrangePi broker, but it’s not easy enough that my wife wants to hack on it.

So if the full-buy-in commercial systems are easy but overly complex, and my DIY network is transparently simple but requires a level of hands-on that isn’t easy for “normies”, is there a middle ground? I know half of you are already screaming Home Assistant or Domoticz, and you’re also thinking of which client device libraries you like the most for all your DIY applications: ESPHome vs Tasmota, for instance. And you’re all right!

We are living the in the golden age of the home automation projects. Open-source software and firmware, combined with an abundance of online tutorials and worked examples, have made huge strides toward bridging the gap between simplicity and ease of use. You can set up a hub for everything on a single-board computer, upload the software of your choice, and you don’t need the complexity or loss-of-support liability of a cloud provider. At the same time, setup is easy enough if you’re willing to roll up your sleeves a little bit, and when it’s not, chances are good that someone else has already figured it out for you. These days, interoperability with popular commercial products is shockingly easy to boot.

I need to spend some time and rationalize my system: given the state of the art, it’s simply too simple, and taking a step into an open-source solution would make it easier to use for the rest of the family, without overly complexifying things, adding sketchy dependencies, or losing our data sovereignty. I haven’t finished exploring my options yet, but from what I can see, the community has converged on some goldilocks setups: not too simple or too easy, but rather just right. Thanks, y’all!

Patterns Everywhere

June 13, 2026 by Elliot Williams 23 Comments

I studied physics in college, and I’m always surprised how fundamental some of the concepts are. Take waves for example. You really wouldn’t expect the same underlying concept to be at work on surface of a pond, the string of a guitar, light passing through two slits, and then in the probabilistic behavior of electrons orbiting inside nuclei. But here we are, in a world filled with wave-like phenomena.

What little control theory I know, I’ve learned in the school of hard knocks. But it’s equally amazing that the same basic concepts govern the tuning of car shock absorbers, PID controllers, active audio filters, and other more complex systems where feedback matters. Crucial in all of these systems is the judicious balance of amplification and damping.

And last week on vacation, learning to drive a covered wagon pulled by a heavy draft horse, I saw the same patterns again. The horse likes to pull, and when the wagon comes over the crest of the top of a hill, it starts to roll forward into his harness, pushing him from behind. This makes the horse uneasy, and he slows down, the wagon pushes him harder, and positive feedback gets out of control.

The man who was teaching me to drive the wagon said, “it’s not like a car” in that you don’t tap the brakes to slow down and then let go. Rather, you hold on the brakes for a lot longer than you think is necessary – until the horse tells you that he feels like pulling again – and then you let up only a tiny bit at a time. Otherwise, you end up in the under-damped case, where you let the wagon go too much, it slows the horse, you slam the brakes, the horse pulls hard, and you let up on the brakes, and the cycle continues anew.

What he meant by “not like a car” was that the brakes aren’t just slowing down the wagon, they’re adding damping to keep the horse-wagon system from oscillating. Once that clicked in my mind, everything was smooth sailing. After a couple of days, I even started adding some feed-forward to my mental PID controller, letting the brakes go a little bit more when the horse was approaching the bottom of a hill, and he obviously wanted to pick up a little more speed before the grade ahead.

The horse seemed happy that I was finally getting it, but I don’t think he had any understanding of tuning PID loops. He did have me pondering, on a long stretch of rolling hills on a summer morning, if there were a good minimal set of patterns that explained a maximal breadth of phenomena. I’m starting with the physics of waves and the control of feedback systems, but what’s next?

Copy Or Redesign?

May 9, 2026 by Elliot Williams 5 Comments

We got asked a great question in the mailbag segment on the Podcast this week: are there hacks that we have read about on Hackaday that we use in our everyday life? The answer was absolutely yes, and I loved Tom’s take it often goes the other way – he sees a hack, tests it out, and then writes it up.

But I started looking around the office and I found more examples of projects that were absolutely inspired by projects I had seen on Hackaday, yet weren’t the same. I made a DIY mechanical keyboard because I saw someone else do it. There are a few home-made battery packs that I probably wouldn’t have attempted without having read about someone doing the same thing. I riffed on [Ted Yapo]’s Tritiled project, making a slightly inferior, but workable knockoff, and they’ve been glowing for many years now.

That got me to thinking about reproducing a project versus taking inspiration from it, and though I enjoy both, I’m find myself most often in the “inspiration” mode. I just can’t leave well enough alone, even when I’m fundamentally copying someone. NIH syndrome? Expediency? Probably both, and sometimes with a dose of hubris or feature creep.

Looking back at [Ted]’s TritiLED, though, I found some great examples in both the rebuild and redesign modes on Hackaday.io. [schlion]’s Making Ted Yapo’s TritiLED couldn’t be a clearer example of the former, and it’s great to look over his shoulder and appreciate all the lessons he learned along the way. [Stephan Walter]’s Yet another ultra low power LED is inspired by [Christoph Tack]’s Ultra low power LED, which is in turn inspired by [Ted]’s project, like a conceptual grandchild.

In a way, I look at this like with music: sometimes you play the notes the way they were written down, and sometimes you riff on someone else’s theme. Both are equally valid, and both owe a debt to the upstream source. Is Hackaday the hackers’ jazz club? And which of these modes do you find yourself working in most?

Peripherals Hacks

May 2, 2026 by Elliot Williams 10 Comments

Custom peripheral projects are among the most rewarding. Especially if you’re like me and you sit at the computer eight hours per day, anything that you can use on a daily basis is super satisfying. This topic of DIY peripherals came up on the podcast while chatting with Kristina, who is no stranger to odd inputs herself.

We were talking about a trackball that had been modified to read twisting gestures, by a clever hijacking of the twin mouse sensors inside. If you do a lot of 3D modeling, you can absolutely get by with just a mouse and shift-ctrl-alt as modifiers, but it’s so much more immediate to use a dedicated 3D input device. (I’ve got an ancient serial Space Mouse just under my left hand as I type this.)

My old favorite, which I haven’t used in ages, is the guts of a 5” hard-drive platter stack that I turned into a scroll wheel. Unfortunately, I don’t have space for it on my desk anymore, but it was just so pleasing to scroll through a document with something that had some real chonky momentum to it.

And it’s easier than ever to make your own. The classic blocky macropad is a great introduction, but as long as you’re doing the design yourself, why not extend it, or at least make it fit your hand? Or take your flights of fancy even further away from the mainstream. Consider the Bluetooth mouse ring, for instance.

Point is, the software side of almost any peripheral device you can imagine is sorted out already, and interfacing with the hardware is equally simple. Peripheral hacks have such a low barrier to entry, but afford so many creative hardware possibilities. And nothing says “Jedi” like building your own lightsaber.

Tool Embodiment And The Dead Trackball

April 18, 2026 by Elliot Williams 42 Comments

There is a currently ongoing debate in the neuropsychology world about how we relate to the tools that we use. The theory of “tool embodiment” says that when we use some tools frequently enough, our brain recognizes them similarly to how it recognizes our own hands, for instance. There is evidence and counter-evidence from experiments with prosthetics, trash-grabber arms, and rubber dummy arms, just to name a few. It’s fair to say the jury is still out.

All I know is that today my trackball broke, and using a normal gaming mouse to edit the podcast was torture. It would be an exaggeration to say that I felt like I’d lost a hand, but I have so much motor memory apparently built up in my use of the trackball that switching over to another tool to undertake the exact same series of hundreds of small audio edits – mostly compensating for the audio delay across continents, but also silencing coughs and background noises – took an extra hour.

Anyone who has switched from one keyboard to another, or heck even from emacs to vim, knows what I experienced. My body just knows how to flick my wrist to make the cursor on the screen move over to the beginning of that “umm”. It’s not like I don’t conceptually know how to use a mouse either, and it does exactly the same job. But the mouse wasn’t my tool for this application. And saying that out loud makes it almost sound like I’m bordering on embodying my trackball.

I probably should have taken the trackball apart and replaced the bad tact switch on the left-click – that would have taken maybe twenty minutes – but I completely underestimated how integral the tool had become to the work. Anyway, as I write this, tomorrow is Saturday and I’ll have time to fix it. But today, I learned something pretty neat about myself in the process, even if I don’t think my single datapoint is going to rock the academic psych world.