Virtual Nodes, Real Waves: A Colpitts Walkthrough

April 22, 2025 by Heidi Ulrich 2 Comments

If you’ve ever fumbled through circuit simulation and ended up with a flatline instead of a sine wave, this video from [saisri] might just be the fix. In this walkthrough she demonstrates simulating a Colpitts oscillator using NI Multisim 14.3 – a deceptively simple analog circuit known for generating stable sine waves. Her video not only shows how to place and wire components, but it demonstrates why precision matters, even in virtual space.

You’ll notice the emphasis on wiring accuracy at multi-node junctions, something many tutorials skim over. [saisri] points out that a single misconnected node in Multisim can cause the circuit to output zilch. She guides viewers step-by-step, starting with component selection via the “Place > Components” dialog, through to running the simulation and interpreting the sine wave output on Channel A. The manual included at the end of the video is a neat bonus, bundling theory, waveform visuals, and circuit diagrams into one handy PDF.

If you’re into precision hacking, retro analogue joy, or just love watching a sine wave bloom onscreen, this is worth your time. You can watch the original video here.

Continue reading “Virtual Nodes, Real Waves: A Colpitts Walkthrough” →

MilliForth-6502, A Forth For The 6502 CPU

April 20, 2025 by John Elliot V 32 Comments

Forth is popular on small computers because it is simple to implement, yet quite powerful. But what happens when you really need to shrink it? Well, if your target is the 6502, there’s milliForth-6502.

This is a port of milliForth, which is a fork of sectorforth. The sectorforth project set the standard, implementing a Forth so small it could fit in a 512-byte boot sector. The milliForth project took sectorforth and made it even smaller, weighing in at only 336 bytes. However, both milliForth and sectorforth are for the x86 architecture. With milliForth-6502, [Alvaro G. S. Barcellos] wanted to see how small he could make a 6502 implementation.

Continue reading “MilliForth-6502, A Forth For The 6502 CPU” →

Rockbox 4.0 Released

April 19, 2025 by John Elliot V 22 Comments

It’s traditional to launch new software on April Fool’s Day, which is when we heard that Rockbox 4.0 has been released. But, in this case, the venerable MP3 firmware actually did update after a long absence. It’s great to see that good old Rockbox is still kicking along. We first mentioned Rockbox here at Hackaday approaching 20 years ago. How time flies. There used to be a whole ‘scene’ around hacking Personal Media Players (PMPs), also known as “MP3 Players”.

We tracked down Rockbox contributor [Solomon Peachy] to ask for some simple advice: If someone wants to install Rockbox on a personal media player today, what hardware should they buy? [Solomon] referred us to the AIGO EROS Q / EROS K, which is the only compatible hardware still being manufactured and sold. Beyond that, if you want to buy compatible hardware, you’ll need to find some secondhand somewhere, such as eBay. See the Rockbox Wiki for supported hardware.

Smartphones and streaming services have subsumed the single-purpose personal media player. Will you put the new Rockbox on something? Let us know in the comments.

Vibing, AI Style

April 19, 2025 by Elliot Williams 38 Comments

This week, the hackerverse was full of “vibe coding”. If you’re not caught up on your AI buzzwords, this is the catchy name coined by [Andrej Karpathy] that refers to basically just YOLOing it with AI coding assistants. It’s the AI-fueled version of typing in what you want to StackOverflow and picking the top answers. Only, with the current state of LLMs, it’ll probably work after a while of iterating back and forth with the machine.

It’s a tempting vision, and it probably works for a lot of simple applications, in popular languages, or generally where the ground is already well trodden. And where the stakes are low, as [Al Williams] pointed out while we were talking about vibing on the podcast. Can you imagine vibe-coded ATM software that probably gives you the right amount of money? Vibe-coding automotive ECU software?

While vibe coding seems very liberating and hands-off, it really just changes the burden of doing the coding yourself into making sure that the LLM is giving you what you want, and when it doesn’t, refining your prompts until it does. It’s more like editing and auditing code than authoring it. And while we have no doubt that a stellar programmer like [Karpathy] can verify that he’s getting what he wants, write the correct unit tests, and so on, we’re not sure it’s the panacea that is being proclaimed for folks who don’t already know how to code.

Vibe coding should probably be reserved for people who already are expert coders, and for trivial projects. Just the way you wouldn’t let grade-school kids use calculators until they’ve mastered the basics of math by themselves, you shouldn’t let junior programmers vibe code: It simultaneously demands too much knowledge to corral the LLM, while side-stepping any of the learning that would come from doing it yourself.

And then there’s the security side of vibe coding, which opens up a whole attack surface. If the LLM isn’t up to industry standards on simple things like input sanitization, your vibed code probably shouldn’t be anywhere near the Internet.

So should you be vibing? Sure! If you feel competent overseeing what [Dan] described as “the worst summer intern ever”, and the states are low, then it’s absolutely a fun way to kick the tires and see what the tools are capable of. Just go into it all with reasonable expectations.

Jenny’s (Not Quite) Daily Drivers: Raspberry Pi 1

April 14, 2025 by Jenny List 46 Comments

An occasional series of mine on these pages has been Daily Drivers, in which I try out operating systems from the point of view of using them for my everyday Hackaday work. It has mostly featured esoteric or lesser-used systems, some of which have been unexpected gems and others have been not quite ready for the big time.

Today I’m testing another system, but it’s not quite the same as the previous ones. Instead I’m looking at a piece of hardware, and I’m looking at it for use in my computing projects rather than as my desktop OS. You’ll all be familiar with it: the original Raspberry Pi appeared at the end of February 2012, though it would be May of that year before all but a lucky few received one. Since then it has become a global phenomenon and spawned a host of ever-faster successors, but what of that original board from 2012 here in 2025? If you have a working piece of hardware it makes sense to use it, so how does the original stack up? I have a project that needs a Linux machine, so I’m dusting off a Model B and going down memory lane.

Continue reading “Jenny’s (Not Quite) Daily Drivers: Raspberry Pi 1” →

Software Project Pieces Broken Bits Back Together

April 13, 2025 by Donald Papp 18 Comments

With all the attention on LLMs (Large Language Models) and image generators lately, it’s nice to see some of the more niche and unusual applications of machine learning. GARF (Generalizeable 3D reAssembly for Real-world Fractures) is one such project.

GARF may play fast and loose with acronym formation, but it certainly knows how to be picky when it counts. Its whole job is to look at the pieces of a broken object and accurately figure out how to fit the pieces back together, even if there are some missing bits or the edges aren’t clean.

Re-assembling an object from imperfect fragments is a nontrivial undertaking.

Efficiently and accurately figuring out how to re-assemble different pieces into a whole is not a trivial task. One may think it can in theory be brute-forced, but the complexity of such a job rapidly becomes immense. That’s where machine learning methods come in, as researchers created a system that can do exactly that. It addresses the challenge of generalizing from a synthetic data set (in which computer-generated objects are broken and analyzed for training) and successfully applying it to the kinds of highly complex breakage patterns that are seen in real-world objects like bones, recovered archaeological artifacts, and more.

The system is essentially a highly adept 3D puzzle solver, but an entirely different beast from something like this jigsaw puzzle solving pick-and-place robot. Instead of working on flat pieces with clean, predictable edges it handles 3D scanned fragments with complex break patterns even if the edges are imperfect, or there are missing pieces.

GARF is exactly the kind of software framework that is worth keeping in the back of one’s mind just in case it comes in handy some day. The GitHub repository contains the code (although at this moment the custom dataset is not yet uploaded) but there is also a demo available for the curious.

Illustration of author surveying the fruits of his labor by Bomberanian

Learning Linux Kernel Modules Using COM Binary Support

April 13, 2025 by Maya Posch 18 Comments

Have you ever felt the urge to make your own private binary format for use in Linux? Perhaps you have looked at creating the smallest possible binary when compiling a project, and felt disgusted with how bloated the ELF format is? If you are like [Brian Raiter], then this has led you down many rabbit holes, with the conclusion being that flat binary formats are the way to go if you want sleek, streamlined binaries. These are formats like COM, which many know from MS-DOS, but which was already around in the CP/M days. Here ‘flat’ means that the entire binary is loaded into RAM without any fuss or foreplay.

Although Linux does not (yet) support this binary format, the good news is that you can learn how to write kernel modules by implementing COM support for the Linux kernel. In the article [Brian] takes us down this COM rabbit hole, which involves setting up a kernel module development environment and exploring how to implement a binary file format. This leads us past familiar paths for those who have looked at e.g. how the Linux kernel handles the shebang (#!) and ‘misc’ formats.

On Windows, the kernel identifies the COM file by its extension, after which it gives it 640 kB & an interrupt table to play with. The kernel module does pretty much the same, which still involves a lot of code.

Of course, this particular rabbit hole wasn’t deep enough yet, so the COM format was extended into the .♚ (Unicode U+265A) format, because this is 2025 and we have to use all those Unicode glyphs for something. This format extension allows for amazing things like automatically exiting after finishing execution (like crashing).

At the end of all these efforts we have not only learned how to write kernel modules and add new binary file formats to Linux, we have also learned to embrace the freedom of accepting the richness of the Unicode glyph space, rather than remain confined by ASCII. All of which is perfectly fine.

Top image: Illustration of [Brian Raiter] surveying the fruits of his labor by [Bomberanian]