![](\"/posts/2026-02-28-publishing-opolua-for-debian-and-ubuntu/dragonfell-debugger@2x/1600.png\"\n)
\n \nContinuing my Psion connectivity themed March December Adventure, I persisted with the process of addressing legacy threading issues in plptools—it’s important that we have a stable foundation on which we can build future functionality, and it’s still my intuition it’s better to build on top of what we have than start again.
\nThe plptools architecture centralises all the complexity in ncpd, the daemon responsible for implementing the Psion Link Protocol (PLP) and exposing different Psion-side server end-points to PC-side TCP clients. This makes the clients relatively simple at the cost of some gnarly internal code which is, unsurprisingly, where all our problems lie.
An overly simplified overview of that looks something like this:
\n---\nconfig:\n class:\n hideEmptyMembersBox: true\n---\nclassDiagram\ndirection TB\n\nclass NCPSession\nclass NCP\nclass Link\nclass DataLink\nclass LinkChannel\nclass SocketChannel\n\nNCPSession \"1\" --> \"1\" NCP : ncp_\nNCP \"1\" --> \"1\" Link : link_\nNCP \"1\" --> \"n\" SocketChannel : channelPtr\nNCP \"1\" --> \"1\" LinkChannel : lChan\nLink \"1\" --> \"1\" DataLink : dataLink_\nOn first blush, this seems complex, but there’s quite a bit that needs to happen and the functionality is relatively well compartmentalized:
\nNCPSession—provides APIs to manage the full daemon life cycleNCP—multiplexes channels to Psion-side servers, pairing them to connected PC-side TCP clients \n LinkChannel—a special channel for communicating with the Psion to manage the overall connectionSocketChannel—PC-side TCP client end-pointLink—manages connection establishment and packet sequencing, transmission, and retransmissionDataLink—frames and un-frames messages, and writes and reads the serial portMost of my effort over the last few days has been focused on DataLink—the goal is to ensure we have a robust core before focusing on other aspects of the architecture. Looking at the existing code, my theory is that this was originally written to be single-threaded and threading was added after-the-fact, with no locking at all. This has given me a wonderful opportunity to refresh my memory of C++’s take on mutexes, locks, and condition variables. The introduction of locks has a significant impact on how we shut down ncpd: the various worker threads were relying on PTHREAD_CANCEL_ASYNCHRONOUS which can stop them at any point during their execution, potentially leaving locks held and resulting in deadlock. With locks, we have to explicitly manage thread cancellation. My PR for these changes has evolved over the past few days, and I think it’s nearly there. Thanks must go to Alex and Fabrice, the other plptools maintainers, for stoically reviewing and testing my many changes, and keeping me honest during the process.
With the various thread-safety improvements in place, I took another crack at adding a self-hosted daemon to plpftp to allow it to be run without necessitating a separate ncpd instance. This involves moving the daemon classes into ‘libplp’ to allow all the plptools commands to share them and, unfortunately, doing so still resulted in a near-immediate crash in that looked like a double-free in BufferStore, our buffer convenience wrapper.
Fairly sure I wasn’t seeing a multi-threading issue this time around, I kept digging and, after altogether too long, realized the crash was a result of the free function itself being NULL. Unsurprisingly, when runtime fundamentals like this are missing, you get some incredibly strange and misleading crashes and call stacks. Thankfully the fix was easy: I had failed to link libgnu; a failure that macOS silently ignores, leaving all function pointers NULL. 🤦
With everything finally working as expected, I was able to make the change I’d intended three days prior, adding a simple call to conditionally start a daemon (NCPSession) instance if the serial port was passed as an argument to plpftp:
Semaphore *sem = new Semaphore();\nNCPSession *session = nullptr;\nif (serialDevice) {\n session = new NCPSession(\n sockNum,\n 115200,\n host,\n serialDevice,\n false,\n 0,\n [](void *context, bool connected, int version) {\n static_cast<Semaphore *>(context)->signal();\n },\n sem);\n session->start();\n sem->wait();\n}\nAs is always the way in software, this ‘feature’ work proved the easiest bit and, with the foundations in place, this worked first time:
\n\n
\n![](\"/posts/2026-03-19-december-adventure-march-17-18/plpftp@2x/400.gif\")
\n ",
"date_published": "2026-03-19T13:32:10-07:00",
"id": "https://jbmorley.co.uk/posts/2026-03-19-december-adventure-march-17-18/",
"title": "December Adventure' March 17-18",
"url": "https://jbmorley.co.uk/posts/2026-03-19-december-adventure-march-17-18/"
},
{
"content_html": "I started the week with grand plans of adding a small feature a day to one of plptools or Reconnect—perhaps a backup command, TCP support for connecting to MAME, improvements to the file transfer, or incremental backups in Reconnect. One day in, it’s clear I’m certainly not going to manage one a day.
\nplptools adheres to a very Linux mindset, comprising multiple command line apps, each providing a distinct piece of functionality. These all rely on a central daemon—ncpd—for managing the serial port and connections to a Psion. While it’s a great system that allows you to run multiple tools in parallel (e.g., installing a program and managing your files at the same time), it does require users to run ncpd in addition to whatever tool they wish to use. For example, I run the following two commands to connect to my Series 3mx:
Start ncpd to connect to the Psion:
ncpd -s /dev/cu.usbserial-A9DA9DOF -d\nRun plpftp to browse and transfer files:
plpftp\nInspite of the clear benefits of the architecture, unless you’re planning to run the daemon all the time (which Reconnect does but we don’t have a great story for yet in plptools), this can feel pretty heavyweight just to copy a file. I also have a theory that having to understand the plptools architecture sufficiently to know to run ncpd is a pretty big barrier to getting started. With that in mind, I plan to allow the different plptools apps to self-host the daemon if you specify a serial port. This will reduce the above to:
plpftp -s /dev/cu.usbserial-A9DA9DOF\nDoing this means using reusing the NCPSession class from ncpd in plpftp, necessitating moving it into libplp (the library that’s shared between all the plptools CLI apps). This should be simple, but moving it left me with an app that segfaults as soon as the Psion connects. My working theory is that I’ve subtly changed the timing or object life cycle in a way that exposes existing race conditions. With that, I returned to the exercise of gently tidying the codebase and the work of adding thread-safety to ncpd—an incredibly nuanced process with a codebase as long-in-the-tooth as plptools.
Inspired by Eli’s post, I’m spending the next week doing some not-quite-December adventuring. It’s hard to believe we’re nearly ¼ of the way through 2026, but here we are, and I suspect many of us already feel we need a break from it all. Time for an adventure!
\nAs I’ve only got a week, I’m planning to keep things simple by focusing on improving the Psion connectivity story with plptools and Reconnect. If I can, I’d like to make one meaningful improvement each day—I think there’s room for a few small changes to each that will make things easier for folks using Psions in 2026.
", "date_published": "2026-03-16T12:34:15-07:00", "id": "https://jbmorley.co.uk/posts/2026-03-16-adventure-time/", "title": "Adventure Time", "url": "https://jbmorley.co.uk/posts/2026-03-16-adventure-time/" }, { "content_html": "Yesterday, I finally got around to publishing my OPL support for highlight.js. I’ve been using it here since I wrote it a couple of months ago, but now it’s available on GitHub and NPM for others to use.
\nPROC hello:\n PRINT \"OPL is amazing!\"\n GET\nENDP\nJust like highlight.js itself, it’s incredibly easy to use, and there are a few different options.
\nYou can use the module directly (what I do on this website):
\nimport hljs from '../highlight.js/es/highlight.js';\nimport opl from './highlightjs-opl/src/languages/opl.js';\nhljs.registerLanguage('opl', opl);\nhljs.highlightAll();\nOr add the minified self-registering version from the UNPKG CDN to your site’s head (how I’m using it on the OpoLua website):
<link rel=\"stylesheet\" href=\"https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.11.1/styles/default.min.css\">\n<script src=\"https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.11.1/highlight.min.js\"></script>\n<script type=\"text/javascript\" src=\"https://unpkg.com/highlightjs-opl/dist/opl.min.js\"></script>\n<script type=\"text/javascript\">\n hljs.highlightAll();\n</script>\nI’m looking forward to seeing all your OPL projects!
", "date_published": "2026-03-01T11:35:42-08:00", "id": "https://jbmorley.co.uk/posts/2026-03-01-syntax-highlighting/", "title": "Syntax Highlighting", "url": "https://jbmorley.co.uk/posts/2026-03-01-syntax-highlighting/" }, { "content_html": "Ever since Tom decided to bring OpoLua—our modern runtime for OPL—to Linux with the introduction of a Qt-based desktop app, I’ve wanted to make it as easy to install and update as the macOS and iOS apps. This week I did that for Debian and Ubuntu by setting up a self-hosted apt repository for the software we publish—if you’re using a Debian-based system and you’ve not yet tried out OpoLua, you can get started with the following simple commands:
\ncurl -fsSL https://releases.jbmorley.co.uk/apt/public.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/jbmorley.gpg\necho \"deb https://releases.jbmorley.co.uk/apt $(lsb_release -sc) main\" | sudo tee /etc/apt/sources.list.d/jbmorley.list\nsudo apt update\nsudo apt install opolua\nI’ve successfully installed OpoLua on Debian Trixie, and Ubuntu Noble and Questing and, thanks to Colin, we have evidence that it even works on Kubuntu:
\n\n
\n![](\"/posts/2026-02-28-publishing-opolua-for-debian-and-ubuntu/kubuntu-screenshot/400.png\")
\n \nThe new apt repositories are built on top of our existing GitHub CI: releases on GitHub now include manifest files that contain metadata about which platforms and architectures binaries and packages support, and these files are then used to determine what to include in the apt repository. Unlike many other GitHub-based solutions I’ve seen, I plan to host historical builds of OpoLua (and other projects) to ensure folks can access builds for their OS for as long as possible, even if we’ve had to drop it to enable new features. (Though thankfully that shouldn’t be necessary with OpoLua as Qt seems to have an amazing backwards compatibility story.)
\nIn addition to the new repository, there have been significant developments in OpoLua over the past few months, with Tom landing a huge feature last week in the form of an interactive decompiler and debugger, complete with breakpoints and live updates:
\n\n\n
\n \nPeeking at the inner workings of Cyningstan’s recent release for the Series 3, Dragonfell.
\nAnd finally, OpoLua wasn’t the only software to receive a release this week: the new apt repository also contains Debian and Ubuntu builds of Reporter, my lightweight file change report generator.
", "date_published": "2026-02-28T11:22:50-08:00", "id": "https://jbmorley.co.uk/posts/2026-02-28-publishing-opolua-for-debian-and-ubuntu/", "title": "Publishing OpoLua for Debian and Ubuntu", "url": "https://jbmorley.co.uk/posts/2026-02-28-publishing-opolua-for-debian-and-ubuntu/" }, { "content_html": "Coming off the back of my December Adventure, I was incredibly keen to continue a practice of daily writing—I found the process deeply rewarding and a wonderful opportunity to reflect on my work, share my process, and be more deliberate about how I approach my projects. Now, nearly a month since I last wrote, it’s clear that, while this works well in the context of adventuring, it doesn’t translate to my typical way of working. I’d like to reflect on why.
\nDuring my December Adventure, I deliberately selected relatively short, self-contained tasks that were fun or immediately rewarding—things I felt others in the Psion community might enjoy reading about—and, consequently, that made the process of writing a joy. The work of exploring and supporting older computers is also wonderfully broad, offers a wide variety of problems, and is charmingly pure when contrasted with the myriad cultural and political shifts happening in the industry and world at large. Simply put: it is something I am happy and excited to engage in and share.
\nAs I’ve transitioned back to more work-like tasks, I find I’m taking on bigger projects in more contemporary languages that are, frankly, less fun—what I’m doing now is driven more by the outcome than the joy of the journey. Specifically, I’ve been focused on infrastructural work in both Folders, my Photos-like file manager for macOS, and Reconnect, my Psion connectivity suite for macOS. This work has necessitated spending many days bashing my head against Swift and SwiftUI, and it’s not fun to write about the endless process of working around Apple’s phoned-in APIs and absentee-parent approach to language design. It’s also much harder, working on modern platforms, to ignore the spectre of AI and how it’s fundamentally changing the culture of creation—a shift that only seems to have accelerated in the past couple of months, and one that quells the deep enthusiasm and optimism I usually hold for engineering.
\nWith all this in mind, I’m going to go back to more ad-hoc writing, highlighting some of the larger pieces of work when I complete them, and documenting my little side-quests as and when they occur. I also hope to take some time to sit down and write about my evolving feelings around AI—specifically how it continues a decades-long trend of abdicating responsibility in product and infrastructure design.
\n(I note that Eli has designated the Ides of March a week of adventuring, something I suspect many of us desperately need. I have plans.)
", "date_published": "2026-02-22T12:24:15-08:00", "id": "https://jbmorley.co.uk/posts/2026-02-22-rethinking-writing/", "title": "Rethinking Writing", "url": "https://jbmorley.co.uk/posts/2026-02-22-rethinking-writing/" }, { "content_html": "The week got off to a slow start as I found myself spending much of Monday writing up the remainder of week 3. Beyond that, I spent time putting a final base coat of paint on the sign for our friend’s coffee shop, briefly revisited the world of Psion emulation, and set my intentions for the week ahead.
\nNigel, the Psion community’s resident MAME expert, has been on a renewed push to get folks to dig out their Psions (not something that needs much encouragement), check their ROM versions, and dump them if they’re not already on record.
\nMuch to my surprise, neither of the builds on my Revo Plus or Series 7 had been dumped, so I broke out PsiROMx and set about rectifying this travesty. Fortunately, the process of dumping an EPOC32 ROM is easy: simply select ‘Save ROM’ and specify the output location. (There seem to be some issues dumping Series 5mx Pro devices, but there are still many earlier devices we need to archive, and PsiROMx serves us well here.)
\n\n
\n![](\"/posts/2026-01-21-week-4-monday/psiromx/400.png\")
\n \nPsiROMx’s interface is wonderfully simple
\nI uploaded these two new ROMs to the Psion-ROM archive on GitHub and was rewarded not long after by the following screenshots of my Revo Plus ROM running in MAME:
\n\n
\n![](\"/posts/2026-01-21-week-4-monday/revo-boot/400.png\")
\n \n\n
\n![](\"/posts/2026-01-21-week-4-monday/revo-system/400.png\")
\n \nSince I was already poking around in the Psion-ROM repository, I also took a few minutes to set up automated builds that package ROMs for use with MAME—I’d love to a establish a single source of ROMs for MAME-based Psion emulation and use this in PsiEmu to make it easy for folks to get started.
\nHaving seen some indication that the hanging issues I’ve been seeing with my website builds might be a bug in InContext—my static site builder—I’ve decided to focus on that for the week. Beyond debugging the hang, I have a growing list of fixes and improvements to make and, if time permits, I’d love to flesh out the Linux support.
", "date_published": "2026-01-21T11:38:00-08:00", "id": "https://jbmorley.co.uk/posts/2026-01-21-week-4-monday/", "title": "Week 4—Monday", "url": "https://jbmorley.co.uk/posts/2026-01-21-week-4-monday/" }, { "content_html": "Keen to make forward progress in spite of other (mostly administrative) distractions, I found myself spending the rest of the week 3 bouncing between infrastructural tasks that I hope will help lay the foundations for future work: trying Portainer, self-hosting Forgejo, and installing FreshRSS. I also took a little time out to continue with some real world maintenance.
\nWhile I’ve been running home infrastructure for a little while, I’m fairly new to the whole thing and I’ve yet to establish my own preferences and best practices. Using Docker to run services, for example, still makes me deeply uncomfortable: I’ve been using Docker Compose—docker-compose.yml files are easy to version using a combination git Git and Ansible—but I find updates and container life cycles hard to manage. With that in mind, I decided to take a shot at using Portainer.
Bootstrapping Portainer proved incredibly easy using Docker Compose:
\nservices:\n portainer:\n container_name: portainer\n image: portainer/portainer-ce:lts\n restart: always\n volumes:\n - /var/run/docker.sock:/var/run/docker.sock\n - /storage/services/portainer/data:/data\n ports:\n - 9443:9443\n - 8000:8000\n\nnetworks:\n default:\n name: portainer_network\n(This deviates very slightly from the off-the-shelf configuration, mapping /data to /storage/services/portainer/data to ensure it’s stored on my ZFS pool and easy to back up.)
Once it was up and running (docker compose up -d), I found Portainer offers a comprehensive management interface, allowing you to create new container ‘stacks’ using Docker Compose files:
\n\n
![](\"/posts/2026-01-19-week-3-tuesday-onwards/portainer-stacks@2x/1600.png\"\n)
\n \nGiven how easy it was to set up, I wish I’d tried Portainer earlier: I’m already finding its container and image management very convenient, and it feels like a great low-effort tool for trying out new services. I may, however, still turn to manually managed compose files for services that I choose to keep around.
\nOver the past couple of weeks, I’ve noticed an uptick in hangs with my website builds using GitHub Actions. This has got in the way of writing, and I decided to see what I could do to improve things. Thinking the issue might be related to a longstanding issue in .NET process management and something that’s unlikely to get fixed any time soon (that the GitHub Actions runner might be failing to notice my build script terminating successfully), I decided to make the most of the opportunity to try out Forgejo to store and build my site.
\nWith Portainer ready to go, installing Forgejo provided incredibly easy—I just used the Docker Compose file from their installation instructions (again mapping the data volume to my ZFS storage):
\nservices:\n forgejo:\n image: codeberg.org/forgejo/forgejo:13\n container_name: forgejo\n restart: always\n environment:\n - USER_UID=1000\n - USER_GID=1000\n volumes:\n - /storage/services/forgejo/data:/data\n - /etc/timezone:/etc/timezone:ro\n - /etc/localtime:/etc/localtime:ro\n ports:\n - \"3000:3000\"\n - \"222:22\"\nEverything just worked and, armed with a working Forgejo instance, I pushed my website—including 50GB of LFS files. Much to my surprise, this also worked (once I remembered to run git lfs fetch --all origin main to ensure I had a local copy of all LFS data)—I had been fully expecting Git LFS to require further setup, but it seems it’s provisioned out of the box with Forgejo.
\n\n
![](\"/posts/2026-01-19-week-3-tuesday-onwards/forgejo@2x/1600.png\"\n)
\n \nConfiguring automated builds using Forgejo Actions proved a little more nuanced however: the Forgejo runner doesn’t support macOS, so you have to use Gitea’s Act Runner instead. I also encountered real problems with Git LFS checkouts on the runner, necessitating a manual—and worryingly precarious—checkout step1:
\n- name: Checkout source\n shell: bash\n env:\n GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n run: |\n set -euo pipefail\n URL_BASE=\"${{ github.server_url }}\"\n\n mkdir -p \"$CHECKOUT_ROOT\"\n if [ ! -d \"$CHECKOUT_ROOT/.git\" ]; then\n git clone --origin origin --no-checkout \"https://${URL_BASE#https://}/${{ github.repository }}.git\" \"$CHECKOUT_ROOT\"\n fi\n\n cd \"$CHECKOUT_ROOT\"\n git clean -fdx\n git config url.\"https://${GITHUB_TOKEN}@${URL_BASE#https://}/\".insteadOf \"https://${URL_BASE#https://}/\"\n git config --unset-all http.${{ github.server_url }}/.extraheader || true # Unhappy LFS workaround.\n git fetch --prune --tags origin\n git checkout \"${{ github.ref_name }}\"\n git reset --hard \"origin/${{ github.ref_name }}\"\nFrom the discussion on Forgejo’s issue tracker, it seems the LFS issue might be related to my running Forgejo behind an nginx proxy. I’d like to investigate this but, for the time being, I have an approach that works.
\nWith the checkout issues resolved, the rest of the build worked with no changes, lifted verbatim from my GitHub Actions workflow—it’s really quite impressive and fills me with hope for migrating other projects. I think I might still be seeing infrequent hangs in my builds though, so I wonder if there’s a race condition buried deep in InContext’s asynchronous code. Something to keep an eye on. 👀
\nHaving written about the process of installing two services already this week, I’ll not go into much detail about FreshRSS. Suffice to say, I used Docker, Portainer, and nginx as a reverse proxy. It went smoothly.
\n\n\n
![](\"/posts/2026-01-19-week-3-tuesday-onwards/freshrss@2x/1600.png\"\n)
\n \nIt’s nice to finally have a self-hosted feed reader again after nearly 20 years (though I still long for Shaun Inman’s Fever feed reader), and I’ve been pleasantly surprised to discover it’s well supported by client apps like NetNewsWire. I’m hopeful the switch will unlock syncing with various retro computers in the future.
\nThe week also brought an analogue pursuit in the form of some maintenance work on the sign for Mele Mele, our friend’s coffee shop. The Hawaiian climate is brutal and will destroy near-everything, so I took the opportunity of Sarah repainting the sign to reinforce it in the hope it’ll last another few years.
\n\n \nThis step is even more complex than it might be as I want to cache checkouts between builds to avoid having to download all 50GB of my site on every build—the Act Runner differs from the GitHub Actions runner in that it doesn’t use stable checkout locations, necessitating some contortions. ↩
Week 3 of the year continues the concerted (if somewhat piecemeal) process of project spring cleaning. Shipping the Qt version of OpoLua remains a priority and I spent much of the day on release adjacent tasks. I also found my thoughts turning to grand ideas of finally packaging things like Reporter, changes, and InContext, but I must resist! (For the time being, at least.) That said, I did take a little time out to work on the endless task that is home infrastructure.
\nLast week, before getting distracted by packaging all the things, I identified a few remaining tasks for shipping OpoLua, our modern OPL runtime:
\nOf these, the highest priorities seemed to be ‘download links’, and ‘documentation’. Both of these will help users install the app: links to downloadable packages; and , for Linux, instructions for how to add our (as yet non-existent) package repositories.
\nThe OpoLua website is a Jekyll static site that lives the docs folder of the source tree, and is built as part of our GitHub Actions build workflow. This makes it really easy to inject details like the current version number into the site build and, armed with the jekyll-environment-variables plugin, it was easy to update the template to add a link to the latest GitHub release:
![](\"/posts/2026-01-19-week-3-tuesday-onwards/mele-mele-sign/IMG_9221/400.jpeg\")
\n ![](\"/posts/2026-01-19-week-3-tuesday-onwards/mele-mele-sign/IMG_9222/400.jpeg\")
\n ![](\"/posts/2026-01-19-week-3-tuesday-onwards/mele-mele-sign/IMG_9225/400.jpeg\")
\n ![](\"/posts/2026-01-19-week-3-tuesday-onwards/mele-mele-sign/IMG_9229/400.jpeg\")
\n <p class=\"download-links\">\n\n <a href=\"https://apps.apple.com/app/opolua/id1604029880\">\n <img src=\"images/Download_on_the_App_Store_Badge_US-UK_RGB_blk_092917.svg\" />\n </a>\n\n <br/>\n\n <a href=\"https://github.com/inseven/opolua/releases/tag/{{ site.env.VERSION_NUMBER }}\">\n Download for macOS, Windows, and Linux\n </a>\n \n</p>\nWhile I’d like to increase the prominence of these new platforms (the App Store link dominates somewhat), something is better than nothing, and I’m pretty pleased with the result:
\n\n\n
![](\"/posts/2026-01-13-week-3-monday/opolua-download@2x/1600.png\"\n)
\n \nAs OpoLua has grown to target multiple platforms, support different OPL versions, and include a suite of CLI utilities, it’s become clear that short FAQ we created when we first shipped was insufficient. Keen to make room for growth, I added a documentation section, styled after Just The Docs:
\n\n\n
![](\"/posts/2026-01-13-week-3-monday/opolua-documentation@2x/1600.png\"\n)
\n \nOur documentation is sparse but now there’s somewhere to put it
\nTo complement these structural changes, I also added highlight.js, Mermaid, and jekyll-gfm-admonitions, to provide us with conveniences for syntax highlighting, diagramming, and GitHub-style admonitions respectively.
\nOver the past few days, I’ve been slowly pushing on with my home infrastructure setup. I finally resigned myself to using Ansible for managing my NAS/server—hopefully this will make it easier to keep the configuration in source control and increase my confidence as I continue to move away from Big Tech hosted services.
\nI also took delivery of a new 1U rack shelf and spent a little while moving my LincStation N2 NAS/server into the rack, indulging in the prerequisite CAD and 3D printing to mount the network switch alongside it:
\n\n
\n![](\"/posts/2026-01-13-week-3-monday/rack/400.jpeg\")
\n ",
"date_published": "2026-01-13T12:13:24-08:00",
"id": "https://jbmorley.co.uk/posts/2026-01-13-week-3-monday/",
"title": "Week 3—Monday",
"url": "https://jbmorley.co.uk/posts/2026-01-13-week-3-monday/"
},
{
"content_html": "Having spent an overly long day working on packaging OpoLua, Friday proved a slow one, with little visible progress: I took some time to plan out the remaining work to ship OpoLua; added Thursday’s binary Arch builds to the releases1; and tidied up the repository a little. Good work, but unexciting.
\nWithout a doubt, the highlight of the day was this screenshot from Alex, host of the Psion Discord and maintainer of Haiku’s MAME package:
\n\n
\n![](\"/posts/2026-01-12-week-2-friday/opolua-haiku/400.jpeg\")
\n \nI continue to be amazed by how portable Qt is, and there’s little better in life than a Haiku screenshot.
\nI plan to follow up with a PKGBUILD distribution for those who prefer source builds, but something is better than nothing. ↩
Continuing with my goal of trying to ship the Qt variant of OpoLua—our modern OPL interpreter—for macOS, Windows, and Linux, I spent much of the day diving into the ugly world of Linux packaging. To make things a little more palatable, I also treated myself to a small update to Reconnect, my Psion connectivity suite for macOS.
\nMy primary focus for the day was to set up Linux smoke-test builds to ensure that we don’t unintentionally break builds on the platform. Having already figured out how to build on Ubuntu, setting up automated builds proved easy—a matter of adding a GitHub Actions job to the workflow, and crafting a lightweight build script. I continue to be impressed by Qt’s tooling, which reduces builds on almost all platforms to:
\nqmake6\nmake\nSpurred on by a quick win, and lulled into a false sense of security, I decided to try tackling packaging for Ubuntu. When I’ve built Debian packages in the past using the standard tooling, I’ve been frustrated by the need for distro-specific directory structures so, to avoid polluting our source tree, I decided to look for an alternative. This took me to fpm or ‘Effing Package Management’, a multi-distro packaging tool which proved incredibly powerful, allowing me to generate a .deb from the directory output of Qt’s make install using a single command:
ARCHITECTURE=`dpkg --print-architecture`\nfpm \\\n -s dir \\\n -t deb \\\n -p \"opolua-ubuntu-24.04-$ARCHITECTURE-$VERSION_NUMBER-$BUILD_NUMBER.deb\" \\\n --name \"opolua\" \\\n --version $VERSION_NUMBER \\\n --architecture \"$ARCHITECTURE\" \\\n --description \"Runtime and viewer for EPOC programs and files.\" \\\n --url \"https://opolua.org\" \\\n --maintainer \"Jason Morley <support@jbmorley.co.uk>\" \\\n --depends libqt6core6 \\\n --depends libqt6gui6 \\\n --depends libqt6widgets6 \\\n --depends libqt6multimedia6 \\\n --depends libqt6core5compat6 \\\n --chdir \"$INSTALL_DIRECTORY\" \\\n .\n(You’ll notice I’m getting the architecture with dpkg --print-architecture—using ARM and Intel runners with GitHub Actions matrix builds, the build script can output releases for both architectures.)
I shared the builds with a few members of the Psion Discord, and Colin kindly sent me a couple of screenshots of OpoLua running on Kubuntu—it’s a real reward to see others using our creation.
\n\n
\n![](\"/posts/2026-01-12-week-2-thursday/kubuntu-welcome/400.png\")
\n \n\n
\n![](\"/posts/2026-01-12-week-2-thursday/kubuntu-jumpy/400.png\")
\n \nJumpy! is a wonderful showcase for OPL
\nWhile there are still many different Linux distributions and versions to add to the build script (and I’d like to set up an apt repository to ensure folks can get automatic updates), I’m pretty pleased with this progress.
\n… But I couldn’t leave it there. I decided to try tackling Arch Linux—a distro I’ve little experience of. Starting this at 10pm was perhaps a poor choice. fpm did its job well, and I able to change a couple of flags and output a pacman binary package, but Alex quickly dissuaded me of the notion that this was good enough: binary packages are (understandably) frowned upon in Archland and PKGBUILD source builds (distributed via AUR) are preferable as they increase transparency.
PKGBUILD configuration files seem mostly well designed and, with Alex’s help, I was able to craft something that worked. The big challenge was how Git submodules are (or aren’t) handled: while there’s good support for Git, there’s absolutely no support for submodules—you have to manually recreate these in your prepare. For a project like OpoLua that relies heavily on recursive submodules, this is a miserable experience. makepkg (which processes PKGBUILD files) will check out each submodule at the top-level, and you have to rewrite all the submodule urls from the bottom up:
prepare() {\n\n cd \"$srcdir/opolua\"\n git submodule init\n git config submodule.LuaSwift.url \"$srcdir/LuaSwift\"\n git config submodule.diligence.url \"$srcdir/diligence\"\n git config submodule.scripts/changes.url \"$srcdir/changes\"\n git config submodule.scripts/build-tools.url \"$srcdir/build-tools\"\n git -c protocol.file.allow=always submodule update --recursive\n\n cd \"$srcdir/opolua/dependencies/LuaSwift\"\n git submodule init\n git config submodule.Sources/CLua/lua.url \"$srcdir/lua\"\n git -c protocol.file.allow=always submodule update\n\n}\nI’ve yet to work out how to synthesize per-release versions of the PKGBUILD file, or how to get those into AUR, but it’s good to have broken the back of this.
\nWhile Apple’s Liquid Glass is incredibly divisive and widely derided (I personally dislike it), I’m keen for my apps to feel at home on the system—I don’t want to add to users' cognitive burden by rejecting platform choices. With that in mind, I’ve been slowly adopting the new menu icons, and I took a little time to add them to the Reconnect menu bar menu:
\n\n\n
![](\"/posts/2026-01-12-week-2-thursday/reconnect-menu@2x/1600.png\"\n)
\n \nIt’s not clear to me that this is an improvement—there’s a recent piece over at tonsky.me that captures many of the issues—but it’s where things are going. Perhaps I’ll use this investigation by Brent Simmons to give users a choice.
", "date_published": "2026-01-12T11:03:19-08:00", "id": "https://jbmorley.co.uk/posts/2026-01-12-week-2-thursday/", "title": "Week 2—Thursday", "url": "https://jbmorley.co.uk/posts/2026-01-12-week-2-thursday/" }, { "content_html": "Having spent the first couple of days of the week bashing my head against Windows and GitHub Actions workflows, I decided to take a ‘break’ to focus on nailing down the licensing for OpoLua—it might not be glamorous, but it’s a necessity when shipping software in today’s world. Thankfully that didn’t take the whole day, so I was able to try out OpoLua Qt on Linux for the first time, and even squeeze in a little Psion-related fun. I also found myself returning—however briefly—to Game Play Color, my semi-retired JavaScript Game Boy emulator.
\nQt’s licensing mandates that any software linking the Qt libraries be licensed GPLv2 or Later for non-commercial access to the library. Keen to keep the more permissive MIT License where possible, I’ve re-licensed just the Qt app under GPL2 or Later and updated our documentation to be far more explicit about the project’s components and licenses: the Lua code which provides the OPL runtime remains MIT licensed, as does the iOS app. You can read all the gory details on the website. This represents a significant milestone in officially shipping OpoLua Qt: we can now do so legally. 🥳
\nDesperate for a change of scene, I also spent a little time setting up an Ubuntu VM and getting OpoLua Qt building on Linux—Ubuntu’s status as the only GitHub Actions Linux runner makes it a natural first choice for automated builds. Once I realized qmake has been renamed to qmake6 on Ubuntu, I was happy to find everything just worked:
\n\n
![](\"/posts/2026-01-08-week-2-wednesday/opolua-ubuntu@2x/1600.png\"\n)
\n \nIt’s incredibly exciting to see OPL running in so many places
\nAfter a morning of licenses and administration, I treated myself to a side-quest back into the world of Psions to explore another way that my Psion might offer daily utility: since letting my Kindle go (I’m exhausted by the modern trend of personal devices becoming marketing vehicles and storefronts), I’ve not had any digital reading solution and, recalling using a reader program for the Series 3c many years ago, I decided to fix that. Thanks to some help from the Psion Discord, I rediscovered eTxtReader:
\n\n
\n![](\"/posts/2026-01-08-week-2-wednesday/reader-unicode/400.jpeg\")
\n \nHaruki Murakami’s Birthday Girl in eTxtReader on a Series 3mx
\nI used Calibre to convert some existing books to text files. They required some further massaging to translate from Unicode to ASCII (you’ll see some strange characters if you look closely at the photo above) and, with this secondary pass, everything worked perfectly:
\n\n
\n![](\"/posts/2026-01-08-week-2-wednesday/reader-ascii/400.jpeg\")
\n \neTxtReader is a really impressive program, barely breaking a sweat when viewing multi-megabyte files on a device with at most 2MB RAM—a must for the modern Psion user.
\nEarlier in the week I received very short notice that Netlify is ending the platform I’ve been using to host Game Play Color. Not ready to let it go just yet, I decided to move to GitHub Pages. Fortunately, as a static site, it was a pretty easy process, and I was able to integrate it into the existing GitHub Actions workflows. (You can see the change here if you’re interested in the details.)
\n\n
\n![](\"/posts/2026-01-08-week-2-wednesday/crystalis@3x/400.png\")
\n \nGame Play Color up and running with different hosting
\nAt some point, I imagine I’ll let gameplaycolor.com go and continue my consolidation on jbmorley.co.uk subdomains—it just doesn’t make sense to continue paying for so many domain names.
With OpoLua Qt macOS and Windows builds complete and available for folks to download, I now have to decide how many of the remaining tasks need tackling before moving onto other projects (and perhaps even feature work). The remaining OpoLua Qt housekeeping I have in mind is:
\nThis feels like more than I’ll manage in the remaining coupe of days this week (which are also being filled with various bits of immigration paperwork), so I’ll do what I can. Providing a clear download link for OpoLua Qt on the website feels like the highest priority, followed by a Linux smoke-test build to ensure we don’t unintentionally break those builds during development.
\nSince this kind of work doesn’t light up my creative and coding brain that much, I might also allow myself a small segue into tidying up a few aspects of Reconnect, my Psion connectivity suite—it’s a tool I use daily, and small quality of life improvements there have an outsize positive impact—self-care for the retro software engineer if you will.
", "date_published": "2026-01-08T12:43:14-08:00", "id": "https://jbmorley.co.uk/posts/2026-01-08-week-2-wednesday/", "title": "Week 2—Wednesday", "url": "https://jbmorley.co.uk/posts/2026-01-08-week-2-wednesday/" }, { "content_html": "Continuing my week of project spring cleaning (I’m keen to clear the decks before launching into new things), I pushed on with the process of preparing OpoLua Qt—our OPL runtime for modern platforms—for release.
\nWhile I finished Monday with a building proof-of-concept Windows CI branch, there was still a lot of polish required—where possible, I like to avoid putting build commands directly in GitHub Actions workflows to ensure builds can be reproduced manually if necessary. I created a new build script (build-qt-windows.sh) which we can run locally in a pinch (or migrate more easily to other build systems when GitHub inevitably becomes untenable)—I prefer separate scripts for each build task as I’ve found this helps ensure it’s clear where functionality lives and reduces complexity in the scripts themselves. For example, our scripts directory contains the following, hopefully self-explanatory, utilities:
build-ios.shbuild-package.shbuild-qt-mac.shbuild-qt-windows.shbuild-website.shinstall-dependencies.shinstall-qt.shrelease.shtest.shupdate-release-notes.shupload-and-publish-release.shSince we’re now building on multiple platforms with OpoLua (macOS) and OpoLua Qt (macOS, Windows, and Linux), our GitHub Actions needed additional work to ensure version and build numbers were shared across all builds, and that artifacts were aggregated at the end for release. To do this, I created two new jobs: generate-version-number and publish-release. These top and tail the pipeline:
\n\n
![](\"/posts/2026-01-07-week-2-tuesday/pipeline/1600.png\"\n)
\n \nThe core of generate-version-number is as follows:
generate-version-number:\n runs-on: ubuntu-latest\n\n outputs:\n version_number: ${{ steps.version.outputs.version_number }}\n build_number: ${{ steps.version.outputs.build_number }}\n\n steps:\n\n - name: Checkout repository\n uses: actions/checkout@v4\n with:\n fetch-depth: 0\n\n # ...\n\n - name: Generate version and build numbers\n id: version\n run: |\n source scripts/environment.sh\n VERSION_NUMBER=`scripts/changes/changes version`\n BUILD_NUMBER=`build-tools generate-build-number`\n echo \"version_number=$VERSION_NUMBER\" >> $GITHUB_OUTPUT\n echo \"build_number=$BUILD_NUMBER\" >> $GITHUB_OUTPUT\nThis uses changes (my semantic versioning script) to synthesize a version number from the git commit log, along with build-tools (a collection of build utilities) to generate an 18-digit build number that encodes the build timestamp and git sha. It then makes these available to subsequent build jobs using outputs.
Once the different platform build jobs have completed, publish-release aggregates their artifacts and, on main builds, uploads the iOS app to TestFlight and creates a new GitHub release if necessary, attaching the build output. 😮💨
While it took much of the day to slowly iterate on the build pipeline, I finished with a new (automatically created) release on GitHub—version 2.1.0—comprising iOS, macOS and Windows apps. It’s early days yet for OpoLua Qt, but we’d love your feedback.
\nNext up, Linux!
", "date_published": "2026-01-08T00:20:58-08:00", "id": "https://jbmorley.co.uk/posts/2026-01-07-week-2-tuesday/", "title": "Week 2—Tuesday", "url": "https://jbmorley.co.uk/posts/2026-01-07-week-2-tuesday/" }, { "content_html": "This post is a spiritual continuation of my December Adventure—I enjoyed the experience of keeping a daily devlog, so I’m going to see how long I can keep it going.
\nHaving spent much of the first week of the year on festivities and wrapping up the last few bits of my 2025 December Adventure, I decided to ease back into things slowly. Armed with my long list of issues from last year, I set about knocking out some bug fixes and—hopefully—clearing the way for future feature work.
\nOpoLua continues to loom over me. Tom is doing stellar work fleshing out our new Qt desktop-focused app, and rounding out our OPL implementation, but we’ve yet to actually ship anything. As our resident GitHub Actions whisperer, that task tends to fall to me.
\nThe Qt app has been building successfully for macOS in CI for the past couple of weeks (since I first took a crack at it on day 12 of my December Adventure), but an issue with the way I was linking the Qt frameworks meant that it would only run if Qt was installed. Thankfully, after a little investigation, the fix proved simple—Qt provides macdeployqt which can embed the Qt frameworks and correctly sign an app for notarization (an entirely unexpected convenience if you’re used to developing for Apple platforms):
macdeployqt \"OpoLua Qt.app\" \\\n -verbose=3 \\\n -sign-for-notarization=\"Developer ID Application: Jason Morley (QS82QFHKWB)\"\nWith the addition of just this simple line, macOS Qt builds are now working!
\nBuoyed by my success, I decided to take a crack at Windows builds—what could possibly go wrong? Much to my surprise, very little! GitHub Action’s Windows runners are, as you might expect, pre-configured for development, and you can opt to use bash for your scripting, allowing me to lean on my macOS and Linux scripting experience rather than trying to wrap my head around PowerShell. Since we want to statically link Qt for the Windows app, this necessitates building Qt itself from source (see install-qt.sh) which takes about 1 ½ hours on GitHub Actions, but this shouldn’t change often, so we can cache the builds, leaving us with typical build times of about 2 minutes.
\n
\n![](\"/posts/2026-01-06-week-2-monday/opolua-qt-windows/400.png\")
\n \nSince I don’t use Windows for development, this is one of the first times I’ve used OpoLua on Windows 11, and it feels like quite an achievement. 🥳
\nI’ve still a few tweaks to make to the Windows builds before merging my changes into main. After that, I’ll start to take a look at tidying up the OpoLua licensing story so we can actually ship these binaries (Qt has some pretty strict requirements if you don’t buy a commercial license).
Having set out to work on a range of mostly Psion-related ideas and tasks during my 2025 December Adventure, I’m incredibly pleased with what I accomplished: I moved a collection of things forwards, started some new projects, and had quite a bit of fun doing it.
\nSome of my highlights:
\nI’ve really enjoyed this December Adventure. It’s encouraged me to be more deliberate about the ideas I explore each day, and I’ve found the practice of daily write-ups to be incredibly positive.
\nThe regular cadence has forced me to metaphorically put down what I’m working on, pause, and reflect on what I’ve done and where it’s going. This has helped me significantly in planning and prioritizing when working on increasingly interdependent projects. It’s also been incredibly rewarding to share more frequently what I create and receive realtime feedback, while also gaining the sense of external accountability (real or imagined) that comes from setting my approach down in a public forum.
\nWith that in mind, I’m keen to continue a more regular practice of writing going into the new year. I’m not sure quite what that needs to look like yet, so I imagine you’ll see a few experiments over the coming weeks and months—I don’t want to overwhelm folks (or myself) with daily updates, but I think whatever I do needs to be regular to ensure that I don’t end up with a backlog.
\nTo start with, I’d like to focus on specific projects to help move them forwards a little more intentionally, so I’m planning to have a theme for each week. I’ll write brief daily journal or devlog (that I may or may not publish), and edit it into weeknotes.
\nI’d love to keep working on many of my December Adventure themes in the coming year. For the established projects, I plan to track the new tasks that have emerged during the month as issues in their respective repositories. This will allow others to engage with them in a public forum, and ensure I don’t feel so overwhelmed (or forget anything):
\nIf you’re excited to help work on some of these—or any other—projects, please don’t hesitate to get in touch; I’m always looking for collaborators.
\nThere are also a few smaller projects I’d still love to write up, or otherwise publish:
\nThis just leaves the ideas and explorations that will have to wait for next year’s adventure (or a lazy Sunday):
\nI’d like to take the time to thank everyone who followed along this month, and to thank the couple of folks who donated this month (you know who you are) 🙇♂️. Waking up to your emails and messages really gave me a huge boost. If you have the time I strongly encourage you to give a little love to the creators and open source developers who make a difference to your life—the emotional support and encouragement goes immeasurably far.
", "date_published": "2026-01-04T23:37:55-08:00", "id": "https://jbmorley.co.uk/posts/2026-01-04-beyond-december/", "title": "Beyond December", "url": "https://jbmorley.co.uk/posts/2026-01-04-beyond-december/" }, { "content_html": "Day 31 brought my December Adventure to a close for another year. I spent much of the day trying to work out how to write up day 30’s plptools-focused AI experiment (about which I remain deeply conflicted), and reflecting on the past month of adventuring. I also managed to squeeze in a last couple of tasks: enabling Doxygen builds for plptools, and designing and printing a holder for 2 AA batteries (a must when daily-driving my two favorite writing devices—a Psion, or Pomera DM30).
\nSince I’ve a fair few thoughts about where to take everything I’ve worked on in my adventures, I’ll cover these in a follow-up post.
\nIn plptools, the current group of maintainers have inherited a C++ codebase that’s very much of its era, making it hard to follow at times. With a view to helping us (and newcomers) understand what’s going on, I’d like to encourage a gradual process of adding documentation (especially class-level documentation) to the project. To help with this, I added a simple Doxygen configuration to the project and set up documentation builds in our CI.
\n\n\n
![](\"/posts/2026-01-04-december-adventure-day-31/doxygen@2x/1600.png\"\n)
\n \nYou can view the (sparse) documentation here.
\nThere’s a myriad designs for AA battery holders out there, but I couldn’t find any simple screw-cap tubes—something that would fit in a pencil case—so I designed my own:
\n\n
\n![](\"/posts/2026-01-04-december-adventure-day-31/battery-holder/400.jpeg\")
\n \nI’d like to update the design to add a rubber o-ring to help the screw lid to stay closed and give it a water-tight seal but, so far, I’m pretty pleased with the design. I plan to publish the STL files in the coming days.
", "date_published": "2026-01-04T15:39:02-08:00", "id": "https://jbmorley.co.uk/posts/2026-01-04-december-adventure-day-31/", "title": "December Adventure Day 31", "url": "https://jbmorley.co.uk/posts/2026-01-04-december-adventure-day-31/" }, { "content_html": "Reconnect was on my mind as I started day 30 of my December Adventure, and I found my thoughts drifting to its relationship with plptools, which provides the Psion Link Protocol implementation and many other conveniences. Allowing myself the distraction—longer-term architectural noodlings are always useful—I ended up spending much of the day focused on plptools, exploring new features and considering its future direction. I also tool a little time to fix a longstanding bug in my website that I spotted while writing-up this adventure.
\nSpeaking with Alex and Fabrice—the other maintainers of plptools—we settled on a couple of small improvements that would significantly improve the usability and testability of plptools. Both are aimed at improving connectivity and compatibility:
\nSupport serial devices without DTR/DSR signalling
Some cheaper RS232 adapters and operating systems (looking at you, Haiku) don’t support these hardware signals meaning they don’t work with plptools. By offering a compatibility mode that ignores these signals, we should be able to significantly increase support at the cost of some connection robustness. A worthwhile trade-off.
TCP Serial Port Emulation
We’d love to be able to connect plptools to Psion emulators. This would serve, not only as a convenience for transferring files to and from the emulators themselves, but as a way to quickly test plptools against a broad range of deices. (Shocking as it may sound, we don’t always have every Psion device ever made to hand.) MAME provides an emulated serial port that streams unframed serial data over a TCP connection, and we would like to explicitly support this in plptools.
Keen to dig into something with some near-term benefits, I decided to take a shot at getting plptools to work with MAME.
\nFirst-up, I spent a little time figuring out how to enable the serial port in MAME:
\nmame \\\n psion3a2 \\\n -sibo serial \\\n -sibo:serial:rs232 null_modem \\\n -bitbanger socket.127.0.0.1:1234 \\\nConstructing this command took quite a lot longer than I’d have liked so, for future travellers, here’s my understanding of how it breaks down:
\n-sibo serial—enable the serial feature-sibo:serial:rs232 null_modem—configure the serial feature to use a null modem-bitbanger socket.127.0.0.1:1234—use the bitbanger interface connecting to 127.0.0.1, port 1234In the process of working all this out, I discovered a couple of commands which might be helpful to others:
\nUse -listslots to show image-specific options:
mame psion3a2 -listslots\nThis will output something like:
SYSTEM SLOT NAME SLOT OPTIONS SLOT DEVICE NAME\n---------------- ---------------- ---------------- ----------------------------\npsion3a2 sibo fax Psion 3-Fax Modem\n parallel Psion 3-Link Parallel Printer Interface\n serial Psion 3-Link RS232 Serial Interface\nUsed in combination with a specific slot option, '-listslots' will show you the additional slots and options for that slot1:
mame psion3a2 -sibo serial -listslots\nThis shows the serial port specific configuration options:
SYSTEM SLOT NAME SLOT OPTIONS SLOT DEVICE NAME\n---------------- ---------------- ---------------- ----------------------------\npsion3a2 sibo fax Psion 3-Fax Modem\n parallel Psion 3-Link Parallel Printer Interface\n serial Psion 3-Link RS232 Serial Interface\n\n sibo:serial:rs232 dec_loopback RS-232 Loopback (DEC 12-15336-00)\n h19 Heath H19 Terminal (Serial Port)\n ie15 IE15 Terminal\n keyboard Serial Keyboard\n loopback RS-232 Loopback\n mockingboard Sweet Micro Systems Mockingboard D\n msystems_mouse Mouse Systems Non-rotatable Mouse (HLE)\n nss_tvi Novag Super System TV Interface\n null_modem RS-232 Null Modem\n patch RS-232 Patch Box\n printer Serial Printer\n pty Pseudo Terminal\n rs232_sync_io RS-232 Synchronous I/O\n rs_printer Radio Shack Serial Printer\n scorpion Micro-Robotics Scorpion Intelligent Controller\n sunkbd Sun Keyboard Adaptor\n swtpc8212 SWTPC8212 Terminal\n terminal Serial Terminal\n votraxtnt Votrax Type 'N Talk (Serial Port)\nArmed with an appropriate command, I was quickly able to use netcat (nc -l -p 1234) to echo text sent from the Psion’s Comms program:
\n
\n![](\"/posts/2026-01-02-december-adventure-day-30/hello-world@2x/400.png\")
\n \nThe serial port implementation in plptools is isolated to packet.cc where it’s treated as a classic POSIX file descriptor. This makes it easy to drop in a replacement TCP socket file descriptor (at least as a proof-of-concept). Since most C socket handling is boilerplate, and I knew exactly what I wanted, I thought it might prove a good test for AI—I find almost every aspect of generative AI deeply concerning, but I do my best to try it out every now and again so I can speak from at least some level of experience and knowledge. With very little prompting, Claude (Sonnet 4.5) was able to produce the following:
// This blocks rather than going back into a listening state.\nint\ninit_tcp(const char *port_str, int debug)\n{\n int listen_fd, conn_fd;\n struct sockaddr_in addr;\n int port = atoi(port_str);\n int optval = 1;\n\n if (debug)\n printf(\"creating TCP listener on port %d...\\n\", port);\n\n listen_fd = socket(AF_INET, SOCK_STREAM, 0);\n if (listen_fd < 0) {\n perror(\"socket\");\n exit(1);\n }\n\n setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval));\n\n memset(&addr, 0, sizeof(addr));\n addr.sin_family = AF_INET;\n addr.sin_addr.s_addr = INADDR_ANY;\n addr.sin_port = htons(port);\n\n if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {\n perror(\"bind\");\n exit(1);\n }\n\n if (listen(listen_fd, 1) < 0) {\n perror(\"listen\");\n exit(1);\n }\n\n if (debug)\n printf(\"waiting for connection...\\n\");\n\n conn_fd = accept(listen_fd, NULL, NULL);\n if (conn_fd < 0) {\n perror(\"accept\");\n exit(1);\n }\n\n close(listen_fd);\n\n if (debug)\n printf(\"connection accepted, fd=%d\\n\", conn_fd);\n\n return conn_fd;\n}\nThis function accepts an incoming TCP connection and returns a file descriptor, serving as a drop-in replacement for init_serial as implemented by mp_serial.c. I updated the code to call init_tcp with the appropriate arguments and, without any further modification, I was able to start up the plptools daemon (ncpd) and connect to a MAME Psion emulator. Success! 🥳
(I’d include a screenshot here, but my attempts to reproduce the experiment have been unsuccessful.)
\nIn spite of this early success, I now feel like I have an AI problem: this code is clearly not production quality (it’s blocking; errors aren’t propagated; it makes no attempt to support multiple sequential or concurrent connections) and, while some might be willing to commit it to a project, the legality and copyright is deeply ambiguous. Although I’m not too worried that what I ultimately produce will be derivative (almost all generated code is boilerplate), I regret using AI here: there’s a lot of work required to turn it into production code and I doubt it saved me more than half an hour of development time, while incurring significant environmental, ethical, and legal cost.
\nI plan to revisit this over the coming weeks and (manually) design and implement an architecture which better fits plptools.
\nIf you view the December Adventure or Archive pages on this website, you’ll see that the list of posts is broken into sections, one for each year. This website is built using InContext (my own take on a static site generator) and uses Tilt, a Lua-based templating language designed by Tom, my partner in crime on many a project.
\nThe template for generating these archive pages looks like this:
\n{% include \"common.lua\" %}\n{% function content() %}\n <div class=\"post\">\n {% include \"post_header.html\" %}\n <article class=\"post-content\">\n\n {{ document.render() }}\n\n {%\n -- Get the posts.\n posts = document.query(\"posts\")\n this_year = \"\"\n previous_year = \"\"\n %}\n\n {% for index, post in ipairs(posts) do %}\n\n {%\n -- Get the year of the current post.\n if post.date then\n this_year = post.date.format(\"yyyy\")\n else\n this_year = \"Undated\"\n end\n %}\n\n {%\n -- Start a new section if the year is different from the previous one.\n %}\n {% if index == 1 then %}\n {% if this_year then %}\n {% if not query then %}<h1>{{ this_year }}</h1>{% end %}\n {% end %}\n <ul class=\"pagelist short\">\n {% else %}\n {% if this_year ~= previous_year then %}\n </ul>\n {% if this_year then %}\n <h1>{{ this_year }}</h1>\n {% end %}\n <ul class=\"pagelist short\">\n {% end %}\n {% end %}\n\n <li><span class=\"date\">{% if post.date then %}{{ post.date.format(site.metadata.day_month_format_short) }}{% end %}</span> <a href=\"{{ post.url }}\">{{ post.title }}{% if post.subtitle then %}: {{ post.subtitle }}{% end %}</a></li>\n\n {% if last(posts, index) then %}\n </ul>\n {% end %}\n\n {% previous_year = this_year %}\n {% end %}\n\n </article>\n\n </div>\n{% end %}\n{% include \"default.html\" %}\nThe approach to determining the section fairly simple: the template iterates over the ordered posts (for index, post in ipairs(posts) do), generates the text representation of the year component of each post’s publish date (this_year = post.date.format(\"yyyy\")) and, if it differs from that of the previous post (if this_year ~= previous_year then), prints a new header, and starts a new ul. While it feels a little inelegant (functional, it is not), this has always proven reliable. Until yesterday:
\n\n
![](\"/posts/2026-01-02-december-adventure-day-30/archive@2x/1600.png\"\n)
\n \nThe astute reader might have already noticed the problem in the template, but it took me a little while to spot: it turns out there’s quite a difference between Y and y date format specifiers (used when getting the years from posts). They are defined as follows:
y —Year. Normally the length specifies the padding, but for two letters it also specifies the maximum length.Y—Year (in “Week of Year” based calendars). Normally the length specifies the padding, but for two letters it also specifies the maximum length. This year designation is used in ISO year-week calendar as defined by ISO 8601, but can be used in non-Gregorian based calendar systems where week date processing is desired. May not always be the same value as calendar year.I was incorrectly using the ‘week of year’ year. 🤦
\nWeek numbers are a fascinating unit of time as, depending on how the weeks align with a given year, the last days of a year might appear in week 1 of the following year, or the first days of the new year, in week 52 of the previous one. Thankfully, the fix was simple: change YYYY to yyyy.
Turtles all the way down. ↩
With the month coming to a close, I decided to spend the last few days of my December Adventure to wrap-up some of the loose ends of the projects I’ve worked on this month: I found a few outstanding changes in Reconnect when I added Psion Word conversion support, and there was some further cleanup to do to the OpoLua source tree to set us up for new features in 2026.
\nAs OpoLua has grown, we’re using it in more-and-more projects: it now serves as a cross-platform library for working with EPOC16 and EPOC32 files, and we’re using it in both Reconnect and the Psion Software Index. As is always the case with software projects, the source structure hasn’t evolved at the same pace, so I took some time to tidy it up: I cleaned up the top-level Swift package, added smoke-test builds for this, and updated the OpoLua app to use the package, rather than including the source files directly. Since Reconnect and OpoLua now use the same ‘OpoLuaCore’ library, it will make keeping Reconnect up-to-date much easier. Over time, I hope to move more functionality from the OpoLua app into OpoLuaCore to allow us to use it in other apps.
\nI caught Reconnect up to the new version of OpoLua and finally got around to adopting the support for customizing SIS file install locations that Tom added sometime ago, unlocking using SIS files with EPOC16—while this was never supported for EPOC16, I hope it will allow us to start packaging EPOC16 programs on the Psion Software Index to make that easier for people to jump into.
\nI also spent a little time triaging the open issues, and had a quick look at what it would take to convert EPOC16 PIC images—it turns out these are just multi-bitmap MBM files with black and grey planes, which I didn’t quite combine correctly on my first attempt:
\n\n
\n![](\"/posts/2025-12-30-december-adventure-day-29/screenshot-large/400.png\")
\n \nA solid day of laying the groundwork for the future. 🧱
", "date_published": "2025-12-30T13:59:59-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-30-december-adventure-day-29/", "title": "December Adventure Day 29", "url": "https://jbmorley.co.uk/posts/2025-12-30-december-adventure-day-29/" }, { "content_html": "Inspired by Alex’s evergreen enthusiasm for the Psion Series 3 devices, and my recent Series 3a maintenance efforts, I’d love to find a way to incorporate these into my daily routines. Boasting a full keyboard, they are natural writing devices so, for day 28 of my December Adventure, I decided to focus on improving my workflows for journaling and writing-up projects on my Series 3mx.
\n\n
\n![](\"/posts/2025-12-30-december-adventure-day-28/writing/400.jpeg\")
\n \nOut of the box, EPOC16 devices are well set up for writing—Psion Word is an entirely serviceable word processor. This leaves just the process of getting the files into modern formats, and into my other workflows. Reconnect, my modern Psion connectivity suite for macOS, supports file transfer for EPOC16 devices, but doesn’t support conversion for these older file formats, so I set about fixing this sort-fall, starting with Word file conversion.
\nTony Smith has already produced an MIT licensed Word parser and converter written in Swift, Word2Text, (thanks Tony!), so this seemed like the natural starting point. Armed with a fully-functional implementation, there wasn’t too much to do but plumb it into Reconnect’s existing file conversion architecture:
\nprivate static let converters: [Conversion] = [\n\n // MBM\n Conversion { entry in\n return entry.fileType == .mbm || entry.pathExtension.lowercased() == \"mbm\"\n } filename: { entry in\n return entry.name\n .deletingPathExtension\n .appendingPathExtension(\"tiff\")\n } perform: { sourceURL, destinationURL in\n let outputURL = destinationURL.appendingPathComponent(sourceURL.lastPathComponent.deletingPathExtension,\n conformingTo: .tiff)\n try PsiLuaEnv().convertMultiBitmap(at: sourceURL, to: outputURL)\n try FileManager.default.removeItem(at: sourceURL)\n return outputURL\n },\n\n // WRD\n Conversion { entry in\n return entry.pathExtension.lowercased() == \"wrd\"\n } filename: { entry in\n return entry\n .name\n .deletingPathExtension\n .appendingPathExtension(\"txt\")\n } perform: { sourceURL, destinationURL in\n let outputURL = destinationURL.appendingPathComponent(sourceURL.lastPathComponent.deletingPathExtension,\n conformingTo: .plainText)\n let data = try Data(contentsOf: sourceURL)\n let bytes = [UInt8](data)[...]\n let result: ProcessResult = PsionWord.processFile(bytes)\n guard result.errorCode == .noError else {\n throw ReconnectError.unknown\n }\n try result.text.write(to: outputURL, atomically: true, encoding: .utf8)\n return outputURL\n }\n\n]\nLooking again at this code, there are some elements of the architecture that I’d love to revisit: I especially dislike the duplicated filename generation code. This exists because macOS needs to know the target filename upfront for drag-and-drop operations, but I could at least change my converter API to inject it back into the perform: block.
Architectural aspirations aside, everything just worked, and it’s now possible to effortlessly convert Psion Word files to text by drag-and-dropping them from Reconnect! 🥳
\nWhile I was at it, I also added a new ‘Conversions’ tab to the Reconnect settings:
\n\n\n
![](\"/posts/2025-12-30-december-adventure-day-28/conversions@2x/1600.png\"\n)
\n \nI plan to expand on this in the future to allow per-file type options: Word2Text supports conversion to text or Markdown and I’d love to expose that functionality in Reconnect.
", "date_published": "2025-12-30T13:11:21-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-30-december-adventure-day-28/", "title": "December Adventure Day 28", "url": "https://jbmorley.co.uk/posts/2025-12-30-december-adventure-day-28/" }, { "content_html": "After altogether too long, day 27 of my December Adventure saw me finally tackling, ‘remove Libretto 50CT batteries’, which my Organiser Il lucky dip has reminded me of countless times this month. I filmed the process, but as there are already good teardown guides, I’ve focused on illustrative stills instead of publishing the whole video.
\n\n
\n![](\"/posts/2025-12-29-december-adventure-day-27/overview/400.jpeg\")
\n \nMy daily driver Libretto 50CT awaiting surgery on the operating table
\nAs I had feared, the BIOS batteries in both machines had started to leak ever so slightly. The leak wasn’t apparent at first, but the battery contacts were corroded and it was clear it had travelled along the battery wires and into the JST connector on the mainboard.
\n\n
\n![](\"/posts/2025-12-29-december-adventure-day-27/battery/400.jpeg\")
\n \nYou can just make out the green corrosion on the connector
\nHaving found the corrosion, I decided to fully tear down both machines and clean the affected area of the mainboard with white vinegar, followed by a healthy rinse in IPA. While I could have done this with the mainboard in the case, I didn’t want to risk further damaging the already-brittle plastics with the vinegar.
\n\n
\n![](\"/posts/2025-12-29-december-adventure-day-27/cleaning/400.jpeg\")
\n \nI used an old stiff-bristle paintbrush1 for the process and focused on the area around the JST connector. After giving the mainboard time to dry, I reassembled everything taking care not to crack the case and verified both machines still worked.
\n\n
\n![](\"/posts/2025-12-29-december-adventure-day-27/working/400.jpeg\")
\n \nThankfully, it looks like I caught the leaks in time, and both machines booted up. I’d still like to switch out the spinning hard disk in my secondary device, but that’s one for another day. 😮💨
\nPerhaps even more concerning than the leaky batteries was discovering the damage Hawaii is doing to the Libretto I have in daily rotation—the climate here is brutal and sadly shortens the life of devices, old and new.
\n\n
\n![](\"/posts/2025-12-29-december-adventure-day-27/corrosion/400.jpeg\")
\n \nThe humid salt air is rapidly corroding the metallic paint on the Libretto’s case
\nThere’s not much I can do about the climate—I keep what I can in weatherproof totes with desiccants—but I can be more selective about the devices I keep out. Seeing this damage is a good reminder to be more deliberate about the devices I use, an encouragement to let a few go to good homes, and practice a little more minimalism.
\nI’ve ordered some antistatic brushes for future work. ↩
Having taken what amounted to a day off from my December Adventure for Christmas, day 26 saw me return to my original list of ideas as I took the time to reinforce the hinges on my Psion Series 3a. As I noted previously, this was on hold as I worked out how to record and document the process to help others looking to do it themselves. Armed with my new desk tripod, I gave it a shot.
\nI also took some time to finish moving both StatusPanel and Anytime from Caddy to a combination of nginx and certbot. I’ll not go into more detail here, but I’m happy to be back on more mainstream infrastructure, and hopeful it will reduce maintenance costs in the future.
\nAnyone who’s searched for a Psion on eBay will know that the hinges are their Achilles' heel—with the exception of the (hingeless) Organisers, if the hinges haven’t cracked yet, it’s only a matter of time. To address this, members of the Psion community have taken to using JB Weld to reinforce hinges, and even restore broken ones. This works incredibly well and, since my wood-grain Series 3a was in need of this treatment, I thought it would be a good idea to document it.
\nThankfully, with the Series 3 range of devices, you can get access the hinges without opening the device—this means you can avoid subjecting them to one last open that might crack the hinges:
\n\n
\nThe process I’ve settled on for my Psions is to just reinforce the screen-side of the hinges—these are easy to access and most prone to cracking. The goal is to fill the recess on the back of each hinge and fillet or taper the JB Weld down to the curve of the hinges themselves, taking care not to get any epoxy onto the other half of the hinges. This is a delicate operation, so go slow, and use a small palette knife like implement: I started with a cut-off Q-tip which proved too large, and ultimately settled on some rounded tweezers.
\n\n
\nIf everything’s gone well you’ll have a small fillet of JB Weld on the back of each hinge. After 24 hours, you can replace the spine, batteries, and battery cover and your Psion should be ready for another 20 years of daily use. 🤞
\n\n
\nI’m looking forward to getting back to using my Series 3a once the JB Weld has cured—I’ve still never tried a Series 3 or 3a with Reconnect, and I’m looking forward to breaking out the 3Link and doing so.
", "date_published": "2025-12-27T17:59:47-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-27-december-adventure-day-26/", "title": "December Adventure Day 26", "url": "https://jbmorley.co.uk/posts/2025-12-27-december-adventure-day-26/" }, { "content_html": "Day 25 (Merry Christmas to those of you who celebrate) of my December Adventure brought somewhat of a departure from the regular adventuring: I wrote up my adventures from the past few days, tried to slow a little, cooked, and primed a sign Sarah’s painting for a friend’s business.
\n\n
\n![](\"/posts/2025-12-27-december-adventure-day-25/sign/400.jpeg\")
\n \nNormal service will (hopefully) return with day 26.
", "date_published": "2025-12-27T13:03:58-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-27-december-adventure-day-25/", "title": "December Adventure Day 25", "url": "https://jbmorley.co.uk/posts/2025-12-27-december-adventure-day-25/" }, { "content_html": "Having spent day 23 of my December Adventure on some fairly process-heavy sysadmin, much of day 24’s adventure time was consumed writing it up—I always struggle to work out how much detail to include, and end up constantly reworking such posts. In spite of that, I managed to roll nginx out to some of the services I run (including this website, the Psion Software Index, and WriteMe), and spent a little time organizing my retro computing and preparing for future adventures. I’ll not write about the switch from Caddy to nginx more here; if you’re curious, check out the various projects on GitHub.
\nWhenever I pick up a retro computer, I try to sort out a convenient way to power it using USB-C: I’m keen to actively use the devices I have and not having to carry an extra power brick significantly reduces the friction of doing so. Often they’ll use some kind of barrel connector at one of the standard voltages (5V, 9V, 12V, 15V, etc). This makes buying cables easy (there’s a plethora of USB PD cables out there), but means I have an increasing array of cables that really shouldn’t be plugged into the wrong device, lest I blow something up.
\nSome time ago, I came across a model on MakerWorld for labelling network cables, and I thought I’d give it a go.
\n\n
\nSince the model was designed for network cables (which have a fairly large diameter), it was a little large for my power cables. After a couple of test prints, I found that scaling the model to 70% worked perfectly:
\n\n
\n![](\"/posts/2025-12-25-december-adventure-day-24/cable/400.jpeg\")
\n \nI plan to print a few of these over the coming days for each of the devices I try to keep in daily rotation.
\n\n
\n![](\"/posts/2025-12-25-december-adventure-day-24/sizes/400.jpeg\")
\n \nTrying out different sizes and color combinations
\nFollowing my struggles to photograph my various projects, Sarah treated me to an early Christmas present in the form of a desk tripod from Facebook Marketplace (presumably owned by a lapsed TikToker). The anglepoise mechanism was missing a bolt which was easy enough to fix, and I now have an overhead camera setup:
\n\n
\n![](\"/posts/2025-12-25-december-adventure-day-24/tripod/400.jpeg\")
\n \nThis should unlock both my Libretto 50CT and Series 3a maintenance tasks, and I’m unduly excited about it. I couldn’t resist a quick test to see how well it works:
\n\n
\nContinuing with day 22’s infrastructural focus, day 23 of my (increasingly random) December Adventure brought further thoughts on using Let’s Encrypt SSL certificates, webserver changes, and a side-quest into dnsmasq.
\nOne of the larger inconveniences of running self-hosted infrastructure (beyond the obvious administrative cost and decision fatigue that comes from needing to understand many disparate projects) is the myriad different URLs, ports, and self-signed certificates that you need to interact with: default setups will have you needing to remember IP addresses, along with the various ports numbers different services run on. Coupled with the increasing challenge of coaxing browsers to trust self-signed certificates (especially on mobile), this can make for a deeply frustrating experience. The key to tidying up this mess is to run your own DNS server, specify unique domain names for each service, and then use a reverse proxy to forward on the relevant ports.
\nHaving never set up my own DNS server before, I went about configuring dnsmasq on one of my Raspberry Pis. I had expected the process to be incredibly complex, but, as I don’t need it to do much, everything proved incredibly simple. The config file (/etc/dnsmasq.d/local.conf) ended up looking like this:
# Listen on ethernet and Tailscale.\ninterface=eth0\ninterface=tailscale0\nbind-interfaces\n\n# Ignore local /etc/hosts and /etc/resolv.conf.\nno-hosts\nno-resolv\n\n# Forward unknown requests to Cloudflare.\nserver=1.1.1.1\n\n# Provide responses for home.jbmorley.co.uk and sub-domains.\naddress=/home/jbmorley.co.uk/100.119.64.74\naddress=/immich.home.jbmorley.co.uk/100.119.64.74\naddress=/jellyfin.home.jbmorley.co.uk/100.119.64.74\naddress=/syncthing.home.jbmorley.co.uk/100.119.64.74\nI was able to check this was working locally on my Raspberry Pi by explicitly querying localhost using nslookup:
# nslookup immich.home.jbmorley.co.uk localhost\nServer: localhost\nAddress: ::1#53\n\nName: immich.home.jbmorley.co.uk\nAddress: 100.119.64.74\nThe custom DNS entries all resolve to an IP address on my Tailscale VPN, meaning they should work whenever I’m connected to Tailscale, irrespective of where I am.
\nI was also able to take advantage of Tailscale’s built-in support to automatically route only the DNS queries for the home.jbmorley.co.uk suffix to my DNS server using Split DNS.
\n\n
![](\"/posts/2025-12-25-december-adventure-day-23/nameservers@2x/1600.png\"\n)
\n \nTailscale’s MagicDNS will defer all DNS queries for home.jbmorley.co.uk to 100.126.47.22
The goal of using fully qualified sub-domains for a domain I own (see above) is to allow me to generate SSL certificates that will be accepted by all my devices. For this, I can use Let’s Encrypt with the DNS-01 challenge with Cloudflare that I dug into on day 22.
\nWhile I originally planned to use Caddy to generate certificates, I eventually accepted that I don’t want to have to maintain a custom build outside of the package manager to be able to use the DNS challenge plugins. Instead, I opted to use certbot for this. I generated a certificate for home.jbmorley.co.uk and a wildcard certificate for *.home.jbmorley.co.uk. This ensures I don’t have to generate a new certificate for each and every service I run:
sudo certbot certonly \\\n --dns-cloudflare \\\n --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \\\n -d \"*.home.jbmorley.co.uk\" \\\n -d \"home.jbmorley.co.uk\"\nHaving decided not to use Caddy for SSL, I returned to nginx and set up a handful of sites: a simple static site at home.jbmorley.co.uk which offers links to all my other services, and a collection of reverse proxies.
Some time ago, created a lightweight home page with links to the various services I run. This proved incredibly useful, and has become a crucial part of my home infrastructure:
\n\n\n
![](\"/posts/2025-12-25-december-adventure-day-23/links@2x/1600.png\"\n)
\n \nNeedless to say, the nginx configuration for this proved very simple:
\nserver {\n listen 80;\n server_name home.jbmorley.co.uk links.home.jbmorley.co.uk;\n\n return 301 https://$host$request_uri;\n}\n\nserver {\n listen 443 ssl http2;\n server_name home.jbmorley.co.uk links.home.jbmorley.co.uk;\n\n ssl_certificate /etc/letsencrypt/live/home.jbmorley.co.uk/fullchain.pem;\n ssl_certificate_key /etc/letsencrypt/live/home.jbmorley.co.uk/privkey.pem;\n\n root /var/www/links;\n index index.html;\n\n location / {\n try_files $uri $uri/ =404;\n }\n}\nConfiguring the reverse proxies proved equally simple. For example, my Syncthing proxy looks like this:
\nserver {\n listen 80;\n server_name syncthing.home.jbmorley.co.uk;\n\n return 301 https://$host$request_uri;\n}\n\nserver {\n listen 443 ssl;\n http2 on;\n server_name syncthing.home.jbmorley.co.uk;\n\n ssl_certificate /etc/letsencrypt/live/home.jbmorley.co.uk/fullchain.pem;\n ssl_certificate_key /etc/letsencrypt/live/home.jbmorley.co.uk/privkey.pem;\n\n location / {\n proxy_pass https://127.0.0.1:8384;\n\n proxy_http_version 1.1;\n proxy_set_header Host $host;\n proxy_set_header X-Real-IP $remote_addr;\n proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n proxy_set_header X-Forwarded-Proto https;\n\n # Syncthing uses a self-signed cert by default\n proxy_ssl_verify off;\n }\n}\nThe only notable element here is the proxy_ssl_verify off which ensures nginx will accept the self-signed certificate that Syncthing generates by default.
The day proved significantly more work-like than I’d been hoping for. Still, it’s great to feel like I’m laying the groundwork for future self-hosted infrastructure and tooling.
", "date_published": "2025-12-25T15:25:47-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-25-december-adventure-day-23/", "title": "December Adventure Day 23", "url": "https://jbmorley.co.uk/posts/2025-12-25-december-adventure-day-23/" }, { "content_html": "Having set an intention to wrap up some projects and focus on more retro-related explorations, I immediately found myself distracted by other things on day 22 of my December Adventure: I’ve been thinking a lot about the seemingly bleak future of GitHub and am keen to start experimenting with Forgejo locally with a view to potentially maintaining a self-hosted instance. In preparation for this, I decided to finally try to wrap my head around using Let’s Encrypt to generate SSL certificates on machines that aren’t Internet-facing—something I’d like for self-hosted infrastructure as well as using Cloudflare to proxy my this website. I also started putting together a website for my partner to showcase her art.
\nSome time ago, I switched to using Caddy for hosting this website, projects like Anytime, StatusPanel, and WriteMe, and for local bits of infrastructure. I was sold by the dream of built-in, auto-provisioning SSL using Let’s Encrypt, and it worked well. However, one thing I’ve never taken the time to set up is out-of-band challenges like DNS-01 that allow me to take advantage of things like Cloudflare’s proxy, or generate SSL certificates for private local infrastructure.
\nThe DNS-01 challenge works by writing a DNS TXT record as a proof of ownership. Enabling this in Caddy is a simple matter of specifying the dns cloudflare challenge. For this website, the whole configuration looks like this:
jbmorley.co.uk {\n root * /var/www/jbmorley.co.uk\n encode zstd gzip\n file_server {\n index index.html index.json\n }\n tls {\n dns cloudflare {env.CLOUDFLARE_API_TOKEN}\n }\n}\nAs you would expect from Caddy, this is wonderfully simple, and my hope was that I could use it for both my public services as well as my personal infrastructure, which I would achieve by adding local DNS entries for valid jbmorley.co.uk subdomains. Unfortunately, it turns out the whole thing is significantly more complex: the version of Caddy packaged with Ubuntu doesn’t include any of the DNS challenge plugins and, since Caddy’s plugins are compiled-in, you can’t just install additional package.
I ended up spending much of the day trying to come up with an approach to this, ultimately settling on a community maintained Docker image which builds-in the Cloudflare DNS-01 plugin. My docker-compose.yml for this is as follows:
services:\n caddy:\n image: ghcr.io/caddybuilds/caddy-cloudflare:latest\n restart: unless-stopped\n network_mode: host\n cap_add:\n - NET_ADMIN\n volumes:\n - /etc/caddy:/etc/caddy\n - /var/www:/var/www\n - caddy_data:/data\n - caddy_config:/config\n environment:\n - CLOUDFLARE_API_TOKEN=...\n\nvolumes:\n caddy_data:\n external: true\n caddy_config:\nThis configuration is slightly tweaked from the one in the project README: it specifies network_mode: host to allow Caddy to see host ports provided by other apps and Docker containers, rather than requiring me to manage network interfaces between Docker containers.
While it ‘works’, deploying Caddy like this concerns me as it introduces another component with a security update life cycle independent of the host OS, and exposes a critical part of my infrastructure to third-party management and build infrastructure. With that in mind, although I switched my staging server (which hosts this website) over to this new approach, I decided to sleep on it and take stock in the morning.
\nIn the afternoon, I took some time to work on a lightweight website to allow my partner Sarah to showcase her paintings. This gave me a nice excuse to spend a little more time with Hugo, which I last used to set up the Psion community website.
\n\n\n
![](\"/posts/2025-12-23-december-adventure-day-22/website@2x/1600.png\"\n)
\n \nKeeping things simple, we decided to use a grid for the home page. Iterating over all the pages in a section is easy to do in Hugo templates and, while I still prefer the InContext1 approach to multimedia for more involved sites, it’s great to be able to specify image dimensions directly in templates:
\n{{ define \"main\" }}\n\n {{ .Content }}\n\n <div class=\"gallery-grid\">\n {{ range (where .Site.Pages \"Section\" \"art\") }}\n {{ range .Pages }}\n <div class=\"gallery-item\">\n {{ if .Params.thumbnail }}\n {{ $image := .Resources.Get .Params.thumbnail }}\n <a href=\"{{ .RelPermalink }}\">\n <img src=\"{{ ($image.Fit \"600x600\").RelPermalink }}\" alt=\"{{ .Title }}\" title=\"{{ .Title }}\">\n </a>\n {{ else }}\n Missing Thumbnail\n {{ end }}\n </div>\n {{ end }}\n {{ end }}\n </div>\n\n{{ end }}\nThis template iterates over all the top-level pages in the ‘art’ section and, for each page, generates a thumbnail matching the one specified in the that page’s Frontmatter. I was briefly caught out by Hugo’s need to differentiate between branch and leaf pages / bundles (branches should be called _index.md, and leaves index.md), but I got there in the end. The corresponding directory structure looks like:
content\n├── _index.md\n├── about\n│ └── index.md\n├── art\n│ ├── _index.md\n│ ├── basil-and-maverick\n│ │ ├── basmav.png\n│ │ └── index.md\n│ ├── kale-flower\n│ │ ├── index.md\n│ │ └── preview.jpg\n│ ├── manu-o-ku\n│ │ ├── index.md\n│ │ └── manuoku.png\n│ ├── na-pali\n│ │ ├── index.md\n│ │ └── na-pali.png\n│ ├── passion-orange-guava\n│ │ ├── index.md\n│ │ └── pog.png\n│ └── red-flower\n│ ├── index.md\n│ └── preview.jpg\n└── contact\n └── index.md\nWith this this template in place, it’s now a matter of slowly fleshing the content out and cleaning up the layout. We’re going to have to be especially careful when generating preview images as paintings can look incredibly flat with the wrong color profiles. I’ve also noticed that some of the built-in macOS apps aren’t able to correctly render the high-resolution TIFF scans we have.
\nMy personal static site builder. ↩
Day 21 brought very little progress with my December Adventure. Instead, I took the time to finish playing ‘The Drifter’, an incredibly well executed modern point and click adventure. I strongly recommend it if you enjoy such things.
\n\n
\n![](\"/posts/2025-12-22-december-adventure-day-21/the-drifter/400.png\")
\n \nI reflected more on my December Adventure ‘progress’ and the slightly daunting list of ideas I have remaining. I think that, rather than starting new things, I’d like to wrap up some of the ideas I’ve worked on this month, and take a few days for more open-ended retro-related play and exploration. My partner would also like some help making a website for selling her art, so expect a few side-quests in that direction as well.
", "date_published": "2025-12-22T11:16:17-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-22-december-adventure-day-21/", "title": "December Adventure Day 21", "url": "https://jbmorley.co.uk/posts/2025-12-22-december-adventure-day-21/" }, { "content_html": "Day 20 didn’t afford me much time to work on my December Adventure, so I thought it might be a good opportunity to take stock, and do a little housekeeping.
\nSince I’m two-thirds of the way through the month, I wanted to see which of my initial ideas remain. In the last 20 days, I’ve taken a crack at:
\nI also distracted myself into a few bits of 3D design and printing that weren’t on the list:
\n \nI even started to create a Psion-focused launcher for MAME.
\nThis leaves me with:
\n(It’s good know that I’m not going to run out any time soon.)
\nWhile the fairly random nature of the Organiser II lucky dip I’ve relied on for much of my adventuring has been enjoyable, that’s a fairly long list and I’d like to be a little more deliberate in the coming days—I don’t anticipate quite so much spare time as we move into the holidays themselves and I’d like to make it count. This list will serve as inspiration, but I’ll be more directed in what I choose.
\nThat said, I’m also going to add one more thing to the list: I had a really fun conversation with Tomsci about how we approach EPOC16 support in OpoLua, during which we decided to look into auto-generating EPOC32-era Psion install (SIS) files for use on EPOC16 devices. We aim to do this as part of the Psion Software Index indexing process, meaning that these new installers will be available for anyone to use, in OpoLua, Reconnect, or other tooling. I’d love to start planning this out.
\nDuring the process of documenting my Organiser II icon designs, I found myself writing a little Python script (which I’ve dubbed gridify) to enlarge pixel art images and add grid lines. The script is tiny but, in the interests of sharing, I’ve uploaded it to Codeberg and assigned an MIT license.
Gridify lets you generate previews like this:
\n\n\n
![](\"/posts/2025-12-21-december-adventure-day-20/icons-large/1600.png\"\n){kind=icon}
\n \nThinking more about the announced GitHub pricing changes for self-hosted Actions runners, I wonder if a tiny project like this might be a perfect excuse to try out CI alternatives. While GitHub have flip-flopped on this, announcing that they’re delaying the planned per-minute metered pricing for using self-hosted runners, the writing’s on the wall, and I need to find an approach that’s more sustainable.
", "date_published": "2025-12-21T19:58:59-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-21-december-adventure-day-20/", "title": "December Adventure Day 20", "url": "https://jbmorley.co.uk/posts/2025-12-21-december-adventure-day-20/" }, { "content_html": "I woke up on day 19 of my December Adventure feeling that I’ve not used my Psions nearly enough in the past week: while I’ve been doing many Psion adjacent things with OpoLua and PsiEmu, I’ve not taken the time to sit down and tinker with the devices that inspire my adventuring and serve as enjoyably disconnected tools. With that in mind, I decided to tackle the first item in the Organiser II lucky dip and, ‘improve the Ideas UX’.
\n\n
\n![](\"/posts/2025-12-20-december-adventure-day-19/prompt/400.jpeg\")
\n \nEver since reading about the Organiser II’s OPL support for user-defined characters, I’ve been keen to try it out and replicate the classic menu screen that the built-in programs provide.
\n\n
\n![](\"/posts/2025-12-20-december-adventure-day-19/home/400.jpeg\")
\n \nOrganiser II LZ home and app menus are a scrollable grid of options with a title bar containing an icon and clock
\nOrganiser II icons are 5px by 8px, and loaded as a sequence of 8 bytes using the UDG command. For example, the following character is written to user-defined character 1 with UDG 1,30,14,4,14,30,14,11,25.
\n\n
![](\"/posts/2025-12-20-december-adventure-day-19/udg/1600.gif\"\n)
\n \nThere’s one additional constraint when creating icons for the title bar: the bottom two-rows of pixels are taken up with the underline, meaning that the icons themselves can only be 5px by 6px.
\nArmed with this information, I spent an enjoyable analog hour-or-so experimenting with icons:
\n\n
\n![](\"/posts/2025-12-20-december-adventure-day-19/sketch/400.jpeg\")
\n \nGiven the restrictions, I’m pretty pleased with what I came up with. I’m particularly fond of the following ones:
\n\n\n
![](\"/posts/2025-12-20-december-adventure-day-19/icons-large/1600.png\"\n){kind=icon}
\n \nThe lightbulb—an early design—remains my favorite for the ideas app, so I set about writing the top-level menu picker. Thankfully, as with OPL on later Psions, there’s a lot of conveniences for producing standard UI and it’s easy to replicate the menu screen with a combination of UDG, CLOCK, and MENUN:
menu::\nCLS\nUDG 0,14,17,21,14,10,4,0,31\nUDG 2,0,0,0,0,0,0,0,31\nPRINT CHR$(0);REPT$(CHR$(2),14)\nCLOCK(1)\nm%=MENUN(2,\"New,View,Random\")\nIF m%=0\n GOTO quit::\nELSEIF m%=1\n GOTO new::\nELSEIF m%=2\n GOTO show::\nELSE m%=3\n GOTO rand::\nENDIF\nIn the process of updating the program, I kept hitting up against an out of memory error on my Organiser II. It turns out the internal drive is drive ‘A’ and not drive ‘C’ as one might expect of DOS and Windows era computers—I’ve been happily writing to (and filling up) my write-once 64k datapak for the past couple of weeks. Time to get a datapak formatter. 🤦
\n\n
\n![](\"/posts/2025-12-20-december-adventure-day-19/complete/400.jpeg\")
\n \nWhile the ordering of menu items could be better, I’m pretty pleased with the outcome. 💡
\n\n
\n![](\"/posts/2025-12-20-december-adventure-day-19/advent-of-beeb/400.jpeg\")
\n \nEnjoying Colin’s Advent of Beeb while designing Organiser II icons—heaven!
", "date_published": "2025-12-20T13:52:25-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-20-december-adventure-day-19/", "title": "December Adventure Day 19", "url": "https://jbmorley.co.uk/posts/2025-12-20-december-adventure-day-19/" }, { "content_html": "My December Adventure took a complete backseat on day 18 as I continued setting up my new home infrastructure—the continued decay of GitHub and other cloud-based services makes this a priority.
\nWhile it took much of the day, I managed to install Ubuntu server, set up 12TB of ZFS RAIDz1 storage, install Syncthing, and kick-off an initial sync. With that done, I’m in a good position to slowly tick away at the remaining tasks, and explore the additional services I can run. (I’m keen to look at self-hosted SCM and CI in the future, but that’s definitely one for another day.)
\nI hope to return to adventuring on day 19, but I’d certainly like to find some time to write more about my various efforts to move away from Big Tech—I’m pretty pleased with the workflows I’ve established over the last few years and I’d love to share some of that1.
\nThe list of December Adventure ideas includes, ‘write up my read later strategy’, which is peripherally related, so there’s still a chance I’ll do a little of that this month. ↩
Keen to get psiemu1, my lightweight launcher for Psion MAME emulators into a usable state, I decided to push on with it on day 17 of my (somewhat Psion themed) December Adventure.
\n\n
\n![](\"/posts/2025-12-19-december-adventure-day-17/overview@2x/400.png\")
\n \nMy goal with PsiEmu is to create a relatively self-contained solution for getting started with the Psion emulators built into MAME (and maybe even some other emulators in the future). To do this, it should be able to fetch ROMs on your behalf, offer conveniences for managing settings specific to Psion emulation (mounting SSDs, configuring serial ports, etc), and have ‘sandboxed’ settings and data directories—it shouldn’t break existing MAME configurations. I really want PsiEmu to be a one-stop shop that makes Psion emulation significantly more accessible.
\nI ended up spending much of the morning talking through this approach with Alex who was initially expecting to use PsiEmu as a MAME command-line generator, manually adding options for things like serial port configuration. This user experience would be far more complex than I’d like, and the discussion proved incredibly helpful, allowing me to better understand just how important those extra options are, while also giving me a chance to share my goals and have Alex help guide the design. For example, it’s clear that having psiemu remain resident to allow emulators to be quickly relaunched is key to software development workflows; as is being able to quickly tweak settings like serial port configurations.
In addition to the various configuration options, I’d also like to add some built-in guides: MAME can be pretty opaque at times, and things like keyboard shortcuts for Psion-specific hardware keys vary subtly from device-to-device. I imagine a per-device ‘info card’, as well as an app-wide help (akin to the built-in help on Psions themselves). This seemed like a perfect minimal case study to try out ‘windowing’ in Curses, so I knocked something up:
\n\n
\n![](\"/posts/2025-12-19-december-adventure-day-17/scrolling@2x/400.gif\")
\n \nThis makes use of ‘pads’ which are Curses' primitive for scrollviews. They’re not the easiest thing to work with, but they allow for an optimized or naive approach to scrolling and will be incredibly useful as the list of emulators grows and I start adding things like lists of settings.
\nI also added a handful of additional emulator configurations: Dutch and French Series 3mx variants, and a French Siena. I also experimented with adding an Organiser II which I’m not ready to commit yet.
\n\n
\n![](\"/posts/2025-12-19-december-adventure-day-17/lincstation/400.jpeg\")
\n \nMy afternoon proved somewhat distracted as I received delivery of a LincStation N2 and took some time to try it out. This will be serve as a (hopefully more robust) replacement for a Raspberry Pi 5 that has been acting as my local Syncthing node and home-infrastructure for the past year-or-so.
\nOr should that be ‘PsiEmu’? ↩
Having made good progress writing a lightweight Psion emulator launcher on day 15 of my December Adventure, I decided to continue with it, flesh out the device support, and add a few quality-of-life improvements.
\nAs an active contributor to the explit28/Psion-ROM repository on GitHub, I’m aware of the large number of Psion variants out there, but I’d not fully internalized it until I tried to produce a UI to make it quick and easy to see them all, and select one.
\nAfter some consideration, I decided to separate the different vendors into their own sections, with Psion and Acorn being the most obvious ones. Ultimately, I’d like to add Geofox, Diamond, Oregon Scientific and Ericsson in there too, but I don’t think we’ve complete emulation for any of their devices yet.
\n\n
\n![](\"/posts/2025-12-17-december-adventure-day-16/vendors@2x/400.gif\")
\n \nModeling the ‘Vendor → Device → Variant’ hierarchy
\nIntroducing new sections forced me to rework the layout and selection handling. To keep things simple, I broke my rendering code into helpers responsible for the different sections. For example,
\ndef render_device_section(devices, is_section_active, y_pos, selection):\n\n for device_index, profile in enumerate(devices):\n title = profile[\"title\"].ljust(22)\n variants = profile[\"variants\"]\n\n for variant_index, variant in enumerate(variants):\n name = variant[\"name\"]\n languages = language_symbol(variant)\n if is_section_active and device_index == selection.device and variant_index == selection.variant:\n name = \"-> \" + name\n else:\n name = \" \" + name\n title += f\"{name} {languages} \"\n\n stdscr.addstr(y_pos + device_index, 0, \" \" + title)\n\n return y_pos + len(devices)\nThis renders vendor data in the following structure:
\n {\n \"name\": \"Acorn\",\n \"devices\": [\n\n {\n \"id\": \"pocketbk\",\n \"title\": \"Acorn Pocket Book\",\n \"resolution\": (240, 80),\n \"scale\": 2,\n \"variants\": [\n {\n \"name\": \"V1.91F\",\n \"bios\": \"191f\",\n \"languages\": [\n \"en-GB\",\n ],\n }\n ]\n },\n\n # ...\n \n ],\n },\nRight now the layout code is all hand-crafted as I’m fairly new to Curses, but I have a sense there are many conveniences I can take advantage of in the future. I’m looking forward to learning what’s possible.
\nIn addition to adding support for different vendors, I decided to lean more on structured data, starting with supported languages (as shown in the example above). Using metadata like this should allow for richer UI in the future, and I experimented with using emoji as a minimal way to display the languages:
\n\n
\n![](\"/posts/2025-12-17-december-adventure-day-16/languages@2x/400.gif\")
\n \nUltimately, I find the additional color distracts me from the other details in the grid, so I’ve decided not to keep them, but I enjoyed seeing what’s possible.
\nAs I progressed through the day, I added more devices and variants to the launcher, making sure the relevant ROMs were present in the explit28/Psion-ROM repository. My hope is that this can serve as a single source for all preserved Psion and Psion-related firmware. The MAME emulators are a good test for that.
\nWrapping up, I created a new repository on Codeberg and pushed what I have. Nascent as it is, it’s nice to get the launcher to a point where I’m happy to share it and invite collaboration.
\n\n
\n![](\"/posts/2025-12-17-december-adventure-day-16/screenshot-alex/400.png\")
\n \nThe day ended on a high when Alex shared a screenshot of it running. 🥳
", "date_published": "2025-12-17T11:19:13-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-17-december-adventure-day-16/", "title": "December Adventure Day 16", "url": "https://jbmorley.co.uk/posts/2025-12-17-december-adventure-day-16/" }, { "content_html": "Day 15 of my December Adventure started with a request from Tom for some Psion Series 3 assets for OpoLua. Since I don’t have a Series 3 to hand here in Hawai'i, this seemed like the perfect excuse to remind myself how to fire-up an emulator using MAME and focus on, ‘write about MAME emulation’, from my original list of adventuring possibilities.
\n\n\n
![](\"/posts/2025-12-16-december-adventure-day-15/series3a@2x/1600.png\"\n)
\n \nMAME includes many Psion hardware and language variants
\nThe Psion emulation story in MAME is really impressive, but I don’t find the MAME launcher works well for standalone computers—it’s really designed for launching individual games. Instead, I run specific emulators from the command line. For example, I launch the Series 3a emulator as follows:
\nmame \\\n -window \\\n -nomaximize \\\n -skip_gameinfo \\\n -rompath ~/Software/Psion/ROMs \\\n -prescale 2 \\\n -resolution 960x320 \\\n psion3a\nThere’s a few notable options in there which—in my opinion—really help the Psion emulation shine:
\n-skip_ganeminfo—don’t show unnecessary dialogs-nomaximize—run in windowed mode—I prefer this as the Psions have fairly unusual aspect resolutions-prescale 2—enable pixel-doubling for high-resolution displays-resolution 960x320—coupled with pixel-doubling, this ensures the emulation displays at exactly 2x for crisp pixelsThere’s also some useful keyboard shortcuts to be aware of. These vary from device to device. For the Series 3a, they look like this:
\n| Device Key | \nShortcut | \n
|---|---|
| On (Esc) | \nEsc | \n
| Off (Psion + Esc) | \nAlt (Opt on macOS) + 1 | \n
| Psion | \nAlt (Opt on macOS) | \n
| Help | \nF10 | \n
| Menu | \nF11 (Shift + F11 on macOS) | \n
| System | \nF1 | \n
| Data | \nF2 | \n
| Word | \nF3 | \n
| Agenda | \nF4 | \n
| Time | \nF5 | \n
| World | \nF6 | \n
| Calc | \nF7 | \n
| Sheet | \nF8 | \n
Needless to say, I find myself looking up the MAME command line and keyboard shortcuts every time I need to use an emulator. I’ve written a number of shell scripts and aliases to help1, but there are so many device variants that this approach gets unwieldy pretty. Finding ROMs can also be challenging—most are available in explit28/Psion-ROM where we’re trying to dump, document, and preserve everything we can find, but it’s currently incomplete.
\nWith that in mind, I decided to finally bite the bullet and start writing my own launcher. The goal here is to clearly present all the different device types and variants to help folks see what’s available. I’d also like to add support for automatically downloading ROMs in the future.
\n\n
\n![](\"/posts/2025-12-16-december-adventure-day-15/preview/400.gif\")
\n \nI’m using Python and Curses to create this to ensure I’ve something instantly cross-platform, as I know most of the Psion community choose to use Linux.
\nIt’s been a really fun experience so far, playing around with writing an interactive terminal UI and seeing future possibilities. I’ve opted for a grid-layout to show devices and variants2, and I’ve realized I can add contextual footers showing additional device details and, ultimately, interactive pickers for configuring attached SSDs, serial ports, etc.
\nI hope to publish this nascent launcher over the coming days. 🚀
\nIf you’re using Linux, you can also create desktop entries for quickly launching each Psion emulators. ↩
For example, to create a local Series 3a desktop entry, create .local/share/applications/psion-series-3a.desktop containing something like:
[Desktop Entry]\n\n Type=Application\n Version=1.0\n Name=Psion Series 3a\n Path=/home/parallels\n Exec=/usr/bin/mame -window -nomaximize -skip_gameinfo -rompath /home/parallels/Software/Psion/ROMs -prescale 2 -resolution 960x320 psion3a\n Terminal=false\nPerhaps I was influenced by Matt Sephton’s notes on using spreadsheets for UI design. ↩
I’m trying to stick to daily write-ups of my December Adventure, meaning that I write about the less exciting days, as well as the more exciting ones. Day 14 falls firmly in latter camp.
\nI had hoped to hit the ground running by reinforcing the hinges of my Psion Series 3a with JB Weld, and later carefully opening my Toshiba Libretto 50CTs to remove their (hopefully non-leaky) backup batteries. Instead day 13’s write-up proved a slow one, and then I found myself trapped, deliberating how to photograph and film these tasks so I can document them.
\nI have been experimenting with a (very flimsy) lightweight tripod and my iPhone to capture top-down photos with very little success: the camera slowly sinks as the tripod really isn’t designed for this orientation; it’s hard to get good lighting; and the iPhone’s automatic exposure and magic colour-correction means images vary wildly. It’s also hard to keep the whole plane in focus when doing closeup work. (This really isn’t my area of expertise.)
\n\n
\n![](\"/posts/2025-12-15-december-adventure-day-14/psiboard-black/400.jpeg\")
\n \n\n
\n![](\"/posts/2025-12-15-december-adventure-day-14/psiboard-yellow/400.jpeg\")
\n \nThe iPhone makes it incredibly challenging to maintain consistent exposure and color temperature
\nAs I find myself working more and more on physical projects, I’d love to come up with a setup that I don’t need to think about. I plan to try Halide over the next few days in the hope that this will give me more control, and I’ve been noodling on a seemingly TikTok-focused tripod that’s essentially an anglepoise arm with a phone mount and ring light. Perhaps I can get into retro unboxings. 📦🙃
\n\n
\n![](\"/posts/2025-12-15-december-adventure-day-14/desk-tripod/400.jpeg\")
\n \nAmazon—🤢—sells near-identical social media ‘desk tripods’ by a seemingly infinite number of brands
", "date_published": "2025-12-15T12:18:23-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-15-december-adventure-day-14/", "title": "December Adventure Day 14", "url": "https://jbmorley.co.uk/posts/2025-12-15-december-adventure-day-14/" }, { "content_html": "Having spent much of the past week of my December Adventure working on OpoLua, I decided it was time for a change. I again consulted the Organiser II lucky dip, which called for, ‘Series 3a hinge replacement’.
\n\n
\n![](\"/posts/2025-12-14-december-adventure-day-13/prompt/400.jpeg\")
\n \nWhile this prompt is slightly incorrect (it should read ‘reinforcement’), it was nice to have something come up that isn’t purely software; a perfect change of pace for the weekend. There’s something incredibly cathartic and soothing about the process of maintenance, and I immediately found myself thinking of other tasks I’d also like to get to: I need to check the batteries in my Libretto 50CTs, finally get my Greaseweazle working, and tidy up my home rack a little.
\nWhile some readers will be disappointed that I didn’t immediately break out the JB Weld and launch into reinforcing my Series 3a’s hinges, I decided to pace myself and approach a few of these tasks over the course of the weekend, picking whichever spoke to me in the moment.
\nLike many folks who play around with retro hardware, I picked up a Greaseweazle some time ago to allow me to read whatever floppy disks I encounter in my travels. And (I suspect), like many, my Greaseweazle has been sitting in a box since I got it: I managed to buy a 3 ½" floppy drive, but failed to pick up any cables, and certainly didn’t start looking for a case.
\nSince I can’t do much with it until I have the appropriate cables, I ordered a power cable and floppy drive ribbon cable, and set about looking for a case to print. While I usually design parts for myself, I wanted to try a community design this time and, after some browsing, I selected this design by Dekkia, remixed from this one for earlier Greazeweazle models.
\n\n
\n![](\"/posts/2025-12-14-december-adventure-day-13/bottom/400.jpeg\")
\n \nThe case, designed in OpenSCAD, prints in two halves and ended up being a pretty good color match for my floppy drive, when printed using Bambu Labs’s Matte Bone White filament.
\nI regret not noticing that the design had been modified to remove the threaded inserts from the original, but thankfully I was able to drill out the holes and fit some I had lying around—the goal was not to produce something perfect, but something that helps me get the Greaseweazle up and running.
\n\n
\n![](\"/posts/2025-12-14-december-adventure-day-13/inserts/400.jpeg\")
\n \nThe top case with threaded inserts installed
\nWith the threaded inserts installed, it was just a matter of screwing everything together and waiting for the cables to turn up.
\n\n
\n![](\"/posts/2025-12-14-december-adventure-day-13/complete/400.jpeg\")
\n \nI have a small home 4U rack that hosts—amongst other things—my Raspberry Pis in a UCTRONICS 1U rack bracket. This holds up to 4 Raspberry Pis on individual sleds:
\n\n
\n![](\"/posts/2025-12-14-december-adventure-day-13/sled/400.jpeg\")
\n \nSince I only need to use two of the sleds, I decided to replace the other ones with custom keystone-compatible blanking plates to allow me to manage the ethernet and USB cabling within this single 1U of space, obviating the need for a separate patch panel. I designed the prerequisite part, printed, and fitted it.
\n\n
\n![](\"/posts/2025-12-14-december-adventure-day-13/panel/400.jpeg\")
\n \nWith these new mini patch panels in place (one serving each Pi), I now have a whole 1U of space to play around with for more adventures in the future.
\n\n
\n![](\"/posts/2025-12-14-december-adventure-day-13/rack/400.jpeg\")
\n \nI hope to publish these designs over the next few weeks. If you’re excited to get hold of them before then, please feel free to get in touch.
\nI couldn’t get through the day without making a couple of tweaks to OpoLua: I renamed the macOS Qt builds to ‘OpoLua Qt.app’ to allow them to live side-by-side with the Mac Catalyst versions, and I switched to using a pre-built version of Qt which cuts build times by about 55 minutes. 🏎️
", "date_published": "2025-12-14T16:42:16-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-14-december-adventure-day-13/", "title": "December Adventure Day 13", "url": "https://jbmorley.co.uk/posts/2025-12-14-december-adventure-day-13/" }, { "content_html": "Continuing with Day 12 of my December Adventure, I decided to make the most of the little momentum I’ve built up around OpoLua over the past few days and continue working on Qt builds.
\nI had an outstanding branch with macOS Qt builds from the early days of development, so I cautiously cherry-picked the relevant changes to see if it still built. Much to my surprise, it did! I followed my usual pragmatic approach of hand-crafting a simple build script rather than trying to use any magic tooling; something I have found to be significantly more maintainable over the lifetime of a project. You can check out the full change here if you’re curious.
\nAt this early stage, I’m making no attempt to publish the binaries—we need to update the OpoLua license to conform to Qt’s requirements around statically linking before we can do that. For the time being this will help give us greater confidence that we’re not breaking things, and allow us to test our work.
\nHaving broken the back of—at least—the macOS Qt builds, I found my thoughts returning to the incredibly absurd and unsustainable situation we’ve found ourselves in: centralized web-based infrastructure, lock-in, spiralling service prices, aggressive deployment of unproven AI, inflation, and skyrocketing consumer hardware prices. These trends concern me, and I’m worried that, even though I try to build open tooling, by targeting closed platforms like macOS and iOS, I play a part in perpetuating this imbalance.
", "date_published": "2025-12-13T13:15:41-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-13-december-adventure-day-12/", "title": "December Adventure Day 12", "url": "https://jbmorley.co.uk/posts/2025-12-13-december-adventure-day-12/" }, { "content_html": "
It's altogether too easy to forget the beautiful world we have on our doorstep here in Hawai'i.
", "date_published": "2025-12-12T18:02:54-08:00", "id": "https://jbmorley.co.uk/photos/snapshots/2025-12-12-18-02-54-sunset/", "title": "Sunset", "url": "https://jbmorley.co.uk/photos/snapshots/2025-12-12-18-02-54-sunset/" }, { "content_html": "Day 11 of my December Adventure proved another slow one, in spite of the Organiser lucky dip demanding that I yet again return to OpoLua to, ‘ship OpoLua Qt’.
\n\n
\n![](\"/posts/2025-12-12-december-adventure-day-11/prompt/400.jpeg\")
\n \nThe day got off to a good start with Apple approving the macOS Catalyst build. This is now available to download from the Mac App Store. 🥳
\n\n\n
![](\"/posts/2025-12-12-december-adventure-day-11/software-index@2x/1600.png\"\n)
\n \nDiscovering OPL programs is easy using the built-in Software Index
\nShipping the new Qt version of OpoLua is something I’ve been wanting to do for some months now—it brings a comprehensive suite of command line tools and the OPL runtime to Linux, Windows, and macOS, and it’s about time we get it out there.
\nI ended up spending the day doing the kind of boring project administration that is pretty thankless in the moment, but makes many things easier going forwards. The primary change was to move the iOS app into its own subdirectory, making the Qt and iOS targets peers in the source code. I also took a moment to update the app icon on the website to use the original EPOC32 OPL icon—this makes things a little less Apple-centric and, over time, I’ll make more changes to make room for the Qt app1.
\n\n
\n![](\"/posts/2025-12-12-december-adventure-day-11/icon/1600.png\"){kind=icon}
\n \nThis early OPL icon now feels far more suitable
\nWith some of the preparatory work for OpoLua Qt in place, I hope day 12 will bring more visible progress: I’d love to have automated Mac, Windows, and Linux builds in the next few days even if, in the first instance, they’re just smoke test builds to ensure we can’t break things.
\nFreed from the restrictions of iOS and mobile application UX, the Qt version of OpoLua works quite differently to the iOS app, eschewing the centralised program library. This means we’ll have to provide distinct documentation, screenshots, and support sections on the website. ↩
Day 10 brought a much needed pause in my adventuring to catch up on other aspects of life, with a couple of exceptions:
\nHaving submitted version 2.0.0 of OpoLua to the App Store during day 8 of my December Adventure, I braced myself for the inevitable rejection, and set about having a somewhat slower day. Much to my surprise, it was approved! Find it here. 🎉
\nSpurred on by this unexpected win, I generated screenshots for the macOS build, submitted it to the Mac App Store, and did a little project housekeeping.
\n\n
\n![](\"/posts/2025-12-10-december-adventure-day-09/mac@2x/400.png\")
\n \nThe Welcome example program running on macOS
\nVersion 2 brings a dedicated macOS Catalyst build, allowing us to better target Mac-specific behaviour. Longer term, I anticipate we’ll replace this with the Qt build, but there’s a lot of work to do before that happens.
\nWith a little more confidence that OpoLua still passes App Review guidelines, I took some time to try out Icon Composer and create icons that will hopefully play better with Liquid Glass—Apple apply a bunch of heuristics to generate icons if you don’t provide your own, so doing this me much greater control over how things appear. This updated icon isn’t shipping in 2.0.0, but it’s ready and waiting for the next point release.
\n\n\n
![](\"/posts/2025-12-10-december-adventure-day-09/icon-composer@2x/1600.png\"\n){kind=icon}
\n \nIcon Composer lets you specify how icons appear in all display styles
\nI also took a little time to give the Revo some love: Fabrice (who’s been rigorously testing OpoLua throughout our development process) noticed that the toolbar doesn’t display correctly, so I grabbed a few example screenshots and Revo-specific resource files to help us improve our support.
\n\n
\n![](\"/posts/2025-12-10-december-adventure-day-09/mbornes-revo/400.png\")
\n \nOne of the possible prompts I set myself myself for my December Adventure was to, ‘write about my 3D printed brackets’. While that day’s yet to come, I did take a little time to revisit my MagSafe bracket to obviate the need for screws and thermal inserts, and make it printable without supports.
\n\n\n
![](\"/posts/2025-12-10-december-adventure-day-09/print@2x/1600.png\"\n)
\n \nI’m pretty pleased with the outcome:
\n\n
\n![](\"/posts/2025-12-10-december-adventure-day-09/magsafe/400.jpeg\")
\n \nFor day 10, I plan to return to the Organiser II lucky dip and am hopeful of a little more retro spelunking—I’ve got my fingers crossed for GlobalTalk.
", "date_published": "2025-12-10T10:28:56-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-10-december-adventure-day-09/", "title": "December Adventure Day 09", "url": "https://jbmorley.co.uk/posts/2025-12-10-december-adventure-day-09/" }, { "content_html": "Day 8 continues the ‘ship OpoLua’ portion of my December Adventure. Since I’m already three days into this (and since I detailed absolutely every one of day 7’s changes), I’m going to keep this write-up brief, with links to the relevant PRs on GitHub for the curious.
\nI put the last few changes in place in preparation for submitting to App Store Review:
\nMost of these were small legacy bug fixes, or final bits of polish to the new Software Index views. Perhaps the only one that really warrants comment is the change relating to drag gestures: iOS 26 has introduced a new navigation stack pop gesture recognizer (.interactiveContentPopGestureRecognizer) which now helpfully steals left-to-right drag gestures from anywhere in your views, and needed to be disabled.
With these changes in-place, I updated the iPhone and iPad screenshots and submitted the iOS build to Apple for review. I’ll follow up with the macOS build if everything goes smoothly. 🤞
\n\n\n
![](\"/posts/2025-12-08-december-adventure-day-08/tile-fall@2x/1600.png\"\n)
\n \nTile Fall running in OpoLua on the iPad Pro 11"
\nHaving had a fairly intense few days getting OpoLua ready for submission, I took advantage of the wait to catch up on my RSS feeds, and other aspects of life. A friend also reminded me that, for my own well-being, it’s important to focus on things that help me feel like I’m really getting to exercise my various engineering skills—something which catching up to new Apple SDKs does not—so I’m going to reflect on that over the coming days.
", "date_published": "2025-12-09T00:49:53-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-08-december-adventure-day-08/", "title": "December Adventure Day 08", "url": "https://jbmorley.co.uk/posts/2025-12-08-december-adventure-day-08/" }, { "content_html": "Keen to preserve the momentum from day 6 of my December Adventure, I decided to continue working on OpoLua—I’d really like to ship version 2 before the month is over.
\nWhile it doesn’t make for the most exciting write-up, I pressed on, polishing the Psion Software Index browser, and ironing out all the little wrinkles introduced by iOS 26 and the new SDK. For the curious, I’ve detailed some of the changes in the following sections.
\nWith the introduction of the Software Index browser, there are now three different ways to get software into OpoLua: adding a folder to the sidebar, opening a standalone SIS (installer) file, and downloading a program from the Software Index. To try to better differentiate these flows, I switched to a plus-badged folder symbol for adding folders to the library, and moved the installer and Software Index flows to a menu in the main programs view. My hope is that by associating the actions with particular views, users will have an improved context for understanding the operations.
\n\n\n
![](\"/posts/2025-12-07-december-adventure-day-07/library@3x/1600.png\"\n)
\n \nThe Library view now boasts an add folder button
\n\n\n
![](\"/posts/2025-12-07-december-adventure-day-07/install-menu@3x/1600.png\"\n)
\n \nTapping the plus button in programs views shows an install menu
\nThankfully I’d already implemented most of the Software Index browser as part of the work to add it to Reconnect, my modern Psion plptools-based connectivity suite for macOS. This left a few remaining tasks:
\nThese proved relatively simple, with the exception of using a monospaced font, which necessitated a custom View extension as the .monospaced modifier isn’t available prior to iOS 16 (OpoLua targets iOS 15):
struct Monospaced: ViewModifier {\n\n @Environment(\\.font) var font\n\n func body(content: Content) -> some View {\n if #available(macOS 13.0, iOS 16.0, *) {\n return content\n .monospaced()\n } else {\n return content\n .font((font ?? .body).monospaced())\n }\n }\n}\n\nextension View {\n\n func monospacedCompat() -> some View {\n return modifier(Monospaced())\n }\n\n}\nI updated the corner radii of the in-program soft silkscreen buttons—it turns out these were picking up the new metrics on iOS 26 and clipping the symbols.
\n\n\n
![](\"/posts/2025-12-07-december-adventure-day-07/silkscreen@3x/1600.png\"\n)
\n \niOS 26 wants to round absolutely everything
\niOS 26 has all-but entirely moved away from buttons with text: ‘Done’, ‘Save’, and ‘Cancel’ buttons have all been replaced by xmarks and checkmarks. Unfortunately folks using older versions of iOS still (rightly) expect the older behaviour, necessitating conditional code like this:
\nToolbarItem(placement: .confirmationAction) {\n Button {\n dismiss()\n } label: {\n if #available(iOS 26, *) {\n Image(systemName: \"xmark\")\n } else {\n Text(\"Done\")\n }\n }\n}\nThe Settings, Installer, and Software Index views all needed updating in subtly different ways as we use a combination of UIKit and SwiftUI depending on the specific needs of each view and view controller.
\n\n\n
![](\"/posts/2025-12-07-december-adventure-day-07/settings@3x/1600.png\"\n)
\n \nThe Settings view boasting a new symbolic dismiss button
\nWhile this kind of seemingly simple design language should make things easier, selecting the correct symbol and button type continues to require altogether too much deliberation: platform-provided semantic confirmation buttons on iOS 26 use a checkmark and are tinted making them far too prominent for most scenarios, often forcing me to override the platform defaults.
\nContinuing with the trend of replacing text with icons, swipe actions now use symbols, and the swipe action for removing library folders needed updating accordingly.
\n\n\n
![](\"/posts/2025-12-07-december-adventure-day-07/remove-folder@3x/1600.png\"\n)
\n \nNothing is safe from the iOS 26 redesign
\nWith all these changes in place, I’m left with perhaps another day of things to do before I can submit to the App Store:
\nDays like this are hard: I always find this process of adopting new Apple SDKs and UIs incredibly gruelling—a constant process of firefighting and decision fatigue that leaves me with very little room to apply the kind of slow, considered design I’d like to bring to my apps. I find myself uncertain of my own work, wondering if I need to look to other platforms in the future.
\nThat said, I’m excited to be moving towards shipping OpoLua. If you’d like to try out the latest TestFlight build, please drop me an email at support@opolua.org.
\nSeeking a moment of respite, I looked into trying out a few more games on my Organsier II, only to find that many need to be written to ROMs to work. As I’ve only a single 64k datapak, I immediately found myself on eBay looking for some, and possibly nerd-sniped myself into building modern storage solutions. Pursuits for another day…
", "date_published": "2025-12-07T22:54:29-08:00", "id": "https://jbmorley.co.uk/posts/2025-12-07-december-adventure-day-07/", "title": "December Adventure Day 07", "url": "https://jbmorley.co.uk/posts/2025-12-07-december-adventure-day-07/" }, { "content_html": "Day 6 of my December Adventure started with a slew of GitHub notifications from Tom, who’s been working on yet more fixes for OpoLua and, as if by fate, my Organiser II lucky dip instructed me to, ‘Ship OpoLua 2.0 for iOS’. Who am I to argue? 🤷
\n\n
\n![](\"/posts/2025-12-07-december-adventure-day-06/prompt/400.jpeg\")
\n \nIt’s been over a year since we last shipped version 1.1.2 of OpoLua and, in that time, Tom’s added database support and a myriad fixes, allowing us to run many new programs. We’ve also added support for browsing and installing from the Psion Software Index directly in-app. Enough to warrant a major version bump.
\n\n\n
![](\"/posts/2025-12-07-december-adventure-day-06/software-index@3x/1600.png\"\n)
\n \nBrowsing the Software Index in OpoLua
\nThere remain a few things to be done before we can submit to the App Store:
\nSince there’s really no way to shortcut this kind of work, I simply set about working my way through it: I managed to catch up to the new Software Index API, ensuring this build should work well into the future, and make a few of the iOS 26 UX tweaks. More to come on day 7.
\nI’m looking at you, Strip Poker. ↩
Having finished day 4 of my December Adventure by getting distracted trying to improve the appearance of code on my website just before going to bed, I decided to skip the random selection and continue with this for day 5—I regularly write about code and I’d like to improve the reading experience a little.
\nI’ve used JetBrains Mono as my terminal font ever since reading Mike’s post exploring different monospaced fonts—it took a little getting used to, but it’s got quite a bit of personality, which I appreciate.
\nNow JetBrains Mono is available in Google Fonts, I updated my code blocks to use this instead of the default monospaced browser font.
Having nerd-sniped myself a few days ago, I decided it was time to look into adding OPL support to highlight.js. It’s a language I seem to write about a lot, and it would be great to have syntax highlighting when I do.
\nThankfully, highlight.js has pretty good documentation explaining how to define and register additional languages, making the process pretty simple. The current definition looks like this:
\nhljs.registerLanguage('opl', function() {\n return {\n case_insensitive: true,\n keywords: {\n $pattern: /[a-z$&%:]+/,\n keyword: 'abs acos acs addr adjustalloc alert alias alloc alog and app append appendsprite asc asin asn at atan atn back beep begintrans bookmark break busy byref cache cachehdr cacherec cachetidy call cancel changesprite chr$ clearflags clock close closesprite cls cmd$ committrans compact compress const continue copy copyw cos cosh count create createsprite cursor datetosecs datim$ day dayname$ days daystodate dbuttons dcheckbox dchoice ddate declare declare external dedit deditmulti defaultwin deg delete deletew dfile dfloat dialog diaminit diampos dinit dinits dir$ dirw$ disp dlong do dow dposition drawsprite dtext dtime dxinput edit else elseif end enda endif endp endv endwh eng entersend entersend0 eof erase err err$ errx$ escape eval exist exp external fac find findfield findlib findw first fix fix$ flt font free freealloc gat gborder gbox gbutton gcircle gclock gclose gcls gcolor gcolorbackground gcolorinfo gcopy gcreate gcreatebit gdrawobject gellipse gen$ get get$ getcmd$ getdoc$ getevent getevent32 geteventa32 geteventc getkey getlibh gfill gfont ggmode ggrey gheight gidentity ginfo ginfo32 ginvert giprint glineby glineto gloadbit gloadfont global gmove gorder goriginx goriginy goto gotomark gpatt gpeekline gpixel gpoly gprint gprintb gprintclip grank gsavebit gscroll gsetpenwidth gsetwin gstyle gtmode gtwidth gunloadfont gupdate guse gvisible gwidth gx gxborder gxborder32 gxprint gy hex$ hour iabs if in include input insert int intf intrans ioa ioc iocancel ioclose ioopen ioread ioseek iosignal iow iowait iowaitstat iowaitstat32 iowrite ioyield key key$ keya keyc killmark kmod kstat last lclose left$ len lenalloc linklib ln loadlib loadm loc local lock log lopen lower$ lprint m0 m1 m2 m3 m4 m5 m6 m7 m8 m9 max mcard mcardx mcasc mean menu menun mid$ min minit minute mkdir mod modify month month$ mpopup newobj newobjh next not num$ odbinfo off onerr open openr opx or os out p1 p2 p3 p4 p5 parse$ pause peek$ peekb peekf peekl peekw pi pointerfilter poke$ pokeb pokef pokel pokew pos position possprite print proc put rad raise rand randomize realloc recall recsize rename rept$ return right$ rmdir rnd rollback round sci$ screen screeninfo second secstodate send setdoc setflags sethelp sethelpuid setname setpath sgn showhelp sin sinh size space sqr sqrt statuswin statwininfo std stdev stop store style sum tan tanh testevent trap uadd udg unloadlib unloadm until update upper$ use usesprite usr usr$ usub val var vector view week while year'\n },\n contains: [\n {\n className: 'string',\n begin: '\"',\n end: '\"'\n },\n hljs.COMMENT(\n 'REM',\n '\\n',\n {\n contains: [{\n className: 'doc',\n begin: '@\\\\w+'\n }]\n }\n )\n ]\n }\n});\nThere’s a couple of things to note with this implementation:
\n$pattern
By default highlight.js uses \\w+ to detect and split keyword tokens. This doesn’t work for OPL as operations and functions can be optionally post-fixed with $, &, or $, to indicate the return type, necessitating a different regex pattern. To make things a little more complex, OPL also permits user-defined procedures with names that collide with the built-in operations and functions, relying on a trailing colon to differentiate them—the pattern therefore also includes : to ensure keywords don’t over-match on user procedures.
keyword
Huge thanks to Fabrice for collating all the OPL operations and functions which made it incredibly painless to put together the list of keywords, saving me quite a bit of time.
With this new language definition in place, OPL looks just that a little bit prettier:
\nPROC hello:\n PRINT \"Hello, World!\"\n GET\nENDP\nFor day 4 of my December Adventure, I again consulted the Organiser II which, in a clear cry for help, demanded that I revisit day 2 and, ‘learn about the Organiser Comm Link’.
\n\n
\n![](\"/posts/2025-12-06-december-adventure-day-04/prompt/400.jpeg\")
\n \nTasked with this for a second day, I set myself a goal of transferring files between my LZ64 and my Mac—there’s a nice selection of software out there that I’d love to try out, and I’d like to be able to develop programs on my Mac instead of fighting the A-Z keyboard all the time.
\nJaap Scherphuis' fantastic Psion II Page hosts a copy of the Comms Link manual which details how to configure later models of the Organiser II Comms Link to use the new ‘PSION’ protocol1 to talk to a DOS server to send and receive files. While I’ve exclusively used modern software for talking to my Psions, many members of the community use one variant of DOSBox or another to run the original PC software, and it seemed like a good time to try it out.
\nIt turns out that setup is incredibly easy—it’s a matter of a single configuration option to forward a host serial port to DOSBox, after which your DOS software should just see the comm port. In DOSBox-X2 on my Mac, I needed to edit ~/Library/Preferences/DOSBox-X 0.83.15 Preferences to ensure the serial section contained the following:
[serial]\n\nserial1 = directserial realport:cu.usbserial-A91MGK6M\nWith my USB-C RS232 adapter connected and the configuration in place, running the PC server was just a matter of launching CL.EXE from Comms Link 2.11 (see Jaap’s Software for PC listings for the download).
\n\n
![](\"/posts/2025-12-06-december-adventure-day-04/cl@2x/1600.png\"\n)
\n \nThis early implementation of the Psion Link Protocol exposes the PCs file as a share to the Psion, meaning everything else takes place on device using the the Transmit and Receive options in the Comms software; just follow the instructions to specify the local and remote filenames.
\n
\n![](\"/posts/2025-12-06-december-adventure-day-04/transmit/400.jpeg\")
\n \nWhile transferring files is slow with a maximum baud of 9600 (and you can only send one file at once), I was able to try out Jaap’s Worm2, an incredibly comprehensive snake clone for a 4-line text-only device. This involves copying the 4 OPL procedures to the Organiser II, updating the grid dimensions to match the LZ64’s larger screen, and compiling each, before finally running Worm2—slightly more involved than a modern app store.
\n
\nAn early version of the Psion Link Protocol used by EPOC16 and EPOC32 devices. ↩
On Alex’s advice, I tried with DOSBox Staging which includes support for changing the configuration from within DOSBox itself. Unfortunately, I hit a segfault early on so, while this looks idea, I had to retreat to DOSBox-X. ↩
Continuing my December Adventure, I started the day by writing up yesterday’s dive into Psion manuals and the Organiser II Comms Link. I also added a couple of new items to my LZ6 Ideas program (aka ‘lucky dip’) to ensure they’re in the running for future adventuring:
\nWith these additional entries in place, I rolled the metaphorical dice for the day’s task. This turned out to be ‘Software Index spelunking’—yet another wonderfully chill excursion, and something I’d been hoping would come up early in the month. My idea behind this entry was to allow myself an opportunity to simply enjoy exploring some of the software the Psion Software Index, perhaps even making the exercise a daily feature.
\n\n
\n![](\"/posts/2025-12-03-december-adventure-day-03/prompt/400.jpeg\")
\n \nSince I had my Series 7 with me for yesterday’s write-up, I decided to try an EPOC32 program or two1 and, with the Software Index built-into Reconnect, doing so was simply a matter of scrolling until something took my interest and clicking the ‘Install’ button.
\nFocusing on programs with color icons (as an indicator that they might have dedicated Series 7 support), I selected ‘Colors’ by vorbauer.com, which turned out to be a disappointingly unplayable game of Simon. While I can’t tell if it’s a function of my aging Series 7’s screen or not, tile flashes were barely visible and far too fast to discern, meaning I was unable to make it past the first sequence.
\n\n
\n![](\"/posts/2025-12-03-december-adventure-day-03/colors/400.png\")
\n \nDespite feeling slightly robbed of an engaging game of Simon, I took some screenshots, wrote a brief description, and added it to the Software Index. Find it here.
\nWith one program down, I decided to bring forward another task from the list to work on: the Software Index ‘I’m Feeling Lucky’ button. Inspired by Colin Hoad’s 2024 ‘Advent of Beeb’, I’ve been meaning to add this early-Google style button2 for a little while. The idea is that it will encourage me (and others) to dive randomly into the library and, hopefully, discover new and exciting programs.
\nSince the Software Index home page already preloads the top-level program listing using JavaScirpt (for the lazy loading and filtering features), adding the button was simply a matter of selecting a random in-memory item from the list and navigating to it:
\nfunction selectRandomGroup() {\n const index = Math.floor(Math.random() * filteredGroups.length);\n const group = filteredGroups[index];\n window.location.href = \"/programs/\" + group.id;\n}\n\n/* ... */\n\nluckyButton.addEventListener('click', function(event) {\n selectRandomGroup();\n});\nHappily, this also respects the current filter, which means you can limit results to EPOC16 or EPOC32 programs, and hopefully, to specific program categories in the future. You can see the full change on GitHub if you’re curious, and I encourage you to try it out (and maybe even contribute some screenshots and metadata).
\nEnergized by the surprising ease of adding the ‘I’m Feeling Lucky’ button (and forgetting my plans to stick to just one thing a day), I decided to add one small quality of life improvement to the index: program versions are now sorted in reverse order, meaning the most recent version will always appear at the top of the page (see Zher0es for an example).
\n\n\n
![](\"/posts/2025-12-03-december-adventure-day-03/zher0es@2x/1600.png\"\n)
\n \nAfter the Organiser II escapades of day 1, I’d been hoping for a slower day, and the LZ64 lucky dip delivered, with the first two entries being, ‘Learn about the Organiser Comm Link’, and ‘Add manuals to psion.community’. Exactly the kind of chill tasks I was looking for.
\n\n
\n![](\"/posts/2025-12-03-december-adventure-day-02/prompt/400.jpeg\")
\n \nSince the Comms Link is a chunky device (especially when paired with the necessary cables and adapters to plug it into a modern computer), I didn’t have it with me over my morning coffee. I therefore opted to start the day by focusing on adding manuals to the Psion Community website.
\nThe goal is to make it easier for folks to find documentation on all eras of Psion computers, akin to Jaap’s Organiser II pages. It’s mostly an exercise in cataloguing what we already have, uploading things to archive.org if they don’t exist, and adding links to the website1. Alex very kindly shared his collection with me and, combining it with mine, I started working my way through.
\n\n\n
![](\"/posts/2025-12-03-december-adventure-day-02/website@2x/1600.png\"\n)
\n \nProgress was a little slow as I had to make a couple of tweaks to the website itself, but I was able to add links to about 11 manuals across 7 Psion models, uploading 3 that didn’t appear to exist on archive.org. Now that I’ve established a pattern, it should be much easier to add more entries over time—I’ve very intentionally opted for a simple list layout in the hope that this will make it more welcoming and encourage others to propose updates to the page.
\nWhile the day proved unexpectedly busy (I found myself judging a local latte art competition), I still managed to find a few moments to poke at the Comms Link.
\n\n
\n![](\"/posts/2025-12-03-december-adventure-day-02/comms/400.jpeg\")
\n \nJust like the 3 Link for the Series 3 and Series 3a, the Comms Link has a built-in ROM which includes all the necessary software for the Organiser. The software uses all 4 lines of the display, telling me that I was lucky enough to pick up a later model with explicit support for the LZ64. While I didn’t get a chance to go further, those menu entries suggest there’s support for manually sending and receiving individual files, and I understand these later versions also have nascent support for the Psion Link Protocol. Something for day 3.
\nWe may choose to re-host these in the future, but that’s a job for another day. ↩
Compiling the ideas for this year’s December Adventure, I found myself coming up with a seemingly infinite list of possibilities1. I also noticed that many of them were relatively small and self-contained—tasks that push forward my projects in meaningful ways, but not ones that will take the full month. With that in mind, I’ve decided to do something a little more like an advent calendar this year, and select a random idea from a list each day.
\nOf course, it wouldn’t be a Psion-themed December adventure without involving at least one of these wonderful portable computers. With that in mind, I’ve decided to start getting to grips with my new Organiser II LZ64 by writing a small OPL program that will generate random selections for me.
\nThe LZ64 came with a small but incredibly comprehensive manual2 which, combined with my past experience of OPL, was enough to get me started. Given there’s language-level support for ‘databases’ in OPL, it makes sense to store my list of ideas in a data file and then randomly select and display a row. It’s a very long time since I’ve worked with data files, so I enjoyed diving into the programming manual over a cup of coffee3.
\n\n
\n![](\"/posts/2025-12-01-december-adventure-2025-day-01/creating-a-data-file/400.jpeg\")
\n \nTo avoid needing to first write a top-level menu and editor, I started by creating a new data file each time, programmatically populating it with some sample data, and then exercising the code for random selection. Typing things on the LZ64’s quirky A-Z keyboard (which also lacks a traditional shift key, forcing you to always use caps lock) was slow going, but I was able to get something going.
\n\n
\nFor the curious, the code (transcribed) looks something like this4:
\nRANDOM:\n\nLOCAL c,p%,k%\n\nCREATE \"C:IDEAS\",A,t$\n\nA.t$=\"Add Im feeling lucky to the Software Index\"\nAPPEND\n\nA.t$=\"Software Index UID table\"\nAPPEND\n\nA.t$=\"Psion webring\"\nAPPEND\n\nc=COUNT\n\nDO\n p%=INT(RND*c)\n POSITION p%+1\n\n PRINT A.t$ \n PRINT \"TRY AGAIN (Y/n)\"\n k%=GET\n\n CLS\n\nUNTIL k%=%N OR k%=%n OR k%=1\n\nPRINT \"Quitting...\"\n\nCLOSE\nDELETE \"C:IDEAS\"\nThe LZ64 helpfully tells me this takes a whopping 604 bytes. Everything counts when all you’ve got is 64k total memory.
\nWith a proof-of-concept in place, I set about adding support for paging through, and managing entries. Refactoring the code proved significantly more tiresome than I’d expected as the LZ64 doesn’t appear to have any kind of copy-and-paste support, and this generation of OPL requires each procedure to be in a separate file. Not having any desire to manage files using the Organiser’s somewhat cumbersome menus, I opted for the lesser of two evils: a combination of labels and GOTO statements 🤷. Happily, it does provide conveniences like the MENU function, so I was able to put something together relatively easily:
RANDOM:\n\nLOCAL c,p%,k%,m%\n\nGOTO init::\n\nmenu::\nWHILE 1\n k%=GET\n IF k%=1\n GOTO quit::\n ELSEIF k%=2\n m%=MENU(\"Random,New,Delete,Quit\")\n IF m%=1\n GOTO rand::\n ELSEIF m%=2\n GOTO add::\n ELSEIF m%=3\n GOTO delete::\n ELSEIF m%=4\n GOTO quit::\n ENDIF\n ELSEIF k%=5\n GOTO prev::\n ELSEIF k%=6\n GOTO next::\n ELSEIF k%=13\n GOTO rand::\n ELSEIF k%=32\n GOTO add::\n ENDIF\nENDWH\n\ninit::\nIF NOT EXIST(\"C:IDEAS\")\n CREATE \"C:IDEAS\",A,t$\nELSE\n OPEN \"C:IDEAS\",A,t$\nENDIF\nGOTO show::\n\nshow::\nCLS\nPRINT POS,\"/\",COUNT\nIF COUNT<1\n PRINT \"No items\"\nELSE\n PRINT A.t$\nENDIF\nGOTO menu::\n\nprev::\np%=POS-1\nIF p%<1\n p%=COUNT\nENDIF\nPOSITION p%\nGOTO show::\n\nnext::\np%=POS+1\nIF p%>COUNT\n p%=0\nENDIF\nPOSITION p%\nGOTO show::\n\nrand::\nc=COUNT\np%=INT(RND*c)\nPOSITION p%+1\nGOTO show::\n\ndelete::\nERASE\nIF POS>COUNT\n POSITION COUNT\nENDIF\nGOTO show::\n\nquit::\nPRINT \"Quit...\"\nCLOSE\nSTOP\n\nadd::\nCLS\nPRINT \"New\"\nINPUT A.t$\nAPPEND\nGOTO show::\nClocking in at 1310 bytes, this now gives me the tools I need to (very slowly) enter my list of ideas for the coming days, select a random one each day, and append new ideas as the month progresses. Perhaps unsurprisingly, I’m going to call it ‘Ideas’.
\nThat list of ideas currently looks something like this (see this year’s introduction for background to some of these).
\nPsion ideas:
\nNon-Psion ideas:
\nmodel-viewerSince I’m selecting things at random, I’ve intentionally let this list grow to include many wishlist and quality-of-life improvement items. I plan to let myself re-roll if ideas don’t speak to me on a given day, but I’ll note down the ones I skipped for folks following along.
\nIn spite of it’s quirks, the Organiser is already proving a very enjoyable device to use—it’s fascinating to see how many of the UX patterns in SIBO and beyond have their roots in these text-only devices.
\nThis might very well be a side effect of having spent most of November traveling, instead of working on projects. ↩
There’s a digial version on Jaap’s Psion II Page but I can’t find a scan of the paper version on the Internet Archive. Another project for when I finally acquire a book scanner. ↩
It was actually matcha, but ‘coffee’ seems the de rigueur hot drink for such narratives. 🍵 ↩
And there’s yet another idea to add to the list: OPL syntax highlighting for highlight.js 🙃. ↩
While I didn’t manage to continue for the full month, I really enjoyed last year’s December Adventure1. It provided me with a clear focus and, far more importantly, gave me permission to spend my time creating, and writing about those creations. With December 2025 fast approaching, I’ve decided to indulge myself again.
\nJust like last year, I’m planning a Psion-themed adventure, with room for a few (probably retro) side-quests as-and-when the mood (or need) takes me. I anticipate things might be a little more piecemeal this year as I’ve a number of smaller ideas to try out. I also intend to shift pace a little on the weekends to ensure I don’t burn myself out on what’s meant to be a fun little excursion.
\nHere’s a few of my initial ideas of things to explore:
\nPsion webring
I’ve really enjoyed seeing webrings reappear in some online communities (e.g., https://webring.xxiivv.com/) and I’d love to have something like that in the Psion space.
Psion community website improvements
There’ll always be an endless list of things we could do with the new (and currently fairly minimal) Psion Community website, and I’d like to take a little time to focus on making it a richer resource for folks discovering the world of Psion for the first time. While the Software Index attempts to catalogue EPOC16 and EPOC32 programs, there are many secondary resources (desktop software, manuals, etc) that exist on the Internet Archive, but aren’t centrally indexed. It’d be great to follow the example of Jaap Scherphuis' wonderful Organiser II pages and collect together useful links for MC devices and beyond.
Organiser explorations
I’ve just acquired a Psion Organiser II LZ64, and I’m excited to take some time to discover this ‘new’ machine.
\nI anticipate very quickly wanting to connect it to my Mac so I’ll need to see what options are available and, potentially, add support to Reconnect. Unlike the later Series 3 and Series 5 devices, Organisers aren’t supported by plptools which provides the connectivity in Reconnect, so I’d need to get my hands dirty with the Psion Link Protocol.
Using Alex’s LZ64 during the recent Retro Computer Festival at the Center for Computing History, I was struck by both how good the screen is, and how impractical the A-Z keyboard is if you’re used to QWERTY layouts. With that in mind, I wondered about seeing if I could create a little hardware dongle to let me use a regular USB keyboard (assuming one doesn’t already exist2) and turn it into some form of minimal writer deck.
Psion emulation
There’s been some amazing progress in the field of Psion emulation in the past few years, with MAME becoming the go-to solution for all things Psion. I’d love to figure out how to showcase all the options, either with a simple blog post, or perhaps something a little more invovled—I dream of using Emscripten to embed the emulators in a dedicated website akin to absolutely wonderful Frame of preference interctive showcase of Mac settings dialogs.
Wrapping up the PsiBoard
I spent much of October working on the PsiBoard, my Psion Bluetooth keyboard, to ensure it was complete for my father’s 80th birthday in November. Now that deadline has passed, I’d like to take the time to finish writing up the project, address a few firmware and design issues, and make it available so others can make their own. PCBWay kindly offered to pay for prototype parts going forwards (I guess this makes me an influencer 🤷) which will take the edge off the last few hardware bug fixes and iterations.
Shipping OpoLua 2.0
Over the past few months, Tomsci has been working hard to create a Qt version of OpoLua, our modern OPL runtime, for Windows, Linux and macOS. This is now all-but ready to go, but we need to revisit the licensing and set up CI for the Qt builds before we’re ready to ship it. There’s also a whole host of improvements and bug fixes to ship in the iOS app (thanks to Fabrice for keeping us on our toes by trying out seemingly every OPL program ever published), along with an integrated Software Index which should make it significantly easier for folks to discover the wealth of OPL programs out there.
And a few weekend side-quest ideas:
\nPsion Series 3a hinge reinforcement
I’ve a Psion Series 3a in need of JB Weld hinge reinforcement that I’d love to document to help other who need to do the same.
Toshiba Libretto 50CT battery removal
The BIOS backup batteries on Toshiba Librettos are, like many batteries from that era, well known for leaking. I’ve a couple of Libretto 50CTs which desperately need their batteries removing. I’d love to take the time to do it, and perhaps print some of polymatt’s replacement parts in the process to stop their cases degrading further. Maybe I could even try a Psion-style JB Weld preventative treatment.
Something ZX Spectrum related
I picked up my ZX Spectrum3 when visiting my folks in the UK and I’m excited to tinker around with it. While I’ve enjoyed playing with the Spectrum core on the MiSTer, it’s not a machine I know at all well, and it’d be great to find a little project to help me really get to know the hardware and software.
Software Index spelunking
Thanks to the great archival work of community members, the Psion Software Index contains a wealth of programs for EPOC16 and EPOC32. I’m keen to dig into the library and start documenting and screenshotting the various programs; perhaps something to do over a morning coffee.
Writing this list, I realize there’s a huge wealth of possibilities! Let’s see what December brings…
\nIf you’re looking for other folks to follow in the December, I highly recommend Colin Hoad, who’s reprising his Advent of Beeb.
\nYou can find out a little more about the idea of a ‘December Adventure’ over at Oatmeal. (I’m glad I reread this when looking out the link as it reminded me that it’s meant to be ‘low key’.) ↩
The Organiser devices are entirely new to me and I’ve a lot of research to do. ↩
Acquired for the princely sum of £5 at a car boot sale in the 90s. ↩
While hunting down sources for the Psion Software Index, I came across a Windows 95 Psion screen saver. Needless to say, I couldn’t resist recreating it for modern macOS.
\n\n
\n![](\"/posts/2025-10-11-psion-screen-saver/preview/400.gif\")
\n \nMy take on a Psion bluetooth keyboard has been in the works since 2018. It’s one of my first hardware projects and, if I’m honest with myself, was a litte beyond my abilities at the time. There were just too many new things all at once: microcontrollers, 3D printing, and PCB design.
\n\n
\n![](\"/posts/2025-10-03-revisiting-the-psion-bluetooth-keyboard/psiboard-so-far/400.jpeg\")
\n \nThe PsiBoard, while working, has never felt complete
\nNow that I’ve a little more experience behind me, I’m going to have a go at finishing it—I receive a constant trickle of emails from folks intereted in building their own, and I’d love to be able to offer a complete set of parts and instructions.
\nThe world of custom keyboards has moved on significantly since 2018, with devices like the Pro Micro and it’s cousin the nice!nano becoming the go-to microcontrolers, supported by a wide range of off-the-shelf customizable firmware.
\nMoving forwards, I’m going to use ZMK and a nice!nano. This is a combination I’ve experience with from my work on the Little Luggable, and it should allow me to foucs on the electronics and the industrial design, rather than spending my days working around already-solved firmware issues.
\n\n
\n![](\"/posts/2025-10-03-revisiting-the-psion-bluetooth-keyboard/ribbon-cable/400.jpeg\")
\n \nThe Psion Series 5/5mx keyboard connects using a 20-pin ribbon cable
\nWhen I last worked on the PsiBoard, my understanding of the keyboard matrix was as follows (ribbon cable pin numbering given in parentheses):
\n| \n | Col 01 (15) | \nCol 02 (11) | \nCol 03 (10) | \nCol 04 (9) | \nCol 05 (8) | \nCol 06 (7) | \nCol 07 (6) | \nCol 08 (5) | \nCol 09 (4) | \nCol 10 (3) | \nCol 11 (2) | \nCol 12 (1) | \n
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Row 01 (20) | \n\n | Space | \nUp | \n. / | \nLeft | \nRight | \nLeft Shift | \n\n | \n | \n | \n | \n |
| Row 02 (19) | \nZ | \nX | \nC | \nV | \nB | \nN | \n\n | Right Shift | \n\n | \n | \n | \n |
| Row 03 (18) | \nH | \nJ | \nK | \nM | \n. ? | \nDown | \n\n | \n | Fn | \n\n | \n | \n |
| Row 04 (17) | \nTab | \nA | \nS | \nD | \nF | \nG | \n\n | \n | \n | \n | \n | Left Control | \n
| Row 05 (16) | \n1 | \n2 | \n3 | \n4 | \n5 | \n6 | \n\n | \n | \n | \n | \n | \n |
| Row 06 (14) | \nU | \nI | \nO | \nP | \nL | \nEnter | \n\n | \n | \n | Menu | \n\n | \n |
| Row 07 (13) | \nQ | \nW | \nE | \nR | \nT | \nY | \n\n | \n | \n | \n | Esc | \n\n |
| Row 08 (12) | \n7 | \n8 | \n9 | \n0 | \nDel | \n‘ - | \n\n | \n | \n | \n | \n | \n |
This has 12 columns, and 8 rows, requiring 20 I/O pins—too many for most microcontrollers (the nice!nano has only 18). Previously, to work around this, I tied the modifier keys to a single column, leading to issues identifying multiple modifier keys1.
\nWith the benefit of experience, I’ve realized that these modifier keys are intentionally broken-out to allow diodes to be introduced on each of the modifer lines to avoid exactly this problem—Psion skipped putting diodes on the flexible PCB itself, but made it possible to add them where it really matters.
\nTaking this into account, here’s my updated understanding of what the Series 5 keyboard matrix should look really look like:
\n| \n | Col 0 (20) | \nCol 1 (19) | \nCol 2 (18) | \nCol 3 (17) | \nCol 4 (16) | \nCol 5 (14) | \nCol 6 (13) | \nCol 7 (12) | \n
|---|---|---|---|---|---|---|---|---|
| Row 0 (15) | \n\n | Z | \nH | \nTab | \n1 | \nU | \nQ | \n7 | \n
| Row 1 (11) | \nSpace | \nX | \nJ | \nA | \n2 | \nI | \nW | \n8 | \n
| Row 2 (10) | \nUp | \nC | \nK | \nS | \n3 | \nO | \nE | \n9 | \n
| Row 3 (9) | \n, / | \nV | \nM | \nD | \n4 | \nP | \nR | \n0 | \n
| Row 4 (8) | \nLeft | \nB | \n. ? | \nF | \n5 | \nL | \nT | \nDel | \n
| Row 5 (7) | \nRight | \nN | \nDown | \nG | \n6 | \nEnter | \nY | \n‘ ~ | \n
| Row 6 (6,5,4,3,2,1) | \nLeft Shift | \nRight Shift | \nFn | \nLeft Control | \n\n | Menu | \nEsc | \n\n |
Our new row 6 is created by tying pins 1-6 from the ribbon cable to a single pin, by means of a diode on each wire. This prevents loops in the keyboard matrix by ensuring current can only flow in a single direction through the circuit. Happily, this also only requires 15 I/O pins, leaving 3 spare pins on the nice!nano.
\n\n
\n![](\"/posts/2025-10-03-revisiting-the-psion-bluetooth-keyboard/breadboard/400.jpeg\")
\n \nUsing a breadboard to test the new modifier row and diodes
\nReturning to a breadboard for prototyping, I was able to confirm this all works correctly and give myself a testbed for my customized ZMK firmware.
\nWith the wiring in place, the next step is to convince myself I can get all the functionality I want with the ZMK firmware, especially around power management.
\nPressing more than one modifier key at once would lead to loops in the circuit; an issue known as key rollover. ↩
",
"date_published": "2025-09-13T11:44:48-07:00",
"id": "https://jbmorley.co.uk/photos/patterns/IMG_8263/",
"url": "https://jbmorley.co.uk/photos/patterns/IMG_8263/"
},
{
"content_html": "
I'd like to think this was intentional.
", "date_published": "2025-09-09T21:55:58-07:00", "id": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_8214/", "title": "Shadows", "url": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_8214/" }, { "content_html": "", "date_published": "2025-09-09T19:10:15-07:00", "id": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_8219/", "title": "Rain", "url": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_8219/" }, { "content_html": "
After spending a large portion of the last decade in the US, it's incredibly refreshing to see so many bicycles in Tokyo.
", "date_published": "2025-09-08T13:29:05-07:00", "id": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_8088/", "title": "Wheels", "url": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_8088/" }, { "content_html": "
",
"date_published": "2025-09-07T10:15:03-07:00",
"id": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_8039/",
"title": "POST",
"url": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_8039/"
},
{
"content_html": "
Who can resist a good manhole cover?!
", "date_published": "2025-09-06T13:57:19-07:00", "id": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_8031/", "title": "Squid", "url": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_8031/" }, { "content_html": "
",
"date_published": "2025-09-03T14:06:32-07:00",
"id": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_7857/",
"title": "Denny's",
"url": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_7857/"
},
{
"content_html": "
The e-boxes in Akihabara are a veritable museum of consumer electronics, making it hard to resist taking photos of most everything there. This [fairly expensive] Sony Walkman was, with its glorious button design and layout, completely irresitable.
", "date_published": "2025-08-31T14:04:38-07:00", "id": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_7753/", "title": "Walkman", "url": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_7753/" }, { "content_html": "
The Yamanashi Press and Broadcast Center remains one of my favourite buildings in Tokyo, and one of very few Metabolist buildings still standing. I felt incredibly lucky to discover a new vantage point to sit and enjoy it.
", "date_published": "2025-08-28T14:32:19-07:00", "id": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_7667/", "title": "Metabolism", "url": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_7667/" }, { "content_html": "
",
"date_published": "2025-08-28T12:01:46-07:00",
"id": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_7646/",
"title": "Tamagotchi",
"url": "https://jbmorley.co.uk/photos/2025/08/tokyo-and-hakodate/IMG_7646/"
},
{
"content_html": "
",
"date_published": "2025-08-25T15:09:19-07:00",
"id": "https://jbmorley.co.uk/photos/patterns/IMG_7628/",
"url": "https://jbmorley.co.uk/photos/patterns/IMG_7628/"
},
{
"content_html": "
",
"date_published": "2025-08-25T15:09:11-07:00",
"id": "https://jbmorley.co.uk/photos/patterns/IMG_7627/",
"url": "https://jbmorley.co.uk/photos/patterns/IMG_7627/"
},
{
"content_html": "
",
"date_published": "2025-08-25T15:08:55-07:00",
"id": "https://jbmorley.co.uk/photos/patterns/IMG_7626/",
"url": "https://jbmorley.co.uk/photos/patterns/IMG_7626/"
},
{
"content_html": "
",
"date_published": "2025-08-25T15:08:44-07:00",
"id": "https://jbmorley.co.uk/photos/patterns/IMG_7625/",
"url": "https://jbmorley.co.uk/photos/patterns/IMG_7625/"
},
{
"content_html": "
Patterns are everywhere in Japan, including this beautiful etching hidden on the underside of a luggage shelf on the Hibya line trains.
", "date_published": "2025-05-04T15:19:41-07:00", "id": "https://jbmorley.co.uk/photos/2025/04/japan/IMG_6562/", "title": "Pervasive Patterns", "url": "https://jbmorley.co.uk/photos/2025/04/japan/IMG_6562/" }, { "content_html": "
Tako-yaki is apparently a big deal in Osaka.
", "date_published": "2025-04-30T12:27:20-07:00", "id": "https://jbmorley.co.uk/photos/2025/04/japan/R0005352/", "title": "🐙", "url": "https://jbmorley.co.uk/photos/2025/04/japan/R0005352/" }, { "content_html": "
",
"date_published": "2025-04-30T12:24:38-07:00",
"id": "https://jbmorley.co.uk/photos/2025/04/japan/R0005349/",
"title": "Waterfront",
"url": "https://jbmorley.co.uk/photos/2025/04/japan/R0005349/"
},
{
"content_html": "
You can see the Don Quijote in Shinsaibashi for miles around thanks to the wonderfully 80s-feeling ride integrated into the building. Sadly it wasn't running when I was there, but it's still a striking addition to the waterfront.
", "date_published": "2025-04-30T12:24:18-07:00", "id": "https://jbmorley.co.uk/photos/2025/04/japan/R0005347/", "title": "ドンキ", "url": "https://jbmorley.co.uk/photos/2025/04/japan/R0005347/" }, { "content_html": "
I couldn't find much of an explanation, but this installation—taking up the whole front-half of Brazil's pavilion—seemed to be about the cycle of rebith and destruction, with these inflatable sculptures shrinking and growing over the course of the piece.
", "date_published": "2025-04-29T19:09:44-07:00", "id": "https://jbmorley.co.uk/photos/2025/04/japan/R0005327/", "title": "Brazil", "url": "https://jbmorley.co.uk/photos/2025/04/japan/R0005327/" }, { "content_html": "
Needless to say, Expo 2025 has its own manhole covers.
", "date_published": "2025-04-29T14:17:59-07:00", "id": "https://jbmorley.co.uk/photos/2025/04/japan/R0005256/", "title": "Manhole Cover", "url": "https://jbmorley.co.uk/photos/2025/04/japan/R0005256/" }, { "content_html": "
It was great to see Tezuka's Astro Boy getting some love at the expo.
", "date_published": "2025-04-29T14:14:41-07:00", "id": "https://jbmorley.co.uk/photos/2025/04/japan/R0005249/", "title": "Pasona Natureverse", "url": "https://jbmorley.co.uk/photos/2025/04/japan/R0005249/" }, { "content_html": "
Weird as they were, the different artistic interpretations of Myaku-Myaku around the expo were so much more engaging than the branded items on sale.
", "date_published": "2025-04-29T13:02:51-07:00", "id": "https://jbmorley.co.uk/photos/2025/04/japan/R0005232/", "title": "More Myaku", "url": "https://jbmorley.co.uk/photos/2025/04/japan/R0005232/" }, { "content_html": "
Ishiguro Hiroshi's robitic visions of the future were somewhat unnerving—these robots were just lifelike enough to reach the uncanny valley and, coupled with the sound design of the exhibit proved disconcerting.
", "date_published": "2025-04-29T12:24:52-07:00", "id": "https://jbmorley.co.uk/photos/2025/04/japan/R0005213/", "title": "Future of Life?", "url": "https://jbmorley.co.uk/photos/2025/04/japan/R0005213/" }, { "content_html": "
Myaku Myaku—Expo 2025's bizarre mascot—could be found everywhere and in every creepy form you could imagine.
", "date_published": "2025-04-29T10:21:42-07:00", "id": "https://jbmorley.co.uk/photos/2025/04/japan/R0005162/", "title": "Myaku-Neko", "url": "https://jbmorley.co.uk/photos/2025/04/japan/R0005162/" }, { "content_html": "
",
"date_published": "2025-04-25T09:49:31-07:00",
"id": "https://jbmorley.co.uk/photos/2025/04/japan/R0005134/",
"url": "https://jbmorley.co.uk/photos/2025/04/japan/R0005134/"
},
{
"content_html": "For the last 4 years, I’ve been working on Bookmarks, a Pinboard client for iOS, macOS, and iPadOS. Bookmarks was my attempt at bringing a Pinboard-like visual experience to private bookmarking. It’s been in public TestFlight beta for the last couple of years and has picked up a fair number of users. After much consideration, I’ve decided to stop working on it.
\n\n\n
![](\"/posts/2025-04-02-retiring-bookmarks/screenshot@2x/1600.png\"\n)
\n \nBookmarks focuses on offering a more visual experience
\nBefore getting into the details, I’d like to say thank you to everyone who’s been helping me test Bookmarks, and has provided feedback and suggestions during development. It makes a huge difference to know that what I’m building helps others and is very much why I started writing software in the first place. Thank you!
\nWhile I’m really proud of what I’ve created with Bookmarks (it’s an app I’ve used almost daily for the last few years), I want to invest my time elsewhere. Maintaining indie software represents a huge amount of work and, of all the software I write and maintain, Bookmarks deviates most from the product I’d design if I started again today1, and is the one with the most alternatives in the market2.
\nBookmarks is open source (under the MIT license), so if you’re interested in taking over the project, I encourage you to do so and am happy to help you get up to speed.
\n
",
"date_published": "2025-03-29T12:30:19-07:00",
"id": "https://jbmorley.co.uk/photos/patterns/IMG_6012/",
"url": "https://jbmorley.co.uk/photos/patterns/IMG_6012/"
},
{
"content_html": "Over the past couple of months, I’ve been working on-and-off on Reporter, a new command line utility to make it easier to keep track of changes to your files.
\nReporter generates email reports letting you know about changes over time. It’s intended to fill in one of the missing pieces from services like Dropbox for folks who choose to self-host their files using network shares, or tools like Syncthing1, providing both a quick sanity check that file changes match expectations and an easy way to discover edits in files shared with others.
\n\n\n
![](\"/posts/2025-03-03-tracking-file-changes/report@2x/1600.png\"\n)
\n \nReporter generates clean email reports showing file changes
\nReporter works by scanning your files and generating a snapshot containing paths, modification times, sizes, and shasums. It then compares this snapshot to the previous one and sends an email summary if there have been any changes. It includes a built in SMTP client (using Swift-SMTP from the Kitura project) to avoid the need to rely on platform-provided mailers and, while it’s written in Swift, compiles and runs happily on Linux (I run it primarily on my Raspberry Pi based home Syncthing mirror).
\nThere’s not much more to say. Reporter is a simple tool with a single purpose. I find it incredibly useful and maybe you will too. Right now, you’ll need to build it from source (and there are some known issues), but if there’s interest, I’ll look into packaging for various platforms. You can find it on GitHub. I’d love to hear how you get on.
\nWhich, although a little nuanced to set up, is an absolutely wonderful tool I can’t recommend enough. ↩
Splitting my time between Linux and macOS, and syncing files between the two systems, I often find myself trying to view and edit macOS-specific files on Linux. One particular frustration comes in the form of .webloc files—Apple’s custom file format for URLs. If you’ve ever dragged-and-dropped a URL on macOS, you’ve probably encountered one of these; they’re a pretty simple (if Apple-specific) format, but I’ve found them to be almost entirely unsupported on Linux.
The few options out there seem either incomplete (Opening Web Internet Location Files on Ubuntu) or overly heavyweight (WeblocOpener). With that in mind, here’s my slightly more complete set of instructions for adding support for opening .webloc files to Linux.
The approach involves creating two new files: a MIME database entry telling Linux about the existence of the application/x-webloc MIME type; and a desktop entry which provides a simple handler for the new MIME type, using xdg-open to open the URL with the default browser.
Create the MIME entry in ~/.local/share/mime/packages/application-x-webloc.xml:
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<mime-info xmlns=\"http://www.freedesktop.org/standards/shared-mime-info\">\n <mime-type type=\"application/x-webloc\">\n <comment>Webloc</comment>\n <glob pattern=\"*.webloc\"/>\n </mime-type>\n</mime-info>\nCreate the desktop entry in ~/.local/share/applications/webloc.desktop:
[Desktop Entry]\nName=Open Webloc Files\nComment=Open webloc files in the default browser\nExec=sh -c \"xdg-open `plistutil -f xml -i \\\\\"$1\\\\\" | xmllint --xpath \\\\\"//dict/string/text()\\\\\" -`\" -- %f\nIcon=text-html\nTerminal=false\nType=Application\nMimeType=application/x-webloc;\nNoDisplay=true\nThis uses a combination of plistutil and xmllint to extract the URL from the webloc property list file so you’ll also need to install these.
Fedora:
sudo dnf -y install libplist libxml2\nUbuntu:
sudo apt-get install -y libplist-utils libxml2-utils\nFinally, update the MIME and desktop databases:
update-mime-database ~/.local/share/mime\nupdate-desktop-database ~/.local/share/applications\nAfter completing these steps, double clicking a .webloc file in your file manager of choice should open the link in your default browser.
20 March 2025: Updated to add --f xml to force an XML output format irrespective of the webloc file input format; thanks for the feedback Nathan!
6 December 2025: Updated to add instructions for installing libplist and libxml2 on Ubuntu. Thanks Jon!.
After taking up altogether too much of my December Adventure, day 19 finally brought working drag-and-drop file transfer to Reconnect, my Psion connectivity software for macOS. 🎉
\n\n
\n![](\"/posts/2024-12-20-december-adventure-day-19/file-transfer/400.gif\")
\n \nThere’s not much to add technically beyond what I’ve covered in previous posts, so feel free to check out my write-ups from day 15 and day 18 if you’re curious about the details.
\nI’ve yet to add support for dragging folders which will require some refactoring: folders are currently handled as a collection of individual file transfers and that will need to change to allow me to track the overall progress and provide a single completion for the NSItemProvider-based drag operation. With that in place, I’ll be ready to push a release. Lots to keep me busy on day 20!
Day 18 of my December Adventure brought a new wave of pain (I strongly advise against fracturing your foot, however exciting it might seem), so everything went slowly and there’s not too much to report—I mostly spent my time thinking about how things needed to work instead of doing. Still, in the interests of journaling the progress I do make, here’s a little update.
\nI’m still committed to adding full support for drag and drop to Reconnect, my Psion connectivity sofware for macOS. The remaining work entails figuring out how drag-and-drop operations should interact with the Transfers window—it feels like the correct place to show progress for drag-initiated transfers, but it’s not currently set up for that.
\nWith drag operations, apps don’t know the file’s destination—they pass the data to the OS and it does what’s necessary to create/copy/move the file. That means the model object that backs the Transfers window and manages on-going transfer operations needs to expose a slightly lower level API that can be used for both the regular transfers from the Psion to the user’s ‘Downloads’ directory, and the NSItemProvider implementation used for drag-and-drop.
Right now, the API to download a file from the Psion looks like this:
\n@MainActor @Observable\nclass TransfersModel {\n\n func download(from source: FileServer.DirectoryEntry,\n to destinationURL: URL? = nil,\n convertFiles: Bool) async throws\n\n}\nThe implementation always defaults to using the users ‘Downloads’ directory if destinationURL is nil:
let fileManager = FileManager.default\nlet downloadsURL = fileManager.urls(for: .downloadsDirectory,\n in: .userDomainMask)[0]\nlet destinationURL = destinationURL ?? downloadsURL.appendingPathComponent(source.name)\nlet temporaryURL = fileManager.temporaryDirectory.appendingPathComponent((UUID().uuidString))\n...\ntry fileManager.moveItem(temporaryURL, to: destinationURL)\n...\nreturn destinationURL\nInstead, of this, it needs to return the resulting URL to the caller and only move the temporary file used for transfers if an explicit destination is specified. The prototype needs to look something like this:
\nfunc download(from source: FileServer.DirectoryEntry,\n to destinationURL: URL? = nil,\n convertFiles: Bool) async throws -> URL\n\nAnd internally, the behavior needs to be a little more like this, moving the temporary file only if destinationURL is non-nil:
...\nlet destinationURL = if let destinationURL {\n try fileManager.moveItem(temporaryURL, to: destinationURL)\n return destinationURL\n} else {\n return temporaryURL\n}\n...\nreturn destinationURL\nI’m sure there’s a cleaner way to write this—I’m still getting used to Swift’s new conditional assignments.
\nThis small change of should allow me to build on the example code from day 15 as follows:
\nTableRow(file)\n .itemProvider {\n let provider = NSItemProvider()\n provider.suggestedName = file.name\n provider.registerFileRepresentation(for: .data) { completion in\n Task {\n let url = await self.browserModel.download([file.id], convertFiles: false)\n let data = try Data(contentsOf: url)\n completion(data, false, nil)\n }\n return nil\n }\n return provider\n }\n\nI still need to work out how to update the suggested filename if it changes during file conversion (e.g., ‘image.mbm’ to ‘image.tiff’) and if possible I’d like to make that conversion decision a user-interactive part of the file transfer.
\nThe legacy download behavior (when the user clicks the download toolbar button) can now be achieved by explicitly passing the downloads directory:
\nTask {\n let downloadsURL = FileManager.default.urls(for: .downloadsDirectory,\n in: .userDomainMask)[0]\n try? await transfersModel.download(from: file,\n to: downloadsURL,\n convertFiles: convertFiles)\n}\nWhile it feels like I’m rapidly running out of days in December, I’m still keen to contribute a little to the Psion emulation story: I’d like to finish my brief write-up explaining some of the emulation options available in MAME, and I’d really love to get a handle on what would be involved in producing something like Infinite Mac—a website showcasing emulators for every Mac—for Psions.
\nWith my sights set on—shall we call it ‘Infinite Psion’?—I had a go at compiling MAME for the web using Emscripten. MAME has some instructions for doing just this, and the Emscripten Getting Started seems pretty accessible. It should be as simple as:
\ncd ~/Projects\ngit clone https://github.com/emscripten-core/emsdk.git\ncd emsdk\n./emsdk install latest\n./emsdk activate latest\nsource ./emsdk_env.sh\n\ncd ~/Projects\ngit clone git@github.com:mamedev/mame.git\ncd mame\nemmake make SUBTARGET=psion3a SOURCES=psion/psion3a.cpp\nNeedless to say, it didn’t just work out of the box, and I now have a number of errors to contend with which, I suspect, require me to think all-too hard about what’s going on under the hood in JavaScript and WASM-land. 🫠
\n\n
\n![](\"/posts/2024-12-19-december-adventure-day-18/mame-emscripten-fail@2x/400.png\")
\n ",
"date_published": "2024-12-19T19:01:28-08:00",
"id": "https://jbmorley.co.uk/posts/2024-12-19-december-adventure-day-18/",
"title": "December Adventure Day 18",
"url": "https://jbmorley.co.uk/posts/2024-12-19-december-adventure-day-18/"
},
{
"content_html": "Life got in the way of day 17 of my December Adventure making for a slow day with little progress. Still, I managed to find the time to correct my design for a replacement MNT Pocket Reform backplate and post it on GitHub.
\n\n
\n![](\"/posts/2024-12-18-december-adventure-day-17/backplate-technical-drawing/400.png\")
\n \nThankfully I spotted yesterday’s mistake fast enough that PCBWay hadn’t started manufacture and I was able to simply provide them with the updated designs. Hopefully I’ve not missed anything this time around. 🤞🏻
\nIf you’re thinking about trying these designs out for yourself, I encourage you to wait until I’ve received the parts from PCBWay and can confirm they fit correctly.
", "date_published": "2024-12-18T09:58:16-08:00", "id": "https://jbmorley.co.uk/posts/2024-12-18-december-adventure-day-17/", "title": "December Adventure Day 17", "url": "https://jbmorley.co.uk/posts/2024-12-18-december-adventure-day-17/" }, { "content_html": "After an increasingly frustrating few days bashing my head against Apple’s development environment, I decided it was time for a change of pace for day 16 of my Psion-themed December Adventure—it is meant to be a bit of low-stakes fun afer all.
\n\n
\n![](\"/posts/2024-12-17-december-adventure-day-16/pocket-reform/400.jpeg\")
\n \nThe incredibly extra MNT Pocket Reform
\nI’ve enjoyed owning an MNT Pocket Reform ever since their Crowd Supply campaign. It’s no Psion (I have to stay on theme somehow), but I’ve been incredibly impressed with how GNOME scales down to smaller screens and I love having a diminutive device on-hand that’s powerful enough to serve as a modern development environment with sufficient storage to have a copy of all my data (thanks Syncthing). Still, it’s far from perfect and feels a lot like a fussy sports car that demands frequent fettling—the keyboard controller is unpredictable, the WiFi cuts out, and it power cycles without notice.
\nI’ve long suspected many of these issues are related to poor thermals so, when I saw pandora’s post on the MNT forums describing the amazing improvements they’ve seen by replacing the FR-4-based PCB backplate with an aluminum panel, I knew I had to try it out for myself. Although they’ve published design files on their GitHub, it seemed like a good opportunity to try my hand at designing and ordering a custom CNC part.
\nEarlier this year, I ordered a prototype stand for StatusPanel from PCBWay (no, this post isn’t sponsored) that just happened to be purple anodized aluminum so I offered it up in place of the existing backplate to see how it felt and how well the color matched.
\n\n
\n![](\"/posts/2024-12-17-december-adventure-day-16/status-panel-experiment/400.jpeg\")
\n \nMuch to my surprise, the color matched pretty closely—well enough to order a prototype. The contrasting darker purple might even prove a design feature.
\nEncouraged by this, I set about figuring out the exact dimensions and tolerances of the backplate. Fortunately, MNT Research publishes all the schematics and designs for the Pocket Reform on GitHub, so I was able to use the backplate PCB designs for dimensions and the keyboard bezel technical drawings to get the CNC tolerances and details of the countersinks.
\n\n
\n![](\"/posts/2024-12-17-december-adventure-day-16/schematics/400.jpeg\")
\n \nSometimes it’s easier to work on paper
\nI had originally thought I would be able simply amend the keyboard bezel designs and use this for the backplate but when I sized it up (boy am I glad I did this), the screw holes didn’t line up:
\n\n
\n![](\"/posts/2024-12-17-december-adventure-day-16/keyboard-bezel/400.jpeg\")
\n \nTesting the keyboard bezel in place of the backplate
\nMuch to my surprise, the vertical spacing of the screw holes on the top half of the case are different to the keyboard—the horizontal and vertical insets are very slightly different. I was able to confirm this by comparing the top PCB and keyboard bezel designs. Instead, I created my own designs from scratch, using a combination of dimensions from both:
\n \nWith the design in place, I kicked off an order on PCBWay and now it’s just a matter of waiting; $70 shipped to Hawaii doesn’t seem at all bad for a custom milled and anodized part.
\n\n
Having discovered such a significant mistake, I guess day 17 will involve a little more design work. That will also give me a chance to publish the design files so that others can use them (so long as everything works out in the end). I’ve reached out to PCBWay and let them know there’s an error in my design and hopefully they’ve not started production yet. 🤞🏻
", "date_published": "2024-12-17T14:47:47-08:00", "id": "https://jbmorley.co.uk/posts/2024-12-17-december-adventure-day-16/", "title": "December Adventure Day 16", "url": "https://jbmorley.co.uk/posts/2024-12-17-december-adventure-day-16/" }, { "content_html": "Day 15 of my Psion December Adventure brought a continued focus on Reconnect, my Psion connectivity software for macOS. Unfortunately I spent much of the day wrestling with the platform, so these notes focus more on figuring out how the APIs work than they do on presenting a complete feature. That’s just how it goes sometimes.
\nEager to continue to improve the file transfer experience, I’ve been looking at adding drag-and-drop support to the file browser. This should have been easy, but a bunch of rough edges sent me down many rabbit holes—Reconnect is implemented in SwiftUI which continues to fall short on macOS, either failing to provide support for native macOS behavior, deviating significantly from the documentation, or being so buggy that it’s simply unusable. I hit up against many of these issues but I think I figured it out by the end of the day, so I’ll try to walk through the solution in detail here in the hope that it helps others.
\n\n\n
![](\"/posts/2024-12-16-december-adventure-day-15/reconnect-browser@2x/1600.png\"\n)
\n \nThe main Reconnect file browser window
\nThe main browser window of Reconnect uses a SwiftUI Table. The code looks something like this:
![](\"/posts/2024-12-17-december-adventure-day-16/technical-drawing-preview/400.png\")
\n Table(browserModel.files, selection: $browserModel.fileSelection) {\n TableColumn(\"\") { file in\n Image(file.fileType.image)\n }\n .width(16.0)\n TableColumn(\"Name\", value: \\.name)\n TableColumn(\"Date Modified\") { file in\n Text(file.modificationDate.formatted(date: .long, time: .shortened))\n .foregroundStyle(.secondary)\n }\n TableColumn(\"Size\") { file in\n if file.isDirectory {\n Text(\"--\")\n .foregroundStyle(.secondary)\n } else {\n Text(file.size.formatted(.byteCount(style: .file)))\n .foregroundStyle(.secondary)\n }\n }\n TableColumn(\"Type\") { file in\n FileTypePopover(file: file)\n .foregroundStyle(.secondary)\n }\n}\nIn order to support drag-and-drop of these rows, SwiftUI requires us to use a slightly different Table constructor which allows each row to be customized:
Table(of: FileServer.DirectoryEntry.self, selection: $browserModel.fileSelection) {\n ...\n} rows: {\n ForEach(browserModel.files) { file in\n TableRow(file)\n }\n}\nThis alternative constructor pushes the file/row iteration down into a ForEach (in the rows view builder) which lets us apply view modifiers to each TableRow. For example, if file conformed to the Transferable protocol, making these rows draggable should be as simple as:
Table(of: FileServer.DirectoryEntry.self, selection: $browserModel.fileSelection) {\n ...\n} rows: {\n ForEach(browserModel.files) { file in\n TableRow(file)\n .draggable(file)\n }\n}\nBut this is where things start to go awry. SwiftUI actually provides two different mechanisms for making things draggable: .draggable, and .itemProvider. .draggable is the new hotness which, of course, means it’s not actually flexible enough to do what we need in Reconnect.
In order to see why .draggable doesn’t work, I’ll first show some pseudo-code for a complete solution using .itemProvider (where I got to by the end of the day) and then break down how it works:
Table(of: FileServer.DirectoryEntry.self, selection: $browserModel.fileSelection) {\n ...\n} rows: {\n ForEach(browserModel.files) { file in\n TableRow(file)\n .itemProvider {\n let provider = NSItemProvider()\n provider.suggestedName = file.name\n provider.registerFileRepresentation(for: .data) { completion in\n Task {\n let data = await self.browserModel.download([file.id])\n completion(file, false, nil)\n }\n return nil\n }\n return provider\n }\n }\n}\nThere’s a few things going on in this code:
\n.suggestedName lets drag destinations like Finder know what the dragged file should be called.registerFileRepresentation provides a completion block (load handler) that can initiate a file transfer from the Psion to fetch the file data and, crucially, specifies a content type of .data which tells macOS tells macOS to expect completion to be called asynchronously (I wasted a lot of time figuring that out)1Progress instance as a way to communicate load progress, but I’ve not found it makes any difference to the user experience, so nil seems to be sufficientSo why isn’t .draggable good enough? The equivalent implementation certainly seems cleaner:
Table(of: FileServer.DirectoryEntry.self, selection: $browserModel.fileSelection) {\n ...\n} rows: {\n ForEach(browserModel.files) { file in\n TableRow(file)\n .draggable(file)\n }\n}\nAnd, the corresponding Transferable conformance:
extension FileServer.DirectoryEntry: Transferable {\n\n static var transferRepresentation: some TransferRepresentation {\n FileRepresentation(exportedContentType: .data) { item in\n return SendTransferredFile(await self.browserModel.download([item.id]))\n }\n }\n\n}\nThis is much more modern and supports an async block by default, avoiding the need to wrap code in a Task2. Unfortunately, there’s one key aspect missing—there’s no way to specify the desired filename, without which, Finder will always create a file named ‘data’ for every drop operation. Assuming that .draggable and .itemProvider offered identical functionality, I spent a lot of time going down dead-ends trying to work around this until I finally chanced upon the .itemProvider-based solution3. 🤦🏻♂️
Having spent altogether too long poking at .draggable and Transferable before settling on .itemProvider and NSItemProvider, I wasn’t able to fully implement drag-and-drop support, but hopefully I’m well set up to get something working on day 16.
Without this, Finder will beachball until completion is called. Unfortunately, I’ve not been able to find any official documentation stating this, only a discussion on StackOverflow that put me on the right path. ↩
Though ironically, even with explicit async support, this method still has the same absurd synchronous behavior of NSItemProvider.registerFileRepresentation for any data type excepting .data and .folder. ↩
Do let me know if I’ve missed something. I’d love to be able to use Transferable instead. ↩
Day 14 of my Psion-related December Adventure was a somewhat frustrating one—I broke my foot a few months ago and, even now, the pain will turn my brain to mush from time to time. Still, I pressed on with Reconnect, my Psion connectivity software for macOS.
\nOne of the things that’s easy to forget in the rose-tinted haze of nostalgia is that most 90s-era devices didn’t use standard file formats, necessitating translation when moving files back and forth. Psions are no exception. Thanks to Tom’s work on OpoLua, Reconnect has built-in support for converting Psion’s MBM image format, but my implementation has never felt quite right.
\nMBM files can store more than one image (literally Multiple BitMap). Most you’ll encounter as a user contain a single image (screenshots, etc), but as a developer, you’ll often use asset files with multiple images—EPOC32’s Eikon.mbm, for example, contains all the images used in the main user interface. While it’s pretty obvious that single-image MBMs should be converted to a single file (PNG, GIF, etc), it’s less clear what should happen to a multi-image MBM as there are few user-friendly modern file formats that support multiple images.
\nMy first implementation simply unpacked images into the Downloads directory, but for large image files (Eikon.mbm contains 87 images) it can get messy quickly. After much consideration, I’ve settled—for the time being at least—on converting all images to TIFFs which natively support multiple images. These can be easily viewed using Preview on macOS.
\n\n\n
![](\"/posts/2024-12-15-december-adventure-day-14/preview-eikon@2x/1600.png\"\n)
\n \nViewing the converted Eikon.mbm TIFF file in Preview
\nThis change to using TIFF files for MBMs is available in Reconnect 0.14.9. In the long term, I plan to offer different options for converting multi-image MBMs—a folder of images, multi-frame GIF, zip file, etc.
\nHopefully day 15 will bring a little more capacity and I can continue to push on with improving the file transfer experience in Reconnect; I’d still like to add drag-and-drop support.
", "date_published": "2024-12-15T11:50:24-08:00", "id": "https://jbmorley.co.uk/posts/2024-12-15-december-adventure-day-14/", "title": "December Adventure Day 14", "url": "https://jbmorley.co.uk/posts/2024-12-15-december-adventure-day-14/" }, { "content_html": "After taking day 12 off from my Psion December Adventure, I returned on day 13, adding a few quality of life improvements to Reconnect, my modern Psion connectivity software for macOS—I’m planning to spend the rest of the month focused on this and the other tooling that keeps these 30 year old computers going in 2024.
\nWorking on Reconnect feels slower than cranking out OPL but there remain a collection of little fixes that will improve my daily experience and, hopefully, make it a little more enjoyable for others to use.
\nContinuing my focus on the Transfers window, I plumbed through file sizes so I can show the number of bytes remaining in a transfer. This is particularly useful on low-memory devices like the Psions where it’s easy to inadvertently copy a file larger than the whole device’s storage—the extra context can help spot such a mistake early. I also added support for showing previews of completed downloads which I find helps in quickly identifying the correct screenshots for these write-ups.
\n\n\n
![](\"/posts/2024-12-14-december-adventure-day-13/transfers@2x/1600.png\"\n)
\n \nTransfers, now with file sizes and previews!
\nIt doesn’t feel like there’s much novelty in the underlying code itself, with the minor exception of the approach taken to generating the file previews. This necessitated wrapping QuickLook’s classic completion-block API as a new cancellable async function to make it easier to call from SwiftUI:
extension QLThumbnailGenerator {\n\n public func thumbnailRepresentation(fileAt url: URL,\n size: CGSize,\n scale: CGFloat,\n iconMode: Bool) async throws -> QLThumbnailRepresentation {\n let request = Request(fileAt: url, size: size, scale: scale, representationTypes: .thumbnail)\n request.iconMode = iconMode\n return try await withTaskCancellationHandler {\n try await withCheckedThrowingContinuation { continuation in\n generateRepresentations(for: request) { (thumbnail, type, error) in\n if let error {\n continuation.resume(throwing: error)\n return\n }\n continuation.resume(returning: thumbnail!)\n }\n }\n } onCancel: {\n cancel(request)\n }\n }\n\n}\nWhile it looks convoluted, this code is actually relatively simple: it uses the platform-provided withCheckedThrowingContinuation function to convert the classic QLThumbnailGenerator.generateRepresentations completion-block API into an async call, and then wraps that with withTaskCancellationHandler which returns a cancellable Task that will call QLThumbnailGenerator.cancel.
It’s frustrating to have to massage platform-provided APIs in this way, but once it’s done, it’s easy to use in SwiftUI:
\n@MainActor\nstruct ThumbnailView: View {\n\n let url: URL\n let size: CGSize\n\n @State var image: NSImage? = nil\n\n var body: some View {\n Image(nsImage: image ?? NSWorkspace.shared.icon(forFile: url.path))\n .task {\n let thumbnail = try? await QLThumbnailGenerator.shared.thumbnailRepresentation(fileAt: url, size: size, scale: 2.0, iconMode: true)\n image = thumbnail?.nsImage\n }\n }\n\n}\n\nThe .task view modifier ensures the new async API is run once when the view is first attached and cancelled when it’s dismissed (if necessary).
With these usability improvements in-place, I took some time to experiment with adding drag-and-drop support and improving multi-image file conversions—is it better to convert multi-image MBMs to gifs, tiffs, or a zipped directory of image files? Questions for day 14 and beyond.
", "date_published": "2024-12-14T17:04:05-08:00", "id": "https://jbmorley.co.uk/posts/2024-12-14-december-adventure-day-13/", "title": "December Adventure Day 13", "url": "https://jbmorley.co.uk/posts/2024-12-14-december-adventure-day-13/" }, { "content_html": "After nearly two weeks working on my Psion-related December Adventure, I find I’m slowing down. I’m at the stage where the bones of the projects are in place and now it’s a matter of slowly chipping away at a long list of issues. Reconnect, my focus for the day, feels particularly like this, so I allowed myself a little time drafting my x-image write-up, and playing around with Blender to create a splash screen for Thoughts for EPOC.
I set out with the continued goal of improving the experience around file transfers, starting with adding icons to the transfers window. This entailed much remembering how Reconnect works under the hood, and setting the ground work for treating local and remote file references interchangably—in the first instance, this allows me to reference files irrespective of transfer direction (download from Psion, or upload to Psion), but hopefully it will unlock adding support for browsing local file systems as well as remote ones in the future. My ultimate goal here is to show full (locally stored) device backups in the sidebar and allow users to inspect them to access and restore files.
\nenum FileReference {\n case local(URL)\n case remote(FileServer.DirectoryEntry)\n}\nWith this simple FileReference wrapper, I can expose a source-agnostic file item to the transfer operation which I can switch on to select an appropriate icon in SwiftUI:
switch transfer.item {\ncase .local(let url):\n Image(.fileUnknown16)\ncase .remote(let file):\n Image(file.fileType.image)\n}\nThis first-cut just shows an unknown icon for macOS-local files, but it gives me a clear point of customization where I can fetch QuickLook previews and icons.
\nIt works great for downloads:
\n\n\n
![](\"/posts/2024-12-12-december-adventure-day-11/transfers-with-icons@2x/1600.png\"\n)
\n \nThere’s a long list of fairly dull little improvements like this that I’d like to chip away at so I’ll try to do one a day for the next few days.
\nTrying to remind myself this is meant to be fun, I fired up Blender (which I have no idea how to use), and set about rendering out some 90s-era 3D text for the Thoughts for EPOC splash screen.
\n\n
\n![](\"/posts/2024-12-12-december-adventure-day-11/thoughts-splash-blender@2x/400.png\")
\n \nSo far, I’ve added the text, a camera through which to render the scene, and a light source. Nothing I do with the light source seems to work, but at least I was able to render something:
\n\n
\n![](\"/posts/2024-12-12-december-adventure-day-11/thoughts-splash-render/400.png\")
\n \nThis is going to take a while.
", "date_published": "2024-12-12T14:36:22-08:00", "id": "https://jbmorley.co.uk/posts/2024-12-12-december-adventure-day-11/", "title": "December Adventure Day 11", "url": "https://jbmorley.co.uk/posts/2024-12-12-december-adventure-day-11/" }, { "content_html": "After the milestone of ‘shipping’ Thoughts for EPOC 0.01, I decided to take something of a day off for day 10 of my December Adventure, tidy up a few things, and address one or two of the frustrations I’ve encountered on the way. I worked on my website, Thoughts for EPOC, and Reconnect—as one of my readers pointed out, this is starting to look more like a developer diary than a December Adventure, offering a bit of a peek into how I develop and maintain my own little ecosystem of software.
\nUpdating my website every day has given me ample opportunity to notice a few rough edges that I wanted to tidy up, focused almost entirely around the symbols and icons I use to identify the different sections of the site.
\nA couple of months ago, I set up a GitHub Sponsors page and, ever since, I’ve been slowly working out how to talk about it, how to integrate it into my website, and how to make room for one-time services like Buy Me a Coffee. I’m not good at asking for money even though it’s necessary—doing so has always felt somewhat gauche. With that in mind, I’ve tried to surface it in subtle ways. For the time being, I’ve settled on a Support page where I can give a quick overview of what I do and link to places to send me money. To try to gently nudge people towards the page, I’ve added the now-fairly-common heart symbol at the end of the site’s navigation.
\n\n\n
![](\"/posts/2024-12-11-december-adventure-day-10/site-header@2x/1600.png\"\n)
\n \nThe hope is that using a colored symbol instead of text helps it stand out, but also hopefully makes it clear it’s not part of the main content of the site.
\nI’ve also selected a suitable heart for the 2004 theme from the GNOME 2.8.0 icons I used back in the day. (You can try the theme out yourself by selecting the little paintbrush in the bottom-right of this site.)
\n\n\n
![](\"/posts/2024-12-11-december-adventure-day-10/site-header-2004@2x/1600.png\"\n)
\n \nI’m really quite pleased how this one turned out.
\nIn the process of adding the heart, and testing it out on my 2004 theme, I noticed I was missing icons for the style guide and drafts sections and, perhaps more importantly to this December Adventure, missing symbols for the pdavision and PsionStyle links on the main theme. So, I ferreted around the GNOME icons for the 2004 theme, and then broke out Inkscape to create a couple of symbols:
\n![](\"/images/custom/psionstyle.svg\")
\n ![](\"/images/custom/pdavision.svg\")
\nWith Thoughts for EPOC growing, I decided it was time to move my task list out of Obsidian and into GitHub Issues (which I much prefer for larger projects). When working with GitHub Issues, I use Taska which offers a great workflow for raising issues and I find makes everything significantly more manageable.
\n\n\n
![](\"/posts/2024-12-11-december-adventure-day-10/thoughts-issues@2x/1600.png\"\n)
\n \nTaska turns GitHub Issues back into a lightweight todo list
\nIt turns out I successfully nerd sniped Tom and he updated OpoLua’s OPL compiler to add support for generating AIF files. Needless too say, I immediately had to adopt this and update Toughts to automatically create .app and .aif files using GitHub Actions. 🙏🏻🎉
Writing OPL every day and documenting the process means I’m relying heavily on Reconnect, my plptools-based Psion connectivity suite for macOS. Needless to say, I’ve encountered a few frustrations with it over the past few days, so I took some time to focus on a few quality of life improvements.
\nWorking with SwiftUI always goes slower than I think it should for a declarative UI framework, but I managed to make some progress on improving the file transfer workflow. Specifically, the Transfers window now shows a small magnifying glass alongside downloads allowing you to reveal completed transfers in Finder—a small but significant UX optimization:
\n\n\n
![](\"/posts/2024-12-11-december-adventure-day-10/reconnect-transfers@2x/1600.png\"\n)
\n \nThe ‘Clear’ button is also new and, just like the Safari downloads popover, clears any completed and cancelled transfers. I’ve also added support for automatically converting files with the .mbm extension, and not just image files with the relevant UID headers.
It’s been surprisingly fun to return to Reconnect and tidy things a little. Given that, I have a few more visual and functional improvements in mind for day 11.
", "date_published": "2024-12-11T12:31:09-08:00", "id": "https://jbmorley.co.uk/posts/2024-12-11-december-adventure-day-10/", "title": "December Adventure Day 10", "url": "https://jbmorley.co.uk/posts/2024-12-11-december-adventure-day-10/" }, { "content_html": "Continuing with day 09 of my December Adventure, I decided to focus on creating an installer for my OPL version of Thoughts—there’s enough basic functionality in place for it to be useful (to me at least) and I’d love others to be able to try it out.
\nCreating a Psion installer (SIS file) is pretty simple, especially if you’re not worried about localization. It’s just a matter of specifying the supported languages, program metadata, then listing the files (and their destinations) and any secondary installers. The package file for Thoughts looks like this:
\n&EN\n #{\"Thoughts\"},(0x100092ca),0,1,0\n \"C:\\System\\Apps\\Thoughts\\Thoughts.app\"-\"!:\\System\\Apps\\Thoughts\\Thoughts.app\"\n \"C:\\System\\Apps\\Thoughts\\Thoughts.aif\"-\"!:\\System\\Apps\\Thoughts\\Thoughts.aif\"\n\n @\"SystInfo.sis\",(0x10000b90)\nThe ! in the destinations indicates that the files can be installed to any drive the user selects, allowing them to install programs to a Compact Flash card.
This package file will create an installer that bundles the all-important SystInfo.opx library that Thoughts relies on to generate timestamps.
\nAlthough Psion never provided any first-party EPOC32-based tools for working with SIS files, Neuon, a fairly prolific software development group, published nSISUtil which can compile package files on-device. This makes it possible to develop and package an app directly on a Psion which, of course, is exactly what I did.
\n\n
\n![](\"/posts/2024-12-09-december-adventure-day-09/nsisutil-creating-sis/400.png\")
\n \nCreating the installer on-device using nSISUtil
\nJust like resource files, we don’t yet have support for generating installers using the OpoLua tooling, but perhaps at some point I’ll be able to automate the whole process on GitHub Actions. 🙃
\nWith the installer in-hand, I again turned to the Revo as my test device, and was able to confirm it worked, and verify yesterday’s fix for note creation.
\n\n
\n![](\"/posts/2024-12-09-december-adventure-day-09/thoughts-about-to-install/400.png\")
\n \nInstalling Thoughts on my Revo
\n\n
\n![](\"/posts/2024-12-09-december-adventure-day-09/editor-hello-world/400.png\")
\n \nCapturing mission critical information
\nAnd with that, Thoughts for EPOC has reached an important milestone—version 0.01! You can view the release on GitHub, or download it directly here. I’d love your feedback!
\nI started day 08 a little behind typing up Saturday’s December Adventure unexpected side-quest. And then bumped into a frustrating crash in InContext, my site builder, that slowed everything up. With that in mind, I decided to return to my more mellow OPL explorations for the rest of the day. (But not before I shipped a proof-of-concept update to my website’s image handling which will hopefully mean images work in the feed.)
\nReturning to Thoughts for EPOC1—there are a lot of little bugs to fix and tiny improvements I’d like to make:
\n.app instead of a .opoThankfully, it’s a heck of a lot more relaxing than working on a large Swift codebase like InContext, so I just started working my way through them.
\nRemembering back to day 06, I was seeing issues opening the newly created notes in Editor on the Revo—it was just opening the last file I’d been editing. It turns out this was a side effect of using a more recent version of Editor (1.41) that revealed a bug in the way I was calling RUNAPP&:. I was passing the command 2 (run), instead of 0 (open), which was causing Editor to ignore the document parameter and open the most recent document.
I wish there were constants for this (Const.oph contains a constant for KCmdLetterCreate$ which is used by CMD$:, but no equivalent for RUNAPP&:), but at least I have a fix (#3):
k& = RUNAPP&:(\"Editor\", path$, \"\", 0)\nA happy side-effect of using this later version of Editor is that it also comes in color for the Series 7:
\n\n
\n![](\"/posts/2024-12-09-december-adventure-day-08/editor-color/400.png\")
\n \nLook at those rich 256-color icons!
\nNice and simple. Check if the directory exists and, if it doesn’t, create it (#4):
\nREM Ensure the destination directory exists.\nIF NOT EXIST(directory$)\n MKDIR directory$\nENDIF\nI’ll make this configurable later on.
\nOPL programs are compiled to ‘executable’ .opo files by default. These don’t have an icon, and don’t appear in the Extras bar—for this to happen, they need to be built as a .app with a corresponding .aif resource file which contains the app caption, unique identifier, and icon. Fortunately, and much to my surprise as I’ve forgotten most of my 90s-era OPL, achieving this simply a matter of adding a declaration to the top of your OPL file (#7):
APP Thoughts, &100092ca\n CAPTION \"Thoughts\", 1\n ENDA\nThere’s a tiny bit of nuance here: OPL apps are identified by globally unique 32-bit integers which were managed centrally by Psion who aren’t about to be issuing new ones anytime soon. Thankfully, they allocated them in blocks of 10 and I was issued a block starting at &100092c8 back in the 90s. I’ve only used two so far, so &100092ca it is!
\nIn case you’re curious (and for my own reference), my current programs are as follows:
\n| UID | \nProgram | \nDescription | \n
|---|---|---|
| 0x100092c8 | \nnEzumi | \nVirtual pet mouse for your Psion. | \n
| 0x100092c9 | \nGreedy | \nRebuild of the EPOC16 game Greedy by Frédéric Botton for EPOC32. | \n
| 0x100092ca | \nThoughts | \nThoughts! | \n
The only small wrinkle is that OpoLua’s compile.lua (which I’ve been using for my GitHub Actions CI builds) doesn’t support generating .app and .aif files so, while I can still benefit from the ‘compiler’ checks, I can’t automate the full build process (yet).
As I’m slowly getting back into OPL programming and remembering the various conventions, there are occasional refactorings that need to happen to keep everything clean. One of those is to adopt the constants in Const.oph wherever possible. Starting using KEvAType% makes indexing into the ev& array a little clearer and prepares the event processing for more complex behaviors (#5):
WHILE 1\n GETEVENT32 ev&()\n IF ev&(KEvAType%) = KKeyMenu% OR ev&(KEvAType%) = KKeySidebarMenu%\n REM Menu button.\n menu:\n ELSEIF ev&(KEvAType%) = %t AND ev&(KEvAKMod%) = KKModFn%\n REM Global hotkey (Fn + T)\n new:\n ELSEIF ev&(KEvAType%) < 32\n REM Key codes are modified if control is pressed.\n k& = ev&(KEvAType%) + %a - 1\n IF k& = %n\n new:\n ELSEIF k& = %e AND ev&(KEvAKMod%) = KKModControl%\n close:\n ELSEIF k& = %k AND ev&(KEvAKMod%) = KKModControl%\n clear:\n ELSEIF k& = %a AND ev&(KEvAKMod%) = (KKModControl% OR KKModShift%)\n about:\n ELSE\n PRINT k&\n ENDIF\n ELSEIF (ev&(KEvAType%) AND &400) = 0\n PRINT ev&(1), ev&(2), ev&(3), ev&(4), ev&(5)\n ENDIF\nENDWH\nWell, that’s me done for the day and I can update my on-going Thoughts todo list:
\n.app instead of a .opoI also added one new task:
\n.app and .aif buildsStill a bunch of things to keep me occupied this month2 🥲
\nThoughts Lite? Thoughts, EPOC Edition? I really don’t know what I’m calling this. ↩
If you enjoy creating retro graphics and would like to join me on this little adventure, I’d love your help! ↩
When I started the day—day 07 of my December Adventure—I anticipated spending it working on some period-correct graphics for my OPL-based version of Thoughts for EPOC. Little did I know that, waiting in my inbox, would be an email from Jon bestowing upon me a side-quest: the mystery of the missing images! It’s proving pretty involved, so I expect it to span multiple days.
\nJon begins:
\n\n\nI just wanted to ping to say how much I’m enjoying your adventure days, and to beg you for images of the things you’re building.
\n
Thank you.
\n\n\nThen I checked your website and lo and behold, there are images. I wonder if you know that they are absent on the feed?
\n
Well, balls. I’m ashamed to say to say that, yes, I do know they’re absent from the feed. In fact, they’ve been missing ever since I implemented a clever approach to trying to make my website more friendly to low bandwidth connections and browsers without JavaScript. 🤦🏻♂️
\nHe continues:
\n\n\nI looked at the feed and it does have the image reference but it’s enshrouded in mystery:
\n\n<x-image width=\"480.0\" height=\"160.0\">\n <x-source width=\"480\" height=\"160\" src=\"/posts/2024-12-07-december-adventure-day-06/revo/1600.png\"></x-source>\n <x-source width=\"480\" height=\"160\" src=\"/posts/2024-12-07-december-adventure-day-06/revo/1200.png\"></x-source>\n <x-source width=\"480\" height=\"160\" src=\"/posts/2024-12-07-december-adventure-day-06/revo/800.png\"></x-source>\n <x-source width=\"400\" height=\"133\" src=\"/posts/2024-12-07-december-adventure-day-06/revo/400.png\"></x-source>\n <noscript>\n <img width=\"400\" height=\"133\" src=\"/posts/2024-12-07-december-adventure-day-06/revo/400.png\" />\n </noscript>\n</x-image>\nThe mystery being the
\n<x-source>stuff which didn’t exist when I was growing up :-), and the weird<body>tag (should that be there) and the<img>tag, the one that contains the gem, being in a<noscript>thingie.
It makes complete sense that’s a mystery: x-image is a custom HTML tag that wrote for my website and, as far as I can see, something I never wrote about or documented. Perhaps it’s time for that to change—x-image represents the end (or so I thought) of a pretty deep dive into the behavior of the different HTML image tags and something I’d appreciate feedback on.
The real issue here appears to be that the noscript that’s meant to ensure feed readers (and browsers without JavaScript) gracefully fall back to displaying a small image isn’t working.
Oh, and yes, there shouldn’t be any <body> tags int the content_html of my JSON Feed.
\n\nAnyway, I hope that helps, and please carry on!
\n
It does indeed. Thank you. I shall.
\nThis website is built using InContext—my own static website builder. I started working on InContext in 2015 when the myriad static site builders we have these days were significantly less mature. The primary goal was to create a builder that would treat media files (photos, videos, audio, STL models, etc) as first class citizens rather than as an after thought to be thrown in an asset directory1; I wanted to break my dependence on mercurial companies like Google, Apple, and Flickr for hosting my photo library.
\nHaving built pretty much every part of the pipeline that takes my writings and puts them in a web browser (or in this case a feed reader) gives me a lot of control, but also means there’s a lot of places things can go wrong.
\nI decided to start with the errant body tag. This seemed like a red herring so I wanted to eliminate it as a possibility. On closer inspection, it turns out that all inline HTML content was being wrapped with unnecessary html and body tags.
InContext uses a Lua-based templating language called Tilt2 which calls back into Swift to pull content and query documents. A simple page template looks like this:
\n<html>\n <head>\n <title>{{ incontext.titlecase(document.title) }}</title>\n </head>\n <body>\n <h1>{{ incontext.titlecase(document.title) }}</h1>\n {{ document.render() }}\n </body>\n</html>\nAnd the JSON Feed is created similarly, with each entry’s content_html being generated using the render method:
for _, post in ipairs(posts) do\n local item = {\n id = site.url .. post.url,\n url = site.url .. post.url\n }\n if post.content then\n do\n item.content_html = post.render()\n end\n end\n ...\n table.insert(feed.items, item)\nend\nThis calls through to the following code in Swift:
\nstruct DocumentContext: EvaluationContext {\n\n func html() throws -> String {\n let content = try SwiftSoup.parse(document.contents)\n for transform in transforms {\n try transform.transform(renderTracker: renderTracker, document: self, content: content)\n }\n return try content.html()\n }\n\n}\nWith a few breakpoints, I was able to determine that somewhere between document.contents and content.html(), outer html and body tags are introduced.
document.contents represents the raw HTML content of the page (converted from Markdown) and this part of the pipeline converts the HTML to a DOM to allow for a collection of lightweight transforms to run to fix-up things like relative paths before returning it to HTML to be included by the templates. It turns out that SwiftSoup always constructs a body irrespective of the input HTML that I need to strip:
struct DocumentContext: EvaluationContext {\n\n func html() throws -> String {\n let content = try SwiftSoup.parseBodyFragment(document.contents)\n for transform in transforms {\n try transform.transform(renderTracker: renderTracker, document: self, content: content)\n }\n return try content.body()?.html() ?? \"\"\n }\n\n}\nYou’ll notice I’ve also changed the SwiftSoup.parse call to SwiftSoup.parseBodyFragment—some digging into the documentation revealed that SwiftSoup.parse isn’t guaranteed to correctly preserve some tags if the input isn’t a full HTML document.
One mystery solved. 🔎
\nAll the moving parts of InContext made progress slow—it’s all a little more nuanced than a starter-OPL program—so that’s all for day 07. I anticipate day 08 will bring more investigations into x-image in preparation for the 90s-era graphics I want to create for Thoughts.
Things like Hugo’s Page Resources come pretty close these days but, back in 2015, it just wasn’t happening. ↩
Nearly a week into my December Adventure (happy Friday!) and it feels like I’ve a text file full of notes and ideas, and a downloads directory full of reference files and links. To ensure I can stay on top of things as the month progresses, I spent a little time on Thoughts, but also allowed myself to tie up some loose ends and work on some related side-quests (ROMs, psion.info, and OpoLua) lest they continue to bounce around my head.
\nI took some time out to set up CI builds using GitHub Acitons and compile.lua from OpoLua. I hit up against a few teething troubles—compile.lua didn’t parse the MENU function correctly—but Tom kindly poked around and fixed a few things. With the fix in place, compiling Thoughts was a simple matter of ensuring my GitHub Actions runner had Lua installed and doing something like:
COMPILE_PATH=\"$SCRIPTS_DIRECTORY/opolua/src/compile.lua\"\n\nlua \"$COMPILE_PATH\" \"$ROOT_DIRECTORY/Thoughts/Thoughts.opp\" \"$ROOT_DIRECTORY/Thoughts/Thoughts.opo\"\nI did encounter a small issue relating to my dependency on SystInfo.opx which seems worth noting here to aid others and for my own future reference. Specifically, the only downloadable version of SystInfo I’ve been able to find1 includes a .txh header file, not an .oxh and, while nOPL+ is more than happy for me to IMPORT \"SystInfo.txh\", compile.lua only has hard-coded support for SystInfo.oxh. I worked around this by creating my own SystInfo.oxh by importing the .txh into OPL on the Psion and saving the resulting file (.oxh files are in the EPOC32-native OPL format and .txh files are plaintext). This allows me to IMPORT \"SysInfo.oxh\" which works in both nOPL+ and GitHub Actions. Feels like something we need to improve on in the future.
I’m unsure how the CI will grow as I start to add more source files, resources, and ultimately package everything up as an installer, but it feels like a great start—perhaps one of the first times anyone’s had continuous integration for an OPL program?
\nWith the administrative bits of build and continuous integration out of the way, I took a little time to add global hotkey support so I can quickly compose a new note whatever I’m doing. Fortunately, unlike modern pesky security conscious operating systems, System.opx provides an off-the-shelf way of doing this, in the form of CAPTUREKEY&:—calling this this ensures matching key events are always dispatched to our program’s waiting GETEVENT32:
REM Capture the global hotkey.\ncapture& = CAPTUREKEY&:(%t, KModifierFunc&, KModifierFunc&)\n\nWHILE 1\n GETEVENT32 ev&()\n k& = ev&(1)\n IF k& = KKeyMenu% OR k& = KKeySidebarMenu%\n REM Menu button.\n menu:\n ELSEIF k& = %t AND ev&(4) = KKModFn%\n REM Global hotkey (Fn + T)\n new:\n ELSEIF k& < 32\n\n ...\n\n ENDIF\nENDWH\nHard coding the global hotkey to Fn + T feels a little ugly so I plan to allow users to customize this in the future but, for the moment, it works! 🎉
\nAfter the last few days, my energy for working on Thoughts was running low, but I did take a few moments to try it out on my Revo. That immediately reminded me that I need an installer as I didn’t have SystInfo.opx installed, and that I need to automatically create the directory notes are stored in if it doesn’t exist. Still, I was able to get it running after a little manual futzing.
\n\n
\n![](\"/posts/2024-12-07-december-adventure-day-06/revo/400.png\")
\n \nEverything feels tiny on the Revo after the Series 7
\nUnfortunately, while Thoughts happily creates the new note on the file system and correctly writes the metadata, the call to RUNAPP&: seems to loose the path and Editor opens an empty file every time. A problem for another day.
I finally got around to adding George’s recent Series 7 ROM dump to explit7/Psion-ROM.
\n| Device | \nEPOC32 Version | \nROM Version | \nLanguage | \nFilename | \nMD5 Checksum | \n
|---|---|---|---|---|---|
| Psion Series 7 | \n\n | 1.05 (254) (Build 754) | \nEnglish | \nseries71.05254build756.bin | \nc78c3cf48d2fd7b8f0d5bc9cadd79159 | \n
It’s been really fun to watch efforts to get this ROM booting in emulation over the last week—clearly early days but exciting stuff!
\nFor the past couple of months, I’ve been slowly working on a Hugo-based version of the psion.info landing site that Alex put together. My goal is to be able to offer something up which is a little easier to maintain, that scales well to hosting the wealth of information the Discord community shares, and is easy for others to contribute to. Since I’ve been collecting quite a bit of Psion-related documentation on the course of this December Adventure, I thought it might be nice to pause and see how that might fit into this prototype site.
\nFirst up, the Hugo documentation provides a great guide on generating tables from CSV files which I was able to pair with DataTables to render out a sortable and searchable table of the ROMs I’ve been adding to GitHub this week:
\n\n
\n![](\"/posts/2024-12-07-december-adventure-day-06/psion-info-roms@2x/400.png\")
\n \nWith the appropriate templates and shortcodes added to the site theme, this ends up being a really simple page to create and edit that can hopefully be a helpful resource for people looking to dig into the details of the Psion handhelds and get started with emulation.
\nI also knocked up a proof-of-concept for publishing a folder of images, like this collection of Psion marketing images:
\n\n
\n![](\"/posts/2024-12-07-december-adventure-day-06/psion-info-marketing@2x/400.png\")
\n \nEven if we don’t end up using this new variant of the site, it’s proving a really interesting exercise to figuring out how to store and present many years of fairly involved information. I see why Alex is so drawn into the Psion Documentation Project.
\nOn a roll, and with fresh and newly acquired knowledge of DataTables, I stepped over to OpoLua, our OPL runtime for iOS and macOS. I’ve been meaning to simplify how we track what programs do and don’t work for some time now as updating an HTML table for every new program is painfully slow. I’ve shifted this over to a CSV file stored in the source tree which we can hopefully add to more easily over time meaning the list will remain current (did I mention we accept PRs?). This should also make it much easier to use this as a source-of-truth when recommending programs to try out in OpoLua itself.
\n\n
\n![](\"/posts/2024-12-07-december-adventure-day-06/opolua-status@2x/400.png\")
\n \nThe list of possible directions for this December Adventure Random Walk seems to get longer-and-longer but hopefully I’ve managed to tidy things up a bit and I can focus a little more—there’s still lots to do to tidy up Thoughts and I’ve barely touched on my Psion emulation related ideas. 😮💨
After the relative successes of the last few days, it’s been a day of taking stock in my December Adventure and focusing exclusively on Thoughts—no ROM uploads today.
\nI started the day by creating a GitHub repository for Thoughts and committed the current version. Without native support for git on my Psion1, I suspect updates will be a little more sporadic than usual, but I’ll try to push each day’s additions.
\nHaving the Thoughts source on my Mac for the first time since starting, I tried running it through Tom’s new Lua-based OPL compiler and was pleasantly surprised to see it worked perfectly. Perhaps tomorrow I’ll set up automated builds using GitHub Actions.
\nI also took a little time out over my morning coffee to improve my workflow—switching between running programs is a multi-step process in EPOC32 and I’m constantly bouncing back and forth between my source, OPL reference, and Thoughts itself. Thanks to a suggestion by Fabrice, I settled on nSwitcher which offers a NeXTSTEP-like dock and the Ctrl + Space global shortcut for cycling between programs.
\n\n
\n![](\"/posts/2024-12-06-december-adventure-day-05/nswitcher/400.png\")
\n \nnSwitcher makes me feel elite
\nWith everything a little tidier, and the basic functionality in place, I went about setting up an application framework on which I can build other features—OPL apps commonly centered around a polling loop, and Thoughts will follow this pattern.
\nFirst up, the main: needs to watch for input events:
PROC main:\n GLOBAL CRLF$(2)\n LOCAL ev&(16), k&\n\n initglobals:\n clear:\n\n WHILE 1\n GETEVENT32 ev&()\n k& = ev&(1)\n IF k& = KKeyMenu% OR k& = KKeySidebarMenu%\n menu:\n ELSEIF k& < 32\n REM Key codes are modified if control is pressed. I don't know why.\n k& = k& + %a - 1\n IF k& = %n\n new:\n ELSEIF k& = %e AND ev&(4) = KKModControl%\n close:\n ELSEIF k& = %k AND ev&(4) = KKModControl%\n clear:\n ELSEIF k& = %a AND ev&(4) = (KKModControl% OR KKModShift%)\n about:\n ELSE\n PRINT k&\n ENDIF\n ELSEIF (ev&(1) AND &400) = 0\n PRINT ev&(1), ev&(2), ev&(3), ev&(4), ev&(5)\n ENDIF\n ENDWH\n\nENDP\nHere, I’m using the synchronous, blocking GETEVENT32 call to poll for events. If you look at the event processing though, you’ll notice some pretty grim manipulation of the key code to handle keyboard shortcuts (things like Ctrl + N, etc). I’ve not found a good discussion of why yet, but hopefully I can figure it out over the next few days and update the code with an explanation at the very least; magic numbers make me incredibly nervous.
The original code is now pushed down into the new: procedure, and I’m able to add the other functionality.
A main menu:
\nPROC menu:\n LOCAL m%\n \n mINIT\n mCARD \"File\", \"New\", -%n, \"Close\", %e\n mCARD \"View\", \"Clear\", %k\n mCARD \"Tools\", \"About Thoughts...\", %A\n m% = MENU\n \n IF m% = %n\n new:\n ELSEIF m% = %e\n close:\n ELSEIF m% = %k\n clear:\n ELSEIF m% = %A\n about:\n ENDIF\nENDP\n\n
\n![](\"/posts/2024-12-06-december-adventure-day-05/menu/400.png\")
\n \nAnd an about screen:
\nPROC about:\n dINIT \"About Thoughts\"\n dTEXT \"\", \"Copyright \" + CHR$(169) + \" Jason Morley 2024\"\n dBUTTONS \"OK\", 13 + $100\n DIALOG\nENDP\n\n
\n![](\"/posts/2024-12-06-december-adventure-day-05/about/400.png\")
\n \nThankfully OPL provides dedicated structures and calls for presenting UI like menus and dialogs, making it incredibly easy to create programs with a native look and feel.
\nAs Thoughts is starting to take shape, I find myself wanting to add some 90s-era graphics to give it character. I also need to add global hot key support, and build an installable app. Lots to keep me entertained.
\nYes, that would be an interesting side-quest. No, I’m not going to try it. ↩
It’s been a successful fourth day of my December Adventure—there are a few too many threads but I feel like I’m making progress: I went on a tiny side-quest to fix the way tables are displayed on my website, uploaded a few more ROMs, and continued to bash my head at OPL.
\nJust like yesterday, I find myself incredibly grateful for the on-going interest and support others have given me—both Fabrice and Tom kept me on-track with my OPL pursuits and Alex gave me a couple of pointers about the Psion Workabout.
\nYou know the drill at this point: I added some new ROMs to the Psion-ROM repository—Workabout and Workabout MX this time around.
\nThe Workabout devices are rugged, industrial handhelds, intended for use in warehouse environments. They run seemingly fully-featured EPOC16 and have absolutely tiny screens making for perhaps the cutest rendition of the operating system I’ve seen.
\n\n
\n![](\"/posts/2024-12-04-december-adventure-day-04/workabout-screenshot@2x/400.png\")
\n \nEPOC in miniature
\n| Device | \nEPOC16 Version | \nROM Version | \nLanguage | \nFilename | \nMD5 Checksum | \n
|---|---|---|---|---|---|
| Psion Workabout | \n3.56f | \n0.24b | \nEnglish | \nw1_v0.24b.bin | \n1afac14fe87e19e7d29d494177dc58d9 | \n
| Psion Workabout | \n3.56f | \n1.00f | \nEnglish | \nw1_v1.00f.bin | \n87c84a27bc71df5e19ac1208735a7a1e | \n
| Psion Workabout | \n3.96f | \n2.40f | \nEnglish | \nw1_v2.40f.bin | \n10b9a0c9174aec0316571827dce42013 | \n
| Device | \nEPOC16 Version | \nROM Version | \nLanguage | \nFilename | \nMD5 Checksum | \n
|---|---|---|---|---|---|
| Psion Workabout MX | \n4.31f | \n7.20f | \nEnglish | \nw2mx_v7.20f.bin | \nd5e5c2aa32f9888e7fec8d2214f1547e | \n
Unfortunately I didn’t get around to adding the new Series 7 ROM dump to the repository. Tomorrow, I hope. 🤞🏻
\nThanks to input from both Tom and Fabrice, the EPOC version of Thoughts feels like it made massive progress today as I was finally able to put everything I’ve worked on over the last few days into an end-to-end demo.
\n\n
\n![](\"/posts/2024-12-04-december-adventure-day-04/thoughts-files/400.png\")
\n \nTimestamped files generated using Thoughts
\nI ended yesterday stuck trying to apply the long representation of the UTC offset returned by SIUTCOffset&: to the date/time returned by DTNOW&:. I had incorrectly assumed that the date/time would be conveniently represented as seconds since epoch (1970-01-01) allowing me to simply subtract the UTC offset. Instead, it turns out all Date.opx operations (functions prefixed by DT) return an opaque pointer to an underlying date/time object which you can only interact with through dedicated functions.
Consider the following code:
\ntimestamp&=DTNOW&:\noffset&=SIUTCOffset&:\nyear&=DTYEAR&:(timestamp&-offset&)\nThis fails because, although timestamp& is a long, it is actually a pointer, so subtracting offset& results in a pointer to goodness knows where and the call to DTYEAR&: ends up operating on random memory.
Finding a suitable API to work around this proved challenging. Out of the box, OPL provides the following functions:
\nDATETOSECS—converts a collection of date and time components to a timestamp represented as seconds since epochSECSTODATE—extracts the date and time components from a timestamp represented as seconds since epochThese both look incredibly helpful and would seem to imply there’s an easy way to get the current time as seconds since epoch. Unfortunately that’s not the case: the language provides DATIM$ which, ‘returns the current date and time from the system clock as a string’, but seemingly nothing that returns seconds since epoch. In fact, it looks like the best you can do with the native OPL API is:
LOCAL timestamp&\ntimestamp& = DATETOSECS(YEAR, MONTH, DAY, HOUR, MINUTE, SECOND)\nWhile it might not be immediately obvious, YEAR, MONTH, DAY, HOUR, MINUTE, and SECOND are all function calls, meaning this code is incredibly susceptible to race conditions and is likely to lead to some wacky results—consider what happens, for example, if the minute rolls-over before the SECONDS call is performed.
Instead of using this mildly terrifying approach, and thanks to a suggestion from Tom, I settled on using DTSECSDIFF&: from Date.opx which allows me to calculate the number of seconds between two dates:
PROC NOW&:\n REM Return the current time as seconds since epoch.\n LOCAL epoch&, now&, result&\n\n epoch&=DTNEWDATETIME&:(1970,1,1,0,0,0,0)\n now&=DTNOW&:\n result&=DTSECSDIFF&:(epoch&,now&)\n DTDELETEDATETIME:(epoch&)\n DTDELETEDATETIME:(now&)\n\n RETURN result&\nENDP\nI have to manually define epoch&, but this provides a robust way to get the current date/time as seconds since epoch and allows me to avoid Date.opx’s quirky opaque date/time objects wherever possible.
This approach necessitates an update to ISO8601$: which is (fortunately) significantly simplified as I can now take advantage of SECSTODATE:
PROC ISO8601$:(timestamp&, utcOffset&)\n REM Return an ISO 8601 formatted date and time with UTC offset.\n REM Result is guaranteed to be 25 characters long.\n\n LOCAL year%, month%, day%, hour%, minute%, second%, yearday%\n LOCAL offsetSign$(1), offsetHours&, offsetMinutes&\n\n REM Extract the timestamp components.\n SECSTODATE timestamp&, year%, month%, day%, hour%, minute%, second%, yearday%\n\n REM Extract the offset components.\n offsetHours& = IABS(utcOffset& / 3600)\n offsetMinutes& = MOD&:(utcOffset& / 60, 60)\n IF (utcOffset& < 0)\n offsetSign$=\"-\"\n ELSE\n offsetSign$=\"+\"\n ENDIF\n\n RETURN NUM$(year%, 4) + \"-\" + ZPAD$:(month%, 2) + \"-\" + ZPAD$:(day%, 2) + \"T\" + ZPAD$:(hour%, 2) + \":\" + ZPAD$:(minute%, 2) + \":\" + ZPAD$:(second%, 2) + offsetSign$ + ZPAD$:(offsetHours&, 2) + \":\" + ZPAD$:(offsetMinutes&, 2)\nENDP\nIt also allows me to generate my UTC filenames in a very similar way and just apply the UTC offset by subtracting it:
\nPROC BASENAME$:(timestamp&, utcOffset&)\n REM Return a string representation of timestamp& and utcOffset& suitable for using in a filename.\n REM Result is guaranteed to be 19 characters long.\n \n LOCAL utcTimestamp&\n LOCAL year%, month%, day%, hour%, minute%, second%, yearday%\n\n utcTimestamp&=timestamp&-utcOffset&\n SECSTODATE utcTimestamp&, year%, month%, day%, hour%, minute%, second%, yearday%\n\n RETURN NUM$(year%, 4) + \"-\" + ZPAD$:(month%, 2) + \"-\" + ZPAD$:(day%, 2) + \"-\" + ZPAD$:(hour%, 2) + \"-\" + ZPAD$:(minute%, 2) + \"-\" + ZPAD$:(second%, 2)\nENDP\nWith all this nuanced code in place, actually assembling a Frontmatter header, writing it to a timestamped file, and launching Editor—the bulk of the functionality—seemed oddly simple (albeit a little bloated):
\nPROC main:\n LOCAL k&\n LOCAL timestamp&, offset&, date$(25)\n LOCAL basename$(22), path$(255)\n LOCAL content$(255)\n LOCAL handle%\n LOCAL r%\n\n REM Get the current timestamp and offset.\n timestamp&=NOW&:\n offset&=SIUTCOffset&:\n\n REM Format the date, path, and content.\n date$ = ISO8601$:(timestamp&, offset&)\n basename$ = BASENAME$:(timestamp&, offset&)\n path$ = \"C:\\Thoughts\\\" + basename$ + \".md\"\n content$ = \"---\" + CRLF$: + \"date: \" + date$ + CRLF$: + \"---\" + REPT$(CRLF$:, 2)\n\n REM Write the metadata to the file.\n r% = IOOPEN(handle%, path$, 1)\n IF (r% <> 0)\n REM TODO: Present the error.\n PRINT \"Failed to open file with error \" + NUM$(r%, 2) + \".\"\n GET\n RETURN\n ENDIF\n REM TODO: Check the number of bytes written.\n IOWRITE(handle%, ADDR(content$) + 1, LEN(content$))\n r% = IOCLOSE(handle%)\n IF (r% <> 0)\n REM TODO: Present the error.\n PRINT \"Failed to close file with error \" + NUM$(r%,2) + \".\"\n GET\n RETURN\n ENDIF\n\n REM Open the file.\n k& = RUNAPP&:(\"Editor\", path$, \"\", 2)\n\n REM GET\nENDP\nNow, running my newly translated ‘Thoughts.opo’ will open a new timestamped file in Editor, ready for me to type my notes:
\n\n
\n![](\"/posts/2024-12-04-december-adventure-day-04/thoughts-new-document/400.png\")
\n \nTomorrow, I plan to add support for launching Thoughts from one of the Series 7’s silkscreen buttons and implementing a global hotkey for devices like the Series 5 and Revo. I’d also like to check this initial version of the project into git so others can follow along more easily.
", "date_published": "2024-12-05T00:30:54-08:00", "id": "https://jbmorley.co.uk/posts/2024-12-04-december-adventure-day-04/", "title": "December Adventure Day 04", "url": "https://jbmorley.co.uk/posts/2024-12-04-december-adventure-day-04/" }, { "content_html": "Continuing my Psion-themed December Adventure, I returned to Sunday’s sorting of ROMs, and chipped away at the OPL take on Thoughts I started yesterday. I’m also rapidly learning that one of the advantages of slowing down a little and writing up my daily adventures is getting to share them with others and, quite wonderfully, receiving realtime feedback, suggestions and contributions.
\n\n
\n![](\"/posts/2024-12-03-december-adventure-day-03/emulators@2x/400.png\")
\n \nI spent some time adding more Psion ROMs to explit7/Psion-ROM—Sienna, Series 3c, and Series 3mx this time around. Thanks to feedback from Alex, I’ve also added MD5 checksums and EPOC16 versions (the latter really helps differentiate between device variants and language variants). There are still a few gaps in the table as I’ve yet to find for myself where the EPOC16 version comes from but hopefully I can flesh that out over the next couple of days.
\nThe additions are as follows:
\n| Device | \nEPOC16 Version | \nROM Version | \nLanguage | \nFilename | \nMD5 Checksum | \n
|---|---|---|---|---|---|
| Psion Siena | \n3.70f | \n4.20f | \nEnglish | \nvine_v4.20f.bin | \n242e80fdbf9b353a05f6ff4d1db1c769 | \n
| Device | \nEPOC16 Version | \nROM Version | \nLanguage | \nFilename | \nMD5 Checksum | \n
|---|---|---|---|---|---|
| Psion Series 3c | \n3.91f | \n5.20f | \nEnglish | \noak_v5.20f_eng.bin | \n3c1a079f53c00916e8d0dc11b35a0390 | \n
| Device | \nEPOC16 Version | \nROM Version | \nLanguage | \nFilename | \nMD5 Checksum | \n
|---|---|---|---|---|---|
| Psion Series 3mx | \n4.08f | \n6.16f | \nEnglish | \nmaple_v6.16f_uk.bin | \n64572cc3522447179d1e6f3b8fb45360 | \n
| Psion Series 3mx | \n\n | 6.20f | \nFrench | \nmaple_v6.20f_fre.bin | \n1b367e2fb862545cf420ff74a7f85ea7 | \n
Looking over the listings of ROMs have been dumped for these devices, it’s abundantly clear that we’re missing many localizations—I understand we know of at least English, French, German, Italian, Flemish, and Dutch variants of the 3c, so we’ve a long way to go. If you have a non-English version of these devices, please get in touch by dropping me a mail or joining us in Discord. We’d absolutely love to talk you through the process and would be eternally grateful!
\nAs an aside, I love how the ROM files use the device codenames and am tempted to surface those as an explicit column. I’ve also just learned that we have a newly minted Series 7 ROM dump, so that’s on the list for tomorrow.
\nFabrice Cappaert spotted a bug in my ZPAD implementation (see yesterday’s notes)—I was using an IF instead of a WHILE-loop when checking to see if my target string was long enough, meaning it would never have worked for pads longer than 1. (Just goes to show that even for small programs, it’s worth unit testing things.) Thankfully, he also offered up a significant simplification which we both suspect will work more efficiently given the costs of certain operations in OPL:
PROC ZPAD$:(value&,length%)\n REM Left-pad strings with '0' up to a length, length%.\n RETURN RIGHT$(REPT$(\"0\",length%)+NUM$(value&,length%),length%)\nENDP\nThis approach also allows me to avoid using a local fixed-size string which makes it far more flexible than the previous implementation which implicitly limited length% to 10.
Perhaps most-crucially however, was Fabrice’s help with OPL time zone wrangling: the macOS version of Thoughts stores the UTC offset in the ISO 8601 timestamp and this is functionality I really want to preserve in the OPL version1. Yesterday, I was starting to get a little nervous about my ability to implement this as I couldn’t find built-in functions to get the user’s UTC offset, even though it’s clear from the World app that the Psion knows where I am and my time relative to UTC.
\n\n
\n![](\"/posts/2024-12-03-december-adventure-day-03/world-honolulu/400.png\")
\n \nMy Series 7 clearly knows I live in Hawaii
\nThankfully, Fabrice pointed me at one of the first-party after-market native libraries—SystInfo.opx—which provides SIUTCOffset&:. This returns the UTC offset in seconds and, a few calls to MOD and IABS later, I was able add the UTC offset to my ISO 8601 formatted date:
PROC ISO8601$:(datetime&,utcOffset&)\n REM Return an ISO 8601 formatted date and time with UTC offset.\n REM Result is guaranteed to be 25 characters long.\n\n LOCAL year&, month&, day&, hour&, minute&, second&\n LOCAL offsetSign$(1), offsetHours&, offsetMinutes&\n LOCAL result$(25)\n\n REM Extract the datetime components.\n year&=DTYEAR&:(datetime&)\n month&=DTMONTH&:(datetime&)\n day&=DTDAY&:(datetime&)\n hour&=DTHOUR&:(datetime&)\n minute&=DTMINUTE&:(datetime&)\n second&=DTSECOND&:(datetime&)\n\n REM Extract the offset components.\n offsetHours&=IABS(utcOffset&/3600)\n offsetMinutes&=MOD&:(utcOffset&/60,60)\n IF (utcOffset& < 0)\n offsetSign$=\"-\"\n ELSE\n offsetSign$=\"+\"\n ENDIF\n\n RETURN NUM$(year&,4) + \"-\" + ZPAD$:(month&,2) + \"-\" + ZPAD$:(day&,2) + \"T\" + ZPAD$:(hour&,2) + \":\" + ZPAD$:(minute&,2) + \":\" + ZPAD$:(second&,2) + offsetSign$ + ZPAD$:(offsetHours&,2) + \":\" + ZPAD$:(offsetMinutes&,2)\nENDP\nIt’s not pretty, but it works
\nIt’s not all been plain sailing though. In addition to storing an ISO 8601 date and time with a UTC offset in the note metadata, I wish to name the file using a UTC date and time to ensure they sort correctly on the file system. For example, a note published at 2024-12-02T16:05:06-10:00 should be named 2024-12-03-02-05-06.md. While I had expected this to be simple (subtract utcOffset% from datetime& and generate a string similarly to the code above), it seems OPL date/times are a little bit magical.
Consider the following code:
\nLOCAL timestamp&, offset&, utcTimestamp&\nLOCAL year&\n\nREM Get the current timestamp and offset.\ntimestamp&=DTNOW&:\noffset&=SIUTCOffset&:\n\nREM Calculate the UTC timestamp.\nutcTimestamp&=timestamp&-offset&\n\nREM Extract the datetime components.\nyear&=DTYEAR&:(utcDatetime&)\nWhile you might expect this to work, it fails with ‘Invalid arguments’ as utcTimestamp& is apparently no longer a valid date/time, even though both timestamp& and utcTimestamp& both behave like longs when passed to many functions. I can only assume they’re backed by a magical object under the hood. Hopefully I can find a way to get the UTC timestamp directly, or initialize a new date/time with a long, but that’s one for another day.
The UTC offset allows notes to be displayed in note-local time, UTC time, or the reader-local time. ↩
Despite writing OpoLua, a modern OPL runtime for iOS and macOS, it’s a long time since I’ve actually written anything in OPL. So what better for a Psion-themed December Adventure than to return to one of the languages that started it all for me?
\n\n
\n![](\"/posts/2024-12-03-december-adventure-day-02/noplplus/400.png\")
\n \nRemembering how to write OPL using nOPL+
\nEarlier this year, I published Thoughts, a lightweight Markdown-based note taking app for macOS which I use primarily for journaling and I thought it would be nice to bring a couple of the main features to my writing experience on EPOC32—a kind of ‘Thoughts-lite’ if you will.
\nThoughts is a simple app offering the following functionality:
\nIt generates Markdown files that look something like this:
\n---\ndate: '2024-11-26T09:23:55-10:00'\ntags: []\nlocation:\n latitude: 2.15791762399229e+1\n longitude: -1.58105437871125e+2\n name: 61-535 Kamehameha Hwy\n locality: \"Hale\\u02BBiwa\"\n---\n\nSelecting multiple matching words in Helix can be done using:\n\nmiw*vn\nWhile it might disappoint some members of the Psion community1, I’ve no plans to tackle a dedicated Markdown editor—I find the Symbian-published Editor just great for writing—but I would like to automatically create and timestamp new notes, and pre-populate them with some Frontmatter for filling in tags.
\nStarting simple, my initial focus is on generating an IS0 8601-formatted timestamp as used by Thoughts. Unfortunately OPL doesn’t make this easy as it’s lacking some basics—I first had to write a way to zero-pad numbers:
\nPROC ZPAD$:(value&,length%)\n REM Left-pad numbers with '0' up to a length, length%, maximum 10.\n LOCAL result$(10)\n result$=NUM$(value&,length%)\n IF LEN(result$) < length%\n result$ = \"0\" + result$\n ENDIF\n RETURN result$\nENDP\nWith that in place, I was able to approach a procedure to format a datetime as ISO 8601:
\nPROC ISO8601$:(datetime&)\n LOCAL year&, month&, day&, hour&, minute&, second&, result$(25)\n\n REM Extract the relevant components.\n year&=DTYEAR&:(datetime&)\n month&=DTMONTH&:(datetime&)\n day&=DTDAY&:(datetime&)\n hour&=DTHOUR&:(datetime&)\n minute&=DTMINUTE&:(datetime&)\n second&=DTSECOND&:(datetime&)\n\n REM Construct the ISO8601 string.\n result$=NUM$(year&,4) + \"-\" + ZPAD$:(month&,2) + \"-\" + ZPAD$:(day&,2) + \"T\" + ZPAD$:(hour&,2) + \":\" + ZPAD$:(minute&,2) + \":\" + ZPAD$:(second&,2)\n\n RETURN result$\nENDP\nDuring this process, I found myself relying heavily on nOPL+, a minimal OPL IDE that, crucially, includes a built-in OPL reference:
\n\n
\n![](\"/posts/2024-12-03-december-adventure-day-02/noplplus-help/400.png\")
\n \nWith my newly-crafted procedure, testing it is simply a matter of getting the current date, calling it with OPL’s weird syntax, and printing the output (not forgetting to use GET to wait for the user to press a key lest my program exits before I see what it’s done):
INCLUDE \"date.opx\"\n\nPROC main:\n LOCAL now&, date$(25)\n now&=DTNOW&:\n date$=ISO8601$:(now&)\n PRINT date$\n GET\nENDP\nSuccess:
\n2024-12-03T03:23:25\nYou might notice I’ve made no attempt to tackle time zones in this implementation, but that’s enough for day 2—remembering OPL’s many quirks took quite a bit longer than I’d expected and the seasonal festivities are already underway. 🎉
\nYou know who you are. ↩
After altogether too much deliberation I settled on a Psion-themed December Adventure (with room for an occasional peripherally related side-quest). Since I’ve collected many different Psion-related projects over the last 25-or-so years, I anticpate this being a bit of a random-walk, but hopefully things will start pulling together as the month progresses.
\nStarting off slowly today, I set about writing up the Psion emulation options in MAME and packaging things up to make them easier for others to use (building on top of my journey into Linux desktop entries a few days ago). That write-up is still in progress, but I was able to start getting to grips with all the ROMs the community has collected over the years and made my first pull request to the explit7/Psion-ROM GitHub repository. This repo is rapidly becoming the authorative resource for Psion images and my change adds the Psion Series 3a variant ROMs from the MAME project in the hope that they’ll be a little easier for others to find.
\nMy understanding is that the MAME ROM set represents everything that’s been dumped to-date. It contains the following device variants:
\n| Device | \nRAM | \nVersion | \nLanguage | \nFilename | \n
|---|---|---|---|---|
| Psion Series 3a | \n1MB | \n3.22f | \nEnglish | \ns3a_v3.22f_eng.bin | \n
| Acorn Pocket Book II | \n1MB | \n1.30f | \nEnglish (ACN) | \npb2_v1.30f_acn.bin | \n
| Psion Series 3a | \n2MB | \n3.40f | \nEnglish | \ns3a_v3.40f_eng.bin | \n
| Psion Series 3a | \n2MB | \n3.40f | \nItalian | \ns3a_v3.40f_ita.bin | \n
| Psion Series 3a | \n2MB | \n3.40f | \nUSA | \ns3a_v3.40f_usa.bin | \n
| Psion Series 3a | \n2MB | \n3.41f | \nGerman | \ns3a_v3.41f_deu.bin | \n
| Psion Series 3a | \n2MB | \n3.43f | \nRussian | \ns3a_v3.43f_rus.bin | \n
The significant bump in version number between the 1MB and 2MB is fascinating to me—it turns out the 2MB version came with two additional programs (Spell and Patience) which I had always assumed were limited to the Series 3c and 3mx models.
\n\n
\n![](\"/posts/2024-12-01-december-advenuture-day-01/more-programs@2x/400.png\")
\n \nSpell and Patience were introduced in the 2MB Series 3a
\nWe’re still looking for Belgian and Dutch ROMs so if anyone out there has one, please drop me an email or join us on the Psion Discord.
", "date_published": "2024-12-01T22:20:34-08:00", "id": "https://jbmorley.co.uk/posts/2024-12-01-december-advenuture-day-01/", "title": "December Adventure Day 01", "url": "https://jbmorley.co.uk/posts/2024-12-01-december-advenuture-day-01/" }, { "content_html": "This year I’m planning a December Adventure:
\n\n\nThe December Adventure is low key. The goal is to write a little bit of code every day in December.
\nPick a project, or projects and work on them a little bit every day in December.
\n
Possible ideas include:
\nRight now, I’m leaning towards the Psion side-quests. Let’s see what tomorrow brings.
", "date_published": "2024-11-30T12:29:00-08:00", "id": "https://jbmorley.co.uk/posts/2024-11-30-december-advenutre-2024/", "title": "December Adventure 2024", "url": "https://jbmorley.co.uk/posts/2024-11-30-december-advenutre-2024/" }, { "content_html": "I’ve been following the fantastic Uxn project for a few years and enjoy using many of the tools Devine has put together for this unique platform—programs like Left, Noodle, Notepad, and m291.
\nTo make it easy to launch these in GNOME, I’ve added custom desktop entries which are picked up by most Linux GUI launchers. Creating these files can be curiously fiddly (especially if you need to reference files in your home directory) so I thought I’d post an example here for reference.
\n\n
\n![](\"/posts/2024-11-29-uxn-desktop-entries/launcher-left/400.png\")
\n \nUser-specific desktop entries are registered by adding .desktop files in ~/.local/share/applications—my entry for Left, the Uxn writing tool, is called left.desktop and contains the following:
[Desktop Entry]\n\nType=Application\nVersion=1.0\nName=Left\nComment=A writing tool\nExec=sh -c \"$HOME/.local/bin/uxn11 $HOME/roms/left.rom\"\nIcon=left.turnip\nTerminal=false\nCategories=Development;\nThere’s a couple of things in here which weren’t obvious to me and might benefit from calling out. Both of these are related to the lack of support for path expansion in desktop entries:
\nUser-specific icons must be placed in ~/.local/share/icons and referenced by their filename excluding the path extension1. In the example above, I’m using one of the PNG files from the Hundredrabbits projects page, saved as ~/.local/share/icons/left.turnip.png and referenced as left.turnip.
You need to jump through sh if the executable is located in your home directory (or you need to reference user-specific paths). Since all the Uxn projects are configured to install ROMs to the ~/roms directory, using sh -c makes it possible to use the $HOME environment variable to specify both the path of uxn11 (the X11 Uxn emulator) and my local copy of the Left ROM.
With a collection of entries like this, I’m able to launch Uxn programs using the GNOME launcher and tools like rofi. Since they all live in my user directory and only use relative paths, I can easily keep them in sync across my various devices using chezmoi.
\n\n
\n![](\"/posts/2024-11-29-uxn-desktop-entries/window-left/400.png\")
\n \n",
"date_published": "2024-11-29T14:07:31-08:00",
"id": "https://jbmorley.co.uk/posts/2024-11-29-uxn-desktop-entries/",
"title": "Uxn Desktop Entries",
"url": "https://jbmorley.co.uk/posts/2024-11-29-uxn-desktop-entries/"
},
{
"content_html": "Today I published fastcommand to PyPI.
fastcommand is a tiny Python package that wraps argparse, making it a little easier to create Python command-line utilities with multiple sub-commands. It provides a simple command decorator that can be used to annotate top-level functions. For example,
import fastcommand\n\n@fastcommand.command(\"hello\", help=\"say hello\")\ndef command_hello(options):\n print(\"Hello, World!\")\n\ndef main():\n cli = fastcommand.CommandParser(description=\"Simple fastcommand example.\")\n cli.run()\nPer-command options and arguments can be specified as follows:
\n@fastcommand.command(\"goodbye\", help=\"say goodbye\", arguments=[\n fastcommand.Argument(\"name\"),\n fastcommand.Argument(\"--wave\", \"-w\",\n action=\"store_true\", default=False)\n])\ndef command_goodbye(options):\n print(f\"Goodbye, {options.name}!\")\n if options.wave:\n print(\"👋\")\nThese sub-commands behave exactly as you’d expect:
\n$ examples/hello.py -h \nusage: hello.py [-h] [--verbose] {hello,goodbye} ...\n\nSimple fastcommand example.\n\npositional arguments:\n {hello,goodbye} command\n hello say hello\n goodbye say goodbye\n\noptions:\n -h, --help show this help message and exit\n --verbose, -v show verbose output\n$ examples/hello.py goodbye --help\nusage: hello.py goodbye [-h] [--wave] name\n\npositional arguments:\n name\n\noptions:\n -h, --help show this help message and exit\n --wave, -ww\n$ examples/hello.py goodbye Jason --wave\nGoodbye, Jason!\n👋\nThere are undoubtedly a myriad similar packages out there and, first-and-foremost fastcommand is a utility that helps me build the tools I’ve needed to develop over the years, but perhaps it can help you too. Please let me know if you use it and feel free to raise GitHub issues and pull-requests.
Publishing fastcommand is the first step in publishing some of the other Python utilities I’ve created over the years to help me with my software development—tools like changes which represents my own take on semantic versioning and conventional commits.