TechyMagThings

Palm OS, an operating system for a range mobile devices that predated mobile phones, is largely forgotten today. Or at least, that’s what [Aaron Ardiri] thought.

That all changed when he was contacted by a developer about some Palm OS software he had written decades ago. He soon realized there was a whole community of enthusiasts enthusiastically exploring a platform he had assumed was a forgotten layer in the strata of early mobile computing history.

This led [Aaron] to dust off and publish his substantial personal archive of development tools, source code, documentation, and more all related to his years of working with Palm OS in the early days of mobile computing.

When it comes to the importance of preserving computing history, we can’t put it better than [Aaron] himself so we’ll just quote him here:

Preservation is not simply about keeping old files. Source code, tools and documentation provide a record of how engineers solved problems under the constraints of their time. They also preserve knowledge that is easily lost when companies disappear and platforms are discontinued.

In many ways, Palm OS devices like the PalmPilot have very little in common with modern mobile computing platforms. They had to do more with less, and development reflected that. If you’re curious what these devices were like, here’s a great tour that includes a browser-based emulator.

[Evan Monsma], the prolific experimenter with cameras, found himself with an issue: he had a small Sony action camera with good performance in every respect but battery life, which was as low as twenty minutes. This was too short for practical everyday use, so [Evan] built an external adapter to add a larger battery and a few other features.

In fairness to the camera’s designers, it wasn’t really meant for consumer use; it was meant as more of a stunt camera, where endurance is less of a concern than size and weight. [Evan] wanted to use it for more general situations, hence the new battery. He first attached a small CNC-machined aluminium half-cage, which provided mounting points for additional hardware, including a screw-mount for a neutral-density filter.

[Evan] next designed, 3D-printed, and attached a mount and battery clip for a larger Sony camera battery; the mount also held a voltage converter to step the battery’s 7.2 V down to the original battery’s 3.7 V. A USB power adapter slotted into the battery compartment and broke out the power leads to the converter. Unfortunately, short battery life isn’t the camera’s only issue; it also eventually overheats with continuous use, which kept [Evan] from running a real battery-life test. He is, however, confident that it will last long enough for practical use.

We’ve seen a similar action camera mod before, as well as a mod to allow the use of third-party batteries in a vendor-locked camera. For larger cameras, we’ve even seen a hot-swappable battery pack.

Thanks to [Luis Mercado] for the tip!

The Amazon Echo Dot is one of Amazon’s so-called ‘smart speaker’ offerings that tie into their larger Alexa-fueled ecosystem, designed to be a pretty minimalistic device that gives you access to this voice assistant and also the Amazon AWS cloud access to your home. If that latter part isn’t really your jam, you can always try to unshackle the device from the Amazonian cloud by rooting the device, as [Andy] recently did with a 2018 Echo Dot 3.

In addition to the video there is also a blog post in which the steps required to root the device are covered. This is then used to turn the device into a Home Assistant voice satellite, using a Claude-vibecoded project created by [Julian Imhof]. As [Andy] notes, this code seems to work, but it’s completely unaudited so YMMV. Device support is also limited to only certain Echo Dot and Echo Show devices as listed on the project page.

The first step is to gain USB access to the board inside the device, which for USB-less devices like the Dot in question requires opening the device to solder a USB connector onto the test pads that are available on the PCB. For other Echo devices you can just use the existing USB port, which makes this first step slightly easier.

These devices run Fire OS, so basically Android, which means a fairly standard process of unlocking the bootloader and installing the hassmic application that replaces Alexa. During testing [Andy] noticed that voice processing was rather slow, requiring switching from Whisper to Speech-to-Phrase to make simple things like turning a light on not take a minute.

Overall it seems like a pretty decent way to repurpose these devices as ESPHome devices, with a few gotchas when it comes to the resources required for local voice processing.

It’s no big secret at this point that we are looking at the final years of the two venerable Voyager spacecraft. With their power supplies diminishing and their 1970s-era electronics still giving it all they got, their teams are working miracles to stretch out the time to the final goodbye for as long as possible. Despite these efforts Voyager 1 went silent for more than 24 hours on October 18 and 19, with the team still trying to figure out what happened.

The most recent change to Voyager 1 was the same ‘big bang’ switching of multiple instruments to lower-power versions, while keeping an eye on keeping the electronics and fuel at reasonable temperatures. This should give both spacecraft a few more years before power reserves fall below usable levels. Whether this switch is related to this communication blackout is currently unknown.

From the diagnostic data that the team obtained after communications were restored it’s clear that a group of thrusters went offline with backup units kicking in, indicating that the onboard computer detected some kind anomaly with the former. Whether this is a recurrence of the clogged fuel lines that has been observed before will have to be investigated.

We still fervently hope that both Voyagers can make it into the 2030s before both of them will fall silent forever. Final goodbyes are never easy, but we are most grateful to the Voyager teams over the decades for going above and beyond to make sure that literally everything has been attempted before those fateful days arrive.

Thanks to [Mark Stevens] for the tip.

Those in the virtual reality scene might be interested in [Prohurtz]’s add-on for the Bigscreen Beyond VR headset. BSB-SLAM adds SLAM (Simultaneous Localization and Mapping) tracking to the headset by attaching a sensor to the front of the headset, and providing the software to tie the two together. As a result, the headset can be fully tracked in 3D space with no need for external base stations. It essentially adds inside-out tracking as a DIY add-on.

Just to be clear, that doesn’t mean the headset becomes wireless. The Beyond connects to a PC, essentially acting as a display, and that part is the same. But it does mean the headset is no longer tied to having to work in a room with base stations pre-installed.

[Prohurtz]’s solution does this by adding a small off-the-shelf Xvisio XR50 board, USB cable, and 3D-printed mount to the unit. The headset works as normal, just with some extra software needed to use the sensor data in lieu of the base stations.

As far as sensors go the Xvisio XR50 is a bit spendy, but the fact that a small and lightweight SLAM sensor that’s capable of delivering positioning data suitable for tracking a headset in near real-time can be bought online and so readily adapted is pretty interesting.

[Prohurtz] got the idea working back in 2025 but it’s now at the point where one can order a part, print an adapter, and be off to the races with a software package.

This isn’t [Prohurtz]’s first time with VR hardware, either. The EyeTrackVR eye tracking add-on is also their work, combining largely off-the-shelf hardware into an effective DIY solution for VR use.

[Dave Farquhar] takes a walk down memory lane about the Commodore 1600 VICModem, perhaps the first phone modem to sell for less than $100. Commodore, of course, was famous for making cheaper computers like the VIC20, the Commodore 64, and lower-cost peripherals like disk drives. But how did they hit the $100 price point with the modem when competing 300 baud modems sold for at least twice that, and a 1200 baud unit would set you back at least $600?

First, Commodore didn’t handle the design themselves. Instead, they outsourced to Anchor Automation, a well-known modem manufacturer. It used a Motorola MC14412 modem on a chip, along with six other chips. The chip could, in theory, do 600 baud, but the modem was rated for 300. But it did make some interesting design choices.

Old-school modems were not allowed to connect to the phone lines directly, so you dialed the phone number and then shoved the handset into some padded cups known as an acoustic coupler that placed a microphone next to the phone speaker and a speaker next to the phone microphone. Modern modems didn’t have this problem (thanks, in part, to Tom Carter), and the VICModem also connected directly. But to save money, it couldn’t dial the phone for you. The idea was you’d dial the phone like you would with an old acoustic modem and then pull the handset cord and plug it into the modem yourself.

There was a problem. In those days, old phones didn’t always have a plug on the handset. Ironically, according to [Dave], the company bought phones to bundle with the modem in Canada only to find out the phones they bought had hard-wired handsets and were not usable. Not only that, if the phones had been the right kind, they would have been illegal in Canada at that time since the phone rules prohibited modular jacks for the handset.

To fix the problem, they also bundled the VIC-1605, which was essentially a Y cable for the phone. You plugged it into the wall, and then plugged the phone into an RJ-11 and the modem into an RJ-9.

There were other cost savings, too. There was a switch that determined if you were originating a call or receiving one, for example. A great example of how to design something as cheaply as possible, other than the faux pas with the phone connectors.

These days, it is hard to find a modem, but even if you do remember them fondly, it is surprising how old they really are and how little you needed to make a low-rate acoustic modem.

When it comes to internal combustion engines (ICEs), it’s generally accepted that each cylinder doesn’t have more valves to let in a fresh fuel mixture and to exhaust the aftermath than absolutely necessary. You could argue in favor of this also because it reduces the amount of valve seat surface and thus the potential for leaks, but there is historical precedent for higher valve counts. Hence [Alexander’s Laboratory] had to give a ten-valve engine a shake, just to see what effect adding more valves has.

A cited historical example is the Yamaha FX750, which features a five-cylinder engine that has three inlet and two outlet valves per cylinder, making for a 20-valve design that is claimed to improve performance, also because each valve can be smaller and lighter than with a single valve per side. Other motorbike manufacturers would also try such configurations, with some fascinating examples shown in the video.

What [Alexander] tries here is to create a 10-valve version, for a symmetric five valves intake and five for exhaust. Rather than building an entire engine from scratch, the largely 3D-printed ICE that was featured in previous videos will be modified with a new cylinder head, replacing the current four-valve one.

For the custom valves large wood screws are used, after making sure that they can take the heat of the combustion. Making even ten of these small valves fit was a challenge, but ultimately got squeezed into a CNCed aluminium and nylon-printed hybrid cylinder head. The existing camshaft was reused by using an adapter that simply drives five valves at the same time.

After some troubleshooting and tuning the engine actually runs pretty well, though sadly no comparison metrics were provided versus the four-valve version of the cylinder head. Hopefully we’ll see this in an upcoming video.