Since deciding to pause some of my personal software, I’ve taken the opportunity to look again at the outstanding work sitting on various plptools branches—I’m keen to remind myself that I do enjoy some of this, and I’d like to keep the (relative) momentum we’ve achieved recently in the Psion space.

Platform Support

Last week, I added CI builds for Haiku, FreeBSD, OpenBSD, and NetBSD. And Ubuntu 26.10, Stonking Stingray (though, excepting its fabulous name, that’s far less exciting).

One of the wonderful aspects of plptools is that we support a wide variety of platforms. It’s something we’re pretty proud of, and something we’d like to more formally in the future—helping give people more choice is important to us. With these new CI builds, we significantly reduce the risk of regressing these platforms, and pave the way for generating pre-built packages.

The work relies on the cross-platform-actions/action GitHub action (wow, that’s a mouthful) to run on-demand VMs for a wide range of systems. It’s a fantastic solution, and something I’ll look at in the future to help us bring OpoLua to other platforms.

strategy:
  matrix:
    include:

    - name: haiku-r1-beta6-x64-64
      os: ubuntu-26.04
      vm:
        name: haiku
        architecture: x86-64
        version: 'r1beta6'

    - name: freebsd-15.1-x64-64
      os: ubuntu-26.04
      vm:
        name: freebsd
        architecture: x86-64
        version: '15.1'

    - name: netbsd-11.0-x86-64
      os: ubuntu-26.04
      vm:
        name: netbsd
        architecture: x86-64
        version: '11.0'

    ...

steps:

    ...

    - name: Create the virtual machine (if required)
      if: matrix.vm
      uses: cross-platform-actions/action@v1.6.0
      with:
        operating_system: ${{ matrix.vm.name }}
        architecture: ${{ matrix.vm.architecture }}
        version: ${{ matrix.vm.version }}
        shell: bash
        memory: 5G
        cpu_count: 4

With GitHub Actions matrix builds, Docker containers, and VMs, it’s surprisingly easy to target a vast range of systems

A More Modern C++

After decades of avoiding ‘modern’ C++, we now require C++17 for plptools—this will allow us to tidy up the codebase significantly by adopting things like optionals without having to roll our own and introducing all the inherent risks that come with that. As far as we’re aware, we’re not significantly limiting our platform support with this choice, and the new CI builds will help keep us in check.

Not much more to say here, except that I’m genuinely excited to get to play with some new language features.

Emulator Support

I’ve taken another crack at supporting connecting to the myriad Psion devices that are now emulated in MAME and am making great progress. While it’s far from perfect, the work we’ve been doing to slowly tidy up the comms stack over the last year-or-so has made the overall change pretty small, and surprisingly robust.

This currently lives on a branch, as there’s quite a bit of work left to do to plumb in the command line options. Once it’s out in the wild, I’ll look at adding support to Reconnect.

Combined with Lua to automate some Psion-side operations at startup, I’m able to perform an unattended plptools connection to Psion, paving the way for integration tests.

local keyboard = manager.machine.natkeyboard
local ports = manager.machine.ioport.ports
local LEFT = ports[':COL0']:field(0x010)
local CTRL = ports[':COL2']:field(0x080)
local MENU = ports[':COL5']:field(0x080)

local function press(...)
  ...
end

local function send(s)
  ...
end

coroutine.resume(coroutine.create(function()
  press(CTRL, MENU)
  emu.wait(1)
  send('{F11}l{ENTER}')
  emu.wait(1)
  press(LEFT)
  send('{ENTER}')
end))

Using MAME’s -autoboot_script option, we can send the necessary key presses to enable the link on startup

FUSE 3

Community PRs are few and far between in plptools-land, but I’m excited that we’ll soon get to land one from Syed, who’s recently taken over plptools Debian maintainership. Syed’s been working on binging FUSE3 support to the codebase and, after taking our time in the review process, we’re ready to move ahead with it.

FUSE is a curious one for us—none of the current plptools maintainers use it, but we recognize it’s vital for some of our users. With this in mind, I plan to put some time into better file system correctness and performance testing in the coming months. Hopefully this will help secure its future even if we’re not dog-fooding it ourselves.

A New Release

With all this in place, we’re starting to talk about cutting our 1.1.0 release; there have been many improvements and it’s about time we turned the handle to ensue folks can use them!