In Search Of The First Comment

October 23, 2021 by Elliot Williams 105 Comments

Are you writing your code for humans or computers? I wasn’t there, but my guess is that at the dawn of computing, people thought that they were writing for the machines. After all, they were writing in machine language, and whatever bits they flipped into the electronic brain stayed in the electronic brain, unless punched out on paper tape. And the commands made the machine do things, not other people. Code was written strictly for computers.

Modern programming practice, on the other hand, is aimed firmly at people. Variable and function names are chosen to be long and to describe what they contain or do. “Readability” of code is a prized attribute. Indeed, sometimes the fact that it does the right thing at all almost seems to be an afterthought. (I kid!)

Somewhere along this path, there was an important evolutionary step, like the first fish using its flippers to walk on land. Comments were integrated into programming languages, formalizing the notes that coders of old surely wrote by hand in the margins of the paper first-drafts before keying it in. So I went looking for the missing link: the first computer language, and ideally the first program, with comments. I came up empty handed.

Or rather full handed. Every computer language that I could find had comments from the beginning. FORTRAN had comments, marked by a “C” as the first character in a line. APL had comments, marked by the bizarro rune ⍝. Even the custom language written for the Apollo 11 guidance computers had comments — the now-commonplace “#”. I couldn’t find an early programming language without comments.

My guess is that the first language with a comment must have been an assembly language, because I don’t know of any machines with a native comment instruction. (How cool and frivolous would that be?)

Assemblers simply translate mnemonic names to their machine instruction counterparts, but this gives them the important freedom to ignore anything starting with, traditionally, a semicolon. Even though you’re just transferring the contents of register X to the memory location pointed to in register Y, you can write that you’re “storing the height above ground (meters)” in the comments.

The crucial evolutionary step, though, is saving the comments along with the code. Simply ignoring everything that comes after the semicolon and throwing it away doesn’t count. Does anyone know? What was the first code to include comments as part of the code itself, and not simply as marginalia?

DOOM Played By Tweet

October 13, 2021 by Bryan Cockfield 5 Comments

Getting DOOM to run on hardware it was never intended to run on is a tradition as old as time. Old cell phones, embedded systems, and ancient televisions have all been converted to play this classic first-person shooter. This style of playing games on old hardware might be passé now as the new trend seems to be the ability to play this game on more ethereal platforms instead. This project brings DOOM to Twitter.

The gameplay is a little nontraditional as well. To play the game, a tweet needs to be sent with specific instructions for the bot. The bot then plays the game according to its instructions and then tweets a video. By responding to this tweet with more instructions, the player can continue the game tweet-by-tweet. While slightly cumbersome, it does have the advantage of allowing a player to resume any game simply by responding to the tweet where they would like to start. Behind the scenes of the DOOM-playing Twitter bot is interesting as well and the code is available on the project’s GitHub page.

While we’ve seen plenty of DOOM instances on all kinds of hardware, it’s safe to say we’ve never really seen a gameplay experience quite like this one. It may stay as a curiosity, but DOOM porters are always looking for something else to run this classic game so it may eventually branch out or develop into something more user-friendly like this cloud-based Atari 2600.

Erasable Pen Ink Adds Colors To 3D Prints

September 28, 2021 by Bryan Cockfield 8 Comments

Changing colors during a 3D print is notoriously difficult. Either you need multiple heads ready to go during the print which increases operating and maintenance costs for your printer, or you need to stop the print to switch the filament and then hope that everything matches up when the print is resumed. There are some workarounds to this problem, but not many of them are as smooth an effortless as this one which uses erasable pen ink to add colors to the filament on the fly.

Erasable pen ink is a thermochromic material that doesn’t get removed from paper when erased like graphite from a pencil. Instead the heat from the friction of erasing causes it to become transparent. By using this property for a 3D print, the colors in the print can be manipulated simply by changing the temperature of the hot end. Of course the team at [Autodrop3d] had quite a learning curve when experimenting with this method, as they had to run the extruder at a much lower temperature than normal to have control over the ink’s color, had to run the print much slower than normal, and were using a very sticky low-temperature plastic for the print.

With all of these modifications to the print setup, there are bound to be some limitations in material and speed, but the results of the project speak for themselves. This allows for stock 3D printers to use this method with no hardware modifications, and the color changes can be done entirely in software. While everyone catches up with this new technology, there are some other benefits to a 3D printer with multiple print heads, though, and some clever ways of doing the switching without too much interruption.

Continue reading “Erasable Pen Ink Adds Colors To 3D Prints” →

The Newlib Embedded C Standard Library And How To Use It

July 19, 2021 by Maya Posch 4 Comments

When writing code for a new hardware platform, the last thing you want to do is bother with the minutiae of I/O routines, string handling and other similarly tedious details that have nothing to do with the actual project. On bigger systems, this is where the C standard library would traditionally come into play.

For small embedded platforms like microcontrollers, resources are often tight enough that a full-blown stdlib won’t fit, which is why Newlib exists: to bring the portability benefits of a standard library to microcontrollers.

Whether you use C, C++ or MicroPython to program an MCU, Newlib is likely there under the hood. Yet how exactly does it integrate with the hardware, and how are system calls (syscalls) for e.g. file and input/output handling implemented? Continue reading “The Newlib Embedded C Standard Library And How To Use It” →

Cracking A GBA Game With NSA Tools

July 16, 2021 by Bryan Cockfield 1 Comment

[Wrongbaud] is a huge fan of Japanese kaiju-style movies, including Godzilla and King Kong. In honor of the release of a new movie, he has decided to tackle a few projects to see how both of these monsters can hold their own against other legendary monsters. In this project, he is using Ghidra, named after another legendary kaiju, against the password system of the Game Boy Advance game Kong: King of Atlantis.

Since this project is a how-to, [wrongbaud] shows how to search Ghidra for existing scripts that might already have the functionality needed for GBA analysis and emulation. When not, he also illustrates how to write scripts to automate code analysis, and then moves on to cracking the level password system on the game.

The key to finding the passwords on this game was looking for values in the code that were seven characters long, and after some searching [wrongbaud] is finally able to zero in on the code responsible for handling passwords. Once found a brute force method was automated to find viable passwords, and from there the game was officially pwned. For anyone interested in security, reverse engineering, or just the way that binaries work, it’s quite the detailed breakdown. Of course, it’s not the only example we have seen that uses this software tool to extract passwords.

USB Comes To The ESP32

March 26, 2021 by Bryan Cockfield 20 Comments

Since the ESP8266 came on the scene a few years ago and revolutionized the way microcontrollers communicate with other devices, incremental progress on this chip has occurred at a relatively even pace. First there was the realization that code could be run on the chip itself. Next the ESP32 was released which built more on that foundation. The next step in that process of improvement may be here now as well, with this project which turns the ESP32 into a USB host.

USB is not a native feature on all microcontrollers or even Arduino-compatible boards. While some do have it built in like those based on the 32u4 for example, most either don’t have it at all or rely on a separate on-board chip to do some form of translating. The ESP32 is lacking this advanced feature so the USB needs to be cobbled together from scratch if you want this specific board to be able to interface directly with peripherals. This project does just that, allowing for four USB 1.1 devices to be connected directly to the ESP32 without a separate dedicated chip.

If you’ve been waiting for USB on this tiny, capable microcontroller this might be your chance to try it out. All of the project’s code is available on the project page. And, while it is limited in scope, it’s easily able to handle a keyboard or mouse. This might be a more cost-effective way of doing something like a KVM switch rather than doing it with three Arduinos.

Lightweight OS For Any Platform

March 22, 2021 by Bryan Cockfield 35 Comments

Linux has come a long way from its roots, where users had to compile the kernel and all of the other source code from scratch, often without any internet connection at all to help with documentation. It was the wild west of Linux, and while we can all rely on an easy-to-install Ubuntu distribution if we need it, there are still distributions out there that require some discovery of those old roots. Meet SkiffOS, a lightweight Linux distribution which compiles on almost any hardware but also opens up a whole world of opportunity in containerization.

The operating system is intended to be able to compile itself on any Linux-compatible board (with some input) and yet still be lightweight. It can run on Raspberry Pis, Nvidia Jetsons, and x86 machines to name a few, and focuses on hosting containerized applications independent of the hardware it is installed on. One of the goals of this OS is to separate the hardware support from the applications, while being able to support real-time tasks such as applications in robotics. It also makes upgrading the base OS easy without disrupting the programs running in the containers, and of course has all of the other benefits of containerization as well.

It does seem like containerization is the way of the future, and while it has obviously been put to great use in web hosting and other network applications, it’s interesting to see it expand into a real-time arena. Presumably an approach like this would have many other applications as well since it isn’t hardware-specific, and we’re excited to see the future developments as people adopt this type of operating system for their specific needs.

Thanks to [Christian] for the tip!