Cuneiforth ---------- Dear Gopherspace, How are ya? I know I haven't written to you for ages. (It's almost April and this is the first 2026 post! Holy crap.) I'm not going to apologise though since, as I've said before, I keep this phlog for my own reasons - as we all do - and we shouldn't let ourselves feel guilty for not engaging exactly as much as we want to. There's enough of that nonsense out there on the surface web. But I do want to say what I've been up to. Actually I'm bursting to talk about it! That's the main problem with niche pursuits: it's almost impossible to find anybody to share them with, except online. So I've got a lot of pent-up words. The problem is though that they're still so muddled up I keep putting this post off, thinking that maybe "next week" they'll be in a better shape to lay out. Nah, fuck it - let's go. I'm building it up too much and, honestly, it's not that exciting to anybody besides me. :) I've spent the last month in a Strange Mood. [1] (This is also why it's been difficult to post: the strange mood makes it extremely difficult to spend time on anything else!) The focus of this Mood has been the machine described by Long Tien Nguyen and Allan Kay in their well-known paper "The Cuneiform Tablets of 2015" [2]. This machine, which they call Chifir after the ultra-strong tea apparently drunk by inmates of Gulags, is a computer described in a single succinct page and intended to form a central part of their proposed "Cuneiform" system for digital preservation of computer software. The idea is that such software would be targeted at this virtual machine either directly or via an emulation layer, then written to some robust storage medium (the choice of which is a separate problem which Nguyen and Key do not attempt to solve), with the one-page Chifir description prepended in bitmap form to the binary data. The medium would then be given a label which would indicate a) how to read the binary data (i.e. how to actually get the 0s and 1s out) and b) how to extract the prepended bitmap for further information. It bears saying explicitly that what Nguyen and Kay present is really the Cuneiform _system_ as a whole. The specific details they include in the paper, including the disk label and their single-page Chifir computer are, from my reading anyway, only intended as _examples_ of how the Cuneiform system could be used to store software. This is very clear in the label, which provides physical dimensions of actual 0s and 1s to be read using a microscope off of the disk containing the binary data. But I think it's been overlooked a bit in the online commentary on the paper, which focuses more on how appropriate the details of the specific Chifir machine described are for the stated purpose of digital preservation. This skepticism isn't helped by the absence of an actual feasibility demonstration. The authors state in the paper that they have an implementation of Smalltalk-72 running on this specific machine. While I've no reason to doubt this, their implementation is nowhere to be found, neither as part of the official supplement nor anywhere else online. In any case, I think the specific machine they present is very interesting. Their one-page description doesn't appear nearly as ambiguous to me as has been claimed (perhaps I'm missing something though), and the machine is likely more than up to the task they set for it. The machine is very minimal. It has a 15 opcodes, one of which is a blocking key input, and a memory-mapped bitmap display. That's it. No other devices, no interrupts, no console output. A maths machine. So of course my first thought is, why not write a FORTH for this? So that's what I've been doing. Over the last month I've written a Chifir emulator, an assembler, and a FORTH kernel. The emulator was for sure the easy part - honestly, you easily do this in an hour or two max, as intended by the Cuneiform project. It's only taken me longer because I decided to write it in C with the SDL2 library, the API for which I'm completely unfamiliar with. The assembler took a lot more time since (a) I've never written one before and (b) I chose to write it in perl, which I've somehow managed to avoid using before. The FORTH itself; well, it's been a challenge! I've written one before, (forth.jl [3]) but it was some time ago and was targeted at Julia of all things. (Why can't I target something normal for once?) While forth.jl was fairly complete, I was able to take some shortcuts that I can't take here. For instance, I already had a terminal in that case: its implementation of the primitive EMIT to print a character to the display simply involved a call to Julia's print() function. For my new FORTH, this can't work: Chifir comes with a bitmap display. Out of the box it can turn a pixel on and off. I've had to include fonts and implement BITBLT in my terrible assembly. And when I mess up an index? Segfault. No easy way to display debug info, at least not at a uselessly low level. You get the idea. Not to say that it's been hard, but for a not-a-real-programmer like me it's been very very fiddly! But it's finally starting to breathe. As I said, I now have a FORTH kernel, by which I mean that the main interpreter QUIT is written that is capable of interpreting and compiling FORTH words from the terminal (I have a terminal now!) or from FORTH's classic block-structured persistent storage system. I'm now in the process of building out the standard library of required words (I'm roughly targeting the FORTH 83 standard) by writing FORTH code. I'm currently doing this via the assembler since at this point I still want to be able to rebuild the entire binary from scratch, but once I've added enough of the required word set I'll implement the minimal EDITOR vocabulary so that I can start programming directly from within the new system. I can make it self-documenting! I can program some graphics libraries! There are so many places I can take this now. The beauty of all of this is that anything I build for this machine can be easily made to run on basically _anything_. As long as I have access to hardware on which I can write an emulator for the one-page Chifir machine, I can run my FORTH system. Nobody can take this away. Honestly I'm still trying to figure out why I find this so exciting. Do I really believe that someday soon I'll lose the ability to run Emacs? There are for sure those who do [4], and while I'm far from convinced they're wrong, I don't think that's what driving me. I think it's rather that computing changes too fast for me. Software rots. Hardware rots. Stuff that's more than a few years old doesn't run anymore. The prospect of being able to carve out a happy space within a machine so incredibly simple that I can describe it to you over lunch well enough for you to successfully implement it yourself gives me a tremendous sense of calm. So, where is this FORTH? Is this to be another Smalltalk-72 disappearing act? I'll of course share it in time, together with my clunky assembler and emulator. But for now it's still cooking. Usually that wouldn't stop me; I like sharing things as I'm working on them. (The main directory of my gopher hole is a graveyard of unfinished projects, after all!) I want to keep this one close a while longer though. And when I share it I'll keep the FORTH system binary separate from its source and that of the emulator. These latter components are spoilers after all! I want you to try writing your own emulator from the description found in the binary, the way Nguyen and Kay intended. A programming puzzle, the correct solution of which wins you your own eternal FORTH system! Okay, enough now. 'Night, Gopherspace. plugd -- [1]: gopher://thelambdalab.xyz/0phlog/2019-06-15-Dwarves-and-Gophers.txt [2]: https://dx.doi.org/10.1145/2814228.2814250 [3]: gopher://thelambdalab.xyz/1projects/forth.jl [4]: https://collapseos.org