Paolo Amoroso's Journal

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

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

Although I used several Lisp systems over a couple of decades, I never tried structure editing.

The chance finally came when I encountered Medley Interlisp, the Lisp system that pioneered structure editing. In particular I use SEdit which is the most advanced and user-friendly Interlisp structure editor.

I really like structure editing. It feels easier than I expected, natural, and productive. Plus it's a lot of fun.

The Medley Interlisp project is rehosting and modernizing the system to run on contemporary operating systems and computers but there are still a few rough edges, such as missing or broken keystrokes. Most notably the arrow keys don't work. I assumed this would severely limit coding with SEdit, but it turns out the tool can still be used productively and with very little friction.

Despite the issue, mouse operation in SEdit may be faster than the equivalent keystrokes of traditional text editors.

For example, once the cursor is at the destination, selecting and moving a complex list structure can be done with a single mouse click while holding down the Shift and Ctrl keys. Text editors typically require delimiting the code block to move, which takes a few keystrokes to go to and mark the end points, and executing the move command with an additional keystroke or more.

Where structure editing shines is with rearranging code. The structure-aware commands to select expressions and lists make it fast to copy, move, adjust the nesting level of, or delete large code blocks with a few mouse clicks or keystrokes.

Text editors allow inserting characters almost anywhere, while SEdit enforces the Lisp syntax and lets me type code only where allowed. But thinking in terms of structures instead of character sequences is less constraining that I thought. I enter Lisp expressions in a fill-in-the-blanks kind of way, in which the blanks are the spots where the syntax allows something. Sometimes it helps to type the code in a top-down way, from the outer list structures to the inner ones.

After relatively little practice with SEdit the awareness of structure editing is fading away, thus letting me focus on the code. It's now second nature and I no longer pay attention to how to perform editing tasks, as my muscle and action memory kicks in.

I had a similar early experience with Lisp's parentheses. They “disappeared” very soon and never were a source of friction.

#Interlisp #Lisp

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

To fight the threat of ChatGPT and other competing machine learning technologies based on GPT-3, Google is doubling down on AI. The first announcements under the new stategy are expected at Google I/O 2023.

I may be old school, but I'm not looking forward to these upcoming Google products and technologies.

As a user, my experience with the Google Assistant has been unimpressive. The features I tried work half of the times and waste my time in failed attempts at getting understood. When such localized features are rolled out at all to my country years later, that is.

So I'm not excited at the prospect of, say, an AI-enhanced Google Search experience.

I don't want a nice, perfectly idiomatic conversation with a chatbot that ends up recommending the usual shallow, keyword-stuffed, SEO-optimized crap of top search results. Maybe created by some ChatGPT-powered bot.

I want products and features created with traditional, boring software and hardware technologies. Something that works all of the times and consistently makes a difference in my productivity and ability to carry out tasks.

Here are a few Google product features that would make me jump with joy:

  • Markdown in Gmail
  • native Android support for full app data syncronization in the cloud, so seamless and compelling developers just can't say no
  • enforcing the requirement that all new Android apps must work also on chromeOS
  • true, substantial (at least 8X) optical zoom in Pixel phones
  • native Docker support in chromeOS
  • full Android app mirroring on chromeOS, not just messaging

Between Google chasing the latest hype, and advanced users always getting a back seat in product decisions, something tells me I'm not going to see any of these features anytime soon.

#Google

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

When I researched a printer for my first Chromebox in 2015, going with a Brother HL-2340DW seemed like a no brainer.

It was one of the few affordable, wireless laser units with support for Google Cloud Print, then the only way of printing from chromeOS. Print quality is okay. But I never liked the HL-2340DW much as it's slow, and it often went into a deep sleep mode from which it was difficult to wake up.

When Google discontinued Cloud Print in 2020 I could still use the HL-2340DW from my new Chromebox via the IPP protocol, but the unit would often ignore print jobs. When printing from the Chromebox the HL-2340DW would acknowledge receiving the data, then just ignore the jobs and return to the ready state. No troubleshooting or combination of restarting chromeOS, the Chromebox, or the printer would help.

One of the times, exasperated, I initiated printing the Google Drive files I wanted from my Pixel 4 XL Android phone instead of the Chromebox. The printer worked flawlessly, and it has been from Android since then.

#chromeOS #Android

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

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

Enter your email to subscribe to updates.