TechyMagThings

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.

In the history of object-oriented (OO) computer languages, Smalltalk has a special place. It wasn’t the first OO language, and it hasn’t spread as well as some others. But it was the first OO language many people encountered, and it influenced many other languages you’ve probably seen. Developed at the famed Xerox PARC, it also introduced many people to the “model/view/controller” (MVC) architecture. Cuis Smalltalk is a free and portable modern Smalltalk-80 environment. It replaces the traditional MVC framework with Morphic, but otherwise, it would be very familiar to someone who used Smalltalk in the 1990s. The project’s goal is to stay simple at the core, although you can add complexity via packages.

The software has been around for a while, but it is on a rolling release model, so the install page suggests you clone the Git repo. You can, however, get a stable release, which might be important if you were deploying applications. Running the program results in a Cuis desktop where you can open various things like workspaces, help documents, and the transcript.

Smalltalk throws some people because it takes OO to an extreme. For example, you don’t add two and three using an operator. You send the object two a message that includes another object, three. You can think of sending a message as calling a method on an object. As with virtual functions in C++, different objects can respond differently to the same request. For example, an Animal class might have a speak message that causes a cow to print “moo” and a chicken to print “cluck.”

You get used to it, and there’s a very nice class browser that lets you examine classes and what you can do with them. There are even packages to work with an Arduino over a serial port. They haven’t been updated lately, so they might (or might not) need a little work.

We’ve looked at GNU Smalltalk before. We’ve also seen a version that runs directly on a Raspberry Pi.

When working on an electronic project it’s likely you will find yourself working with a variety of different instruments, be they logic analysers, oscilloscopes, or whatever. These can take up a lot of space, not to mention cost a bundle of cash. [Max.K] came up with PicoLab as a solution, it’s an all-in-one box containing a 4-channel oscilloscope, 8-channel logic analyser, GPIOs, a data logger, and serial, SPI, and i2C interfaces. There’s even an adjustable power supply!

Behind it all is an RP2350, in its larger package with more pins, coupled to some custom interface and protection circuitry. Perhaps the cleverest part is its interface, which it serves as a web site on the network card it exposes through the USB port. Any OS that supports a web browser and USB networking can thus use this thing. You can find all the code in a GitHub repository, should you wish to have a go at building one yourself. We like this idea.

Some MiSTer users put a small secondary “marquee” display on the FPGA board that can show information about the system such as the currently loaded core and what game it happens to be running. Generally these take the form of a small monochrome OLED display, likely the one most of us have sitting in a parts bin somewhere.

But [Erico Mendonca] wanted a something with a bit more style, so he’s come up with a firmware for the ESP32-C3 that connects to MiSTer’s existing secondary display protocol but works with slightly more visually impressive panels such as the round GC9A01 that so many hackers have been playing with as of late. If the whole circular display thing isn’t your…thing, you can even run the firmware on the Cheap Yellow Display for a turn-key rectangular experience.

Because [Erico] didn’t want to fiddle with anything on the MiSTer side of the equation, his firmware has to do the heavy lifting when it comes to the art that shows on the display. So there’s a web-based editor that lets you put together your own artwork to show on the marquee based on what command the MiSTer has actually sent out. Flashing the firmware on the ESP32 can be done through the browser as well, as is becoming increasingly common these days, making it relatively easy to get this project up and running.

With this project it’s also possible to control multiple client displays over WiFi from one system, just in case you wanted to show off what console you were booting up in multiple places.

We’re fans of the round display here at Hackaday, so it’s been great to see more folks putting them to use as of late.

We’re living at an interesting time here in 2026, when microcontrollers are becoming powerful enough to surpass the capabilities of “real” computers from a time when those real computers were starting to become useful. We’ve seen plenty of microcontrollers emulating machines from the 1990s, but what if instead they were giving all their power to the OS? It’s a question [Thomas] is trying to answer with SylphideOS, a general purpose GUI operating system aimed at multiple microcontroller platforms.

On the surface it has a GUI that appears to owe a lot to the early Macintosh machines, but underneath it has the FreeRTOS kernel, something that has been around for quite a while. You can argue among yourselves as to whether this make it an OS in its own right or a FreeRTOS distro. Aside from driving a screen through a framebuffer it also has the hardware interfaces you’d expect, for keyboard and storage. There’s support for RP2350 and selected ESP32 platforms so far, as well as an emulator.

We have already seen a few operating systems for microcontrollers that provide a user interface for a binary bootloader rather than persisting under whatever programs are running, so this marks an interesting departure. Only time will tell if it becomes a success, but perhaps it’s one to watch.