Paolo Amoroso's Journal

Tech projects, hobby programming, and geeky thoughts of Paolo Amoroso

My first Medley Interlisp blog post was shared on Hacker News, got over a hundred upvotes, and ended up on the front page, where it still is a day later after climbing up to number 5. So far my post received over 24K views, and counting.

I'm really glad Medley Interlisp is gaining some very well deserved attention.

#blogging #Interlisp #Lisp

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

Beagle Term is a terminal emulator Chrome packaged app for controlling serial USB devices.

I checked it out with the Z80-MBC2 and the V20-MBC homebrew computers on my Chromebox and the app works well, with good VT100 emulation. A major downside is it doesn't support XMODEM or other file transfer protocols. And Google deprecated Chrome apps, so this one will eventually be discontinued.

When plugging a serial device into a USB port, chromeOS prompts to connect to the device from the Crostini Linux or the Android container. But Beagle Term runs in Chrome, so the selection isn't necessary and the notification may be dismissed.

Launching the app opens a connection configuration dialog prefilled with the default communication parameters, which are fine for the homebrew computers.

As I said VT100 emulation is pretty good. For example, here is the CatChum Pacman clone running under CP/M Plus on the Z80-MBC2:

CatChum Pcaman clone under CP/M Plus on the Z80-MBC2 homebrew computer.

And this is what WordStar 4 looks like under CP/M-86 on the V20-MBC:

WordStar under CP/M-86 on the V20-MBC homebrew computer.

Good VT100 support shouldn't be taken for granted in terminal emulators as it may be missing or broken such as in CuteCom or Serial USB Terminal.

#z80mbc2 #v20mbc #chromeOS

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

I enrolled into Bring Back Blogging. It's a project to encourage and bring awareness to blogging by challenging bloggers to publish at least 3 posts in January of 2023, and enabling readers to discover content in the list of participating blogs that includes almost 140 so far. I blog regularly anyway, so it was a no brainer.

I shared Bring Back Blogging on Mastodon and my toot generated huge enthusiasm, with many saying they'll join.

#blogging

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

The iLoad feature of the Z80-MBC2 homebrew Z80 computer allows uploading binary code that runs on the bare metal.

I thought it would be fun to try iLoad with some Intel 8080 code generated by the asm80 assembler of Suite8080, the suite of 8080 Assembly cross-development tools I'm writing in Python. But the code crashed the Z80-MBC2, uncovering a major asm80 bug.

It all started when, to practice the toolchain and process, I started with a Z80 Assembly demo that comes with the Z80-MBC2, which prints a message to the console and blinks one of the devices's LEDs. I assembled the program with the zasm Z80 and 8080 assembler, uploaded it via iLoad, and successfully ran it.

Next, I ported the blinking LED demo from Z80 to 8080 code and assembled it with asm80. But when I ran the demo on the Z80-MBC2, it crashed the device.

The baffling crash left me stuck for threee months, as I had no tools for debugging on the bare metal and there were only a few vague clues.

I carefully studied the less than a hundred lines of code and they looked fine. To isolate the issue I cut the code in half, leaving the part that prints a message to the console, and transforming the blinking demo into this bare.asm hello world for the bare metal:

OPCODE_PORT     equ     01h
EXEC_WPORT      equ     00h
TX_OPCODE       equ     01h
EOS             equ     00h
CR              equ     0dh
LF              equ     0ah


                org     0h

                jmp     start

                ds      16
stack:


start:          lxi     sp, start
                lxi     h, message
                call    puts

                hlt


message:        db      CR, LF, 'Greetings from the bare metal', CR, LF, EOS


puts:           push    psw
                push    h
puts_loop:      mov     a, m
                cpi     EOS
                jz      puts_end
                call    putc
                inx     h
                jmp     puts_loop
puts_end:       pop     h
                pop     psw
                ret


putc:           push    psw
                mvi     a, TX_OPCODE
                out     OPCODE_PORT
                pop     psw
                out     EXEC_WPORT
                ret

                end

The constants at the beginning define the addresses of the output ports, the opcode for sending a character over the serial line, and a couple of control characters. Next, the program sets up the stack and iterates over the output string to print every character.

The simplified demo program still crashed the Z80-MBC2, forcing me back to the drawing board.

Then I had an epiphany. What if the binary code asm80 generates is different from zasm's?

I fired up the dis80 disassembler of Suite8080 and compared the output of the assemblers. Sure enough, the difference jumped at me: the destination addresses of all the branches after the label message are off by 5 bytes.

The instructions branch to addresses 5 bytes lower, so the call to puts executes random string data that chrashes the device. The last correct address asm80 outputs is that of the label message. The address of the next one, puts, is wrong and leads to the crash.

Indeed, the same demo code assembled with zasm ran fine on the Z80-MBC2 and printed the expected message. This confirmed my hunch.

What now?

The next step is to find the bug in the Python source of asm80, which I'm developing with Replit. Although Replit provides a debugger, I won't use it. The tool is not well documented and I'm not sure how it works. In addition the Replit debugger is best suited to code started from the run button. This is inconvenient for command line programs like the Python scripts of Suite8080.

Therefore, I'll take the opportunity to use Python's native debugger pdb, which I always wanted to try in a real project. I played with pdb a bit and it looks easy to use, with all the commands and options handy.

Let's see if pdb can help me pinpoint the bug in the Python code.

#Suite8080 #z80mbc2 #Assembly #Python

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

I'm reading the book Writing An Interpreter In Go by Thorsten Ball, which I got along with the sequel Writing A Compiler In Go.

I have always been fascinated by compilers and seeked good learning resources. These books bridge the gap between short tutorials that teach how to write an arithmetic expression parser, and 900 page compiler tomes packed with math.

I don't know Go, but Ball designed the books and sample code so that no knowledge of the language is required other than a general programming background. All I know about Go comes from reading the Wikipedia entry and a short reference. Yet the code of Writing An Interpreter In Go is easy to understand, reads as pseudocode, and is arranged in short blocks rarely spanning more than a page.

I really love Writing An Interpreter In Go.

The book presents the material in a smooth and clear progression and anticipates the questions the reader may have. For example, whenever I wonder why some code does or doesn't do something, the next paragraph acknowledges and addresses the hurdle.

I hope Ball's books will help me rewrite the assembler of my Suite8080 suite of Intel 8080 Assembly tools, finally replacing the ad hoc syntacting analysis mess with a true and extensible parser.

#development #books

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

This is the 200th post over 10 months of my blog hosted at Write.as. The milestone is even more significant considering I published 146 posts over 3 years to my previous blog hosted at the bloated, inflexible, and clunky old Blogger.

I credit the milestone in large part to Write.as, a lightweight blogging platform that nearly eliminates friction with its Markdown support and minimalist design.

Typing into the Write.as editing area is all it takes to insert, format, and present the content of a post. With Blogger, even basic text formatting requires laboriously moving and clicking the mouse to select text, click icons, pick menu items, and apply formatting. It all adds up to enough friction to dread the experience and be discouraged from posting.

I started this blog on February 28, 2022. I stumbled upon Write.as at the end of a long research process that led to the best platform for my technical writing needs.

#blogging

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

I'm always looking for terminal emulators and communication programs for controlling the Z80-MBC2 and V20-MBC, hoping they provide useful features Minicom misses.

That's why when stumbling upon CuteCom I eagerly checked it out. CuteCom is a graphical serial terminal program for Linux with a clean and simple user interface.

I tried it in Crostini Linux on my Chromebox connected to the Z80-MBC2 and the V20-MBC. The layout of CuteCom's window reminds me of the Serial USB Terminal app for Android which, unlike Minicom's single input and output area, has an input field separate from the output area.

The basic features of CuteCom are okay, but the program has major limitations when used with my homebrew computers. The main one is the program does no terminal emulation, doesn't support the escape codes for terminal control, and doesn't even properly align the output of a simple program like DIR. This screenshot of a V20-MBC CP/M-86 session shows the issue:

CuteCom terminal connected to a V20-MBC homebrew CP/M-86 computer.

I checked out CuteCom also with the Z80-MBC2 and tried to upload a file with XMODEM to a CP/M Plus session. However, an error informed CuteCom was unable to start the Linux program sz. There were no other clues and CuteCom has no documentation, so I have no idea what may be wrong. sz seems correctly set up under Crostini.

Given these issues, I can't unfortunately use CuteCom with the Z80-MBC2 and the V20-MBC.

The program is not a full terminal emulator to run programs that send terminal control codes to format the output. Instead, it's designed for the different use case of accessing electronic boards, embedded systems, and other devices via a serial connection, which typically produce line-oriented output.

#z80mbc2 #v20mbc

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

The great experience with Mastodon and the Fediverse made me curious about other decentralized and federated platforms.

As the next step, I decided to check out the Matrix messaging and communication network. Browsing the list of the main homeservers led me to join aria-net.org, the only one in Italy where I live.

As Matrix clients I use the Element web app on my Chromebox and the Element Android app on my Pixel 4 XL. Element has a clean, modern design the developers rightly describe as “glossy”. I also love the Markdown support, a key productivity feature. There are several features and settings I need to study in more detail, especially the message encryption options.

However, my experience with the Matrix infrastructure has been a bit bumpy so far as the homeserver has configuration, stability, and certificate issues.

When signing up, an error reported the handle of my account was already in use, but the server let me sign in with and use it anyway. As prompted, I tried to verify my phone numer but received another error. According to the server's help desk phone verification was disabled.

Sometimes the Element web app doesn't load or is slow. But an even more serious issue prevents me from using the web app. For the past severel days, visiting the website has been returning the error NET::ERR_CERT_COMMON_NAME_INVALID due to certificate issues.

If these issues persist, I will have to migrate to a more stable homeserver. It won't be a problem as only one of my contacts uses Matrix so far.

#misc

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

Enter your email to subscribe to updates.