Freeing Windows

There have been several attempts to make an unencumbered version of Windows. ReactOS is perhaps the best-known. You could also argue that Wine and its progeny, while not operating systems in the strictest sense of the word, might be the most successful. Joining the fray is Free95, a GPL-3.0 system that, currently, can run simple Windows programs. The developer promises to push to even higher compatibility.

As you might expect, the GitHub site is calling for contributors. There will be a lot to do. The src subdirectory has a number of files, but when you consider the sheer volume of stuff crammed into Windows, it is just a minimal start.

Continue reading “Freeing Windows”

Physical Computing Used To Be A Thing

In the early 2000s, the idea that you could write programs on microcontrollers that did things in the physical world, like run motors or light up LEDs, was kind of new. At the time, most people thought of coding as stuff that stayed on the screen, or in cyberspace. This idea of writing code for physical gadgets was uncommon enough that it had a buzzword of its own: “physical computing”.

You never hear much about “physical computing” these days, but that’s not because the concept went away. Rather, it’s probably because it’s almost become the norm. I realized this as Tom Nardi and I were talking on the podcast about a number of apparently different trends that all point in the same direction.

We started off talking about the early days of the Arduino revolution. Sure, folks have been building hobby projects with microcontrollers built in before Arduino, but the combination of a standardized board, a wide-ranging software library, and abundant examples to learn from brought embedded programming to a much wider audience. And particularly, it brought this to an audience of beginners who were not only blinking an LED for the first time, but maybe even taking their first steps into coding. For many, the Arduino hello world was their coding hello world as well. These folks are “physical computing” natives.

Now, it’s to the point that when Arya goes to visit FOSDEM, an open-source software convention, there is hardware everywhere. Why? Because many successful software projects support open hardware, and many others run on it. People port their favorite programming languages to microcontroller platforms, and as they become more powerful, the lines between the “big” computers and the “micro” ones starts to blur.

And I think this is awesome. For one, it’s somehow more rewarding, when you’re just starting to learn to code, to see the letters you type cause something in the physical world to happen, even if it’s just blinking an LED. At the same time, everything has a microcontroller in it these days, and hacking on these devices is also another flavor of physical computing – there’s code in everything that you might think of as hardware. And with open licenses, everything being under version control, and more openness in open hardware than we’ve ever seen before, the open-source hardware world reflects the open-source software ethos.

Are we getting past the point where the hardware / software distinction is even worth making? And was “physical computing” just the buzzword for the final stages of blurring out those lines?

A CaptionCall Phone Succumbs To Doom, Again

Pour one out for yet another device conquered. This one’s a desk phone for conferences and whatnot, a colour display, a numpad, and a bog standard handset with a speaker and mic. Naturally, also running Linux. You know what to expect – [Parker Reed] has brought Doom to it, and you’d be surprised how playable it looks!

This is the second time a CaptionCall device has graced our pages running Doom — CaptionCall patched out the previous route, but with some firmware dumping and hashcat, root has been acquired once again. [Parker] has upgraded this impromptu gaming setup, too – now, all the buttons are mapped into Doom-compatible keyboard events coming from a single input device, thanks to a C program and an Xorg config snippet. Feel free to yoink for your own Doom adventures or just general CaptionCall hacking!

If you’re interested in the hacking journey, get into the exploitee.rs Discord server and follow the hack timeline from password recovery, start to finish, to Doom, to the state of affairs shown in the video. Now, as the CPU speeds have risen, should the hackerdom switch away from Doom as the go-to? Our community remains divided.

Continue reading “A CaptionCall Phone Succumbs To Doom, Again”

The rust language logo being branded onto a microcontroller housing

Esp-hal, A Stable-API ESP32 HAL Gift For Your Rust Code

Looking to write Rust on the ESP32? You’re in luck, a new challenger has entered the scene, looking to help you write code that lasts – [Scott Mabin] and the team from Espressif have brought us the esp-hal 1.0.0-beta. From a personal project to an Espressif-sponsored one to an effort under Espressif’s wing, [Scott] tells us about the arduous journey of bringing first-class Rust support to ESP32 chips, Xtensa and RISC-V alike.

In particular, esp-hal, with the hal part standing for Hardware Abstraction Layer, focuses on providing you with a stable API to access hardware, making sure your code can remain stable for years to come. For now, you get drivers for GPIO, UART, SPI and I2C, as well as a number of auxiliary features like time and SoC reset, more than enough for a large amount of projects we hackers build with a generic MCU in mind.

Next stop? WiFi and BLE support, of course, an ESP32 just doesn’t feel the same without these two. Rust is a fun and seriously promising language, and it’s a joy to use! So, if you have a wireless-less project in mind and you’re looking for a HAL, try out the esp-hal, it might just be exactly what you need.

If you’re looking for examples, here’s an STM32 touchpad project with Rust firmware, a PIC32 Rust blinky demo, and we’ve even featured larger projects like this ESP32 open-source (reverse-engineered) WiFi MAC stack being written in Rust. In case you missed it, we’ve introduced Rust to you a couple of times, even as far as 2015!

A Web-Based Graphics Editor For Tiny Screens

These days, adding a little LCD or OLED to your project is so cheap and easy that you can do it on a whim. Even if your original idea didn’t call for a display, if you’ve got I2C and a couple bucks burning a hole in your pocket, why not add one? Surely you’ll figure out what to show on it as the project develops.

But that’s where it can get a little tricky — in terms of hardware, adding a screen just takes running a few extra wires, but the software side is another story. Not only do you have to contend with the different display libraries, but just creating the image assets to display on the screen can be a hassle if it’s not something you do regularly. Enter Lopaka, a graphics and user interface editor for electronic projects created by [Mikhail Ilin].

Continue reading “A Web-Based Graphics Editor For Tiny Screens”

UNIX Archaeology Turns Up 1972 “V2 Beta”

In 1997 a set of DEC tapes were provided by Dennis Ritchie, as historical artifacts for those interested in the gestation of the UNIX operating system. The resulting archive files have recently been analysed by [Yfeng Gao], who has succeeded in recovering a working UNIX version from 1972. What makes it particularly interesting is that this is not a released version, instead it’s a work in progress sitting somewhere between versions 1 and 2. He’s therefore taken the liberty of naming it “V2 Beta”.

If you happen to have a PDP-11/20 you should be able to run this operating system for yourself, and for those of us without he’s provided information on which emulator will work. The interesting information for us comes in the README accompanying the tapes themselves, and in those accompanying the analysis. Aside from file fragments left over from previous users of the same tape, we learn about the state of UNIX time in 1972. This dates from the period when increments were in sixtieths of a second due to the ease of using the mains power frequency in a PDP, so with a 32-bit counter they were facing imminent roll-over. The 1970-01-01 epoch and one second increments would be adopted later in the year, but meanwhile this is an unusual curio.

If you manage to run this OS, and especially if you find anything further in the files, we’d love to hear. Meanwhile, this is not the oldest UNIX out there.

Featured image: “PDP-11/20 Rocker Switches” by Don DeBold

Belfry OpenSCAD Library (BOSL2) Brings Useful Parts And Tools Aplenty

OpenSCAD has a lot of fans around these parts — if you’re unaware, it’s essentially a code-based way of designing 3D models. Instead of drawing them up in a CAD program, one writes a script that defines the required geometry. All that is made a little easier with the Belfry OpenSCAD Library (BOSL2).

Designing a part like this is a cinch with BOSL2.

BOSL2 has an extensive library of base shapes, advanced functions for manipulating models, and some really nifty tools for creating attachment points on parts and aligning components with one another. If that sounds handy for designing useful objects, you’re in for even more of a treat when you see their functions for gears, hinges, screws, and more.

There’s even one that covers bottle necks and caps. (Those are all standardized by the way, so it’s never been easier to interface to existing bottles or caps in a project.)

OpenSCAD really is very versatile software. It powers useful tools like this screw, washer, and nut generator as well as having more unusual applications like a procedural terrain generator. It’s free, so if you’ve never looked into it, check it out!