Porting DOOM To A Forgotten Apple OS

Apple hasn’t always had refined user experiences in their operating systems. In the distant past of the ’90s they were still kind of clunky computers that were far from the polished, high-end consumer machines of the modern era. That wasn’t all that Apple offered back then, though. They had a long-forgotten alternative operating system that was called A/UX designed for government applications, and [Keriad] is here to show us this relic operating system and port DOOM to it.

A/UX was designed in the pre-PowerPC days when Macintosh computers ran on Motorola 68000 chips. Luckily, [Keriad] has a Mac Quadra 800 with just such a chip that is still fully-functional. DOOM was developed with the NeXTSTEP operating system which can run on old Macs thanks to another tool called MacX which allows X11 applications to run on Mac. A version of gcc for A/UX was found as well and with the source code in hand they were eventually able to compile a binary. There were several hiccups along the way (including the lack of sound) but eventually DOOM was running on this forgotten operating system.

The main problem with the build in the end, besides the lack of sound, is that the game only runs at 2 – 3 frames per second. [Keriad] speculates that this is due to all of the compatibility layers needed to compile and run the game at all, but it’s still impressive. As far as we know, [Keriad] is the first person to port DOOM to this OS, although if you’re looking for something more straightforward we would recommend this purpose-built Linux distribution whose sole task is to get you slaying demons as quickly as possible.

Making The Case For COBOL

Perhaps rather unexpectedly, on the 14th of March this year the GCC mailing list received an announcement regarding the release of the first ever COBOL front-end for the GCC compiler. For the uninitiated, COBOL saw its first release in 1959, making it with 63 years one of the oldest programming language that is still in regular use. The reason for its persistence is mostly due to its focus from the beginning as a transaction-oriented, domain specific language (DSL).

Its acronym stands for Common Business-Oriented Language, which clearly references the domain it targets. Even with the current COBOL 2014 standard, it is still essentially the same primarily transaction-oriented language, while adding support for structured, procedural and object-oriented programming styles. Deriving most of its core from Admiral Grace Hopper‘s FLOW-MATIC  language, it allows for efficiently describing business logic as one would encounter at financial institutions or businesses, in clear English.

Unlike the older GnuCOBOL project – which translates COBOL to C – the new GCC-COBOL front-end project does away with  that intermediate step, and directly compiles COBOL source code into binary code. All of which may raise the question of why an entire man-year was invested in this effort for a language which has been declared ‘dead’ for  probably at least half its 63-year existence.

Does it make sense to learn or even use COBOL today? Do we need a new COBOL compiler?

Continue reading “Making The Case For COBOL”

Even More Firmware In Your Firmware

There are many ways to update an embedded system in the field. Images can fly through the air one a time, travel by sneaker or hitch a ride on other passing data. OK, maybe that’s a stretch, but there are certainly a plethora of ways to get those sweet update bytes into a target system. How are those bytes assembled, and what are the tools that do the assembly? This is the problem I needed to solve.

Recall, my system wasn’t a particularly novel one (see the block diagram below). Just a few computers asking each other for an update over some serial busses. I had chosen to bundle the payload firmware images into the binary for the intermediate microcontroller which was to carry out the update process. The additional constraint was that the blending of the three firmware images (one carrier and two payload) needed to happen long after compile time, on a different system with a separate toolchain. There were ultimately two options that fit the bill.

The system thirsty for an update

Continue reading “Even More Firmware In Your Firmware”

Putting The Firmware In Your Firmware

Performing over-the-air updates of devices in the field can be a tricky business. Reliability and recovery is of course key, but even getting the right bits to the right storage sectors can be a challenge. Recently I’ve been working on a project which called for the design of a new pathway to update some small microcontrollers which were decidedly inconvenient.

There are many pieces to a project like this; a bootloader to perform the actual updating, a robust communication protocol, recovery pathways, a file transfer mechanism, and more. What made these micros particularly inconvenient was that they weren’t network-connected themselves, but required a hop through another intermediate controller, which itself was also not connected to the network. Predictably, the otherwise simple “file transfer” step quickly ballooned out into a complex onion of tasks to complete before the rest of the project could continue. As they say, it’s micros all the way down.

The system de jour

Continue reading “Putting The Firmware In Your Firmware”

Compiler Explorer, Explored

It wasn’t long ago that we introduced you to a web site, the Godbolt compiler explorer, that allows the visitor to compile code using a slew of compilers and compare their output. We suspect some number of readers said, “Wow! I can use that!”, while perhaps everyone else said, “Huh?” Well if you were in the second group, you ought to watch [What’s a Creel’s] video below where he walks through using the website. He looks at four different algorithms using four different compilers and it is a good example of how you might use the tool to make decisions about how you write software.

Continue reading “Compiler Explorer, Explored”

Linux Fu: Shell Scripts In C, C++, And Others

At first glance, it might not seem to make sense to write shell scripts in C/C++. After all, the whole point to a shell script is to knock out something quick and dirty. However, there are cases where you might want to write a quick C program to do something that would be hard to do in a traditional scripting language, perhaps you have a library that makes the job easier, or maybe you just know C and can knock it out faster.

While it is true that C generates executables, so there’s no need for a script, usually, the setup to build an executable is not what you want to spend your time on when you are just trying to get something done. In addition, scripts are largely portable. But sending an executable to someone else is fairly risky — but your in luck because C shell scripts can be shared as… well, as scripts. One option is to use a C interpreter like Cling. This is especially common when you are using something like Jupyter notebook. However, it is another piece of software you need on the user’s system. It would be nice to not depend on anything other than the system C compiler which is most likely gcc.

Luckily, there are a few ways to do this and none of them are especially hard. Even if you don’t want to actually script in C, understanding how to get there can be illustrative.

Continue reading “Linux Fu: Shell Scripts In C, C++, And Others”

Lambdas For C — Sort Of

A lot of programming languages these days feature lambda functions, or what I would be just as happy to call anonymous functions. Some people make a big deal out of these but the core idea is very simple. Sometimes you need a little snippet of code that you only need in one place — most commonly, as a callback function to pass another function — so why bother giving it a name? Depending on the language, there can be more to it that, especially if you get into closures and currying.

For example, in Python, the map function takes a function as an argument. Suppose you have a list and you want to capitalize each word in the list. A Python string has a capitalize method and you could write a loop to apply it to each element in the list. However, map and a lambda can do it more concisely:

map(lambda x: x.capitalize(), ['madam','im','adam'])

The anonymous function here takes an argument x and calls the capitalize method on it. The map call ensures that the anonymous function is called once for each item.

Modern C++ has lambda expressions. However, in C you have to define a function by name and pass a pointer — not a huge problem, but it can get messy if you have a lot of callback functions that you use only one time. It’s just hard to think up that many disposable function names. However, if you use gcc, there are some nonstandard C features you can use to get most of what you want out of lambda expressions.

Continue reading “Lambdas For C — Sort Of”