Paolo Amoroso's Journal

retrocomputing

My journey to Lisp began in the early 1990s. Over three decades later, a few days ago I rediscovered the first Lisp environment I ever used back then which contributed to my love for the language. Here it is, PC Scheme running under DOSBox-X on my Linux PC:

Screenshot of the PC Scheme Lisp development environment for MS-DOS by Texas Instruments running under DOSBox-X on Linux Mint Cinnamon.

Using PC Scheme again brought back lots of great memories and made me reflect on what the environment taught me about Lisp and Lisp tooling.

As a Computer Science student at the University of Milan, Italy, around 1990 I took an introductory computers and programming class taught by Prof. Stefano Cerri. The textbook was the first edition of Structure and Interpretation of Computer Programs (SICP) and Texas Instruments PC Scheme for MS-DOS the recommended PC implementation. I installed PC Scheme under DR-DOS on a 20 MHz 386 Olidata laptop with 2 MB RAM and a 40 MB hard disk drive.

Prior to the class I had read about Lisp here and there but never played with the language. SICP and its use of Scheme as an elegant executable formalism instantly fascinated me. It was Lisp love at first sight.

The class covered the first three chapters of the book but I later read the rest on my own. I did lots of exercises using PC Scheme to write and run them.

Soon I became one with PC Scheme.

The environment enabled a tight development loop thanks to its Emacs-like EDWIN editor that was well integrated with the system. The Lisp awareness of EDWIN blew my mind as it was the first such tool I encountered. The editor auto-indented and reformatted code, matched parentheses, and supported evaluating expressions and code blocks. Typing a closing parenthesis made EDWIN blink the corresponding opening one and briefly show a snippet of the beginning of the matched expression.

Paying attention to the matching and the snippets made me familiar with the shape and structure of Lisp code, giving a visual feel of whether code looks syntactically right or off. Within hours of starting to use EDWIN the parentheses ceased to be a concern and disappeared from my conscious attention. Handling parentheses came natural. I actually ended up loving parentheses and the aesthetics of classic Lisp.

Parenthesis matching suggested me a technique for writing syntactically correct Lisp code with pen and paper. When writing a closing parenthesis with the right hand I rested the left hand on the paper with the index finger pointed at the corresponding opening parenthesis, moving the hands in sync to match the current code. This way it was fast and easy to write moderately complex code.

PC Scheme spoiled me and set the baseline of what to expect in a Lisp environment.

After the class I moved to PCS/Geneva, a more advanced PC Scheme fork developed at the University of Geneva. Over the following decades I encountered and learned Common Lisp, Emacs, Lisp, and Interlisp. These experiences cemented my passion for Lisp.

In the mid-1990s Texas Instruments released the executable and sources of PC Scheme. I didn't know it at the time, or if I noticed I long forgot. Until a few days ago, when nostalgia came knocking and I rediscovered the PC Scheme release.

I installed PC Scheme under the DOSBox-X MS-DOS emulator on my Linux Mint Cinnamon PC. It runs well and I enjoy going through the system to rediscover what it can do.

Playing with PC Scheme after decades of Lisp experience and hindsight on computing evolution shines new light on the environment.

I didn't fully realize at the time but the product packed an amazing value for the price. It cost $99 in the US and I paid it about 150,000 Lira in Italy. Costing as much as two or three texbooks, the software was affordable even to students and hobbyists.

PC Scheme is a rich, fast, and surprisingly capable environment with features such as a Lisp-aware editor, a good compiler, a structure editor and other tools, many Scheme extensions such as engines and OOP, text windows, graphics, and a lot more. The product came with an extensive manual, a thick book in a massive 3-ring binder I read cover to cover more than once. A paper on the implementation of PC Scheme sheds light on how good the system is given the platform constraints.

Using PC Scheme now lets me put into focus what it taught me about Lisp and Lisp systems: the convenience and productivity of Lisp-aware editors; interactive development and exploratory programming; and a rich Lisp environment with a vast toolbox of libraries and facilities — this is your grandfather's batteries included language.

Three decades after PC Scheme a similar combination of features, facilities, and classic aesthetics drew me to Medley Interlisp, my current daily driver for Lisp development.

#Lisp #MSDOS #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org

Medley Interlisp is the cover story of issue 70 of 8bitnews. I brought the historical Lisp environment to the attention of the 8bitnews editors, who published a story that also shares the post on my encounter with Medley Interlisp. Thanks Jan and Bastian!

8bitnews is my favorite retrocomputing newsletter, an interesting and engaging resource I always look forward to reading.

#Interlisp #Lisp #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org

The post on my encounter with Medley Interlisp ended up on the front page of Hacker News, receiving over 34K views and a lot of attention.

Larry Masinter, one of the original Medley Interlisp designers and current maintainers, invited me to join the project. I'm really honored and happy to have accepted, as I'm meaning to explore Medley Interlisp and use it as my main development environment. Also, I hope to give something back to this incredible retrocomputing project.

My first pull request was merged. It's a trivial change that adds a new section, written by another maintainer, to a page of the project website. But I'm pleased as it helped me familiarize with the development process, the code base, and the toolchain.

I'll initially focus on documentation and outreach, a byproduct of my learning journey. In the long term I may venture into contributing some fixes or additional Lisp code.

#Interlisp #Lisp #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org

Imagine someone let you into an alien spaceship they landed in your backyard, sat you at the controls, and encouraged you to fly the ship. This is the opportunity Medley Interlisp offers.

The project

Medley Interlisp is a project aiming to restore the Interlisp-D software environment of the Lisp Machines Xerox produced since the early 1980s, and rehost it on modern operating systems and computers. It's unique in the retrocomputing space in that many of the original designers and implementors of major parts of the system are participating in the effort.

The project started slightly over three years ago and is little known, so I stumbled upon it by chance. I was immediately drawn to Medley Interlisp for two reasons.

My experience with Lisp

First, I have a soft spot for Lisp. Since the early 1990s, for a couple of decades I extensively used several Lisp dialects and systems such as Scheme, Common Lisp, and Emacs Lisp.

I read a lot about Lisp Machines and their lost wonders but never got a chance to use one.

Although I always wanted to try such a system, hardware solutions are impractical and there are only a handful of Lisp Machine emulators, usually limited or difficult to set up. So the second reason Medley Interlisp caught my attention is, unlike similar efforts, it offers a complete environment that's easy to install and run. It can even run in the cloud and be accessed in a browser, here it is on my Chromebox:

Medley Interlisp running in a browser on chromeOS.

Why Medley Interlisp is different

The Medley Interlisp project is significant because it provides access to the full Interlisp-D software system. Working with a Lisp Machine environment feels like an encounter with an advanced civilization, so the spaceship metaphor is fitting.

A number of features make the image-based environments of Lisp Machines unique and still largely unparalleled by traditional file-based development environments and tools, where code is stored in source files and the environments are separate from the systems being built.

In an image-based environment, the developer builds programs by directly adapting and extending the running image of a system that consists of system software and development tools. The programs under development and the tools they're built with share the same space.

Everything is an API. Pretty much everything — system services, functions, user code, data structures, libraries, tools, GUI components and graphics, files, and resources — can access, inspect, call, and modify everything else. The environment provides a myriad of such building blocks that can be easily and quickly combined in countless ways to create more complex systems.

All these features transform Medley Interlisp into a productive, controlled creative chaos that encourages and supports prototyping and exploration.

The challenges

Medley Interlisp has some key strenghts, such as a rich environment and the ability to run in a browser. But the restoration and rehosting work is still under way, which makes using the system even more challenging.

The learning curve of such a complex system is steep, almost vertical.

This is less of an issue than it seems as I overcome these hurdles by diving deep into the documentation. I read everything I come across and at first not much makes sense. Eventually, my brain processes in the background all the information and the pieces start to fall into place.

Medley Interlisp comes with a dozen thousand pages worth of manuals, books, and academic papers, not to mention Lisp's built-in documentation and introspection facilities. I hope this knowledge will eventually help me contribute to the project in some way.

Also, due to the many layers of modern software the system now runs on, some of the original keybindings are broken or not properly mapped.

For example, pressing the arrow keys has no effect and doesn't move the text cursor. The keys are important for controlling system tools such as code and text editors. But, for the time being, there are good mouse-based alternatives that don't introduce too much friction when coding.

How I'll use Medley Interlisp

Despite some issues, my interest in Medley Interlisp goes beyond studying a significant software artifact of the history of computing. This decades old environment still has great practical value.

I'd like to use Medley Interlisp as my primary development environment for exploring problem domains, prototyping, and learning computer science. The problem understanding and design insights gained by experimenting with Medley Interlisp can be transferred to the projects I choose to implement with modern programming languages and tools.

The performance of the rehosted Medley Interlisp is pretty good. On my Chromebox it even runs faster in the browser than in the Crostini Linux container.

And I love the timeless, clean design of the black and white Medley Interlisp GUI, a style that evokes the elegance of printed paper. Only some pixelation gives away the historical roots of Medley Interlisp in an era predating the wide support for anti-aliasing.

As a hobby programmer I get to decide what tools to use and what projects to work on. I highly enjoy this complete creative freedom. The freedom to play with the tools I love, no matter how old or weird.

#Interlisp #Lisp #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org

You know what I envied of those influencers with millions of followers? The magic of tweeting a question and getting valuable answers and advice from knowledgeable people.

I'm no celebrity, but on Mastodon I'm getting the same experience with orders of magnitude fewer followers.

As a retrocomputing enthusiast, it's a lot of fun to explore and program my V20-MBC homebrew Nec V20 computer. But CP/M-86, one of the operating systems the V20-MBC runs, was eclipsed by MS-DOS back in the day, leaving little surviving documentation and literature. Especially about CP/M-86 development.

So the Open Library listing of the book CP/M-86 Assembly Language Programming by Jon Lindsay (Brady Communications Co., 1986) caught my attention. Sadly, the text isn't available. I decided to try to track down the book, starting by asking for help on comp.os.cpm.

Without expecting much, I also posted a toot to my Mastodon account in case anyone had useful clues on the book. What happened next blew my mind.

Within a day the post was boosted over a hundred times, got some fifty stars, and received dozens of valuable replies. The replies contributed promising leads, tagged others who might know something, suggested workarounds or other lines of inquiry, and started a few interesting side conversations. Everyone went out of their way to assist.

I was speechless, breathless. Literally. I didn't even know how to adequately thank the many who chimed in.

This isn't possible on Twitter, where the algorithms boost celebrities and influencers and bury everyone else.

You may think this overwhelming support has something to do with my 1.1K Mastodon followers. But I've been having a similar experience since joining Mastodon ten months ago. I'd say the critical mass is somewhere between a few dozen and a couple hundred followers.

I want to give back. I want to give others the opportunity of a similar positive experience, which is within reach of everyone in the Fediverse. Boosts proved crucial to amplify my quest for help, so I'm boosting more toots for a chance to reach someone who may be interested or willing to help.

People are the ultimate algorithm.

#fediverse #retrocomputing #books

Discuss... Email | Reply @amoroso@fosstodon.org

I'm collecting and reading more Pascal programming books than I ever did.

My Z80-MBC2 and V20-MBC come with Turbo Pascal for CP/M preinstalled. Using the environment is making me rediscover Turbo Pascal and realize it's great for creating small CP/M tools and programs.

To take advantage of Turbo Pascal I have been gathering old books and other Pascal learning resources that cover the CP/M version I use, selecting only the best and most interesting.

All of them are available online, for example at the Open Library or Bitsavers.org. But these works are too precious and may disappear, not to mention the high prices of rare retrocomputing books. I want backups, so I bought used copies of some of these. Here's what my Pascal programming retro bookshelf looks like:

Pascal programming books.

These are the Pascal books and resources I reference most often, along with notes on what they cover or why I like them:

#pascal #retrocomputing #books

Discuss... Email | Reply @amoroso@fosstodon.org

I assumed in Turbo Pascal for CP/M, when printing to a terminal, writeln wraps lines longer than the screen width. A quick test under CP/M-86 on the V20-MBC proved such lines are truncated instead. In hindsight it makes sense, as there's limited output state on a terminal system with no frame buffer.

#v20mbc #retrocomputing #development

Discuss... Email | Reply @amoroso@fosstodon.org

To code on the Z80-MBC2 and V20-MBC homebrew computers I often transfer text files to and from their CP/M environments.

In one direction I send files from Crostini Linux by dumping them to CP/M, where PIP saves the text to CP/M files. In the opposite direction I run PIP on CP/M to print the files to the screen, where Minicom captures the text and saves it to files on Crostini.

CP/M and Unix have different line break and end of file encodings. In addition, the transfer process may introduce unwanted text. That's why the text files exchanged between the systems need some conversion, to automate which I wrote two short Bash scripts.

The first script, unix2cpm, converts line breaks and the end of file marker in the input to the CP/M encoding and prints the result to stdout. If the optional file name argument isn't supplied the script reads from stdin with a technique I researched. This is the script:

#!/usr/bin/env bash

# Convert line breaks and end of file from Unix to CP/M.
#
# Usage:
#
#   unix2cpm [filename]
#
# Reads from stdin if the optional argument is missing.

input_file="${1:-/dev/stdin}"

cat "$input_file" | unix2dos
echo -e -n '\x1a'

The script calls unix2dos distributed with the dos2unix / unix2dos tools. unix2dos converts line breaks from Unix to MS-DOS, which borrows the encoding from CP/M. unix2cpm needs only to append with echo the ^Z end of file control character.

Once converted, the file is ready to be dumped from Linux to CP/M.

I initiate file transfers in the oppostite direction by executing the Minicom command to capture the terminal output to a file, Ctrl-A L (Capture on/off). Then, at the CP/M prompt, I execute a command like this to print a file to the console:

A>a:pip con:=filename.txt

When printing ends and the A> prompt reappears, I turn off output capture in Minicom to close the capture file. The captured output contains the PIP command in the first line, then the text of the file, and finally the A> prompt in the last line.

To remove the unwanted first and last line I wrote the second script, skipfl (skip first and last). Again, the script reads from stdin if the optional file name isn't supplied and writes to stdout. The code is:

#!/usr/bin/env bash

# Skip the first and last file of the argument file
#
# Usage:
#
#   skipfl [filename]
#
# Reads from stdin if the optional argument is missing.

input_file="${1:-/dev/stdin}"

cat "$input_file" | sed '1d' | sed '$d'

The script calls sed to delete the first and last line with the d command.

No further processing of the captured CP/M output file is necessary as Minicom takes care of inserting the proper line break and end of file encodings.

#z80mbc2 #v20mbc #linux #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org

Turbo Pascal 3.0 for CP/M has a display issue I noticed on the Z80-MBC2 and V20-MBC homebrew computers. When using the development environment, text in the terminal remained stuck with boldface turned on.

It was enough to launch Turbo Pascal and execute any command (e.g. compiler Options), or exit Turbo Pascal, to turn on boldface and leave it stuck in the IDE, in CCP, and when running other programs. Everything went bold such as code in source files edited in Turbo Pascal, CCP command lines, and the output of transient programs.

The issue occurred under CP/M 3.0 on the Z80-MBC2 and CP/M-86 1.1 on the V20-MBC, both accessed from the Minicom terminal emulator under Crostini Linux on my Chromebox.

I tried ANSI and VT102 emulation in Minicom and run the Turbo Pascal configuration utility TINST to set the terminal to ANSI, but the issue persisted. The only workaround was to resize the terminal window, which reinitializes the display.

I posted to comp.os.cpm for help and learnt Borland left the terminal reset string blank in the ANSI entry, which thus doesn't reset text attributes.

The fix was simple. I run TINST, selected the ANSI terminal, and edited the definition to insert the following reset string via the option Send a reset string to the terminal (the corresponding escape code strings and descriptions are below the hex values):

$1b $63    $1b  $5b $32 $4a

ESC c      ESC  [   2   J
Reset      Clear screen

ESC c is not enough as it only resets the terminal but doesn't clear the screen. With the new string the text attributes are now properly handled and the terminal is no longer stuck in boldface after using Turbo Pascal.

#z80mbc2 #v20mbc #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org

The option 4: Autoboot-80 of the V20-MBC boot menu switches the Nec V20 to Intel 8080 mode and loads version 1.4 of the IMSAI 8K BASIC interpreter. In this session I typed in and run a short BASIC program to print the ASCII character set:

IMSAI BASIC on the V20-MBC homebrew computer.

The code is:

10 FOR I=32 TO 127
20 PRINT CHR$(I);
30 NEXT I

Despite the brevity, entering the code I bumped into some unexpected errors and behavior. It's been almost four decades since I used a resident BASIC on a microcomputer, and never with a terminal. No wonder interacting with IMSAI BASIC felt weird.

Reading the IMSAI BASIC manual and experimenting with the interpreter cleared the hurdles and let me make progress, though I'm not sure whether the issues may be related to the terminal settings. By the way, the commented Assembly source of the interpreter in the manual is an interesting reading.

Here are some notes on what I learned.

BASIC keywords, commands, and identifiers must be in all uppercase. Lowercase is supported only in strings assigned to variables, but printing string literals yelds uppercase text.

Pressing Backspace or Ctrl-H moves the cursor one character to the left and Del does nothing. The only ways of fixing typos or errors are deleting the whole line with Ctrl-U or entering it again.

When the environment gets messed up I execute the NEW command that clears the program and data, thus letting me start from scratch.

#v20mbc #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org