Mysterious Files PH

In many places, municipal water from a utility is something that’s often taken for granted. A local government or water utility will employ a water tower or pumping facility to ensure that there’s always water available to every home and business connected to it, all day, every day, and at a relatively constant pressure. This isn’t true the world over, though, and in [Sameer]’s home of Rajasthan he has to deal with a particularly onerous problem with the local water supply. Although he is connected to a utility, there is only water available at certain times of day, and not on a reliable schedule or at a particularly high pressure. This causes all kinds of problems, but he was able to employ an ESP32 to solve some of the headaches.

Most of [Sameer]’s neighbors install small pumps on the water main to pull water into reservoirs when it’s available. This creates two major problems, the first of which is that with all these pumps running, they can sometimes pull a vacuum on the water main, which can draw in contaminants and cause cavitation in the pumps. The second is that, if these pumps are on a timer and run when there’s no water available, they can damage themselves. [Sameer]’s solution pairs a flow sensor with a pump that is controllable via an automation tool like Home Assistant. He also includes a hydraulic analysis of this particular situation, such as placing the sensor on the output side of the pump rather than the inlet, as well as making sure that there is a laminar flow of water in the pipe it is installed on to ensure that it is taking valid measurements.

With everything set up and running, the water pump can automatically detect if there is water available, pump it to the reservoir as long as it lasts, and then automatically turn off the pump to avoid any thermal damage from running dry. [Sameer] even includes a complete Home Assistant setup for those who would like to replicate his work. We also think that this has utility outside of household water supplies as well, perhaps those watering their gardens with stored rainwater or those using other unique, semi-automated water catchment systems.

It’s no real secret that modern-day cars are basically a collection of computers on wheels, which also means that we get all the joys of debugging complex computer systems and software with cars these days. Rather than a quick poke under the hood to rebuild a carburetor and adjust the engine timing by hand, you’ll be pulling out a scan tool to gain access to the computer and figure out why the darn thing won’t start after someone else used a scan tool on it, as happened to [DiagnoseDan].

The question was whether the third-party scan tool that was used by the owner had done something to the software settings that would prevent the engine of this 2012 Renault Megane RS from starting, such as erasing keys, or if it was something more subtle. With no stored fault codes and the engine having healthy fuel, spark, and cam sensor readings, the conclusion was that the ECU was not doing its fuel injector things for some reason.

Ultimately, the root cause was that the ECU had been modded, with a re-mapping performed in 2020, meaning that the scan tool that [Dan] was using couldn’t properly interact with the ECU. Reflashing the ECU with the original manufacturer’s firmware was thus the next step, which is pretty involved in itself.

Reinstalling the OS on the car proved to be the solution. Likely, the modded firmware had stored some fault codes, as the ECU normally doesn’t start the engine if there are active codes stored. The third-party scan tool was thus likely blameless, but the inability to just clear fault codes was the real issue.

One of the joys of browsing secondhand shops is the possibility of finding old, perhaps restorable or hackable, electronics at low prices. Admittedly, they usually seem to be old flat-screen TVs, cheap speakers, and Blu-ray players, but sometimes you find something like the Dash, an educational toy robot. When [Jonathan] came across one of these, he decided to use it as a turtle robot. However, he found the available Python libraries insufficient, and improving on them required some reverse-engineering.

While [Jonathan] was rather impressed with the robot as it was – it had a good set of features, and thought had clearly been put into the design – he wanted a more open way to control it. There was already a quite useful, official Python program to control the robot over a BLE connection, but it only worked with Python 2 on OS X ([Jonathan] theorizes that it might have been written as a development tool, open-sourced, and not diligently supported afterwards). There were also a few third-party libraries ported to Python 3, but they all seemed to be missing some important features.

All the newer libraries were limited because the official library passed commands to an OS X binary, which handled the actual communication, so anyone wanting to do everything in Python would have to reverse-engineer the communications protocol. [Jonathan] therefore used Ghidra to decompile the binary. He first found the JSON structure used for message data, followed by a function that reads command information and sets up packets, and a mapping between Python command names and command IDs. Once he found the section that creates packets from data, he was able to port the program to Python 3. Interestingly, examining the binary revealed some previously unknown commands that appear to be capable of defining autonomous behavior.

We’ve previously seen Ghidra used on devices ranging from a camera to a router; if you’d like to learn more, there’s a HackadayU course on it.

Are you in the mood for a retrocomputing deep dive into the Scriptovision Super Micro Script? It was a Canadian-made vintage video titler from the 80s, and [Cameron Kaiser] has written up a journey of repair and reverse-engineering for it. But his work is far more than just a refurbish job; [Cameron] transforms the device into something not unlike 8-bit homebrew computers of the era, able to upload and run custom programs with a limited blister keypad for input, and displaying output on a composite video monitor.

A video titler like the Super Micro Script gave people the ability to display bitmapped images (like text or simple graphics) onto a video stream electronically. A standalone device, under the hood, it uses a 6502 as CPU and a Motorola 6847 VDG video chip. [Cameron] observes that architecture-wise, it actually had a lot in common with early 8-bit home computers. Sure, it performed only one “job” but that really had more to do with its restrictive firmware than anything else.

[Cameron] obtained a used unit and repaired it, reverse-engineered the scrambled address and data lines (an anti-cloning and anti-tampering measure), and converted it into something for which he could write his own software and run his own programs. As for uploading those programs? A bit-banged serial port on I/O borrowed from the blister keypad, running at a frankly quite respectable 19.2 kbps.

We hope you’re intrigued, because [Cameron] has one more surprise: he created a MAME emulator for the Super Micro Script called SMSBUG. Originally created to make software development easier, its existence also means anyone can join in on the vintage computing fun. The emulator, along with other handy utilities and info, is available on GitHub.

The lovely thing about the x86 architecture is its decades of backwards compatibility, which makes it possible to run 1990s operating systems on modern-day hardware, with relatively few obstacles in the way. Recently [Yeo Kheng Meng] did just that with Windows 98 SE on a 2020 ThinkPad P12s Gen 1, booting it alongside Windows 11 and Linux from the same NVMe drive.

Naturally, after previously getting MS-DOS 6.22 from 1994 running on a 2020 ThinkPad X13, the step to doing the same with Windows 98 SE wasn’t that large. The main obstacles that you face come in the form of UEFI and hardware driver support.

Both ThinkPad laptops have in common that they support UEFI-CSM mode, also known as ‘classical BIOS’, as UEFI boot wasn’t even a glimmer yet in some drunk engineer’s eye when Win98 was released. After this everything is about getting as many hardware drivers scrounged together as possible.

[Yeo] ended up having to bodge on a USB 2.0 expansion card via a Thunderbolt dock as Win98 doesn’t have xHCI (USB 3.0) support. With that issue successfully bodged around using a veritable tower of adapters, installing Windows 98 was as easy as nuking Secure Boot in the BIOS, enabling UEFI-CSM along with Thunderbolt BIOS assist mode and disable Kernel DMA protection.

Because UEFI-CSM implementations tend to be buggy, the CREGFIX DOS driver was used to smooth things over. Another issue is the same that we chuckled about back in the day, as Windows 98 cannot address more than 512 MB of RAM by default. Fortunately patches by [Rudolph Loew] helped to fix this and some other smaller issues.

Unfortunately neither Intel nor NVIDIA have released Win98 drivers for quite some time, so there’s no graphics acceleration beyond basic VESA support and the SoftGPU driver. Disk access goes via the BIOS too rather than using an NVMe driver, so it’s not as zippy as it could be, but for Win9x it’s quite usable.

Finally ACPI wasn’t recognized by Win98, but it’s only fair to blame that on the complete flaming train wreck that is ACPI rather than anything to do with Windows. This particular issue was worked around by configuring the BIOS to support S3 power state and with that making Win98 happy again.

It’s honestly quite a shame that UEFI-CSM is largely ignored by new systems, as it makes installing even Windows 7 basically impossible, and thus creating probably the largest split within the x86 ecosystem since the arrival of AMD64/x86_64.

Musician Brian Eno’s Oblique Strategies are like a Tarot card deck full of whimsical ideas meant to break up a creative-block situation, particularly in the recording studio. They’re loads of fun to pick one at random and actually try to follow the advice, as intended, but some of them are just plain good advice for creatives.

One that keeps haunting me is “Honor thy error as a hidden intention”, which basically boils down to taking a “mistake” and seeing where it leads you if you had meant to do it. I was just now putting the finishing touches on this week’s Hackaday Podcast, and noticed that we have been honoring a mistake for the past 350-something shows. Here’s how it happened.

When Mike and I recorded the first-ever podcast, I had no idea how to go about doing it. But I grew up in Nashville, and know my way around the inside of a music studio, and I’ve also got more 1990s-era music equipment than I probably need. So rather than do the reasonable thing, like edit the recording on the computer, we recorded to an archaic Roland VS-880 “Digital Studio” which is basically the glorified descendant of those old four-track cassette Portastudios.

If you edit audio in hardware, you can’t really see what you’re doing – you have to listen to it. And so, when I failed to notice that Mike and I were saying “OK, are you ready?” and “Sure, let’s go!”, it got mixed in with the lead-in music before we started the show off for real. But somehow, we said it exactly in time with the music, and it actually sounded good. So we had a short laugh about it and kept it.

And that’s why, eight years later, we toss random snippets of conversations into the intro music to spice it up. It was a mistake that worked. Had we been editing on the computer, we would have noticed the extra audio and erased it with a swift click of the mouse, but because we had to go back and listen to it, we invented a new tradition. Honor thy error indeed.

Cyberdecks are great projects, and [Salim Benbouziyane]’s scratch-built CM Deck is a fantastic specimen. It’s a clamshell-style cyberdeck with custom split keyboard, trackpad, optional external WiFi antenna, and some slick underlighting thanks to a translucent bottom shell. There’s even a hidden feature that seems super handy for a cyberdeck: a special USB-C port that, when plugged in to another host (like another computer), lets the cyberdeck act as an external keyboard and trackpad for that downstream machine.

Notably, the CM Deck is custom-built around the Raspberry Pi Compute Model 5. When we first peeped the CM5 the small size was striking, but of course that comes at the cost of having no connectors, supporting hardware, or heat management. That’s something [Salim] embraced because it meant being able to put connectors exactly where he wanted them, and not have to work around existing hardware. A custom PCB let him to lay out his cyberdeck with greater freedom, less wasted space, and ultimately integrate a custom-built keyboard (with RP2040 and QMK firmware).

Even the final enclosure is custom-made, with 3D printing being used to validate the design and PCBway providing finished plastic shells in addition to manufacturing the PCBs. [Salim] admits that doing so was an indulgence, but his delight at the quality of the translucent purple undercarriage is palpable.

[Salim]’s video (embedded below) is a deep dive into the whole design and build process, and it’s a great watch for anyone interested in the kind of work and decisions that go into making something like this. Experienced folks can expect to nod in sympathy when [Salim] highlights gotchas like doing CAD work based on the screen’s drawings, only to discover later that the physical unit doesn’t quite match.

The GitHub repository contains the design files for everything, so give it a browse if you’re interested. [Salim] is no stranger to clean builds, so take a moment to admire his CRT-style Raspberry Pi terminal as well.

Thanks [Keith Olson] for sharing the tip!