You know what they used to say– once you go Commodore, you’ll never leave by any door. Well, they might not have said that, but given the prevalence of projects still using Commodore-branded systems decades after the company’s demise, perhaps someone should have. A case in point is [Jit06] with this writeup on his Ultimate Amiga 1200 — or “Amiga 1232 Storm CD”– which crams just about every upgrade you might think of into the 1990s wedge computer.

Of course it has the PiStorm 32, with a CM4 providing supercomputer performance, at least by A1200 standards. That’s rather old hat, though, and it’s everything else crammed into the old Commodore that takes the score. For one thing, there’s a slot-loading, slim-form DVD drive from an old laptop that’s been incorporated so smoothly it almost looks factory. Ditto for the compact flash card slot, which is also on the IDE bus. The two share a custom IDE cable– yes, kids, we did used to roll our on 44-pin cables back in the day, but you’d better believe no one did it unless they really had to. With the space constraints inside the A1200 case, [Jit06] falls into that category.

The optical and CF cards trigger the drive LED on the Amiga case by default, but [Jit] wanted to see access on the PiStorm’s SD card as well, so he wired a couple of red LEDs to the default lightguide to get a colour-contrasting flash. That SD card is also broken out with an extender for easy access without opening the case– and once again, it looks almost as good as stock. So does the modded-on VGA port, which is stealing space that once belonged to the Amiga’s RF modulator and fed by a ScanPlus AGA board.

The only thing that really stands out as modded is the volume knob on the floppy-drive side of the case; that controls a mixer that sits between the CD audio and Paula, the Amiga’s custom sound chip. This lets him use the A1200 as a CD-32 system, and is very handy to have as CD-32 games used CD audio tracks that apparently were not well mixed with the digital audio in the games.

With all the cutting and soldering, this is not a reversible mod, something people are becoming much more concerned with as these machines slowly increase in rarity. Still, as a quality-of-life improvement, this sort of upgrade might be worth it if can keep the old A1200 relevant for another three decades. For anyone else who never got over the Amiga bug, he’s also published a linux-native SD-card creator called emu68 bootstrap on github to help with making images for the PiStorm.

Thanks to [Jit] for the tip! With the easy OS-swapping he’s enabled with the SD-breakout, there’s no reason not to try the rediscovered Amiga Unix. If you want the same without cutting into a vintage case, the PiStorm can be a sidecar.

youtube.com/embed/LV2FffhXCYo?…

hackaday.com/2026/06/11/amiga-…

An old algebra teacher used to say, “You have to take what you know and use it to get what you don’t know.” You might say the same thing about converting analog signals into digital. Computers know how to count and keep time. [Eric Explains] has a video purporting to explain “every type of analog-to-digital converter.” We aren’t sure he got every possible method, but there’s still a lot of information in the video, which you can see below.

From the flash ADC, using a ton of comparators to the successive approximation converter, which essentially plays a game of hi/lo, guessing the answer and figuring out if the real answer is higher or lower.

Those are pretty common, but the video also covers things like the Wilkinson ADC and other more exotic techniques. Each method, of course, has its advantages and disadvantages. For example, the flash ADC is fast, but requires a lot of components and power.

Sometimes, the method you use depends on how you are building. For example, you probably wouldn’t use a charge system on a breadboard since precision capacitors are finicky. But on an integrated circuit, capacitors made with photolithography may not be very precise, but the ratio between capacitors is super precise, making that a common technique in that domain.

Even if you never need to design your own converter, understanding the different architectures will let you make a better selection among alternatives. Then again, you can design your own. We’ve seen most of these architectures in past projects.

youtube.com/embed/mG8td8mqF3Y?…

hackaday.com/2026/06/11/so-man…

Well there’s your problem. (Credit: Bits und Bolts, YouTube)
Recently [Bits und Bolts] stumbled over a pair of Dragon 3000 branded 3dfx Voodoo 2 cards in his unfixed cards pile, and decided that the best course of action was to not only fix them, but also run them in SLI for some sweet Unreal Tournament action. Naturally, these cards being in the broken cards pile meant that he first had to figure out why they were broken and fix all issues.

The advantage of having two identical Voodoo 2 cards is of course that any missing components, like some resistors on one card, could be referenced on the other card. Beyond that it was mostly a matter of reflowing clearly corroded pins on the ICs and replacing damaged resistors and resistor arrays before the first tests could be run.

Using the mojo utility it was easy enough to spot that there were still some lingering issues, with clear issues visible in 3D games as well. These were tracked down to a dodgy pin on one of the texture mapping units (TMUs) that needed some more reflowing, and a very sneaky resistor array that was cracked but not obviously so until prodded with a multimeter.

With both cards now making happy noises when individually tested, it was time to go full SLI, fire up the Pentium 2 system and enjoy the glory of 24 MB of VRAM at high resolutions in Unreal Tournament. Considering that the bloke who had sent in these cards had found them while cleaning up a shed, it’s quite amazing how little rework was needed to once again party like it’s 1999.

youtube.com/embed/c7OOJfYCSS0?…

hackaday.com/2026/06/11/repair…

Unlike on Mars where for decades we have had dozens of orbital and ground-based platforms zipping and scurrying about to prod at every bit of emitted radiation, rock type and twitch of dust devils in its thin atmosphere, for other planets and their moons we have to do a lot more speculative interpretation of data. Such was the case with the presumed existence of water plumes on Jupiter’s moon Europa. These now appear to have been a statistical fluke, per research by [L. Roth] et al. in Astronomy & Astrophysics.

As succinctly summarized in the article on this by [Javier Barbuzano] of Sky and Telescope, the original 2013 finding of said water plumes by the same team was based on faint UV emissions from Europa’s southern hemisphere as captured by the Hubble Space Telescope. However, in more recent captures these emissions were not detected again, leading them to reexamine their original analysis of the 2013 data.

One of the main flaws was in the assumption of where Europe was located on Hubble’s 1,000 x 1,000 resolution detector, with the re-analysis showing that they were off by a couple of pixels. A second flaw was quite understandable as since 2013 we have learned that Europa has a thin hydrogen exosphere which interacts with the Sun’s UV radiation. The resulting scattering induces a UV glow which could be mistaken for UV radiation emanating from the moon’s surface.

Even with this one intriguing feature turning out to be a mirage, it doesn’t make Europa any less interesting as it’s still assumed to have vast liquid water oceans. Along with Uranus’ moon Miranda this makes it very worth it to experience more of the sights and sounds of these alien worlds, whether in person or via our robotic friends.

hackaday.com/2026/06/11/eviden…

If you work with radio, the chances are that before too long you’ll be winding an inductor. At radio frequencies these won’t be big chunky transformer style chokes, but often air-cored affairs supported by their own rigidity. As grizzled old radio amateurs will tell you though, relying on such a coil for stability is a fool’s errand. It will shift inductance from the slightest movement, thermal expansion, or even sound. Luckily [SolderSmoke] is here to remind us of the trusty fix, in the form of Q-dope, or a polystyrene solution that dries to form a rigid low-dielectric coating.

Where this is being written it wasn’t on the market so it was more usual to use nail lacquer, but reading the piece it seems American hams swore by the stuff. That’s in the past tense because it seems it’s no longer on the market. Even there though help is at hand, because dissolving packaging polystyrene in solvent yields an acceptable substitute. There’s even an 11-year-old how-to video linked from the SolderSmoke post, should you fancy making some of your own. We suggest you proceed with caution though, polymers dissolved in solvents sounds a lot like home-made napalm, and probably puts out fumes you don’t want to breathe.

Meanwhile should you fancy experiments of your own with inductors, we’ve got you covered.

hackaday.com/2026/06/11/mechan…

The world of software has seen many paradigms come and go, all of which were supposed to revolutionize its development. Still, one of the basic tenets in engineering of there being no shortcuts to just doing the work properly also rings true in the field of software engineering: trying to skip ‘nice to haves’ like proper documentation, code formatting, and proper testing inevitably results in developers nervously trying to ignore the looming avalanche of technical and other project debts as they keep piling up.

While Test-Driven Development (TDD) once got praised as the silver bullet, the principle of writing tests before writing code merely postpones the inevitable project collapse. The elephant in the room is that you cannot pass on the basics in engineering and expect to come out fine on the other end. There’s a reason why phrases like “all tests green, successfully failed in production” have become common.

This is where the concept of Comment-Driven Development (CDD) comes into play. What started as a bit of a joke many years ago stuck in my mind and led me to my current approach in software development that tries to effectively mirror solid engineering principles.

Defining Comments

In the field of software engineering, code comments are often regarded as a bit of an unloved stepchild. No developer regards them in the same way, few appreciate them, most neglect them and some outright banish them from their lives. The most extreme response here is probably that of the Clean Code movement, who together with the Self-Documenting Code crowd insist that inline comments in particular are unnecessary, an eyesore and that beautiful, well-written code documents itself.

Then there are those who use comments as a (temporary) crutch, as in what is referred to as ‘comment programming‘. This puts comments in the place where code is supposed to go, for either later replacement or to elucidate a specific aspect. None of this uses comments consistently to provide a parallel flow with the code that explains the what, why and how of said code.

Why this matters is that despite claims to the contrary, reading and understanding code is hard. Grasping architectural decisions and intuitively separating them from quick hacks is hard even if you’re reading back your own code after a few development cycles. This is also basically why writing documentation based on just code with at most spotty inline commentary is a nightmare at best.

After working with a variety of (commercial) codebases over the years that were practically dripping technical debt and regrets – as well as writing comprehensive documentation for some of them – I have become convinced that comments are ultimately the Alpha and Omega of a healthy codebase and up to date documentation.

Software Engineering

Hot-patching the Millennium Tower in 2022. (Credit: ArnoldReinhold, Wikimedia)
Although most people see the finished product of engineering and believe that that’s all there’s to it, the truth is that before that bridge, high-rise building or even some fancy electronic widget sees the light of day, most of the work has already happened. Building it is then theoretically as easy as following the provided instructions.

An essential point here is the assumption that said instructions are half-way correct and you don’t end up building your very own Millennium Tower.

Thus the process of engineering begins with the list of requirements. These have to be chiseled into the hardest of stone, as any change here will have potentially massive repercussions. From these requirements you can then begin to work on a design document that details the overall design of the product, from which the desired architecture follows.

While the specific details will differ for each specific field of engineering, it is this condensing from an abstract idea into increasingly more concrete steps that enables for all angles to be considered before committing to a specific decision that can be hard to revert or change later. In the case of the aforementioned Millennium Tower project, those in charge omitted steps like peer review, where an external set of eyes is asked to give their two cents, because this would have ‘taken too long’.

From Design To Code

Even if in general software is easier to change than e.g. the blueprints for a civil engineering project, you still want to avoid having to go back repeatedly to change or modify parts of a codebase. To this end you do not want to write code until you are very confident that said code is proper and correct.

Fortunately, with the detailed design document and architectural planning already in the bag you can then start start the feedback loop of laying out the foundations, with any obvious issues discovered during this phase being used to improve the design and architectural documentation.

Laying out these foundations involves creating the codebase’s basic layout, including details like creating header and source files with appropriate naming. Next, within these files the architectural structure is laid out, such as creating the skeletons of types, classes, functions and methods that establish the APIs.

For each file a heading comment block is added that briefly summarizes the file’s purpose, the features contained therein, as well as a truncated change list with date and name, for accountability.

At this point we are ready to pour in the details of each compile unit’s implementation, starting by taking the design and related documents and turning the details contained therein into comments that describe the overarching design decisions, special considerations, the flow within a section and any interactions with other modules.
Fragment of the C++ port of the Sarge CLI argument library.
An example of this can be found in my Sarge command line argument parsing library, which both in its C++ and Ada form would be a very hairy mess of logic to keep track of without having the continuous flow of thought describing what is happening, why it’s happening and relevant implications.

Although it may seem simple and obvious, doing this consistently and in a way that doesn’t leave future you staring dumbfounded at a section of code, or chasing red herrings during a debugging session due to a flawed assumption is somewhat of an art. Here it’s crucial that whenever you find yourself in such a state that the relevant inline comments are updated or new ones added as necessary to prevent future confusion.

It shouldn’t even have to be said that keeping these comments – and related documentation – updated whenever code changes are made is absolutely paramount as well. While it’s ‘boring’ work, you don’t do it for your present self, but your future self and/or fellow developers who’ll otherwise use extremely colorful language related to your person.

Documentation And Tests

Writing the documentation with CDD starts from the first list of requirements, with the design document being the next major part, both providing the higher-level overview of the project before diving into the nitty-gritty of the architecture and implementation.

What the best approach here is largely depends on the project and who might be interested in documentation and to which extent. For a typical commercial project where there never is budget for ‘writing documentation’, simply having the design document and the detailed inline comments in the source might be what one has to settle for.

Here it might also be possible to use said inline comments to generate e.g. API listings from with tools such as Doxygen. My own experiences with such tools are mixed, but in a CDD context such auto-generated documentation could be significantly more useful, not to mention accurate.

Finally, any tests required to test specific functionality would be defined along with the code’s architecture, letting it define the testing scope rather than vice versa. With APIs for modules already settled early on, writing unit- and integration tests tends to be a lot easier and without the nagging and nebulous goal of that mystical ‘100% test coverage’.

Mitigating Circumstances

Of course, not every software project is the same, especially for hobbyist projects where you’re often the sole maintainer. It is here your prerogative to take all the shortcuts you want, as long as it is in the knowledge that you’ll only have yourself to blame.

This is why some of my projects are definitely a bit more loose in their adherence to CDD, while others are a complete stickler. for example, when I created my NyanSD network service discovery protocol, I started by writing out a complete requirements and design document, including the protocol itself. By following the top-down CDD approach here I was able to design and implement the entire protocol in the course of about two days, and have it mostly work first try.

Ultimately, CDD in my eyes is the correct approach to software engineering, as it saves a lot of time while being the only approach that actually follows basic engineering principles. You can change the field, but ultimately both physics and underlying hardware remain just as unimpressed by your personal views on how things ought to work.

hackaday.com/2026/06/11/the-me…

The weather is warming up, and for many of us that means more time spent working out in the yard. You probably won’t find any new life or new civilizations out there, but if you’ve spent the last few months indoors on your computer, the garden may as well be a strange new world. In that case, you’d do well to equip the members of your landing party with this Star Trek: The Original Series hose sprayer designed by [Curt Turner].

If you’re wondering how [Curt] managed to 3D print a functional hose sprayer, the short answer is that he didn’t. Once assembled, the printed parts cleverly attach to the top of a standard sprayer, specifically the model 56516 “Pro Flo” from Orbit. Without the design constraints that would have come from trying to make the thing actually contain pressurized water, [Curt] was free to focus on the aesthetics, and it shows.

Even with a garden variety — no pun intended — sprayer strapped to the bottom, it’s remarkable how much the “Sprayser” looks like the real thing. Well, not real, but you know what we mean.

[Curt] has also done an excellent job documenting this project for others that want to imagine they’re fighting off Romulans in their backyard. He’s got assembly diagrams that break down which color each of the principle components is to be printed in, as well as a build video that we’ve embedded below.

We’ve seen a fair number of Star Trek props built over the years, some of which have packed in considerably more functionality than anything they would have had back on the set. These days you can even by an officially licensed tricorder that can actually do some of the things the fictional versions were capable of.

youtube.com/embed/Zh9aOr3lYZo?…

hackaday.com/2026/06/11/3d-pri…