It is easy to port C compilers to architectures that look like old minicomputers or bigger CPUs. However, as the authors of the Small Device C Compiler (SDCC) found, pushing C into a typical 8-bit CPU is challenging. Lessons learned from SDCC inspired a new 8-bit architecture, F8. This isn’t just a theoretical architecture. You can find an example Verilog implementation in the SDDC project and on GitHub. The name choice may turn out to be unfortunate as there was an F8 CPU from Fairchild back in the 1970s that apparently few people remember.

In the video from FOSDEM 2025, [Phillip Krause] provides a nice overview of the how and why of F8. While it might seem odd to create a new 8-bit CPU when you can get bigger CPUs for pennies, you have to consider that 8-bit machines are more than enough for many jobs, and if you can squeeze one into an FPGA, it might be a good choice as opposed to having to get a bigger FPGA to hold your design and a 32-bit CPU.

Many 8-bit computers struggle with efficient C code mainly because the data size is smaller than the width of a pointer. Doing things like adding two numbers takes more code, even in common situations. For example, suppose you have a pointer to an array, and each element of the array is four bytes wide. To find the address of the n’th element, you need to compute: element_n = base_address + (n *4). On, say, an 8086 with 16-bit pointers and many 16-bit instructions and addressing modes can do the calculation very succinctly.

Other problems you frequently run into with compiling code for small CPUs include segmented address spaces, dedicated registers for memory indexing, and difficulties putting wider items on a stack (or, for some very small CPUs, even having a stack, at all).

The wish list was to include stack-relative addressing, hardware 8-bit multiplication, and BCD support to help support an efficient printf implementation.

Keep in mind, it isn’t that you can’t compile C for strange 8-bit architectures. SDDC is proof that you can. The question is how efficient is the generated code. F8 provides features that facilitate efficient binaries for C programs.

We’ve seen other modern 8-bit CPUs use SDCC. Writing C code for the notorious PIC (with it’s banked memory, lack of stack, and other hardships) was truly a surreal experience.

It is easy to forget that many technology juggernauts weren’t always the only game in town. Ethernet seems ubiquitous today, but it had to fight past several competing standards. VHS and Blu-ray beat out their respective competitors. But what about USB? Sure, it was off to a rocky start in the beginning, but what was the real competition at that time? SCSI? Firewire? While those had plusses and minuses, neither were really in a position to fill the gap that USB would inhabit. But [Ernie Smith] remembers ACCESS.bus (or, sometimes, A.b) — what you might be using today if USB hadn’t taken over the world.

Back in the mid-1980s, there were several competing serial bus systems including Apple Desktop Bus and some other brand-specific things from companies like Commodore (the IEC bus) and Atari (SIO). The problem is that all of these things belong to one company. If you wanted to make, say, keyboards, this was terrible. Your Apple keyboard didn’t fit your Atari or your IBM computer. But there was a very robust serial protocol already in use — one you’ve probably used yourself. IIC or I2C (depending on who you ask).

I2C is robust, simple, and cheap to implement with reasonable licensing from Philips. It just needed a little tweaking to make it suitable for peripheral use, and that was the idea behind ACCESS.bus. [Ernie] tracked down a 1991 article that covered the technology and explained a good bit of the how and why. You can also find a comparison of A.b, I2C, and SMBus in this old datasheet. You can even find the 3.0 version of the spec online. While DEC was instrumental in the standard, some of their equipment used SERIAL.bus, which was identical except for using 12 V power and having a slightly different pinout.

The DEC Station 5000 was an early adopter of ACCESS.bus. From the user’s guide:

In theory, one ACCESS.bus port could handle 125 devices. It didn’t have a hub architecture like USB, but instead, you plugged one device into another. So your mouse plugs into your keyboard, which plugs into your printer, and finally connects to your PC.

The speed wasn’t that great — about 100 kilobits per second. So if ACCESS.bus had won, it would have needed to speed up when flash drives and the like became popular. However, ACCESS.bus does sort of live even today. Computer monitors that support DDC — that is, all of them in modern times — use a form of ACCESS.bus so the screen you are reading this on is using it right now so the monitor and PC can communicate things like refresh rates.

We love to read (and write) these deep dives into obscure tech. The Avatar Shark comes to mind. Or drives that used photographic film.

Last year, we saw [How To Make Everything’s] take on [DaVinci’s] machine for cutting threads. However, they stopped short of the goal, which was making accurate metal screw threads. After much experimentation, they have a working solution. In fact, they tried several different methods, each with varying degrees of success.

Some of the more unusual methods included heating a bar red hot and twisting it, and casting a screw out of bronze. The last actually worked well with a normal screw as the mold, although presumably, a good wood or wax shape would have resulted in a workable mold, too.

The real goal, though, was to make the DaVinci machine more capable on its own. The machine uses leadscrews and can cut its own leadscrews, so, in theory, if you improve the machine, it can cut better components for itself, which may make it possible to cut even better leadscrews.

The reality was the machine required some significant rework to correctly cut metal threads. But it does, as you can see in the video below. With some additional scaling of gears, they were able to cut a 20 TPI threaded rod that would take an off-the-shelf nut.

If you missed the original post on the machine, you can still go back and read it. Of course, once you have a threaded rod, you are just a few steps away from a tap, too.

How hard can it be to write a simple four-function calculator program? After all, computers are good at math, and making a calculator isn’t exactly blazing a new trail, right? But [Chad Nauseam] will tell you that it is harder than you probably think. His post starts with a screenshot of the iOS calculator app with a mildly complex equation. The app’s answer is wrong. Android’s calculator does better on the same problem.

What follows is a bit of a history lesson and a bit of a math lesson combined. As you might realize, the inherent problem with computers and math isn’t that they aren’t good at it. Floating point numbers have a finite precision and this leads to problems, especially when you do operations that combine large and small numbers together.

Indeed, any floating point representation has a bigger infinity of numbers that it can’t represent than those that it can. But the same is true of a calculator. Think about how many digits you are willing to type in, and how many digits you want out. All you want is for each of them to be correct, and that’s a much smaller set of numbers.

Google’s developer, [Hans-J. Boehm] tackled this problem by turning to recursive real arithmetic (RRA). Here, each math function is told how accurate it needs to be, and a set of rules determines the highest required accuracy.

But every solution brings a problem. With RRA, there is no way to tell very small numbers from zero. So computing “1-1” might give you “0.000000000”, which is correct but upsetting because of all the excess precision. You could try to test if “0.00000000” was equal to “0”, and simplify the output. But testing for equality of two numbers in RRA is not guaranteed to terminate: you can tell if two numbers are unequal by going to more and more precision until you find a difference, but if the numbers happen to be equal, this procedure never ends.

The key realization for [Boehm] and his collaborators was that you could use RRA only for cases where you deal with inexact numbers. Most of the time, the Android calculator deals with rationals. However, when an operation produces a potentially irrational result, it switches to RRA for the approximation, which works because no finite representation ever gets it exactly right. The result is a system that doesn’t show excess precision, but correctly displays all of the digits that it does show.

We really like [Chad’s] step-by-step explanation. If you would rather dive into the math, you can read [Boehm’s] paper on the topic. If you ever wonder how many computer systems handle odd functions like sine and cosine, read about CORDIC. Or, avoid all of this and stick to your slide rule.

[Paul] likes his piano, but he doesn’t know how to play it. The obvious answer: program an Arduino to do it. Some aluminum extrusion and solenoids later, and it was working. Well, perhaps not quite that easy — making music on a piano is more than just pushing the keys. You have to push multiple keys together and control the power behind each strike to make the music sound natural.

The project is massive since he chose to put solenoids over each key. Honestly, we might have been tempted to model ten fingers and move the solenoids around in two groups of five. True, the way it is, it can play things that would not be humanly possible, but ten solenoids, ten drivers, and two motors might have been a little easier and cheaper.

The results, however, speak for themselves. He did have one problem with the first play, though. The solenoids have a noticeable click when they actuate. The answer turned out to be orthodontic rubber bands installed on the solenoids. We aren’t sure we would have thought of that.

Player pianos, of course, are nothing new. And, yes, you can even make one with a 555. If a piano isn’t your thing, maybe try a xylophone instead.

As electronics rely more and more on ICs, subtle details about discrete components get lost because we spend less time designing with them. For example, a relay seems like a simple component, but selecting the contact material optimally has a lot of nuance that people often forget. Another case of this is the Miller effect, explained in a recent video by the aptly named [Old Hack EE].

Put simply, the Miller effect — found in 1919 by [John Milton Miller] — is the change in input impedance of an inverting amplifier due to the gain’s effect on the parasitic capacitance between the amplifier’s input and output terminals. The parasitic capacitance acts like there is an additional capacitor in parallel with the parasitic capacitance that is equivalent to the parasitic capacitance multiplied by the gain. Since capacitors in parallel add, the equation for the Miller capacitance is C-AC where C is the parasitic capacitance, and A is the voltage gain which is always negative, so you might prefer to think of this as C+|A|C.

The example uses tubes, but you get the same effect in any inverting amplification device, even if it is solid state or an op amp circuit. He does make some assumptions about capacitance due to things like tube sockets and wiring.

The effect can be very pronounced. For example, a chart in the video shows that if you had an amplifier with gain of -60 based around a tube, a 10 kΩ input impedance could support 2.5 MHz, in theory. But in practice, the Miller effect will reduce the usable frequency to only 81.5 kHz!

The last part of the video explains why you needed compensation for old op amps, and why modern op amps have compensation capacitors internally. It also shows cases where designs depend on the Miller effect and how the cascade amplifier architecture can negate the effect entirely.

This isn’t our first look at Miller capacitance. If you look at what’s inside a tube, it is a wonder there isn’t more parasitic capacitance.

We’ve seen a lot of interest in Meshtastic, the license-free mesh network for small amounts of data over the airwaves. [Ham Radio Rookie] was disappointed with his Meshtastic node’s small and inefficient antennas. So he decided to make what we suspect is the world’s first Meshtastic necktie.

We assume the power is low enough that having it across your thorax is probably not terrible. Probably. The tie is a product of a Cricut, Faraday cloth, and tiny hardware (the Xiao ESP32S3 and the WIO SX1262 board). The biggest problem was the RF connector, which needed something smaller than the normal BNC connector.

Of course, ideally, you’d like to have a very tiny battery. We can handle tying the knot, but you might prefer using a clip-on. Besides, then you could clip it to anything handy, too.

The tie antenna is probably going to outperform the rubber duckies. Still, we don’t expect it to get super long range. If you press a USB battery into service, you might find the low power electronics keep letting the battery shut off. There is an easy fix for this, but it will up your power consumption.

If you mention punch cards to most people, they’ll think of voting. If you mention it to most older computer people, they’ll think of punching programs for big computers on cards. But punched cards are much older than that, and [Nichole Misako Nomura] talks about how the original use was to run looms and knitting machines and — thanks the Internet Archive — you can still find old cards to drive modern machines.

According to the post, a dedicated group of people own old commercial knitting machines, and with some work, they can use archived punch cards with patterns that predate the computerized world. The Jacquard loom was famously the first machine to use cards like this, and it is no secret that they were the inspiration for Hollerith’s use of cards in the census, which would eventually lead to the use of cards for computing.

This is an interesting example of format issues. There are many card patterns stored on the Internet, but getting from a digital image to a workable card or even a set of instructions. But it is doable. You have to wonder if pulling old data off other, more modern media will be workable in the future.

If you want to relive (or try for the first time) keypunching, you can use your browser. The Jacquard loom may be ancient history, but it has many spiritual descendants.

You know the problem. You are ready to melt some metal in your microwave oven, and you don’t have any crucibles. Not to worry. [Shake the Future] will show you how to make your own. All you need is some silicon carbide, some water glass (sodium silicate), and some patience.

The crucible takes the shape of a glass container. Don’t get too attached to it because the glass will break during the crucible construction. You can also use 3D-printed forms.

You can shape the vessel before it cures and after. Then, you give it a heat treatment. [Shake The Future] also recommends you harden it at the end. This is optional; he tells you how to decide if you need it.

Hardening helps prevent cracking during use. The process involves wrapping the vessel in a ceramic sheet and heating it until the crucible turns red. The ceramic sheet is somewhat dangerous to work with because it has such tiny fibers and dust, so he only treats the crucibles when necessary.

We always enjoy watching [Shake] casting metal. He’s even done a Benchy.

The Free Software Foundation is holding an auction to celebrate its 40th anniversary. You can bid on the original sketch of the GNU head by [Etienne Suvasa] and [Richard Stallman’s] Internet Hall of Fame medal.

There are some other awards, including the FSF’s 1999 Norbert Wiener Award. There’s even a katana that symbolizes the fight for computer user freedom.

The FSF has done a lot of important work to shape the computing world as we know it. We hope this sale isn’t a sign that they are running out of money. Maybe they are just funding their birthday party in Boston.

If you use Linux (even if it is disguised as Android, a Raspberry Pi OS, or hiding on a web server you use), you can thank the FSF. While we commonly call them “Linux systems,” Linux is just the kernel. Most of the other things you use are based on either GNU-sponsored code or builds on that GNU-sponsored code. If you want to know more about the history of the organization, you can catch [ForrestKnight’s] video below.

Without the GNU tools and the Linux kernel, you have to wonder what our computers would look like. While [Richard Stallman] is a sometimes controversial figure, you can’t argue that the FSF has had a positive impact on our computers. Maybe we’d all be on BSD. It is worth noting that the FSF even certifies hardware.

We were surprised when we read a post from C++ creator [Bjarne Stroustrup] that reminded us that C++ is 45 years old. His premise is that C++ is robust and flexible and by following some key precepts, you can avoid problems.

We don’t disagree, but C++ is much like its progenitor, C, in that it doesn’t really force you to color inside the lines. We like that, though. But it does mean that people will go off and do things the way they want to do it, for any of a number of good and bad reasons.

We will admit it. We are probably some of the worst offenders. It often seems like we use C++ the way we learned it several decades ago and don’t readily adopt new features like auto variables and overly fancy containers and templates.

He proposes guidelines, including the sensible “Don’t subscript pointers.” Yet, we are pretty sure we will, eventually. Even if you are going to, also, it is still worth a read to see what you ought to be doing. We were hoping for more predictions in the section entitled “The Future.” Unfortunately — unlike Hackaday authors — he is much too smart to fall for that trap, so that section is pretty short. He does talk about some of the directions for the ISO standards committee, though.

We should have known about the 45 years, as we covered the 30th birthday. We like safer code, but we disagree with the idea that C++ is unsafe at any speed.

Photograph by [Victor Azvyalov] CC-BY-SA-2.0.

With so many cheap oscilloscopes out there, the market for old units isn’t what it used to be. But if you have a really old scope, like the Heathkit O-10 that [Ken] found in his basement, there is vintage cred to having one. [Ken’s] didn’t work, so a repair session ensued. You can see the results in the video below.

You can tell this is in an old scope — probably from the mid 1950s — because of its round tube with no graticle. Like many period scopes, the test probe input was just 5-way binding posts. The O-10 was the first Heathkit “O-series” scope that used printed circuit boards.

The device looked pretty good inside, except for a few dents. Of course, the box has tubes in it, so every power up test involves waiting for the tubes to warm up. [Ken] was very excited when he finally got a single green dot on the screen. That did, however, require a new CRT.

It wasn’t long after that he was able to put a waveform in and the scope did a good job of reproducing it. The unit would look good in an old movie, but might not be the most practical bench instrument these days.

These Heathkit scopes and their cousins were very popular in their day. The $70 price tag sounds cheap, but in the mid-1950s, that was about a month’s rent in a four-room house. While primitive by today’s standards, scopes had come a long way in 9 or 10 years.

It seems obvious once you think about it, but if you can spin your cell phone and coordinate the display with the motion, you can create a 3D display. [Action Lab] had used such a setup to make a display that you could view from any angle. After he showed it, a viewer wrote him to mention that if you spin the picture at the same rate, it will appear in 3D. The results look great, as you can see in the video below.

The spinning mechanism in this case is an inexpensive pottery wheel. Whatever you use, though, you need a way to match the speed of the graphics to the speed of the phone’s rotation. For this example, there are just a few pre-spun 3D models on a website. However, creating your own viewer like this wouldn’t be that hard. Even more interesting would be to read the phone sensors and spin the image in sync with the phone’s motion.

We keep hearing about awesome commercial 3D stuff coming out “any day now.” Meanwhile, you can always settle for Pepper’s Cone.

Graphene always sounds exciting, although we aren’t sure what we want to do with it. One of the most promising features of the monolayer carbon structure is that under the right conditions, it can superconduct, and some research into how that works could have big impacts on practical superconductor technology.

Past experiments have shown that very cold stacks of graphene (two or three sheets) can superconduct if the sheets are at very particular angles, but no one really understands why. A researcher at Northeaster and another at Harvard realized they were both confused about the possible mechanism. Together, they have started progressing toward a better description of superconductivity in graphene.

Part of the problem has been that it is hard to make large pieces of multi-layer graphene. By creating two-ply pieces and using special techniques, an international team is finding that quantum geometry explains how graphene superconductors resist changes in current flow more readily than conventional superconductors.

Another team found that adding another layer makes the material behave more like a family of conventional higher-temperature superconductors. The research appears in two different papers. One covers the two-ply material. The other talks about the material with three layers.

Making little bits of graphene isn’t hard. Making it in quantity is a different story. We keep dreaming of what we could do with a room-temperature superconductor.

The crux of most supercomputers is the ability to operate on many pieces of data at once — something video cards are good at, too. Enter T1 (short for Torrent-1), a RISC-V vector inspired by the Cray X1 vector machine.

T1 has support for features, including lanes and chaining. The chip contains a version of the Rocket Core for scalar operations, but there’s no official support for using it. The project claims you could easily replace that core with any other RISC-V CPU IP.

By focusing on parallelism instead of out of order execution, the design gets to skip branch prediction, register renaming, and similar problems.

There is an emulator if you want to experiment. You can even grab a docker image for easy installation. This doesn’t look like something you could pick up in an hour, so prepare to spend some time. Everything is bare-metal, too, so leave your favorite development tools at home.

The project uses Chisel, which we’ve covered before. The build system seems very complex, but based on Nix Flakes, so it should be understandable.

If your high-performance RISC-V dreams are more conventional, there’s work going on in that area, too.

Title graphic from Freepik.

We may have found the killer app for AI. Well, actually, British telecom provider O2 has. As The Guardian reports, they have an AI chatbot that acts like a 78-year-old grandmother and receives phone calls. Of course, since the grandmother—Daisy, by name—doesn’t get any real phone calls, anyone calling that number is probably a scammer. Daisy’s specialty? Keeping them tied up on the phone.

While this might just seem like a prank for revenge, it is actually more than that. Scamming people is a numbers game. Most people won’t bite. So, to be successful, scammers have to make lots of calls. Daisy can keep one tied up for around 40 minutes or more.

You can see some of Daisy’s antics in the video below. Or listen to Daisy do her thing in the second video. When a bogus tech support agent tried to direct Daisy to the Play Store, she replied, “Did you say pastry?” Some of them became quite flustered. She even has her own homepage.

While we have mixed feelings about some AI applications, this is one we think everyone can get onboard with. Well, everyone but the scammers.

It might not do voice, but you can play with local AI models easily now. Spoofing scammers is the perfect job for the worst summer intern ever.

While we aren’t heavy-duty woodworkers, we occasionally make some sawdust as part of a project, and we admire people who know how to make wood and do what they want. We were surprised when [Newton Makes] showed a wooden dowel that was quite long and was mostly hollow. The wall was thin, the hole was perfectly centered, and he claimed he did not use a drill to produce it. Check it out in the video below and see what you think.

We don’t want to spoil the surprise, but we can tell you that making something that long with a drill or even a drill press would be very difficult. The problem is that drills have runout — the bits are usually not totally centered, so the bit doesn’t spin like you think it does. Instead, it spins and rotates around a small circle.

At the chuck, that small circle isn’t a big deal. But the further you get from the chuck, the bigger the runout circle gets. So a 10 cm long drill bit won’t amplify the runout much, but a 100 cm bit will make more of a cone shape unless the drill press is very accurate.

Take your guess, go watch the video, then come back and tell us if you guessed correctly. We didn’t. If you want to get better at woodworking, we can help. If you get really good, you can bend wood to your will.

The invention of the computer is a tricky thing to pinpoint. There were some early attempts that were not well known and some early attempts that were deliberately secret. [Alan Turing]’s efforts with Colossus were top secret for years, and while that work built on earlier efforts in Poland, [Turing] has as much claim to be the father of computers as anyone. But [Jack Copland] points out in a recent post that the famous computer scientist was also involved in another secret project: Delilah.

While [Turing] is best known for his work breaking ciphers at Bletchley Park, he also put time in on a second project about ten miles away in a secret electronics lab at Hanslope Park. There he worked with an assistant, [Donald Bayley] on Delilah — a portable system for encrypting voice transmissions.

The keyword is “portable.” In 1942, Bell Labs created SIGSALY for the U.S. Army to encrypt voice. It took up an entire room and weighed about 25 metric tons. [Turing] found a way to get the job done in a box that, including power, weighed in at 39 kilograms — not a cellphone, but portable in a truck. For comparison, an SCR-300 (the backpack radio used in the war, carried by “the lucky soldier”) weighed about 17 kilos with a full-sized battery.

The machine worked by generating a pseudo-random number sequence, synchronized with a similar unit on the other end of the transmission. Voice input was converted to digital, the numbers added on one end were transmitted, and the same numbers were subtracted from the other end. The result was not perfect for a number of reasons, but you could understand it, reportedly. But with the end of the war, interest in voice encryption wore off, and [Turing] and [Bayley] went on to other projects.

Luckily, [Bayley] saved his papers, which were auctioned off after his death for nearly half a million dollars. Without those papers, we wouldn’t know much about Delilah outside of a previously classified report (paywalled) and a few other notes.

The British National Museum of Computing rebuilt the device back in 2024, and you can see a video about it below. You can also see an interview in the video below with [Turing’s] nephew that mentions Delilah at the very end.

Title photo from The National Archives, London.

It isn’t that hard to make an electronic rain gauge if you have a steady source of power or you don’t mind changing batteries often. But [Matthew Ford] offers a third option: a simple device with a Bluetooth Low Energy (BLE) module that can get a few years of a pair of AA batteries.

The approach has several advantages. Batteries make the device self-contained, and changing them infrequently is an obvious win. In addition, the BLE allows the device to be wireless and send data directly to an Android device. Thanks to a WH-SP-RG rain gauge, there’s not much to that part. The smart part is an nRF52832 module and some minor parts. The phone side uses an off-the-shelf Android app.

In a project like this, it is critical to have timers that really put the CPU to sleep. [Matthew] had to modify the Arduino libraries to allow the lp_timer objects to make it to an hour. Without the modifications, the timer can only reach 8.5 minutes. Sure, you could stack them, but that means taking a power hit multiple times an hour which would affect battery life.

Not the most complex project, but more complexity would mean lower battery life, so — as they say — less is more. We couldn’t help but think that with rechargeable batteries and a small solar panel, this could last a very long time.

LoRa, of course, is another choice. You can make 3D print a tipping bucket device, too.