2026-09-15 04:00:58
There are many uninterruptible power supply (UPS) solutions for the Raspberry Pi that take the form of HATs with a battery on board, but they’re not suitable for every situation. Web3-Pi are using the Pi 5 as an Ethereum node, and found the need for a UPS that didn’t sit on top of the Pi. Their solution is the Web3 Pi UPS, a device that sits in the USB power chain.
It’s a box that takes three power inputs, USB-C PD, a barrel jack, or a hot-swappable Sony camera battery, and puts out the constant 5 V at 5 A the Pi requires. The USB output isn’t just for power, it can communicate with the Pi to deliver telemetry and ask the OS to shut itself down if power reserves are failing. Inside are a CH32 RISC-V microcontroller that handles the power circuitry, and an RP2040 that handles control and an OLED screen for a UI. The project’s web site also mentions provision for an LTE add-on for remote monitoring, however this doesn’t at the time of writing appear to be fully implemented in the GitHub repository.
While it’s probable that few of you are mining Ethereum on your PI, we can see that there are plenty of other situations that this project could find a home in. It’s not the first Pi UPS we’ve seen, though some of them are considerably less complex or capable.
2026-09-15 02:00:00
With VHDL being arguably more deterministic and bullet-proof than Verilog, it’s good to see another open source VHDL simulator joining the fray that is not a variation of ghdl. Written by [Óscar Grimal] in C++ with an MIT license, the Pulse project is a still in progress package that provides the entire toolchain, from the compiler to the requisite waveform output.
This waveform output is provided in the form of a text-based user interface (TUI), which at the very least helps a lot with making it cross-platform compatible. As dependencies only a C++20 capable compiler and CMake are indicated.
Of course, with VHDL being a rather hefty language especially once you start piling up the associated standard library, the currently supported language and library features are somewhat limited still so that you’re limited to basic IEEE packages and types, with default values are not supported yet.
Per the roadmap on the GitHub project’s Readme more VHDL language features including generics and additional types will be added, along with an enhanced simulation engine. It’s also said that mixed-language support with Verilog will be added, though SystemVerilog looks to be getting the short end of the stick as usual.
It will definitely be interesting to compare this package to ghdl.
2026-09-15 01:05:29
If you’re in motorsport, or maritime, or mining fields, you can always call on a technician to come down and fix something when it’s broken. You can lay hands on the parts, reconfigure things, make repairs, and get something working again. In space, that’s seldom possible. If you’re lucky enough to have a manned mission, you might be able to make some running repairs; if you’re working with an unmanned robot, probe, or satellite, your potions are altogether more limited. If you can’t find a fix, it’s game over—a particularly brutal result when huge budgets and years of work are on the line.
Janelle Wellons came down to Hackaday Europe to talk about space. More particularly, the engineering and debugging operations that keep all sorts of space programs alive. Her talk dives into some of the creative solutions engineers have had to come up with to save million-dollar missions from becoming unrecoverable boondoggles.
Janelle came down to Hackaday Europe to talk about space, because she lives and breathes it. An experienced aerospace engineer, she’s worked at NASA JPL and iSpace, contributing to the success of missions taking place far from our humble globe. She drew on that experience to talk through what it takes to keep a mission on the rails when things go a little sideways, which happens in space, just as it does anywhere else.
A fantastic example of that, retold in her talk, is the Galileo mission. It was built to travel far across the solar system, eventually winding up at Jupiter to study the Red Giant and its moons. The probe was engineered with a pair of communication systems—a low-gain antenna for vital signs and management, and a high-gain antenna for sending science data and images back to Earth. The high-gain antenna was key to the mission, capable of offering 10,000 times the bandwidth of the low-gain antenna.
Tragically, though, the high-gain antenna never got to play its starring role. It didn’t deploy properly after launch, and that left NASA with a probe capable of capturing all this fantastic science data, but no way to send it home at a reasonable data rate. Janelle steps through the multiple hacks that make the most of the communication link with the low-gain antenna. NASA engineers whipped up compression algorithms for images and science data, and figured out how to array several Deep Space Network antennas for better signal. This netted an effective data transfer rate of 1,000 bits/second with the low gain antenna. It was still a far cry from the 134 kilobits per second that should have been possible with the high-gain antenna, but a huge leap forward from the 8-16 bits originally possible with the low-gain rig. Ultimately, it saved the mission, allowing the capture of mountains of scientific data on the largest planet in the solar system.
“NASA Astronaut Christina Cook is also working through troubleshooting steps of the waste management system that’s aboard the Integrity spacecraft.” – Ground control, Artemis II mission, 2026
Another great story told by Janelle concerned the Artemis II mission. The lunar flyby was part of NASA’s efforts to eventually return to the Moon itself, and was notable for debuting some special new hardware—the toilet. Unlike previous visits to the moon as part of the Apollo program, Artemis astronauts travel in luxury, with a proper commode built to handle the specific requirements of the zero-gravity space environment. Unfortunately, though, this new hardware had plenty of teething problems.
Early attempts to repair the system involved attempting to reprime the toilet’s pump by adding water to the system. It wasn’t long before the toilet threw another error, though. On the short-duration Artemis II mission, the toilet was set up to vent urine to space. Only, venting wasn’t working—with the suspicion being that the vent pipes had frozen over. The trick to solve this was simple—turning the spacecraft to face the vents towards the sun, so as to heat them enough to melt the blockage. Janelle also notes that during the multiple periods the toilet was down, the astronauts had to rely on alternative means of passing waste—showing a slide of the “collapsible contingency urinals” that did the job.
There’s also a great look at Perseverance’s twin, which lives here on Earth. Janelle has been down to the Mars yard at NASA’s Jet Propulsion Laboratory, where engineers, in her words—”test before you do.” The problem is, when you’re driving a robot on a foreign planet, you can’t just send someone over to repair a broken wheel or flip it back up if it tips over. Thus, many maneuvers and operations are rehearsed in the Mars yard with the twin of Perseverance, running it over recreated obstacles to determine a safe plan of attack.
2026-09-14 23:30:23
Recently researchers finished mapping the central nervous system (CNS) connectome of not just the female Drosophila melanogaster (i.e. fruit fly) brain, but also that of the male D. melanogaster for a comparative analysis. Here the sexually dimorphic changes turned out to induce specific mating behavior that ensures that there will only be smooching between genetically fit D. melanogaster males and females, while the rest of the connectome remained effectively the same.
Of course, with this connectome in hand it led some people to ask themselves what else one can do with this connectome graph of about 160,000 neurons other than make a fruit fly into a fruit fly. So far we have seen [Nftechie] turn this connectome into a crypto stock trader with the Stonkfly project that uses the connectome’s reward circuits to potentially make profitable trades, though [Nftechie] says that they haven’t verified yet how good a fruit fly is at trading stocks, only that it does said stonks.
Over at [PC Gamer] they summarized a number of things that people have also done, including trying to make the connectome control a game of DOOM and Beat Saber. Each game frame stimulates sensory neurons, with the generated outputs then mapped to game controls, with dopamine-producing reward circuits wired in for reinforcement learning.
Although the D. melanogaster brain is only the merest fraction of the size of the human brain, it does provide us with a glimpse of what actual artificial intelligence research may lead to, as we unravel how even a 160,000 neuron connectome is enough to make these terrors of rotting plant matter do their wonderful things.
2026-09-14 22:00:44
Most of us are guilty of romanticizing the past. Do you long to be the captain of a tall ship? Just as long as you don’t mind weevils in your food, vitamin deficiencies, and death from an infection when there were no antibiotics. Want to be a medieval knight? Even worse. But surely, retrocomputing is as fun as we remember, right? Turn your computer on, and it comes up with BASIC! Ready for you to write your own programs. None of this GUI foolishness. Of course, this is just another example of rosy retrospection.
Even if you like BASIC or a similar language today, things have changed. You have a nice text editor, a fast computer, debugging tools, along with things like named functions, no line numbers, and modern control structures. None of those things were very common in the 1980s. At least, not on a hobby-grade computer.
Why am I thinking about this? Well, the Hackaday Retrocomputing Challenge is on, and it occurred to me that I wanted to work with some young students in glorious MBASIC on a CP/M machine I built and modified from a Hackaday project. Perfect, right? Many of us started that way, so why shouldn’t they?
But it quickly got old. Even a simple program gets bogged down with GOTOs and GOSUBs to mysterious line numbers. It made me remember the time back in the early 1980s, or maybe even the late 1970s, that I wrote a BASIC preprocessor to scan BASIC with no line numbers and produce proper source, converting labels to line numbers in two passes.
Of course, that code is long gone or, at least, on a floppy I haven’t tried to read in a few decades. I decided to take another crack at it six years ago, but I still didn’t make it much more robust. For example:
PRINT: X=X+10
Is that two statements? Or a label? Hard to tell. My 2020 version used awk. Awk is great for this kind of thing because of the regular expressions and the input loop. But it still has some issues with things like comments and strings. Consider the code below.
PRINT "HELLO: IS IT ME YOU'RE LOOKING FOR?"
This would probably have made my awk preprocessor chew the string up and create a bogus label named HELLO.
Preprocessing one language to another is nothing new. RATFOR and RATFIV by Brian Kernighan converted modern constructs to conventional FORTRAN IV. Even C++ started out as a program that emitted C code.
So the idea is good, but there are dozens of corner cases. As I anticipated having another go at the idea for BASIC, I realized my earlier versions had some design choices that made it harder than it should have been. So I started from scratch.
First, I gave up the idea of just having labels as you might in other languages. Instead, they’d be part of a comment and hard to mistake. This makes for easier parsing and also allows you to keep them around for reference. I also gave up on having labels magically expand. You need a way to make them unique, too. Here’s what I settled on:
':TOPLABEL GOTO @TOPLABEL
The plan was to go through the source once to assign line numbers. When a label occurs, it adds to the symbol table. Then a second pass actually writes output, replacing @TOPLABEL with the value from the symbol table. Of course, you still want this line to not trigger a label expansion:
PRINT "Send messages to @JTKIRK"
I decided to keep going in awk, but my eventual goal was to rewrite the whole thing in BASIC using the same syntax. Then you could convert the translator itself using the awk version once and then run it on an old computer using BASIC, even if you wanted to retranslate the translator itself. Perverse, huh? But that allows you to keep that authentic development experience. You don’t have to jump over to a PC to process your code, unless you just want to.
So I decided to do a better job on the awk part with this new scheme. At some point, though, you lose some of the advantages. Then feature creep set in.
I suppose I was subconsciously remembering RATFOR. I decided to add a small number of modern control structures. Again, I wanted something easy to pick out of the source file, so I went with this:
IF X=0 THEN!
PRINT "There is no X!"
X=10
ENDIF!
There’s also WHILE!, DO!, EXIT!, and CONTINUE!
Of course, it didn’t end there. I decided to add a way to include or exclude parts of the source (sort of like #if in C but simpler), along with source code inclusion and a few other neat options such as numeric constants, conditional source blocks, compile-time errors, and even a small numeric stack with PUSH! and POP!.
The source code inclusion can be made to work with awk, but it is ugly. I decided it was better to proceed with another language, but since I didn’t feel like starting over, I just had an LLM convert my awk to Python, which it did with no trouble at all. I then did a little more feature development in Python, but I made sure not to use those new features in the translator itself so the awk version could still process an input file.
So while the original plan was to develop and test in awk and then implement similar code in MBASIC, I now had three versions: a frozen awk script, a Python version, and an MBASIC version.
This was getting a bit much to test. I had the LLM cook up some documentation, additional comments, and tests. It was especially nice to verify that all three versions — awk, Python, and BASIC — did the same things for their common features. The LLM was good at running tests and finding corner cases. It would even run tests in a RunCPM session on the MBASIC version.
As you might expect, the BASIC version is a little more convoluted. However, the use of labels and control structures makes it much easier to write, read, and maintain.
Writing the translator in MBASIC imposed some very old-fashioned constraints. There are no dictionaries or dynamic lists, so labels and block state live in fixed-size arrays. Included files require an explicitly managed stack, and parsing strings and comments has to be done character by character. It is not as compact as the Python version, but it is ordinary MBASIC and can run on the target CP/M machine. The limitations also influenced some features that would have been feasible in Python but are nearly impossible in an MBASIC program.
Better yet, lblbasic.bal stays within the subset the original awk translator understood. That provides a bootstrap path: awk produces the first lblbas.bas, after which the MBASIC translator can process its own BAL source.
One project I had in mind was to drive an LED display module. I wrote a library and then wrote the test program below. It doesn’t matter, but I used .bal as a file extension.
REM TM1637 TEST – PORT 3, BIT 2=DIO, BIT 3=CLK
REM Uses the TM1637.BAL library with LBLBASIC
STACK! 8 ' Required by the library
' Confirm that the library preserves I while initializing its data table.
I=3141
gosub @init
print "I is now:";I
PRINT "Starting number: ";
INPUT CT
PRINT "1-Up, 0-Down: ";
INPUT UD
OFFSET=-1
IF UD<>0 THEN OFFSET=1
':CDLOOP
WHILE! CT>=0 and CT<=9999
NUM=CT
GOSUB @sendnum4
CT=CT+OFFSET
WEND!
CT=0
IF OFFSET=-1 THEN CT=9999
GOTO @CDLOOP
END
' Include the library after the main program.
'INCLUDE! TM1637.BAL
The BASIC code, including a few lines of the library, is much harder to read:
10 DIM LBLBSTACK#(8):LBLBSP=0
20 I=3141
30 gosub 230
40 print "I is now:";I
50 PRINT "Starting number: ";
60 INPUT CT
70 PRINT "1-Up, 0-Down: ";
80 INPUT UD
90 OFFSET=-1
100 IF UD<>0 THEN OFFSET=1
110 ':CDLOOP
120 IF CT>=0 and CT<=9999 THEN 140
130 GOTO 180
140 NUM=CT
150 GOSUB 330
160 CT=CT+OFFSET
170 GOTO 120
180 CT=0
190 IF OFFSET=-1 THEN CT=9999
200 GOTO 120
210 END
220 ':init
230 IF LBLBSP+1>64 THEN PRINT "BAL stack overflow":STOP
240 LBLBSTACK#(LBLBSP+1)=I:LBLBSP=LBLBSP+1
250 DIM D(9)
260 FOR I=0 to 9: READ D(I): NEXT I
270 DATA 63,6,91,79,102,109,125,7,127,111
280 X=12:OUT 3,X
290 IF LBLBSP<1 THEN PRINT "BAL stack underflow":STOP
300 I=LBLBSTACK#(LBLBSP):LBLBSP=LBLBSP-1
310 return
320 ':sendnum4
330 GOSUB 500
340 B=64:GOSUB 610
If you haven’t used the TM1637 before, it uses a serial protocol with a clock and data line and is very forgiving of timing. The display update speed is quite slow, partly because MBASIC isn’t that speedy and partly because the Z80 chip communicates to the outside world via another microcontroller talking over an I2C bus. But non-BAL code would be just as slow on the same computer. You’ll notice, though, that I took all the delays out and the code and it still works fine.
The bigger sample, though, is HILO.BAL. This lets you set a few compile-time constants that let you select what parts of the program get built. It also makes good use of the control loops. Of course, if you really want to dig in, lblbasic.bal uses quite a bit of the awk-compatible syntax and is a substantial program: around 1300 source lines of BAL which generate nearly 900 lines of regular BASIC due to comment and white-space stripping.
Does this turn MBASIC into a modern language? Of course not. The generated program still has line numbers, the machine is still tiny, and the implementation makes compromises that would horrify anyone writing a real compiler. But it removes enough friction that programming the old machine becomes enjoyable again, especially with WordStar as an editor.
More importantly, the translator can live on the machine it targets. The awk prototype can translate lblbasic.bal once, producing ordinary MBASIC. From then on, the CP/M machine can translate BAL programs — including the translator itself — without help from Python or a modern computer.
So perhaps the lesson isn’t that retrocomputing was better than we remember. It’s that, with a little strategic cheating, it can be almost as much fun as we remember.
2026-09-14 19:00:12
If you had an 8-bit computer in the 1980s and bought a speech synthesiser for it, what you got was invariably an alophone-based synthesiser using the SP0256 or similar. You definitely couldn’t afford DEC’s DECtalk, a high-end standalone speech synthesiser made famous to the masses as the unit used by Stephen Hawking. But now those two worlds can come together, thanks to [Michael Wessel], whose Perfect Paul ][ is a drop-in DECtalk emulator card for the Apple ][.
The PCB includes an RP2040-based Raspberry Pi Zero, plus an I2S DAC and amplifier, speaker, and bus-interface logic. It appears at a set of memory addresses, and interfacing to it is as simple as POKEing DECtalk commands to those addresses. Looking at it, we are guessing this would be easy to bring to other 8-bit era machines.
You can see and hear it sing in the video below the break, and it certainly has the feel of the real thing. We can say with certainty that this would have been a sensation had it appeared back in the early 1980s. This one may be a modern reproduction, but it’s not the first time DECtalk has appeared here; we’ve even brought you a real one.
