While pondering some repairs for his Gaggia Classic Pro espresso machine, [Hans Gaensbauer] ended up machining an entirely new boiler from stainless steel.
It was a nontrivial undertaking, since the boiler is an assembly that integrates not only heaters and pump connections, but one end is also the group head into which the portafilter interfaces. [Hans] had to deal with machining out the contours and pockets necessary for a portafilter to lock in securely, complete with the little screen and perforated plate responsible for even water distribution. And of course, the whole thing still has to fit into the original machine. All in all, [Hans] had some constraints to work around, making it a considerably more complex job than just milling a chamber out of a block of stainless steel.
LEGO building blocks are a great toy, but every so often a hacker decides to take the little bricks outside of the toy room and make them an integral part of a build. [Adam Turaj] took that idea further than most with his Studprint, a 3D printer that’s 92% LEGO.
We aren’t just talking LEGO bricks making up part of the frame here, or even the bed — though that’s obviously the case — but [Adam] goes so far that even the motion system is using LEGO leadscrews to drive the axes of this printer. Is it particularly capable? Well, no. He’s not boasting of a remarkable bed size or high speeds here because that’s really not the point. The point is that he made a printer in LEGO and if you don’t see the fun in that, we don’t know what to tell you.
The whole project is open source, and includes the CAD files for the handful of non-LEGO bits you’ll need to mount the electronics, steppers and such. With an unheated bed of ABS bricks, you’re going to be limited in filament choices, but [Adam] has at least made a Benchy, which is all anyone really needs, right?
In light of recent work, we can might suggest that the printer is also a pick-and-place machine. If you want to turn the phrase “LEGO 3D Printer” around, we have seen 3D Printed LEGO before as well. We’d be remiss not to note that this isn’t the first printer to use the ubiquitous building blocks we’ve seen, though this one keeps with the regular filament and extruder rather than hot glue like the 2013 version.
A few times in the life of someone interested in technology, there comes along something which after seeing it, you know the field is never going to be the same again. For a teenage future Hackaday writer this came in seeing Elite, on a BBC Micro. Nowadays an open world game is normal, but in the mid-1980s it was mind-blowing. Of course, such a powerful piece of software couldn’t be ported to any old computer, so owners of less capable machines were left envious of their more well-heeled friends.
It will be a surprise to Commodore Pet owners then, that over four decades later, [David Given] has ported the game to their platform. It’s not such a leap, as the Pet has the same (albeit slower) 6502 as the BBC Micro, and the game requires the Commodore machine to have 32k of memory.
So what you get is Elite, but with the Pet’s block graphics rather than the higher-resolution you’d have seen on the newer machines. He admits it doesn’t play well and that the code is something of a mess, but we suspect 32k Pet owners in 2026 won’t be too bothered by this. All the code and disk images are there in the repository, and you can see it at work in the video below the break. Meanwhile if you’re curious about the Elite codebase, you can take a look at it yourself.
This week Jonathan chats with Sattyam Jain about Agent Audit Kit and Agent Airlock. We’re in a brave new world, where anyone can use AI to generate an AI agent. But what keeps those builds secure? And what can we do to prevent AI jailbreaking where it matters? Listen to find out! Continue reading “FLOSS Weekly Episode 883: Telnet Broke Us”→
If the word “train” didn’t grab your attention, you’re probably not the target audience for this project. If it did, then there is no need to explain why [AeroKoi] has come up with a modular 3″ train whistle, available on Thingiverse and well explained in the video embedded below. It’s a train whistle. Who doesn’t want their own train whistle?
The great part of this design– aside from requiring less air than his earlier, larger-diameter iterations–is the modularity. With adjustable bell caps, you can alter the size of the resonant chamber and thus the notes the whistle plays on the fly. That’s the key difference between a train whistle, as used in the steam era, and a train horn as you find on a modern diesel or electric– whistles use a resonant chamber, while a horn uses a diaphragm to create the vibrations we call sound. By using the movable chamber caps to change the resonance, you can go from a Santa Fe 5 chime to a B&O 3 chime whistle by matching the measurements in the handy-dandy spreadsheet [TrainArtisan] provided– and doubling up on a couple of chimes.
One excellent tip he gives in the video is to grease all the mating surfaces of the whistles with petroleum jelly, but it’s worth watching the whole thing on YouTube for both full build and tuning instructions, and to learn more than you ever thought you needed to know about whistles– he gets right into the physics of sound waves to explain exactly the limitations of trying to replicate the sound of brass steam whistles with plastic and compressed air. If you just want to hear a bunch of train whistles to see how well it works, jump to the ten minute mark. The disappointing part comes later, where he explains the airflow requirements: if you don’t have a compressor with a big tank, you can’t expect more than one short toot at a time.
Writing a computer game has always been hard. It is only the nature of the difficulty that changes. A modern game is as much about graphics, sound, and storytelling as it is about programming. But in the early days of computers, writing a game was a challenge because of limited graphics, slow CPUs, and tiny memory capacity. If you wanted to write a game for an early microcomputer, you generally wrote it in assembly language. BASIC was available on many machines, but it was usually too slow for anything requiring fast animation. Assembly language was fast, but it was also difficult to write, debug, and port to another machine.
RCA — in particular [Joseph Weisbecker], the architect of the 1802 — introduced the COSMAC VIP into the primordial 1977 home video game market. In addition to using ready-made games, the idea was that you could create your own. But writing games in 1802 assembly language would be beyond most of RCA’s customers. [Weisbecker] devised CHIP-8, a tiny virtual machine. It wasn’t quite a programming language. Instead, it was a simple instruction set implemented by an interpreter running on a real computer. You wrote programs for the imaginary CHIP-8 processor, and the interpreter made them run on the actual hardware. CHIP-8 is perfect for the kind of games you’d see in those days and still has a following among those who love retro games.
A Different Time: Tiny Interpreters
Today, when we think of interpreters, we often imagine something like Python, where the interpreter reads source code and figures out what to do. However, there’s another approach that was particularly attractive when memory and processor cycles were precious: threaded code.
In a threaded-code interpreter, a program consists of references (like indices into a command table) to routines that perform operations. Instead of decoding complicated instructions, the interpreter follows these references, executing the corresponding routines. There are several variations, including direct threading, indirect threading, and token threading. Forth is probably the best-known example of a language that commonly uses threaded code. In a typical Forth implementation, a program is compiled into a sequence of references to words, and a compact inner interpreter executes them.
Why bother? Because the implementation can be remarkably small. Instead of generating native machine code, a compiler can produce a compact representation that is relatively easy to execute. CHIP-8 belongs to the same general family of ideas, although it is more accurately described as a bytecode interpreter than a conventional threaded-code system. Its instructions are two bytes long, and the interpreter decodes each instruction and executes the corresponding operation. The original implementation was written in RCA 1802 machine code.
History Of CHIP-8
The VIP ([Dave Ruske] CC-BY-SA-2.0)The COSMAC VIP was an interesting machine. A basic system had 2 KB of RAM, a hexadecimal keypad, and a monochrome video display. Programs were generally entered as hexadecimal bytes using the keypad, although expansion options were available. The 1802 CPU inside wasn’t exactly a speed demon. It was an 8-bit processor with sixteen 16-bit registers and an unusual architecture that made it well suited to certain embedded applications. There were versions that were also well-suited for spacecraft, and so the chip is in Magellan, Galileo, and even some parts of the Hubble.
CHIP-8 made programming the VIP considerably easier, especially for games. Rather than dealing with the peculiarities of the 1802 and the VIP’s display hardware, programmers could use a small, consistent instruction set designed around graphics and keypad input.
The CHIP-8 virtual machine provides sixteen 8-bit registers, conventionally named V0 through VF. It also has a 16-bit index register, a program counter, a stack for subroutine calls, and two timers.
The display is 64 pixels wide and 32 pixels high. Pixels are either on or off. There’s no color, no hardware sprites, and no sophisticated graphics processor. There are, however, instructions specifically intended to make games easier to write. You can draw a sprite with a single instruction, test whether a key is pressed, generate a random number, and use timers to control animation.
A sprite is simply a sequence of bytes, with each bit representing a pixel. A typical sprite can be up to eight pixels wide and fifteen pixels high. The instruction set is tiny, with only a few dozen basic operations. Yet it is sufficient to implement games such as Pong, Breakout, and Space Invaders-like shooters.
CHIP-8 subsequently appeared on other systems, and later variants extended its capabilities. The best-known extension is Super-CHIP, which added features including higher-resolution graphics. Today, CHIP-8 survives largely because it is an excellent target for emulator projects. Writing a CHIP-8 interpreter is a manageable exercise, and there are thousands of small programs available to test one. But you don’t need to write an interpreter to experiment with CHIP-8.
Adjustable standing desks have had some ergonomic and health benefits for many people who would otherwise be sitting down all day, but those benefits come at a cost of a bit of usability. They can be more expensive, they make cable management and lighting a bit more difficult, and of course they take up more space than a normal desk. Related to that, they may have limited or no drawer space. [Super Valid Designs] decided to tackle all of these problems, while at the same time addressing the larger problem of a very disorganized workspace.
The idea seems simple on its face. The desk surface would be removed from the legs and a full-sized drawer built that matches the footprint of the desk and attaches to the same points, then the surface can be put back on top of that. But this is where feature creep started to set in, although in this case it was all a net positive for the build. [Super Valid Designs] wanted a front for the drawer but, since this is where his keyboard and mouse would go, wanted it to automatically move aside so it’s not in the way. He built a clever mechanism that pivots the front down when the drawer slides out. Not only that, but the drawer locks into place when it’s halfway out in “keyboard mode” and by lifting the front and pulling the drawer further out he can access a deeper storage space further to the back of the drawer.
Although adding these features in took him longer than he originally thought, the new desk is much more usable than the old while helping him eliminate some of the clutter around his workspace. Like any prototype, though, there were a few issues such as cable management (which is a problem with most standing desks) and the fact that he forgot that some of his peripherals were attached to the desk with clamps, which can’t be used with the drawer cabinet in the way. Overall though it’s a major improvement which we think could only be further improved by making it not just a standing desk, but a walking desk.
