Retrocomputing: Simulacrum Or The Real Deal?

December 20, 2025 by Elliot Williams 35 Comments

The holidays are rapidly approaching, and you probably already have a topic or two to argue with your family about. But what about with your hacker friends? We came upon an old favorite the other day: whether it “counts” as retrocomputing if you’re running a simulated version of the system or if it “needs” to run on old iron.

This lovely C64esque laptop sparked the controversy. It’s an absolute looker, with a custom keyboard and a retro-reimagining-period-correct flaptop design, but the beauty is only skin deep: the guts are a Raspberry Pi 5 running VICE. An emulator! Horrors!

We’ll admit to being entirely torn. There’s something about the old computers that’s very nice to lay hands on, and we just don’t get the same feels from an emulator running on our desktop. But a physical reproduction like with many of the modern C64 recreations, or [Oscar Vermeulen]’s PiDP-8/I really floats our boat in a way that an in-the-browser emulation experience simply doesn’t.

Another example was the Voja 4, the Supercon 2022 badge based on a CPU that never existed. It’s not literally retro, because [Voja Antonics] designed it during the COVID quarantines, so there’s no “old iron” at all. Worse, it’s emulated; the whole thing exists as a virtual machine inside the onboard PIC.

But we’d argue that this badge brought more people something very much like the authentic PDP-8 experience, or whatever. We saw people teaching themselves to do something functional in an imaginary 4-bit machine language over a weekend, and we know folks who’ve kept at it in the intervening years. Part of the appeal was that it reflected nearly everything about the machine state in myriad blinking lights. Or rather, it reflected the VM running on the PIC, because remember, it’s all just a trick.

So we’ll fittingly close this newsletter with a holiday message of peace to the two retrocomputing camps: Maybe you’re both right. Maybe the physical device and its human interfaces do matter – emulation sucks – but maybe it’s not entirely relevant what’s on the inside of the box if the outside is convincing enough. After all, if we hadn’t done [Kevin Noki] dirty by showing the insides of his C64 laptop, maybe nobody would ever have known.

How Do The Normal People Survive?

October 4, 2025 by Elliot Williams 115 Comments

It was one of those weeks last week at Hackaday’s home office. My mother-in-law handed me her favorite power bank and said “it’s not charging”. She had every expectation that I’ll open it up, desolder the weary pouch inside, scrounge a LiPo out of some corner of the basement, and have it back up and running before the weekend. And of course that’s what happened, although maybe it looks a little worse for wear because it was hard to open the sealed case without excessive force. Sorry about that!

Then on the weekend, I finally got fed up with the decomposing foam on the face seal on my FPV goggles. It was leaking light all over the place. Of course I could have bought a new seal, but then I’d have to wait a week or so for delivery. So I pulled the velcro backing off, tossed it in the bed scanner, pulled the image up in Inkscape, converted it to Gcode, and cut out a couple seals out of EVA foam on the laser. Not only are they essentially indestructible, but I was able to customize them a little bit, and the fit is now better than ever.

And then, one of our neighbors bought a new garage door fob, flipped the DIP switches into the right configuration, and couldn’t figure out why it wouldn’t open the garage door. Knock knock knock. Using the tried-and-true RF probe that everyone with a scope probe has sitting around, namely hooking the ground pin to the tip and putting the radio device in the loop, it was clear that the sense of the DIP switches was inverted from what it said in the instructions. That was a fun little puzzle.

It was the garage door opener that triggered me to think about how normal people would handle any of these situations. “How do the normies even get by?” were the exact words that went through my head. And let’s face it: we’re not entirely normal. Normal people don’t have a soldering setup just sitting around ready to get hot 24/7, or a scope to diagnose a garage door RF transmitter at the drop of a hat. But these things seem to happen to me all the time. How do the normal people survive? Maybe they all know someone with a scope?

I take it as my service to the world to be “that guy” for most of our friends and family, and I pretty much do it without complaint. “With great power” and all that. My wife is just about as gracious when she’s stuck debugging a parent’s Windows setup, so I’m not saying I’m the only saint in the world, either. Surely you have similar stories.

But last week it made me reflect on how good we’ve got it, and that does make me want to pay it forward a little bit. If you’re one of the people who can, try to help out those who can’t.

Version Control To The Max

May 14, 2025 by Al Williams 42 Comments

There was a time when version control was an exotic idea. Today, things like Git and a handful of other tools allow developers to easily rewind the clock or work on different versions of the same thing with very little effort. I’m here to encourage you not only to use version control but also to go even a step further, at least for important projects.

My First Job

The QDP-100 with — count ’em — two 8″ floppies (from an ad in Byte magazine)

I remember my first real job back in the early 1980s. We made a particular type of sensor that had a 6805 CPU onboard and, of course, had firmware. We did all the development on physically big CP/M machines with the improbable name of Quasar QDP-100s. No, not that Quasar. We’d generate a hex file, burn an EPROM, test, and eventually, the code would make it out in the field.

Of course, you always have to make changes. You might send a technician out with a tube full of EPROMs or, in an emergency, we’d buy the EPROMs space on a Greyhound bus. Nothing like today.

I was just getting started, and the guy who wrote the code for those sensors wasn’t much older than me. One day, we got a report that something was misbehaving out in the field. I asked him how we knew what version of the code was on the sensor. The blank look I got back worried me. Continue reading “Version Control To The Max” →

Physical Computing Used To Be A Thing

March 8, 2025 by Elliot Williams 71 Comments

In the early 2000s, the idea that you could write programs on microcontrollers that did things in the physical world, like run motors or light up LEDs, was kind of new. At the time, most people thought of coding as stuff that stayed on the screen, or in cyberspace. This idea of writing code for physical gadgets was uncommon enough that it had a buzzword of its own: “physical computing”.

You never hear much about “physical computing” these days, but that’s not because the concept went away. Rather, it’s probably because it’s almost become the norm. I realized this as Tom Nardi and I were talking on the podcast about a number of apparently different trends that all point in the same direction.

We started off talking about the early days of the Arduino revolution. Sure, folks have been building hobby projects with microcontrollers built in before Arduino, but the combination of a standardized board, a wide-ranging software library, and abundant examples to learn from brought embedded programming to a much wider audience. And particularly, it brought this to an audience of beginners who were not only blinking an LED for the first time, but maybe even taking their first steps into coding. For many, the Arduino hello world was their coding hello world as well. These folks are “physical computing” natives.

Now, it’s to the point that when Arya goes to visit FOSDEM, an open-source software convention, there is hardware everywhere. Why? Because many successful software projects support open hardware, and many others run on it. People port their favorite programming languages to microcontroller platforms, and as they become more powerful, the lines between the “big” computers and the “micro” ones starts to blur.

And I think this is awesome. For one, it’s somehow more rewarding, when you’re just starting to learn to code, to see the letters you type cause something in the physical world to happen, even if it’s just blinking an LED. At the same time, everything has a microcontroller in it these days, and hacking on these devices is also another flavor of physical computing – there’s code in everything that you might think of as hardware. And with open licenses, everything being under version control, and more openness in open hardware than we’ve ever seen before, the open-source hardware world reflects the open-source software ethos.

Are we getting past the point where the hardware / software distinction is even worth making? And was “physical computing” just the buzzword for the final stages of blurring out those lines?

Multitasker Or Many Monotaskers?

February 22, 2025 by Elliot Williams 21 Comments

In Al Williams’s marvelous rant he points out a number of the problems with speaking to computers. Obvious problems with voice control include things like multiple people talking over each other, discerning commands from background conversations, and so on. Somehow, unlike on the bridge in Star Trek, where the computer seems to understand everyone just fine, Al sometimes can’t even get the darn thing to play his going-to-sleep playlist, which should be well within the device’s capabilities.

In the comments, [rclark] suggests making a single button that plays his playlist, no voice interaction required, and we have to admit that it’s a great solution to this one particular problem. Heck, the “bedtime button” would make fun project in and of itself, and it’s such a limited scope that it could probably only be an weekend’s work for anyone who has touched the internals of their home automation system, like Al certainly has. We love the simplicity of the idea.

But it ignores the biggest potential benefit of a voice control system: that it’s a one-size-fits-all solution for everything. Imagine how many other use cases Al would need to make a single button device for, and how many coin cell batteries he’d be signing himself up to change out over the course of the year. The trade-off is that the general purpose solution tends not to be as robust as a single-tasker like the button, but also that it can potentially simplify the overall system.

I suffer this in my own home. It’s much more a loosely-coupled web of individual hacks than an overall system, and that has pros and cons. Each individual part is easier to maintain and hack on, but the overall system is less coordinated than it could be. If we change the WiFi password on the home automation router, for instance, I’m going to have to individually log into about eight ESP8266s and change their credentials. Yuck!

It’s probably a matter of preference, but I’ll still take the loose, MQTT-based system that I’ve got now over an all-in-one. Like [rclark], I value individual device simplicity and reliability above the overall system’s simplicity, but because our stereo isn’t even hooked up to the network, I can’t play myself to sleep like Al can. Or at least like he can when the voice recognition is working.

A Guide To Making The Right Microcontroller Choice

February 14, 2025 by Dan Maloney 50 Comments

Starting a new microcontroller project can be pretty daunting. While you have at least a rough idea of where you want to end up, there are so many ways to get there that you can get locked into “analysis paralysis” and never get the project off the ground. Or arguably worse, you just throw whatever dev board you have in the junk bin and deal with the consequences.

While it’s hard to go wrong with relying on a familiar MCU and toolchain, [lcamtuf] argues in this recent guide to choosing microcontrollers that it’s actually not too much of a chore to make the right choice. Breaking the microcontroller universe down into three broad categories makes the job a little easier: simple process control, computationally intensive tasks, and IoT products. Figuring out where your project falls on that spectrum narrows your choices considerably.

For example, if you just need to read some sensors and run a few servos or solenoids, using something like a Raspberry Pi is probably overkill. On the other hand, a Pi or other SBC might be fine for something that you need wireless connectivity. We also appreciate that [lcamtuf] acknowledges that intangible considerations sometimes factor in, such as favoring a new-to-you MCU because you’ll get experience with technology you haven’t used before. It might not override technical considerations by itself, but you can’t ignore the need to stretch your wings once in a while.

There’s nothing earth-shattering here, but we enjoy think pieces like this. It’s a bit like [lcamtuf]’s recent piece on rethinking your jellybean op-amps.