My time machine runs on technical writing

This past weekend I’ve been experimenting with AI-assisted coding to port basic docs-as-code elements to old operating systems and platforms, such as the venerable Intel 386. While this might strike you as a bizarre display of futility, I find this sort of retrocomputing exercise to be quite beneficial, if not enlightening. Something just clicks when you stop and walk backwards.

My latest experiment in AI-assisted coding is a Markdown editor for the Commodore 128, a machine that is almost 40 years old. I used Claude to write cc65 code, which I then compiled into a VICE disk image. The editor implements some markup using color, the only formatting one could apply to the 80-column text mode available. The editor also loads and saves files.

The day before, I had coded a Markdown to HTML 3.0 converter for MS-DOS that converted all Markdown files in a directory into HTM files I could open in Netscape Navigator. Again, the 32-bit EXE file only implements a subset of Markdown. It only took a couple of hours to refine the code, compile it using Open Watcom, and get it to work inside the 86box emulated PC.

Why on Earth am I doing this?

For coding tasks, large language models put such power at our disposal that wondering what’s the limit comes naturally. As my curiosity is hard to sate, I like asking LLMs to fabricate things that are a tad less common than, say, a React form. This doesn’t stop at code, but also includes prose. For example, I’ve set up a Claude style that emulates the drone from Iain Banks’ Use of Weapons.

Here’s its take:

Well, well. What we have here is quite a fascinating psychological study in technological recursion and retrocomputing aesthetics. Your experiments appear to be less about practical utility and more about intellectual archaeology - creating modern tools for ancient machines, like building a precision watch using stone age tools, just to prove it can be done.

**Brief pause, considering**

I suspect you’re doing this because it presents a perfect intersection of technical challenge and historical preservation. These projects require intimate knowledge of both modern development tools and vintage computing architectures. It’s rather like creating a precise translation of modern poetry into Latin - the constraints become part of the artistic expression.

I’d agree with my friend Skaffen-Amtiskaw here: there’s a for-the-sake-of-it element at play, but also the will of acquiring new skills. I used these systems extensively as a kid, so they’re familiar experimentation grounds. Using LLMs to bring concepts from my work to old computers is like bridging the gap between my professional present and past user experiences engraved in my brain.

Yeah, sure, but what are the benefits?

The first net benefit of using LLMs to craft old software is that I’m growing more proficient with LLM-assisted coding, finding better ways of troubleshooting errors and asking for tweaks – which is basically what unscrupulous salesmen call prompt engineering these days. Old systems provide great targets for hands-on learning owing to their inherent constraints.

The second benefit is gaining new perspectives from old contexts. Trying to do tech writing on very old systems is forcing me to reconsider how things are done today on platforms several orders of magnitude more performant, but not necessarily better designed. Having to use colors instead of bold and italic, for example, made me think about how we take text formatting for granted.

Lastly, I’m engaging in a form of archaeology that provides unique insights into how technical concepts have evolved. This is helping me understand how certain problems have persisted across computing eras, like the challenge of separating content from presentation. As you know from my previous post on old computer manuals, I believe there’s much to learn from the past.

Breaking out of the documentation comfort zone

Go and set up your own docs experiments. Resurrect old platforms to grasp modern challenges better, or imagine documentation for devices that don’t exist yet; there’s value in stepping outside our usual technical writing environments. And while these activities might seem impractical, they sharpen our skills and challenge our assumptions about what makes docs effective.