When The Sojourner Mars Rover Nearly Ran LISP

August 7, 2023 by Maya Posch 11 Comments

During the late 1980s NASA’s Jet Propulsion Laboratory (JPL) was busy developing the first ever wheeled robot that would roam the surface of Mars. Due to the long round-trip times of any signals between Mars and Earth, development of the firmware that would control the rover was a major point, with the two teams occupied with the task each picking different levels of autonomy for the rover. In a retrospective, [Ron Garrett] who worked at JPL on the ‘more autonomy’ team describes his recollections.

Whereas [Ron]’s team focused on creating a rover that could be provided with high-level instructions which the sophisticated LISP-based firmware would use as guidelines to navigate and operate by, the other team pursued a more limited autonomy approach whereby a human driver would use explicitly plan out the route which the rover would follow before awaiting new instructions.

Perhaps unsurprisingly, the system requirements for running LISP and the additional uncertainties and complexities with the autonomous approach, as well as testing and validating the firmware, resulted in the Sojourner Mars rover featuring the latter approach, with straightforward C-based firmware. Most of Sojourner’s autonomy was limited to a home return function if communication with the lander was lost, which limited both its range and operations during its 85-day extended mission.

As [Ron] covers with examples from later missions, one advantage of LISP is that it allows you to send instructions which can be interpreted (e.g. to debug the system) without having to program in such functionality explicitly. With later Mars rover missions much more of this autonomy that [Ron]’s team pioneered was implemented, although C remained the language of choice for these later rovers.

Heading image: Ron Garrett standing in front of the Robbie prototype. Rocky III can be see in the lower left, and above him are Rajiv Desai and Robert Ivlev, two other members of the team. (Credit: Ron Garret)

Reviving Interlisp With The Medley Interlisp Project

July 9, 2023 by Maya Posch 21 Comments

Within the Artificial Intelligence and natural language research communities, Lisp has played a major role since 1960. Over the years since its introduction, various development environments have been created that sought to make using Lisp as easy and powerful as possible. One of these environments is Interlisp, which saw its first release in 1968, and its last official release in 1992. That release was Medley 2.0, which targeted various UNIX machines, DOS 4.0, and the Xerox 1186. Courtesy of the Interlisp open source project (GitHub), Medley Interlisp is available for all to use, even on modern systems.

The documentation contains information on how to install Medley on Linux but also Mac and Windows (via WSL1 or WSL2). For those just curious to give things a swing, there’s also an online version you can log into remotely. What Medley Interlisp gets you is an (X-based) GUI environment in which you can program in Lisp, essentially an IDE with a debugger and the (in)famous auto-correction tool for simple errors such as typos, known as the DWIM (Do What I Mean), which much like the derived version in Emacs seeks to automatically fix simple issues like misspellings without forcing the developer to fix it and restart the compilation.

Thanks to [Pixel_Outlaw] for the tip and for also telling us about a project they wrote using Medley Interlisp for the Spring Lisp Game Jame 2023 titled Interlisp Fifteen Puzzle.

Punched Cards Are In The Cloud, With This Arduino

June 20, 2023 by Jenny List 15 Comments

Grizzled veterans of the computing industry will relate stories of submitting projects on stacks of punched cards, something those of us who stored their 8-bit works on audio cassettes could only imagine. But for those who fancy experimenting with the format it’s still possible to make a basic card reader using LEDs and light sensors, as [Nino Ivanov] has done using an Arduino Uno as the brains. And these aren’t just for show, each of his cards holds a LISP program that runs in a cloud service.

The Uno does the job of reading, passing its data over its USB serial port to a tablet. On the tablet the serial data is piped to a cloud API to a LISP interpreter. It seems a needlessly complex way to run a factorial program and it’s certainly a little over the top, but on the other hand we love it as a glorious combination of the old and the new. With only 23 characters per card it’s quite an impressive feat to even fit a program on the format, perhaps writing code to fit on minimalist punched cards like this could become a programming challenge in its own right for a generation accustomed to mega-and gigabytes.

If you fancy a go yourself, this isn’t the first punched card reader we’ve shown you.

Continue reading “Punched Cards Are In The Cloud, With This Arduino” →

Computers For Fun

March 11, 2023 by Elliot Williams 9 Comments

The last couple years have seen an incredible flourishing of the cyberdeck scene, and probably for about as many reasons as there are individual ’deck designs. Some people get really into the prop-making, some into scrapping old tech or reusing a particularly appealing case, and others simply into the customization possibilities. That’s awesome, and they’re all different motivations for making a computer that’s truly your own.

But I really like the motivation and sentiment behind [Andreas Eriksen]’s PotatoP. (Assuming that his real motivation isn’t all the bad potato puns.) This is a small microcomputer that’s built on a commonly available microcontroller, so it’s not a particularly powerful beast – hence the “potato”. But what makes up for that in my mind is that it’s running a rudimentary bare-metal OS of his own writing. It’s like he’s taken the cyberdeck’s DIY aesthetic into the software as well.

What I like most about the spirit of the project is the idea of a long-term project that’s also a constant companion. Once you get past a terminal and an interpreter – [Andreas] is using LISP for both – everything else consists of small projects that you can check off one by one, that maybe don’t take forever, and that are limited in complexity by the hardware you’re working on. A simple text editor, some graphics primitives, maybe a sound subsystem. A way to read and write files in flash. I don’t love LISP personally, but I love that it brings interactivity and independence from an external compiler, making the it possible to develop the system on the system, pulling itself up by its own bootstraps.

Pretty soon, you could have something capable, and completely DIY. But it doesn’t need to be done all at once either. With a light enough computer, and a good basic foundation, you could keep it in your backpack and play “OS development” whenever you’ve got the free time. A DIY play OS for a sandbox computing platform: what more could a nerd want?

A yellow computer with a black keyboard and a small monochrome LCD screen

Low Power Challenge: The PotatoP Runs Lisp For Months Without Recharging

March 6, 2023 by Robin Kearey 53 Comments

A common complaint among laptop users is that while battery technology has vastly improved over the past decades, a simulltaneous shrink in form factors has meant that a typical laptop today doesn’t last much longer on a battery charge than one from the early 2000s. But it doesn’t have to be that way, as [Andreas Eriksen] demonstrates with his entry for the Low Power Challenge. The PotatoP is a portable computer that should be able to run for about two years on a single battery charge, and can be topped up through an integrated solar panel.

Granted, it doesn’t have the processing power of even the cheapest laptop you can buy today, but it’s perfectly fine for [Andreas]’s use case. He’s a Lisp hacker, and a Sparkfun RedBoard Artemis can run uLisp just fine on its 48 MHz Cortex-M4F processor. The operating environment is very basic though, even requiring [Andreas] to write his own text editor, called Typo, to give him editing luxuries like backspace functionality and a movable cursor.

The Artemis board is very power-efficient by itself – typical power consumption is less than 1 mA. [Andreas] added a simple monochrome black-and-white LCD screen capable of displaying 53 columns of text, plus an SD card reader for data storage, and designed a sleek 3D-printed case to hold everything together. When running a typical piece of code, the entire system uses around 2.5 mA, which translates to about 125 days of continuous run-time on the beefy 12000 mAh lithium battery. Add a bit of solar power, plus a more realistic eight-hour working day, and the two year runtime estimated by [Andreas] appears entirely reasonable.

This has to be one of the most power-efficient portables we’ve ever seen, and one running Lisp at that. Despite its age, Lisp keeps popping up in interesting custom computers like the Lisperati1000 cyberdeck and The Lisp Badge.

Continue reading “Low Power Challenge: The PotatoP Runs Lisp For Months Without Recharging” →

Lisp Runs This Microcontroller Pendant

December 10, 2022 by Bryan Cockfield 20 Comments

As a programming language, Lisp has been around longer than any other active language except for Fortran. To anyone who regularly uses it, it’s easy to see why: the language allows for new syntax and macros to be created fluidly, which makes it easy to adapt it to new situations, like running it on a modern Atmel microcontroller to control the LEDs on this star pendant.

The pendant has simple enough hardware — six LEDs arranged around the points of the star, all being driven by a small ATtiny3227 operating from a coin cell battery. This isn’t especially spectacular on it’s own, but this particular microcontroller is running an integer version of a custom-built Lisp interpreter called uLisp. The project’s creator did this simply because of the whimsy involved in running a high-level programming language on one of the smallest microcontrollers around that would actually support the limited functionality of this version of Lisp. This implementation does stretch the memory and processing capabilities of the microcontroller quite a bit, but with some concessions, it’s able to run everything without issue.

As far as this project goes, it’s impressive if for nothing other than the ‘I climbed the mountain because it was there’ attitude. We appreciate all kinds of projects in that same vein, like this Arduino competitor which supports a programming language with only eight commands, or this drone which can carry a human.

Fossil Files: My .Emacs

December 10, 2022 by Elliot Williams 63 Comments

Last week, I wrote about cargo culting in a much more general context, so this week I’m going to come clean. The file that had me thinking about the topic was the worst case you’ve probably ever seen: I have a .emacs file kicking around that I haven’t really understood since I copied it from someone else – probably Ben Scarlet whose name is enshrined therein – in the computer lab in 1994! Yes, my .emacs file is nearly 30, and I still don’t really understand it, not exactly.

Now in my defence, I switched up to vim as my main editor a few years ago, but this one file has seen duty on Pentiums running pre-1.0 versions of Linux, on IBM RS/6000 machines in the aforementioned computer lab, and on a series of laptops and desktops that I’ve owned over the years. It got me through undergrad, grad school, and a decade of work. It has served me well. And if I fired up emacs right now, it would still be here.

For those of you out there who don’t use emacs, the .emacs file is a configuration file. It says how to interpret different files based on their extensions, defines some special key combos, and perhaps most importantly, defines how code syntax highlighting works. It’s basically all of the idiosyncratic look-and-feel stuff in emacs, and it’s what makes my emacs mine. But I don’t understand it.

Why? Because it’s written in LISP, for GNU’s sake, and because it references all manner of cryptic internal variables that emacs uses under the hood. I’m absolutely not saying that I haven’t tweaked some of the colors around, or monkey-patched something in here or there, but the extent is always limited to whatever I can get away with, without having to really learn LISP.

This ancient fossil of a file is testament to two things. The emacs codebase has been stable enough that it still works after all this time, but also that emacs is so damn complicated and written in an obscure enough language that I have never put the time in to really grok it – the barriers are too high and the payoff for the effort too low. I have no doubt that I could figure it out for real, but I just haven’t.

So I just schlep this file around, from computer to computer, without understanding it and without particularly wanting to. Except now that I write this. Damnit.

Featured image: “A Dusty Old Book” by Marco Verch Professional.