Past Future Plus Dot

Introduction: Executive Computing

2026-08-06T16:00:00-04:00

Introduction: Executive Computing

Around 1980, a computer consultant in Boston, John M. Nevison, wrote a book entitled Executive Computing, with the enticing sub-title, “How to get it done on your own”. The book was published by Wiley and was popular enough to go through multiple printings. I own a copy of the fifth printing from 1985.

The cover does an excellent job of conveying the goal of the book, as well as a bit of the flavor of the times. The idea is to free yourself from the tyranny of the mainframe. Do it all yourself with a relatively inexpensive business computer. The book is truly excellent, with a nice blend of appropriately cheesy instructional scenarios and very clear, well-explained code.

The book was targeted at users of Radio Shack Level II BASIC on a TRS-80 computer. Level II BASIC was a 16K BASIC, written by Microsoft, that included floating point numbers in both single and double precision. The computer was available starting in 1978. According to Nevison’s book, a TRS-80 Model I with 16K RAM and Level II BASIC cost $849 (approximately $3,440 in 2026). This got you a monitor and a keyboard with real keys. Data storage was via cassette tape.

There are a number of TRS-80 emulators out there. I’m using trs80gp - A TRS-80 Model 1,2,3,4,12,16,6000,Tandy 10,MC-10,Color Computer,DT-1,Green Thumb,Videotex Emulator, which seems to work just fine. It’s cross-platform; I’m currently running it on a Mac.

To run the emulator and boot into the Level II BASIC ROM, try: ./trs80gp -m1 -l2 -mem 16 -dx. The most important thing to know is that the BREAK key from the TRS-80 is mapped to the ESC key, at least on my Mac. If you type AUTO to auto-number BASIC program lines, you’ll need to hit ESC to get back to the prompt.

Incidentally, one of the interesting things about Nevison’s book is that it is written in the looming shadow of VisiCalc. Appendix D introduces VisiCalc and notes that many of the programs in the book could be re-written to run in newfangled VisicCalc. Forty-odd years later, we know how that turned out.

Anyway, I’d like to use Nevison’s book to explore an alternate future, where Forth was the bundled language and business users adopted Forth as their “basic” language of choice. Stop laughing! It could have turned out this way, maybe. Just think of HP’s calculators and their success in scientific and financial applications.

I am not an expert Forth programmer - quite the opposite. After using BASIC as a youngster, I spent some years with Pascal and then many years with Python. Forth does not come naturally to me. That’s the challenge and the fun of it. Join me next time as I make my way down this rabbit hole.

Using blag to host a small static blog site

2026-08-05T11:05:00-04:00

Using blag to host a small static blog site

Set-up directories and install blag

I use an older Macbook Air running Sonoma as my local desktop. The focus of this article is how to set up blag on this local Mac. Blag is a blog-aware, static site generator – it uses Markdown and is written in Python. Because it also uses Jinja2 as its templating engine, it should be relatively easy to modify the menus and even the theme later on. Later the generated static html and css are uploaded to a server that uses caddy to securely serve static files.

Here are the steps to get started with blag. Create a working directory – I just created blag/ in my usual projects directory. Create and activate a Python virtual environment and then activate the environment. Once activated, install blag.

  python3 -m venv .venv
  source .venv/bin/activate
  python3 -m pip install blag

To exit the virtual environment, use deactivate. I always forget and type ‘exit’, which will just close your terminal window. Probably not what you want! Also, don’t forget that you will have to do source .venv/bin/activate any time you want to use the blag program.

Modify blag to support footnotes

Currently, the version of blag available via PyPi for installation via pip does not contain support for footnotes. To enable footnote support in the downloaded version, do the following:

cd .venv/lib/python3.14/site-packages/blag

Open markdown.py in your favorite editor and locate these lines:

    md = Markdown(
        extensions=[
            "meta",
            "fenced_code",
            "codehilite",
            "smarty",
            MarkdownLinkExtension(),
        ],
        output_format="html",
    )
    return md

Modify the file to activate the footnotes extension:

    md = Markdown(
        extensions=[
            "meta",
            "fenced_code",
            "codehilite",
            "smarty",
            "footnotes",
            MarkdownLinkExtension(),
        ],
        output_format="html",
    )
    return md

Save the file and you have now enabled support for footnotes¹. Blag uses the Python system-default markdown library and extensions, so you can turn on (or off) support for various features. See the markdown extensions documentation for more detail.

At some point, the blag author may release his updated version; in that case, pip will install the latest version with footnote support built in and you won’t need to hand-edit the file, unless you want to turn on support for other extensions.

Minor template modifications

Blag is a very simple system. Both “pages” and “articles” can be kept in the same content folder. “Articles”, which contain a header at the top of the document with the date, are blog posts. “Pages” are static pages, such as an “About” page, etc. They do not contain a date header. Read the manual for all of the details and don’t forget to edit the config.ini to add in default blog information.

I decided to create a folder in the content directory called posts for blog content, as well as a folder called pages for static content.

I edited the template very slightly to display the about page on the main menu. Here’s how to do that. Edit templates/base.html and locate the nav section of the template file. Add in a new line for the about page, so that the section now looks like this:

<nav>
  <h2>{{ site.description }}</h2>
  <ul>
  <li><h2><a href="/">Blog</a></h2></li>
  <li><h2><a href="/archive.html">Archive</a></h2></li>
  <li><h2><a href="/tags/">Tags</a></h2></li>
  <li><h2><a href="/pages/about.html">About</a></h2></li>
  </ul>
</nav>

Save the file, rebuild, and you should now have a link on the navbar of the home page.

I also changed from a serif to a sans-serif font and made other tiny tweaks to the style page for the site, which is located in static/style.css.

Configure settings to ease file generation and upload

I set up a Makefile to make it easier for me to generate and publish documents. I used the Makefile from another and much more complicated static site generator, Pelican, and modified it to work with blag and it simplifies the process a good bit. Here’s the modified file if you want to take a look at it.

Workflow for publishing

Blag is such a simple system that there is no concept of “draft” vs. “published” articles. If the document is in the content folder or one of its subfolders, it will get published. I’ve just created a folder at the root of the blag folder called drafts, where I keep draft Markdown files. This works for me.

Once I’m satisfied with my work, I move the document into the content/posts folder and then do make ssh_upload which rebuilds and posts everything to the server.

Blag is about perfect for my needs right now. Thanks to Bastian Venthur for writing and sharing it!

This is the footnote text, just so you can see how it is rendered by default. ↩

XKCD

2026-08-04T15:30:00-04:00

The venerable XKCD apparently has a soft spot for Forth.

xkcd: Forth

Yay!

Editing Tali Forth block data in Vim

2026-08-04T08:42:00-04:00

Editing Tali Forth block data in Vim

One of my favorite things about Forth, especially older bare-metal Forths, is the use of 1K “blocks” for data storage. The Planck 6502 uses block storage on a CF card. There is no file system, just bytes, arranged in 1024 byte “blocks”, traditionally displayed as 16 lines of 64 characters per line. In Tali Forth on the Planck, I have access to 64MB of persistent storage, all in these 1024 byte blocks.

Sometimes, it’s easier to edit blocks outside of the Forth system. Here’s one approach, focused on editing the csim simulator’s blocks.

Using the c65 block file in Tali

One of the very cool things about the csim simulator for Tali is that it allows you to have persistent storage by supporting blocks in a traditional file in the file system. This is covered in the manual, but here’s a quick summary.

Create an empty blockfile to hold Forth blocks: touch blockfile.block. Then start up csim like so:

cd $TaliForthDir
./tools/c65/c65 -b blockfile.block -r taliforth-c65.bin

To start up the block system, run the word block-c65-init. It will return -1 (true) once the block system is available. List, load, and edit blocks as usual. See the Tali Forth manual for the use of the supplied editing commands. Make sure to save changes to some blocks and then exit the simulator. You’ll notice that the file is now 1MB in size.

Editing the block file from outside of Tali

The blockfile is initialized with nuls (\$00) in every character position. This makes it awkward to edit with an external editor like vim, in part because nuls are displayed as ^@ so every line is twice as long as you would expect. It’s easiest to replace all of the nuls with space characters. You can do that with GNU sed like this:

sed -e 's/\x00/ /g' -i blockfile.block

CAVEAT: If you use MacOS, you have the FreeBSD version of sed, which doesn’t seem to handle nuls. You can install GNU sed by doing brew install gnu-sed. After that, run gsed in place of sed for the replacement above. Sed is very cool and you can read more about it here.

Now that the file is one ginormous line of space characters, you can open it in vim to edit. Here’s one way to do it, from this answer on r/vim.

augroup forth
  " insert a newline after every 64 bytes when reading
  au! BufReadCmd *.block call setline('1', split(join(readfile(expand('%')),''), '\%65c\zs'))
  " remove newlines when writing
  au! BufWriteCmd *.block call writefile([join(getline('^','$'),'')], expand('%'))
augroup end

This is really clever. It inserts a hard-return after every 64 characters, so that we get the 64 character wide lines for blocks, but only when you retrieve the file. It then removes the hard returns upon writing the file. Add this to your .vimrc and restart vim to see the changes. NOTE: Every .block file that you bring into vim will have this applied, so be aware of that. This is also why I chose .block as the extension for the csim block files in place of the original .dat, which might be used for other file types.

Also, it’s still possible to mess up your blocks by deleting lines, etc. during the vim session.

Next, you need a way to visualize block boundaries.

This solution from Stack Overflow provides one approach:

function HighlightEvery(lineNumber, lineEnd)
    highlight myhighlightpattern ctermbg=darkred guibg=darkred
    let pattern="/"
    let i = 0
    while i < a:lineEnd
        let i += a:lineNumber
        let pattern .= "\\%" . i . "l\\|"
    endwhile
    let pattern .= "\\%0l/"
    let commandToExecute = "match myhighlightpattern ".pattern
    execute commandToExecute
endfunction

command -nargs=* Highlightevery call HighlightEvery(<f-args>)

Put this in your .vimrc. In vim, call it with Highlightevery 16 2000. This will highlight the 16th (last) line of each block through line 2000.

Editing caveats

You have to be really careful with this. Turn on non-printing characters in vim with set list so that you can see the end of line character, as it’s easy to add a bunch of spaces to the line without noticing. You need to be very careful when deleting lines so that you do not accidentally move a subsequent block back into the block you are editing. However, for cutting and pasting data into the block file, this may be completely adequate. It’s probably best to do all of your editing in replace mode.

Of course, another option is to slurp in the block data using your favorite programming language and then write the changes back out. After all, it’s just a stream of bytes. I’ll share a Python script to do that at some point.