Powering Up A Pluggable Module From The 1948 IBM 604 Electronic Calculator

June 8, 2026 by No comments

In that awkward transition phase between electromechanical accounting systems used in the 1940s and the introduction of fully digital computers we find systems such as the IBM 604 Electronic Calculator, advertised for accounting, calculating and engineering tasks. While not capable of complex instructions, loops and other advanced features, it did use an interesting modular architecture with easily swappable modules containing a vacuum tube and associated components. Recently [Ken Shirriff] took a poke at one of these and even powered it up.

This kind of pluggable system would become a staple of computer systems, as they enabled the use of modules or cards with specific functions that could be swapped and combined at will to increase system flexibility, lower costs and make repairs a snap. For the IBM 604 a total of about 1250 vacuum tubes were used, apparently all of which were found on these pluggable modules.

The module that [Ken] got his hands on has a thyratron tube, which is effectively a high current switch and rectifier. In the short demonstration video you can see it being used to switch a lamp on and off, with further details explained in the article.

Despite being rather limited in its functionality and limited by the punch card input and output speed, the IBM 604 was still a smashing commercial success with over 5600 units produced. A transistorized prototype version with 2200 transistors and 95% less power usage was created in 1954 that formed the basis for the IBM 608, the world’s first commercial all-transistorized calculator.

The 608 didn’t last too long, however, as at that point the breakneck pace of semiconductor technology meant that any newly released product was already obsolete by the time it hit the market. Despite this, fundamentals like pluggable modules would keep showing up over and over, ranging from the 1950s Bendix G-15 to even modern day systems, including PCs with pluggable RAM and expansion cards as well as mainframes where hot swapping of even entire CPU modules is just another feature.

Continue reading “Powering Up A Pluggable Module From The 1948 IBM 604 Electronic Calculator” →

Over-Engineering An FDM Spool Holder From Prusa Mk4S Remains

June 5, 2026 by 2 Comments

Unlike resin printers where you generally just pour the fresh resin into the easily accessible vat, FDM printers need to squirrel away at least one spool and its requisite holder somewhere. For bed slingers this generally means a top-mounted spool holder, while for CoreXY enclosed printers they can appear on the sides, top or – inexplicably – on the back. While a side-mounted spool is often convenient, access to the side can still be blocked, in which case you do what [3D Maker Noob] did and over-engineer a fancy top-mounted spool holder.

The problem started after converting a Prusa Mk4S to a Core One using the conversion kit, which changes the position of the spool, forcing him to work around not having access to the right side of the machine where the default position is. After a first version using many of the left-over parts of the original Mk4S to create a fancy box-shaped spool holder, he proceeded to upgrade it as detailed in the video. All project files and instructions are available on Printables.

The result is a box you stack on top of the printer somewhat like a multi-spool box, just flatter and with a flippy lid on the front from which a rail slides out with the magnetically attached spool holder. A spool holder which you naturally can further customize to fit different spools. Even if over-engineered, you can’t deny that it would fit in confined spaces and looks pretty good while doing its job.

Continue reading “Over-Engineering An FDM Spool Holder From Prusa Mk4S Remains” →

Game Dodecahedron Runs AArch64 Assembly

June 3, 2026 by No comments

Operating systems are great things to have for general purpose computing, but sometimes they can just get in the way. There’s RAM overhead and processor cycles required for all that operating, after all. For something like a game system, it seems unnecessary. The NES certainly did well enough without an OS, as did its various successors for several console generations.

[Inkbox] wanted to get back to those heady days by programming bare-metal games for a Rasberry Pi 3 that had sat unused since 2016. Games are on cartridge, running bare metal, in assembly — as God and Masayuki Uemura intended. Also, the console is a dodecahedron, because the name GameCube was already taken.

The GitHub link above doesn’t exactly have documentation, at least as of this writing, so you’ll need to watch the video to get the full details. The dodecahedron form factor might not be ideal for packing away in a bag, but as a handheld we have to admit it does look comfortable to hold. Two faces of the dodecahedron get a half-dozen buttons each, which are wired to a GPIO pin on the Pi via a Schmitt trigger for hardware debounce. Like all good consoles, it uses cartridges, these ones being adapted from SD cards on large PCBs derived from a project we featured before.

That all sounds great, but it’s the assembly programming we’re really interested in — skip to around the seven-minute mark in the video for that. Ultimately it’s a build video, so not the ideal tutorial for ARM assembly programming, but it might not be a bad introduction for some. Unfortunately you don’t get line-by-line of the PacMan game he put together — but he does have it in the repository for you to examine. The repo also has STLs if you want to make a dodecahedron of your own.

Of course he’s got a RetroPi cartridge as well, loaded with emulators, and we suspect that’s mostly how this GameDodecahedron will get used. Still, we’ll always have a soft spot for assembly code and projects that use it — be it on ARM, good old 6502, the open-source RISC V architecture, or even the absolute monster of op codes that is x86.

Continue reading “Game Dodecahedron Runs AArch64 Assembly” →

4-bit Relay Logic Counter Begs To Have Its Buttons Pushed

May 31, 2026 by 5 Comments

What’s one to do with some nice little relays of questionable pinout, and prototyping board? How about a quietly clicky 4-bit counter using relay logic with tons of buttons?

The register with LEDs and buttons is on the top board, the incrementer on the bottom board.

[Agatha Mallett] made the counter after finding herself in possession of a quantity of relays burdened by terrible documentation (the datasheet shockingly lacks a pinout, and doesn’t even mention the coil being unidirectional). But since the relays are also small and of decent quality, they were a good candidate for a small relay logic-based project.

The key to the build is implementing D-type flip-flops using relays. This is done by holding the coil voltage of each relay between its set and release voltage levels. A small voltage bump will energize the coil, closing the relay and leaving it closed. Conversely, a small negative spike releases the coil, leaving it open. This forms the basis of the counter, and [Agatha] has a separate write-up all about the details of using relays in this way.

Implementing this was rather less straightforward than it may sound because it relies on balancing the coils of many relays on a figurative knife-edge of voltage, but not every component is perfectly identical. A tweaked resistor or capacitor here and there was needed before things settled into reliability.

The end product has indicator LEDs, buttons to increment or clear the current count, and it even has buttons to set or clear individual bits. This is a project that begs to be interacted with, and there’s a short video on the project page so you can watch it go through its paces.

Thanks to [Jess] for the tip!

Tiny C64 PSU Rejects Tradition, Embraces USB

May 26, 2026 by 36 Comments

The Commodore 64 has, by modern standards, the interesting power requirement of needing both 5 VDC and 9 VAC. Traditionally, one would use an iron-core transformer to step-down the wall current — be it 220 V or 115 V, 50 Hz or 60 Hz — to produce the low-voltage AC.

That’s how Commodore did it, and that’s how most of the aftermarket replacements do it, too. That iron-core transformer is bulky, though, and [Side Projects Lab] decided that in this day and age of switching supplies and USB-PD he could surely do better. Which he did, with the diminutive PD-64.

As you can see, it just covers the power port of the C64, and not much else. Partly that small size comes from offloading some of the hard work onto a USB-PD wall wart. The PD-64 requests 12 VDC, which it then steps down to 5 VDC with the usual buck converter, and inverts to 9 VAC in a circuit that is the most interesting part of the project.

There are various ways one could do this, after all, and we’re sure some of you will have different ideas than [Side Projects Lab], but his method seems sound. In order to provide galvanic isolation between the two outputs, the 12 VDC line is first chopped into a 500 kHz signal, and run through a tiny 5:6 ferrite transformer. That output gets rectified to 13.6 VDC, a voltage that is used to run a class-D audio amplifier to produce the 9 V peak-to-peak, zero-DC-offset signal the C64 needs.

[Side Projects Lab] has released both FreeCAD files for the case and STLs as BY-CC-ND 4.0, and a circuit diagram is available for the electrical side. If you don’t want to design your own PCB, [sideprojectslab] will be selling finished versions.

If you’re interested in further dragging your C64 into the modern era, check out the HDMI output that [Side Projects Lab] hacked together for the iconic computer last year.

Continue reading “Tiny C64 PSU Rejects Tradition, Embraces USB” →

A square red circuit board is shown on a black workbench. The circuit board houses two large chips in the upper left corner, each with a large heat sink attached.

Just How Bad Was The Intel IAPX432?

May 25, 2026 by 38 Comments

Processor design over the last few decades has moved toward RISC processors that aim to implement a few simple operations very efficiently. For a while, though, the trend was toward ever-more-complex CISC designs that let programmers implement complex behaviors using as few instructions as possible. Few processors took this approach further than the Intel iAPX432. This hyper-CISC processor was a commercial failure, largely due to its notoriously poor performance, but [MarkTheQuasiEngineer]’s benchmark suggests that this notoriety wasn’t totally deserved.

The first step before running a benchmark was to build a computer around the processor. The iAPX432 was implemented in three chips, two of which acted as the general data processor (GDP), and one of which handled input and output. [Mark] built an SBC (design and code here) that houses the two GDP chips and an FPGA for I/O. The 432 did have a well-deserved reputation for efficiently turning electricity into heat, and the original voltage regulator failed rather quickly.

The 432 was designed to use machine code which was almost a high-level language, with built-in object-oriented programming. It had over 200 operators, some of which implemented complex object-oriented operations, and a wide variety of data types, but it had no directly-accessible general-purpose registers. In addition to the lack of registers, it also had a very complex addressing system, allowing both direct and indirect addressing. For better performance, [Mark] used direct addressing.

For the benchmark, [Mark] implemented the Spigot algorithm to calculate the value of Pi. The results were somewhat surprising: calculating 2048 digits, it beat his previous retro-processor benchmarks; an Intel 8086 running the same algorithm took 2.5 times as long. Based on the results of this hand-written code, [Mark] speculates that the 432’s poor performance had more to do with poor compiler optimization than with the fundamental design.

We’ve covered some of the history of this troubled chip before. For a similarly ambitious but ill-fated Intel project, check out the history of Itanium.

Hackaday Links Column Banner

Hackaday Links: May 24, 2026

May 24, 2026 by 5 Comments

If your first-generation Chromecast was acting a little wonky this week, don’t worry. Contrary to fears online, the 2014 device hasn’t been excommunicated by Google. In a statement to Ars Technica, a rep for the search giant explained that the issue, which was keeping the devices from being able to stream video from services like Netflix, was temporary and should now be resolved. That said, the OG Chromecast hasn’t officially been supported since 2023, so it’s not clear how much longer they will remain operational. Google be Google, after all.

After resisting for years, this week, Mozilla finally relented and brought Web Serial to Firefox. While there’s been some debate about the wisdom of letting the Internet directly talk to hardware gadgets, anyone who’s flashed Meshtastic or configured their Betaflight-powered drone from the browser can attest to how convenient it is. In the announcement, Mozilla acknowledges that “most folks won’t use this API”, but points out that the “community of builders and tinkerers” (that’s us!) is sure to be excited about the news. They’ve even teamed up with Adafruit to ensure their web-based microcontroller workflows are compatible in Firefox 151 and beyond. If you give it a shot, let us know how it goes.

Speaking of hardware support, the Linux Vendor Firmware Service (LVFS) recently picked up a couple of big-name sponsors. As reported by It’s FOSS, this week, Lenovo, Dell, and HP have signed on as Premier-level sponsors to the tune of $100,000 per year. For those unfamiliar, LVFS offers a central repository where hardware vendors can upload firmware updates. On the client side, fwupd can be used to pull these updates down automatically without having to hunt around on each vendor’s website. The experienced players don’t need a service like LVFS, but it’s certainly one of those quality-of-life improvements that make the desktop experience a bit more accessible.

Continue reading “Hackaday Links: May 24, 2026” →