Dune 3D: Open Source 3D Parametric Modeler From The Maker Of Horizon EDA

When coming from the world of Autodesk and kin’s proprietary CAD solutions, figuring out which FOSS 3D CAD solution is the right one can be a real chore, as none of them are on the same level. This is what the author of the Horizon EDA software – [Lukas K.] – struggled with as well when he decided to make his own 3D CAD package, called Dune 3D. Per the documentation for Dune 3D, it’s effectively the solver and workflow from SolveSpace, the Open CASCADE geometry kernel and the user interface from Horizon EDA wrapped up into a single package.

So why not just use FreeCAD or contribute to it? [Lukas]’s main gripes appear to be the issues with the topological naming problem (TNP) in FreeCAD, as well as the modal sketcher that’s limited to 2D, with no constraints in 3D for extrusions. With the recent version 1.1 release it seems to be picking up new features and fixes, and installing it is very easy on Windows with an installer. For Arch there’s an AUR package, and other Linux seems to get a Flatpak if you’re not into building the software yourself.

As for the UI, it’s got a definite MacOS vibe to it, with most of the functionality hidden from the main view. Fortunately some tutorials are available to get you started, but it remains to be seen where Dune 3D lands compared to FreeCAD, OnShape and others. As a sidenote, the name is probably not going to help much when asking Google for answers, courtesy of a certain vaguely well-known book with associated movies and series.

RISC OS Gets An Update

There should be rejoicing among fans of the original ARM operating system this week, as the venerable RISC OS received its version 5.30 update. It contains up-to-date versions of the bundled software as well as for the first time, out-of-the-box WiFi support, and best of all, it can run on all Raspberry Pi models except the Pi 5. If you’ve not encountered RISC OS before, it’s the continuing development of the OS supplied with the first ARM product, the Acorn Archimedes. As such it’s a up-to-date OS but with an interface that feels like those of the early 1990s.

We like RISC OS here, indeed we reviewed the previous version this year, so naturally out came the Hackaday Pi 3 and an SD card to run it on. It’s as smooth and quick as it ever was, but sadly try as we might, we couldn’t get the Pi’s wireless interface to appear in the list of available network cards. This almost certainly has more to do with us than it does the OS, but it would have been nice to break free from the tether of the network cable. The included Netsurf 3.11 browser is nippy but a little limited, and just as it was during our review, sadly not capable of editing a Hackaday piece or we’d be using it to write this.

It’s great to see this operating system still under active development, and we can see that it so nearly fulfills our requirement here for a lightweight OS on the road. For those of us who used the original version, then called Arthur, it’s a glimpse of how desktop computing could, or perhaps even should, have been.

MUDLink Is Making UART Data Links More Reliable

Many of us have used UARTs to spit data from one system or chip to another. Normally, for quick and dirty maker projects, this is good enough. However, you’ll always get the odd dropped transmission or glitch that can throw a spanner in the works if you’re not careful. [Jake Read] decided to work on a system that could use UARTs while being far more reliable. Enter MUDLink.

MUDLink is a library that works with an Arduino’s UART port and stacks on a bit of protocol to clean things up. It uses a packetized method of sending data to ensure that transmissions are received reliably as intended by the sender. Packets are framed using a method called Consistent Overhead Byte Stuffing, which is a nice lightweight way of doing so. The system also uses CRC16-CCITT as an error checking mechanism. There’s also an ack-and-retransmit system for ensuring any dropped transmissions are repeated and received successfully.

If you need reliable UART transmissions without too much overhead, you might want to look at what Jake is doing. It’s a topic we’ve looked at before, too.

How Additional Aerodynamic Drag Helped Make GTA III Work On PS2

The PlayStation 2 was a revelation when it hit the market in 2000, and yet by modern standards, it’s almost hopelessly weak. In fact, it’s so under-powered, Rockstar developers had to pull every trick in the book to make Grand Theft Auto IIIĀ even work on the platform.

The story comes to us from developer [Obbe Vermeij]. He explains that the PlayStation 2 couldn’t keep the entire open-world game map in its tiny 32 MB of RAM. Instead, models had to be streamed from the DVD drive as the player moved around the world. However, even the DVD drive wasn’t fast enough. If the player moved too quickly, they would outpace the system’s ability to load new assets, and the world would fall apart. Roads would vanish, buildings simply wouldn’t appear before the player passed by them.

According to [Obbe], getting around this challenge was the job of one [Adam Fowler]. He notes that even optimizing the layout of data on the DVD wasn’t enough to help. Nifty hacks had to be employed to slow the player down. Road networks were changed to stop the player speeding towards areas that needed lots of new models. In other areas, vehicles in the game would experience a nearly-imperceptible 5% increase in air drag to dull their speed. This was chosen as a more invisible solution; cutting engine power directly was audible to players as the audio changed.

It shows you just how hard developers had to work back when resources were far more constrained than they are today!

Microsoft Updates MS-DOS GitHub Repo To 4.0

We’re not 100% sure which phase of Microsoft’s “Embrace, Extend, and Extinguish” gameplan this represents, but just yesterday the Redmond software giant decided to grace us with the source code for MS-DOS v4.0.

To be clear, the GitHub repository itself has been around for several years, and previously contained the source and binaries for MS-DOS v1.25 and v2.0 under the MIT license. This latest update adds the source code for v4.0 (no binaries this time), which originally hit the market back in 1988. We can’t help but notice that DOS v3.0 didn’t get invited to the party — perhaps it was decided that it wasn’t historically significant enough to include.

That said, readers with sufficiently gray beards may recall that DOS 4.0 wasn’t particularly well received back in the day. It was the sort of thing where you either stuck with something in the 3.x line if you had older hardware, or waited it out and jumped to the greatly improved v5 when it was released. Modern equivalents would probably be the response to Windows Vista, Windows 8, and maybe even Windows 11. Hey, at least Microsoft keeps some things consistent.

It’s interesting that they would preserve what’s arguably the least popular version of MS-DOS in this way, but then again there’s something to be said for having a historical record on what not to do for future generations. If you’re waiting to take a look at what was under the hood in the final MS-DOS 6.22 release, sit tight. At this rate we should be seeing it sometime in the 2030s.

Combadge Project Wants To Bring Trek Tech To Life

While there’s still something undeniably cool about the flip-open communicators used in the original Star Trek, the fact is, they don’t really look all that futuristic compared to modern mobile phones. But the upgraded “combadges” used in Star Trek: The Next Generation and its various large and small screen spin-offs — now that’s a tech we’re still trying to catch up to.

As it turns out, it might not be as far away as we thought. A company called Vocera actually put out a few models of WiFi “Communication Badges” in the early 2000s that were intended for hospital use, which these days can be had on eBay for as little as $25 USD. Unfortunately, they’re basically worthless without a proprietary back-end system. Or at least, that was the case before the Combadge project got involved.

Designed for folks who really want to start each conversation with a brisk tap on the chest, the primary project of Combadge is the Spin Doctor server, which is a drop-in replacement for the original software that controlled the Vocera badges. Or at least, that’s the goal. Right now not everything is working, but it’s at the point where you can connect multiple badges to a server, assign them users, and make calls between them.

It also features some early speech recognition capabilities, with transcriptions being generated for the voices picked up on each badge. Long-term, one of the goals is to be able to plug the output of this server into your home automation system. So you could tap your chest and ask the computer to turn on the front porch light, or as the documentation hopefully prophesies, start the coffee maker.

There hasn’t been much activity on the project in the last year or so, but perhaps that’s just because the right group of rabid nerds dedicated developers has yet to come onboard. Maybe the Hackaday community could lend a hand? After all, we know how much you like talking to your electronics. The hardware is cheap and the source is open, what more could you ask for?

3D Printer Streaming Solution Unlocks Webcam Features

While 3D printer hardware has come along way in the past decade and a half, the real development has been in the software. Open source slicers are constantly improving, and OctoPrint can turn even the most basic of printers into a network-connected powerhouse. But despite all these improvements, there’s still certain combinations of hardware that require a bit of manual work.

[Reticulated] wanted an easy way to monitor his prints over streaming video, but didn’t have any of the cameras that are supported by OctoPrint. Of course he could just point a cheap network-connected camera at the printer and be done with it, but he was looking for a bit better integration than that. In the process, he demonstrates how to unlock some features hidden in inexpensive webcams.

He set about building something that wouldn’t require buying more equipment or overloading the limited hardware responsible for the actual printing. A few of his existing cameras have RTMP support, which allows a fairly straightforward setup with YouTube Live once Monaserver is set up to handle the RTMP feeds from the cameras and OBS Studio is configured to stream it out to YouTube. Using the OctoPrint API, he was able to pull data such as the current extruder temperature and overlay it on the video.

One of the other interesting parts of this build is that not all of [Reticulated]’s cameras have built-in RTMP support but following this guide he was able to get more of them working with this setup than otherwise would have had this capability by default. Even beyond 3D printing, this is an excellent guide (and tip) for getting a quick live stream going for whatever reason. For anything more mobile than a working 3D printer, though, you might want to look at taking your streaming setup mobile instead.