Porting The Nvidia GPU Driver To Haiku For 3D Acceleration

July 12, 2026 by Maya Posch 2 Comments

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

July 12, 2026 by Maya Posch 11 Comments

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

July 11, 2026 by Maya Posch 5 Comments

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

July 11, 2026 by Maya Posch 4 Comments

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” →

A Look Inside A 1997 BBC Ceefax Generator

July 11, 2026 by Maya Posch 21 Comments

Ceefax was the BBC’s broadcast teletext service that ran until 2012, providing text and rudimentary graphics that were broadcast invisibly with the TV signal. In order to get this teletext data merged into the analog TV signal, special equipment was needed, of which [Nathan Dane] has a 1997-era unit on his bench to take a gander at.

Interestingly, until this time the Ceefax signal had been generated centrally in London, meaning that regional TV broadcasts might have Ceefax issues on occasion due to retransmission glitches. This makes this Ceefax Inserter system so much more interesting, as it was one of the early examples of what these regional stations would end up installing in their racks.

At their core these units are regular PCs, running MS-DOS 6.22 on a 486-class CPU and all the typical bits and bobs that go with a PC. The speculation here is that these are essentially rebranded industrial PCs, which would make a lot of sense. As for how [Nathan] got his hands on these units, it required a deal with the company scrapping them, preventing him from showing details of the software configuration.

Following a booting demonstration, we get the teardown of a typical 1990s rackmount PC, revealing a rather interesting backplane with the mainboard being one of the cards on it. Of these, two ISA cards provide the special Ceefax sauce as well as a timing signal in the form of a PDC card featuring a Lattice CPLD or FPGA that VCRs could use to automatically start recording.

The Ceefax main event comes in the form of the inSERT Teletext Encoder card. This is pretty much its own computer system, featuring a TI TMS34010 CPU and its own RAM as well as IO. Compared to modern takes on teletext generators, this card appears to directly mix the analog signals, without any kind of conversion.

Although teletext systems have been largely shutdown now at this point due to the transition to digital TV broadcasting, there’s still a lot to be said for having such a service available for basic news and information.

Continue reading “A Look Inside A 1997 BBC Ceefax Generator” →

Fixing The Fix For A 3dfx Voodoo Card’s Overly Bright Picture

July 10, 2026 by Maya Posch 6 Comments

After previously fixing an overly bright picture from a Voodoo graphics card with a simple resistor on one of the RAMDAC’s pins to correct its faulty internal Vref, [Bits und Bolts] got called out for not taking component drift into account. Thus in an update video he shows how instead to use an adjustable AMS1117 voltage regulator to hopefully prevent either the original issue or something new and exciting from cropping up later.

The basic idea here is to use the external voltage reference (Vref) pin for this ICS5342 RAMDAC and supply it with a constant 1.235V. If unused – as on this Orchid-branded Voodoo card – it is connected via an 0.1 microFarad capacitor to ground. This fortunately means that the pin is routed to easily accessible pads that make this modification relatively straightforward.

Basically this is where the AMS1117-ADJ chip comes into the picture, as a widely available adjustable LDO option, even if the 0.8A current rating is very much overkill for this application. With the supplied voltage the lowest voltage this LDO can output is around 1.25V, which is within the 1.10 – 1.35 V range of the datasheet.

Of course, with the PCB never having had a provision for this part, much of the rest of the video is about planning out where to place and route the components. After that tedious work and testing that nothing explodes, the new voltage is used for the RAMDAC’s Vref pin, fixing the brightness issue.

While one could argue that this RAMDAC is likely simply defective and already beginning to break down inside, this should at least give it a bit longer on what seems to be a little used card anyway.

Continue reading “Fixing The Fix For A 3dfx Voodoo Card’s Overly Bright Picture” →

Documenting The IR Protocol Of The PumpSaver Plus Device

July 10, 2026 by Maya Posch 2 Comments

Having a pump in a remote location where you aren’t constantly monitoring it is a common scenario, which can be unfortunate when said pump runs into problems like a dry well, jammed impeller or power issues. This is where pump monitors like the older SymCom (now Littelfuse) PumpSaver Plus 233P will protect the pump if such conditions are detected. Of course, the infrared communication port on it uses an undocumented protocol that was meant to be used with a long-since discontinued handheld device. Ergo [Elizabeth Camporeale] saw fit to reverse-engineer this protocol.

In the installation manual for this device this Informer unit is briefly mentioned along with the information it will display on its screen, making it clear that it’s quite literally just there to act as a display for the information that’s constantly generated on this interface. Naturally, this is incredibly useful if you wish to tie the system into a wider monitoring and automation system.

Somewhat unusual, this IR interface on the used 233P-1.5 unit turned out to be use a 5,000 baud NRZ, MSB-first protocol, with the juicy details fully documented and a Python-based decoder implementation provided.

Naturally [Elizabeth] didn’t just reverse-engineer this for the fun of it, but also for ESPHome integration. This uses a setup as can be seen in the top image, with an ESP32-C6 module providing the processing power and Wi-Fi, with a standard phototransistor recording the data pumped out by the pump monitor.