TinyBasicLike: A Target-Independent BASIC Interpreter

In the long and winding history of BASIC, it’s sometimes hard to keep track of all the different variants and dialects. Some may still remember TinyBASIC, which was published in 1976 as Palo Alto Tiny BASIC by [Gordon Brandly]. Later, TinyBASIC was modified by a number of people including [Scott Lawrence] who created TinyBASIC Plus (TBP). Inspired by this, [Karl] figured he could improve on TBP by making the original C-based project even easier to port by removing whatever platform dependencies he could find, creating what he calls TinyBasicLike.

The main change is that TinyBasicLike consists out of two C files, with one containing the core code, and the second the platform-specific details that can be used by the core. Although [Karl] started off with the Palo Alto Tiny BASIC-like code by [Scott Lawrence], he decided to make it into his own by making a few alterations, such as adding left and right shift operators, adding an ADDR() function, expanding the features of INPUT and adding multiple logical operators.

In the example STM32F4 project linked on the project page it is demonstrated how to target a new platform with TinyBasicLike. Performance on the STM32F4 Discovery board with a simple counting loop yielded about 6 lines of TBL program code per millisecond. For a 168 MHz STM32 MCU that’s definitely not astounding, but considering how straightforward Tiny BASIC (and TBL as a consequence) is, it’s definitely no slouch.

This is probably a good time to remind that BASIC was the original champion of cross-platform programming and the source of countless fond (and frustrating) memories.

Illumos Gets A New C Compiler

Illumos is an OpenSolaris-derived Unix system, and no Unix is complete without a C compiler or two. And with a name like Portable C Compiler (PCC), you would think that would be a great bet to get up and running on Illumos. That’s probably what [Brian Callahan] thought, too, but found out otherwise.

PCC already generates x86 code, so that wasn’t the problem. It was a matter of reconfiguring the compiler for the environment, ironic since PCC probably started on true Unix but now won’t work with 64-bit Solaris-like operating system. According to the post:

It looks like some time ago someone added configuration for 32-bit x86 and SPARC64 support for the Solaris family. But no one ever tried to support 64-bit x86. So first we had to teach the configure script for both pcc and pcc-libs that 64-bit x86 Solaris

Continue reading “Illumos Gets A New C Compiler”

Ask Hackaday: Learn Assembly First, Last, Or Never?

A few days ago, I ran into an online post where someone pointed out the book “Learn to Program with Assembly” and asked if anyone had ever learned assembly language as a first programming language. I had to smile because, if you are a certain age, your first language may well have been assembly, even if it was assembly for machines that never existed.

Of course, that was a long time ago. It is more likely, these days, if you are over 40, you might have learned BASIC first. Go younger, and you start skewing towards Java, Javascript, or even C. It got me thinking, though: should people learn assembly, and if so, when?

Continue reading “Ask Hackaday: Learn Assembly First, Last, Or Never?”

Linux Device Drivers In Only A Few Years

[Johannes 4GNU_Linux] has been filming a video series on how to write Linux device drivers for a couple of years now, but luckily, you won’t need that long to watch them or to create your own driver. He’s added some recent videos to the series, like the one below, but might want to rewind a few years and start at the beginning.

If you build your own hardware for Linux, you’ll probably eventually want to write a driver which runs as a privileged program. While there are many things you can do in user space, for the ultimate control and performance, you can’t beat a driver.

One problem, though, is that drivers can really crash your system in a big way. In the old days, it was common to have a dedicated system for driver development. Today, for many drivers, you can get away with running a virtual machine that you can crash and reload without much trouble.

The videos cover diverse topics like interrupts, completions, polling, and threads. He even uses a Raspberry Pi, which will be very useful for many embedded projects. Of course, the trend these days is to have one driver — like the USB driver — and have it provide user-space access so that everyone doesn’t have to write their own drivers. But, as usual, that only goes so far.

We aren’t sure how many more videos there will be, but if you make it through the first 31, maybe more will be waiting for you. It has been a while since we looked at SPI drivers in Linux. As an example of why you might want to roll your own, consider a custom FPGA driver.

Continue reading “Linux Device Drivers In Only A Few Years”

MicroLisp: Lisp For Microcontrollers Now Has Lisp-Based ARM Assembler

In a way it feels somewhat silly to market a version of Lisp as targeting resource-constrained platforms, considering the systems it ran on back in the 1960s, but as time goes on, what would have given 1970s Big Iron a run for its money is now a sub-$5 microcontroller that you can run uLisp (MicroLisp) on. This particular project now even has an ARM assembler that is written in Lisp whose source code (GitHub) fits on a mere two A4-sized pages.

ULisp currently supports five platforms, being AVR-nano (ATmega328 and similar low-cost AVRs), AVR, ARM, ESP (8266 and 32), as well as RISC-V. The purpose of this assembler is to execute native ARM instructions when running on an ARM board, since uLisp itself runs a Lisp interpreter on the platform. When executed natively like this, a considerable speed-up of the task can be expected, as illustrated by a number of ARM assembler examples in the documentation.

Running a Fibonacci sequence that takes 24.6 seconds with the Lisp version on an Adafruit Metro M4 is reduced to a mere 61 ms when ARM assembly is used instead. This shouldn’t be too shocking, since this assembler essentially bypasses the Lisp runtime, coming closer to what would be the performance of firmware written in e.g. C. However, it also demonstrates that with this ARM assembler it is possible to have your Lisp and still get native performance when you want it, all using Lisp code.

Suc Aims To Replace Slack In Five Lines Of Bash

The design philosophy of Unix is fairly straightforward. Software should do one thing as simply as possible, and do that one thing only. As a design principle this is sound advice even well outside of the realm of Unix, and indeed software in general, but that doesn’t stop modern software packages from being too large for their own good. So, if you’re tired of bloated chat programs like Slack or Mattermost with their millions of lines of code, you might instead favor something like Simple Unix Chat (suc).

The idea is that suc can perform almost all modern chat functions in only five lines of Bash, supporting rich-text chat, file sharing, access control, and encryption. These five lines, though, only perform the core function of suc — which is to write text to a file on the system. Indeed, suc makes liberal use of plenty of other Unix services which do not add to the line counts, such as the use of SSH to handle authentication. It also relies on some other common Unix system features to handle things like ownership and access for the text files that host the text for the chat.

As channels are simply text files, it makes writing bots or other tools exceptionally simple. You can also easily pipe the output of commands directly into suc with one-liners that can do things like dump the output of make into a specific channel if compilation fails.

While it’s not likely that everyone will ditch tools like Slack to switch to something like this, it’s still an impressive demonstration of what can be done when designing around the Unix philosophy and taking advantage of system tools that already exist rather than reinventing the wheel and re-programming all of those tools into the application. Practices like this might decrease development time and increase the ease of developing cross-platform applications but they often also produce a less than desirable user experience.

Reviving Interlisp With The Medley Interlisp Project

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.