FreeBSD At 30: The History And Future Of The Most Popular BSD-Based OS

Probably not too many people around the world celebrated November 1st, 2023, but on this momentous date FreeBSD celebrated its 30th birthday. As the first original fork of the first complete and open source Unix operating system (386BSD) it continues the legacy that the Berkeley Software Distribution (BSD) began in 1978 until its final release in 1995. The related NetBSD project saw its beginnings somewhat later after this as well, also forking from 386BSD. NetBSD saw its first release a few months before FreeBSD’s initial release, but has always followed a different path towards maximum portability unlike the more generic nature of FreeBSD which – per the FAQ – seeks to specialize on a limited number of platforms, while providing the widest range of features on these platforms.

This means that FreeBSD is equally suitable for servers and workstations as for desktops and embedded applications, but each platform gets its own support tier level, with the upcoming version 15.x release only providing first tier support for x86_64 and AArch64 (ARMv8). That said, if you happen to be a billion-dollar company like Sony, you are more than welcome to provide your own FreeBSD support. Sony’s Playstation 3, Playstation 4 and Playstation 5 game consoles namely all run FreeBSD, along with a range of popular networking and NAS platforms from other big names. Clearly, it’s hard to argue with FreeBSD’s popularity.

Despite this, you rarely hear people mention that they are running FreeBSD, unlike Linux, so one might wonder whether there is anything keeping FreeBSD from stretching its digital legs on people’s daily driver desktop systems?

Continue reading “FreeBSD At 30: The History And Future Of The Most Popular BSD-Based OS”

Atari’s Pac-Man Flop: How A Classic Went Off-Course

For fans of retro games, Pac-Man is nothing short of iconic—a game so loved it’s been ported to nearly every console imaginable. But the Atari 2600 version, released in 1982, left players scratching their heads – as laid out in a video by [Almost Something]. Atari had licensed Pac-Man to ride the wave of its arcade success, but the home version, programmed solely by [Todd Fry], missed the mark, turning an arcade icon into a surprising lesson in over-ambitious marketing.

Despite the hype, [Fry] faced an almost impossible task: translating Pac-Man’s detailed graphics and complex gameplay to the Atari’s limited 4 K cartridge with only 128 bytes of RAM. Atari’s strict limitations on black backgrounds and its choice to cut costs by sticking with a 4 K cartridge left the game barely recognizable. The famous pellet-chomping maze became simpler, colors were changed, and the iconic ghosts—reduced to single colors—flickered constantly. And then, Atari went all in, producing twelve million copies, betting on the success of universal appeal. In a twist, Pac-Man did sell in record numbers (over seven million copies) but still fell short of Atari’s expectations, leaving millions of unsold cartridges eventually dumped in a New Mexico landfill.

This debacle even kind of marked Atari’s 1983 decline. Still, Pac-Man survived the hiccup, evolving and outlasting its flawed adaptation on the 2600. If you’re interested in learning more about the ins and outs of game ports, check out the fantastic talk [Bob Hickman] gave during Supercon 2023.

Continue reading “Atari’s Pac-Man Flop: How A Classic Went Off-Course”

DIY 3D Hand Controller Using A Webcam And Scripting

Are you ready to elevate your interactive possibilities without breaking the bank? If so, explore [Caio Bassetti]’s tutorial on creating a full 3D hand controller using only a webcam, MediaPipe Hands, and Three.js. This hack lets you transform a 2D screen into a fully interactive 3D scene—all with your hand movements. If you’re passionate about low-cost, accessible tech, try this yourself – not much else is needed but a webcam and a browser!

The magic of the project lies in using MediaPipe Hands to track key points on your hand, such as the middle finger and wrist, to calculate depth and positioning. Using clever Three.js tricks, the elements can be controlled on a 3D axis. This setup creates a responsive virtual controller, interpreting hand gestures for intuitive movement in the 3D space. The hack also implements a closed-fist gesture to grab and drag objects and detects collisions to add interactivity. It’s a simple, practical build and it performs reliably in most browsers.

For more on this innovation or other exciting DIY hand-tracking projects, browse our archive on gesture control projects, or check out the full article on Codrops. With tools such as MediaPipe and Three.js, turning ideas into reality gets more accessible than ever.

A stylized image of Haskell code from the article

Alphabet Soup: Haskell’s Single-Letter Naming Quirks

When you used punch cards or tape to write a computer program, brief variable names were the norm. Your compiler or assembler probably only allowed six letters, anyway. But times change, and people who, by habit, give array indices variable names like I, J, or K get a lot of grief. But [Jack Kelly] points out that for highly polymorphic languages like Haskell, you often don’t know what that variable represents anyway. So how are you supposed to name it? He provides a guide to one-letter variable names commonly used by Haskell developers and, sometimes, others.

Haskell’s conventions are particularly interesting, especially with i, j, and k, which are borrowed from mathematical tradition to signify indices or integers and passed on via Fortran. The article also highlights how m often refers to Monads and Monoidal values, while t can represent both traversables and text values. Perhaps more obscurely, p can denote profunctors and predicates, giving a glimpse into Haskell’s complex yet efficient type system. These naming conventions are not formal standards but have evolved into a grass-roots lexicon.

Of course, you can go too far. We see a lot of interesting and strange things written in Haskell, including this OpenSCAD competitor.

Easily Program RP2040 Boards With Your Android Device

You could write your microcontroller code on your desktop PC, or you could do it on your laptop on the go. Or, if you want to get really portable about things, you could write your embedded code on your phone. Enter DroidScript.

Basically, DroidScript is a JavaScript and Python IDE for Android phones and tablets. Simple enough. You can use it to write apps for your phone or tablet. But its party piece? You can now also use it to program for embedded devices—namely, a range of those based on the RP2040 microcontroller. For example, the Adafruit QT-Py RP2040, the Pimoroni TinyFX, or the Pimoroni Yukon. They run MicroPython and CircuitPython, and you can program them from DroidScript. Easy.

A decade ago, this would have been a royal pain in the butt. But today? It’s easy, because the smartphones and devboards both use USB-C connectors. All you need is a regular USB-C cable and you can hook straight up to the board and burn your code.

You can get the app on the Google Play Store if you’re so inclined. We’ve seen some other neat smartphone programming projects over the years, too. Meanwhile, if you’ve found any other nifty ways to get your code on to a dev board, don’t hesitate to let us know!

New Release Of Vision Basic: Hot New Features!

As the Commodore 64 ages, it seems to be taking on a second life. Case in point: Vision BASIC is a customized, special version of the BASIC programming language with a ton of features to enable Commodore 64 programs to be written more easily and with all sorts of optimizations. We’ve tested out both the original 1.0 version of Vision BASIC, and now with version 1.1 being released there are a whole host of tweaks and updates to make the experience even better!

One of the only limitation of Vision BASIC is the requirement for expanded RAM. It will not run on an unexpanded C64 — but the compiled programs will, so you can easily distribute software made using Vision on any C64. A feature introduced in version 1.1 is support for GeoRAM, a different RAM expansion cartridge, and modern versions of GeoRAM like the NeoRAM which has battery-backed RAM. This allows almost instantaneous booting into the Vision BASIC development environment.

Some of the standout features include a doubling of compilation speed, which is huge for large programs that take up many REU segments in source form. There are new commands, including ALLMOBS for setting up all sprites with a single command; POLL to set up which joystick port is in use; CATCH to wait for a particular scanline; and plenty more! Many existing commands have been improved as well. As in the original version of Vision BASIC, you can freely mix 6510 assembly and BASIC wherever you want. You can use the built-in commands for bitmaps, including panning, collision detection, etc., or you can handle it in assembly if you want! And of course, it comes with a full manual — yes, a real, printed book!

One of the nice features of Vision BASIC is the customization of the development environment. On the first run, after agreeing to the software terms, you enter your name and it gets saved to the Vision BASIC disk. Then, every time you start the software up, it greets you by name! You can also set up a custom colour scheme, which also gets saved. It’s a very pleasant environment to work in. Depending on how much additional RAM you have, you can hold multiple program segments in different RAM banks. For example, you could have all your source code in one bank, all your bitmaps and sprites in another, and your SID tunes in yet another. The compiler handles all this for you when you go to compile the program to disk, so it’s easy to keep large programs organized and easy to follow.

If you’ve always wanted to write a game or application for the C64 but just didn’t know how to get started, or you felt daunted at having to learn assembly to do sprites and music, Vision BASIC is a great option. You will be blown away at the number of commands available, and as you become more experienced you can start to sprinkle in assembly to optimize certain parts of your code if desired.

From High Level Language To Assembly

If you cut your teeth on Z-80 assembly and have dabbled in other assembly languages, you might not find much mystery in creating programs using the next best thing to machine code. However, if you have only used high level languages, assembly can be somewhat daunting. [Shikaan] has an introductory article aimed to get you started at the “hello world” level of x86-64 assembly language. The second part is already up, too, and covers control structures.

You can argue that you may not need to know assembly language these days, and we’ll admit it’s certainly not as important as it used to be. However, there are unusual cases where you really need either the performance or the small footprint, which is only possible in assembly language. What’s more, it is super useful to be able to read assembly from your high-level tools when something goes wrong.

Of course, one of the problems is that each assembly language is different. For example, knowing that the x86 assembly doesn’t completely transfer to ARM instructions. However, in most cases, the general concepts apply, and it is usually fairly easy to learn your second, third, or fourth instruction set.

We’ve had our own tutorials on this topic. You can also debate if you should learn assembly first or wait, although in this case, the audience is people who waited.