UDP Broadcasting And The Joys Of IPv4 Subnetting

In the previous installment on UDP broadcasting and service discovery, the basics of both were explored, including an implementation in the form of NyanSD and its protocol. Contained in the comment section was a very good demonstration of why one of the most exciting aspects of software development is the opportunity to share your latest creations with other people. This being the ability to get solid feedback on all the points – including any potential boneheaded omissions – that you really should address, whether intentional or accidental.

The most pertinent point raised was definitely that of broadcast addresses and IPv4 subnets, with the latter topic especially being something that the sysadmins at the office would talk about all the time, but which us software developers were always happy to ignore as something that didn’t concern us. Turns out the joke was on me and everyone else – like our esteemed readers – who thought that they could escape the fascinating world of subnets, as today we’ll take an in-depth look at what subnets are and how they are relevant to the world of UDP network discovery.

I somewhat alluded in the first article to the topic of ‘which broadcast address to use’ as being somewhat of a rough topic to figure out, which is clearly why I just stuck to a blatantly ‘works for me’ /24 subnet that usually will work on networks, until it does not.

Continue reading “UDP Broadcasting And The Joys Of IPv4 Subnetting”

Using Your Own RBMK Reactor Control Center At Home

To give people the most intimate RBMK experience, the [Chornobyl Family] has been working tirelessly at not only replicating the original RBMK reactor control room and its SKALA industrial control system’s controls, but also to create a version that you could tinker with at home if you ever fancied getting your own RBMK operator license. This starts with the operator console, with its use demonstrated in a recent video including a range of common commands.

In this video the entering of codes on the console to interact with the system is detailed, including the logic behind it. In the absence of large displays to display many parameters and such, this way the operator could ‘talk’ with the control system, including obtaining current sensors readings and the setting and changing of setpoints. From the same console you can also select and run programs, which is useful for automating tasks, like monitoring coolant flows.

In the second video not only the construction of the control panel is covered, but also a visual representation of the simulated reactor core which is displayed on a connected monitor. Although not a part of the original SKALA system as such, a much larger version existed as a wall-sized physical version inside the control room, so it’s definitely more home-simulator friendly.

We previously covered this SKALA system that controls RBMK reactors, as well as the 1990s modernization of the Chornobyl Nuclear Power Plant.

Continue reading “Using Your Own RBMK Reactor Control Center At Home”

The Death Of Physical Media And The Real Challenges To Software Archiving

Along with the many displays of outrage, gnashing of teeth and other displays of profound grief at the recent news that Sony will no longer manufacture physical game discs come 2028, we have also heard some voices pipe up with a variety of statements, such as that this decision makes game archiving basically impossible. Of course, the truth of the matter is that software archiving in general has become much harder already over the past decades, while game consoles are just late to the archiving-hostile party.

As an example, one merely has to contrast Sony’s PlayStation with e.g. the Valve Steam store and software by juggernauts like Adobe and Autodesk. Here the former moved after the Creative Suite (CS6) series of Photoshop and other tools fully over to the Creative Cloud (CC) subscription model, where DRM and constant rental software renewals are in order. Unlike that disc copy of CS6 Master Collection that will stay good practically forever, there’s nothing really to archive with Adobe’s CC software.

Similarly, with digital game downloads and their constant patches now put inside a heavily encrypted environment that relies on a special launcher, preserving video games has been turned into into a virtual nightmare for many years now.

Continue reading “The Death Of Physical Media And The Real Challenges To Software Archiving”

Porting The Nvidia GPU Driver To Haiku For 3D Acceleration

As good as a desktop OS may be, at some point it has to feature accelerated 3D graphics. This has been a bit of a sticking point for Haiku OS, as none of the big names in GPU cards are likely to start putting out drivers for this OS any time soon. Fortunately there is the Linux open source driver code from Nvidia that can be used as a jumping-off point for a port, which is what [X512] and the community over at the Haiku forums did over the course of more than a year.

In a recent video [Action Retro] takes a poke at the fruits of these efforts, trying out the driver with an RTX2070 Super GPU. Of note is that this driver requires the GSP (GPU System Processor) controller that got added by Nvidia with the Turing series of GPUs, meaning that you need at least a GTX16 or RTX20 series card.

You can get an installation package from the GitHub repository, such as for the v0.0.2 pre-release that was created in January of 2026. In this pre-release state quite a few things are working, with the ability to play 3D games at a reasonable FPS being the biggest improvement over plain VESA mode. Features like CUDA are not available as they’re not in the open sourced section, of course.

In the [Action Retro] video the whole installation process is demonstrated, starting with a fresh nightly Haiku build. First the gaming performance in software-rendered VESA mode is demonstrated before the GPU driver is installed. This shows a marked improvement in performance, although Minecraft needs to be updated for the newest Mesa library that omits OSMesa, so that couldn’t be tested. Overall it shows that Haiku has made another massive leap forward in becoming a viable daily driver OS.

Meanwhile, over on the ReactOS side of things we just saw a Half-Life 2 playthrough by [Aotori Hibiki], on an Intel Sandy Bridge PC with GeForce 8400GS graphics. Here ReactOS has the advantage of being Windows NT-compatible, including WDDM-style GPU drivers, allowing it to use the same drivers as Windows. Simultaneously, ReactOS is now implementing its first NT6 kernel API calls to make it compatible with modern  (Vista+) Windows.

The upshot here is that for people who want to daily drive an open source OS with all the creature comforts imaginable, things have never seemed more promising. Especially for people who don’t want Yet Another Linux Distro but just an utterly boring desktop-centric, single-user focused OS that Just Works™ these are great tidings.

Continue reading “Porting The Nvidia GPU Driver To Haiku For 3D Acceleration”

Building A Better CNC Hot Wire Foam Cutter

Cutting foam with a hot wire is a common technique to shape foam in a wide variety of shapes. If you want to cut something detailed and precise, like an airfoil, you probably want to use a computer-controlled cutting tool. Here [Michael Rechtin] has been working on creating a very versatile DIY CNC hot wire cutter, with the results recently announced in a video, along with the GitHub project repository if you want to give it a shake yourself.

Key in hot wire foam cutting is getting the nickel-chromium wire hot enough to gently slice through the foam rather than annihilating it or having the wire encounter significant resistance. For an automated cutter it either needs to be able to adjust the current on the fly, or have a predetermined optimal current for the cutting speed.

The machine itself is a 4-axis system, allowing the wire to be moved just about any way in between the two sides. It uses typical NEMA 17 stepper motors, along with other components that you’d find on a 3D printer. The same is true for the control board that processes the g-code from the software.

The unique part is the pulley-based mechanism that tensions the cutting wire, along with the way that the current gets passed through the wire, which uses MIG welding tips rather than just some alligator clips, which would probably also have worked but not looked as nice.

There are a few 3D-printed parts for which the STLs are provided, and the design is such that the entire assembly can be fairly easily collapsed into a compact shape that’s much easier to store if you’re not cutting foam every single day. For [Michael] cutting airfoils is the main use, for which you got a few software packages that are mentioned in the video.

Continue reading “Building A Better CNC Hot Wire Foam Cutter”

Porting DOOM To The Casio Loopy

Targeted towards refined female gamers unlike the savagery of the mainstream game consoles of the era, 1995’s Casio Loopy was a bit of an oddity of a game console. Despite being standard enough in its design and backed by the might of Casio, it saw only one year of active software development and hardware manufacturing ceased by the end of 1998. With only eleven titles released for the system, with none of them being Doom, this obviously terribly upset [Throaty Mumbo], who set out to right this egregious wrong.

For the two dozen people or so who have one of these systems, you can experience the fruits of his labor yourself via the GitHub repository and something like the FloopyDrive cartridge.. Despite the quite capable Hitachi SH-1 16 MHz CPU and 1 MB of RAM, the main limitation is probably the original 2 MB of ROM space that does not leave a lot of space for DOOM WADs, even after doubling it on the FloopyDrive. Correspondingly you only get a handful of levels out of it.

Overall game performance isn’t too bad, though in the port’s current unoptimized state the resolution is fairly low. That said, even the console’s built-in printer is supported and demonstrated in the video, which is a pretty nice touch. It’s not like Sega or Nintendo consoles allowed you to screenshot those glorious headshots.

Continue reading “Porting DOOM To The Casio Loopy”

Trying To Use A 2007 Samsung UMPC As Wii U Gamepad

As unique the Nintendo Wii U Gamepad may appear to be, at its core it’s pretty much just a tablet with game controls stuck on it. Now that the communication between the Wii U and the Gamepad have been fully reverse-engineered and poured into easy to use software, this opens the possibility of using other tablets with suitable controls on them for Wii U Gamepad purposes, like the Windows-capable Samsung tablet that [Bringus Studios] decided to experiment on.

Originally designed to run Windows XP Tablet PC Edition, the Samsung Q1 series of ultra-mobile PCs (UMPC) was first released in 2007, featuring a 900 MHz Celeron M CPU. Amusingly [Bingus] mixes up mAh and mWh when comparing battery capacities, as the Li-ion battery pack for this UMPC is an 11.1V one, whereas a smartphone battery is 3.7V nominal.

To turn this UMPC into a Wii U Gamepad, first 32-bit Debian 12 is installed along with the Vanilla Wii U Gamepad project. The main challenge then is to find a Wi-Fi adapter that works for this purpose, as the connection uses a slightly non-standard handshake. Naturally the TP-Link USB WiFi adapter that [Bingus] used changed from its previous and better supported Mediatek chipset to a Realtek one with typical poor Linux support, requiring manual driver compiling.

After more troubleshooting, it’s unfortunately found that the 900 MHz Celeron M in this UMPC just isn’t up to the task, with the decoding of the compressed HDMI stream correspondingly pegging the CPU at 100% with all the frame dropping. It’s likely that this is due to a lack of h.264 hardware decoding support, as this would push this burden onto the CPU. The system uses the Intel 915GMS chipset with the GMA 900 iGPU, which appears to just provide hardware acceleration for MPEG 2.

Continue reading “Trying To Use A 2007 Samsung UMPC As Wii U Gamepad”