TechyMagThings

If you were in the market for a games console in 1990, the chances are that the object of your desire was either a Super Nintendo with its 16-bit 6502 derivative, or the Sega Megadrive, sold as the Genesis in North America, with its Motorola 68000. Both machines featured impressive graphics and sound for their time, but they remain firmly in the 16-bit era. Which makes it a surprise to see LinuxMD. It’s Linux, for the Sega Megadrive, with the latest mainline kernel.

The Motorola 68000 series of chips was the first porting target for Linux, and is still maintained in 2026. This build runs from an SD card  in a modern Megadrive storage peripheral, and is reported to run on the original hardware. The lowly 68000 in the Sega doesn’t have a memory management unit required for the full Linux experience, so what’s really running here is a kernel compiled with the -nommu option. That in itself is a feat, on this architecture. On it you get smolutils, a cut down coreutils, and that seems to be it.

We like this project, for pushing both console and kernel to the limit, even though we see that maybe it’s not the most practical Linux machine. Meanwhile though, this isn’t the only UNIX-like OS for this console.

Image: Evan-Amos, Public domain.

Offloading acceleration and braking to an electric motor in a hybrid configuration allows the less efficient combustion engine run in a more narrow set of RPM and torque ranges. In some cases the motor is decoupled from the mechanical drivetrain entirely and used simply as a generator, where it can run at a single speed all the time. And this concept isn’t limited to passenger vehicles, either. [rctestflight] put this premise to the test using a small knockoff Honda motor as a generator for an electric boat.

This project builds on a previous version where he used a much smaller hobby motor to see if it could generate usable power, and that system powered a small autonomous boat as a proof-of-concept. Those motors aren’t really designed to be used in this sort of application though, so this build upgrades the internal combustion engine and pairs it with an electric skateboard motor that’s configured to run as a generator. The setup is capable of producing almost 800 watts for as long as the gasoline lasts, provided that the 3D printed parts all hold together and the other parts don’t vibrate off of the assembly.

Out on the lake at full throttle, the small generator can get the boat up to seven knots (13 kph) but at this speed [rctestflight] reports that the generator is “quite unpleasant” due to the noise and vibration. Instead, he ran it on a test bench at several RPM and torque points and documented the efficiency of the motor at each one, and then operated the boat mostly at the point he found it to be most efficient. For a hybrid drivetrain, that not only decreases noise and vibration, but also maintenance and fuel efficiency.

Although the energy density of fossil fuels is much better than batteries, a fuel-free long-distance option is still available if you’d rather equip your boat with solar panels instead.

Sometimes, it’s hard to stop picking up your phone every few minutes to check on notifications and scroll endlessly through the slop of the day. [PushpendraC2] has been working on a solution to this problem that would ideally discourage such behavior —  a nifty little smartphone stand!

The concept is straightforward enough—the smartphone stand uses a simple tactile button to determine if your smartphone is sitting on the little 3D printed shelf, or not. However, the smarts inside do a bit more than that, too. An ESP32-S3 is charged with monitoring whether the smartphone is sitting in place, and starts counting “focus time” while it’s there. If the phone is picked up, the OLED display on the shelf starts ticking down a 5-second timer to encourage you to put it back. If you don’t, the focus time is reset and you lose your streak.

It’s also possible to tap a touch sensor on the device which sets a reminder timer, prompting you to put your phone back after a set period of time, between 2 to 30 minutes. A buzzer will then start going off to prompt you to put the phone down. If you want to track the devices impact, you merely need to log in to the web server hosted by the ESP32, which shows your current focus session time, along with a heatmap of your daily productivity.

It’s a simple idea, but one that uses a few neat psychological hooks to encourage compliance and behavioral change. We’ve featured similar projects in this vein before, No surprise, as phone addiction is a problem experienced by many.

Reachy Mini is a limbless desktop robot from Hugging Face made for human interaction experiments, and to give you an idea of what it’s like is a guide on how to implement expressive, local conversational AI complete with head movements and antenna wiggles. It’s conversational in the sense that it aims to feel natural, with low-latency responses and the ability to interrupt, with everything running on local hardware if one so wishes.

The software stack is essentially VAD (voice activity detection) → STT (speech-to-text) → LLM (large language model) → TTS (text-to-speech) which allows users to tweak things to their liking, or independently swap or modify pieces as things evolve.

This also allows users to tailor the services to match whatever their hardware is capable of. For example, one could easily use a frontier AI model via remote API for the LLM while keeping everything else local.

The local models in the example configuration are effective and relatively modest (Qwen3-4B-Instruct for the LLM, and even smaller models for the rest) but it’s nice to have the option to offload parts to remote providers if necessary.

Reachy Mini looked very interesting when it was launched as a kit last year, and since then Hugging Face has built up an impressive software suite and infrastructure through which users can easily share their applications. If you’re curious, there’s a simulator for Reachy Mini which should give you an idea of what it can do.

RC planes are a lot of fun, and the bigger the better! [Ramy RC] has built the world’s biggest RC A380.

At 29 ft (8.83 m) long, with a 32 foot (9.75 m) wingspan, and weighing 800 lb (362 kg), this 1/8 scale jumbo jet is not your typical model. The fuselage is built from CNC cut EPS foam layed up with fiberglass on the outside and carbon fiber inside. The wings have a combination of carbon, aluminum, foam, and wood components to handle the aerodynamic loads.

The attention to detail is wild. Instead of painting the windows, each one is an actual hole in the plane with a 3D printed window frame and acrylic window. You can actually see one falling out of the plane in the video below. An Airbus mechanic in the comments even notes the landing gear door order of operations are identical to the real thing.

If [Ramy] looks familiar, perhaps you remember his previous A380 build? Much like the 747, the full size A380 is no longer in production, but they can run on cooking oil while they’re still flying.

YouTube streaming typically involves a camera with an HDMI output, a USB3 HDMI digitiser, and a suitably beefy PC to run it all. It’s quite a process, and for [Coreymillia], more complex than it needs to be. He’s come up with something simpler, a dedicated self-contained streaming rig using a Raspberry Pi 4.

As you might expect it uses the Raspberry Pi HQ camera at the optical end, but it’s the software surrounding it that transforms it from a mere camera into a streaming rig. There’s a web based user interface, but perhaps more interesting are the companion dashboard peripherals. A Raspberry Pi or an ESP32 Cheap Yellow Display can both serve as a small in-view dashboard and controller.

We know from experience that a stream can be a difficult thing to get right even with high-end hardware, and we’re interested to see this standalone device allowing , we hope, an easier way to do it. If you’re a streamer we’re guessing you’ll be taking a closer look. Even so, this is surprisingly, not the simplest Raspberry Pi based streaming device we’ve seen.

Swift is a relatively modern program language, appearing in 2014 as a replacement for Objective-C. Since then, it’s become a popular solution for programming apps across Apple platforms. That led [Yeo Kheng Meng] to a simple yet fun idea—porting Swift to the oldest Apple platform of all.

Yes, [Yeo] managed to build a development environment for Swift that targets the Apple II platform. Not just one machine, either—everything from the original Apple II up to the IIe and a little beyond. Now, the Apple II is very different from modern Macs and iPhones and the like, having debuted in 1977 with a 1 MHz 6502 CPU and a minuscule 4 KB of RAM. But that doesn’t mean you can’t use a modern language to develop for it!

[Yeo] does a great job of explaining how it all works, and how Claude Code and GPT 5.5 Codex were used to help piece things together. The compiler is set up to spit out bytecode that’s executed by a virtual machine running on the 6502. The target was to allow the setup to work on a standard 1977 Apple II from the factory, which would allow it to then run on subsequent models without issue. However, there is a small note— [Yeo]’s implementation requires the RAM to have been upgraded to 48 KB.

We love seeing modern stuff ported to the Apple II. This Portal port was a particular highlight.