Just had a short break away from the constant pace of previous work – 16 months’ worth of near-daily updates – in which I caught up on the stack of magazines, articles, books I’d been meaning to get through. So away from tech for a while hence no blog post last month.

The book stack never goes down – see Michael Simmons’ article at – if I could take a yearly two-week reading vacation, I would… but back in the real world..

Now I’m ready to start on Parachute 0.0.2, the rework of the node server protocol to be iserver compatible. This should mean that the emulator could work with other emulators’ iservers, and vice-versa. However, the link emulation mechanism would need additional variants, to use the mechanism used by other emulators – e.g. as used by Gavin Crate’s emulator (see

During this work, I’ll update the Hello World assembly program, and start upgrading the C++ code to C++11 as needed.


16 months after picking up this old project, I’m happy to release the first cross-platform version of my T800ish Transputer Emulator!

See the Parachute 0.0.1 release notice for more details, download links etc.

As the previous blog post here described, there have been several frustrating aspects to the development- and these have only continued since then. However, I now have a good base, with mostly fully automated build/test and release systems- so subsequent releases should be easier.

One aspect of the build has been to use Maven & Jenkins for everything- despite several components of Parachute not being pure Java. Between these two, and a moderate collection of plugins, I have a multi-platform C++ build, with deployment to Maven Central.

I have a long-standing dislike of language ecosystems building their own component build/dependency/deployment systems. They re-invent Maven – sometimes poorly, usually because of a mistaken idea that it is Java-only. I’d much rather build on the existing base of Maven than see my language experiments as in some way “special”, requiring me to unnecessarily re-invent it. Maven is not perfect, but I think it’s a good fit for Parachute. I’ll still be providing build tools as command line tools and libraries, for easy use in non-Maven systems.

In the next phase of Parachute I’ll be converting the protocol between the emulator and host I/O server to be compatible with the Inmos iServer, then getting eForth working.

But first, a rest. Happy Summer Solstice!

TL;DR: Frustration, but the end is in sight.

Parachute is composed of several separate projects, with independent versions, held in separate repositories:

  • the Transputer Emulator itself, written in C++, built using Maven/CMake/Make, which requires building and packaging on macOS, CentOS 7, Ubuntu 1604 and 1804, Raspbian Stretch, and Windows 10.
  • the Transputer Macro assembler, written in Scala, built using Maven, which requires building and packaging on macOS, Linux (one cross-platform build for all the above Linux variants), and Windows 10.
  • and eventually there will be the eForth build for Transputer, other languages, documentation, etc.

Getting all this to build has been quite the journey!

I use Maven as an overall build tool, since it gives me sane version management, build capability for all the languages I use via plugins, packaging, signing, deployment to a central repository (I’m serving all build artefacts via Maven Central).

Each project’s build runs across a set of Jenkins instances, with the master on macOS, and nodes on virtual machines, and a physical Raspberry Pi.

Each project deploys a single artefact per target OS, into Maven Central’s staging repository. So there are six build jobs, one on each node, that can sign and deploy on request.

The effect of this is that a single commit can trigger six build jobs for the C++ code, and three for the JVM-based code (since all Linux systems package the same scripts). Deployment is manually chosen at convenient points, with manual closing of the staging repository in Sonatype’s OSSRH service.

The manual deployment choices may be removed once all this is running smoothly. Since I cannot produce all platform-specific artefacts from a single Maven build, I cannot use the Maven Release Plugin.

Once the emulator and assembler are deployed for all their variants, there is a final build job that composes the Parachute distribution archives, signs them and deploys them to Maven Central via Sonatype OSSRH.

There have been several ‘gotchas’ along the way..

… the GPG signing plugin does not like being run on Jenkins nodes. It gets the config from the master (notably, the GPG home, from which it builds its paths to the various key files). So that had to be parameterised per-node.

… getting the latest build environments for C++ on each of the nodes. I’m not using a single version of a single compiler on everything. A variety of clangs (from 3.5.0 to 8.0.0) and Microsoft Visual C++ Build Tools.

… Windows. It’s just a world of pain. Everything has to be different.

So this long ‘phase one’ is almost at an end, and I hope to ship the first build very soon.

It would be ‘fun’ to see if I can replicate all the above with a cloud-based build system instead of Jenkins + VMs. However, Windows, macOS and Raspberry Pi will be problematic. Travis CI does not have CentOS or Raspberry Pi hosts; Circle CI does not have Windows, CentOS or Raspberry Pi hosts (Windows is on their roadmap).

If you need to visualise molecular structures, RasMol is a venerable program that should run on multiple platforms. I was recently asked to help getting it working on modern Mac OSX. There are instructions on the RasMol website, but not for modern Mac OSX. Hence, these rough notes – offered in the hope they may help others…

RasMol uses the older X11 windowing system that is no longer provided as part of macOS, so we’ll install the open source XQuartz X11 system from
Download the .dmg (disk image file), open it, and run the installer. You’ll then need to log out and log in.

Then download RasMol from its SourceForge download area. You’ll need the file:

Once this has downloaded (into your Downloads folder), you’ll need to open a Terminal, and extract its contents, with the following commands. Note that MyMacBook$ is the prompt provided by the Terminal/OS:

MyMacBook$ cd Downloads
MyMacBook$ tar xzvf RasMol_2_7_5_3_i86_64_OSX_High_Sierra_19Dec18.tar.gz
(Many lines will scroll by)

We’ll put this extracted software somewhere a bit easier to get to:

MyMacBook$ mv RasMol_2_7_5_3_i86_64_OSX_High_Sierra_19Dec18 ~/Applications/RasMol_2_7_5_3

(Now it’s in your personal Applications folder).

We need a launch script, since the one that comes with the software doesn’t seem to work, since it can’t find XQuartz’s libraries. So from the terminal:

MyMacBook$ cd ~/Applciations/RasMol_2_7_5_3
MyMacBook$ nano

This puts you into the ‘nano’ text editor, then you must copy and paste:


Then press Control-X, and press Y then return to save the file. Then:

MyMacBook$ chmod 755

OK, nearly there.

Only kidding 🙂

Let’s create an alias to let you run RasMol…

MyMacBook$ cd (then press return)
MyMacBook$ nano .bashrc

Again, you’re in the nano editor, so copy and paste this:

alias rasmol='cd ~/Applications/RasMol_2_7_5_3; ./'

Then Control-X, and Y then return to save the file.

Righty, let’s run XQuartz (via spotlight [Command-Space]). After a few seconds, you’ll see an X11 terminal window (xterm) appear. This is different from the usual Mac Terminal. You won’t be able to run RasMol from the Mac Terminal: you must use XQuartz and in the xterm, type:

bash-3.2$ rasmol (then press return)

Then you’ll see the beautiful RasMol window. It’s very different from what you’re used to on macOS, but this is how we used to use graphical programs back in the 80s.

The main RasMol window has its own menu – it’s not in the top menu bar like ‘normal’ Mac programs.

When you close XQuartz, you close ALL the X11 programs you’re running – xterm, rasmol, etc.

To open a file in RasMol, use the File menu, then Open…, then use the old-style file dialog to navigate using the ‘..’ (Parent Folder) directories to find where you’ve stored your RasMol files.

Since Feb/Mar 2018, I’ve been working on a new phase of one of my old projects: Parachute, a modern toolchain for programming the Transputer, and a Transputer Emulator – cross-platform for Mac OSX, Windows 10 and Linux.

The Transputer architecture is interesting since it was one of the first microprocessors to support multitasking in silicon without needing an operating system to handle task switching. Its high level language, occam, was designed to facilitate safe concurrent programming. Conventional languages do not easily represent highly concurrent programs as their design assumes sequential execution. Java has a memory model and some facilities (monitors, locks, etc.) to make parallel programming possible, but is not inherently concurrent, and reasoning about concurrent code in Java is hard. occam was the first language to be designed to explicitly support concurrent (in addition to sequential) execution, automatically providing communication and synchronisation between concurrent processes. If you’ve used go, you’ll find occam familiar: it’s based on the same foundation.

My first goal is to get a version of eForth running on my emulator (as I’ve long wanted to understand Forth’s internals). The eForth that exists is a) untested by its author and b) only buildable on MASM 6, which is hard to obtain (legally). I’m trying to make this project as open and cross-platform as possible, so first I had to write a MASM-like macro assembler for the Transputer instruction set This is mostly done now, written in Scala, and just requires a little packaging work to run it on Mac OS X, Linux and Windows.

I’ve written up the history of this project at Parachute History, so won’t repeat myself here..

I’m not yet ready to release this, since it doesn’t build on Windows or Linux yet, and there are a few major elements missing. Getting it running on Windows will require a bit of porting; Linux should be a cinch.

Once I have a cross-platform build of the emulator, I intend to rewrite my host interface to be compatible with the standard iServer (what I have now is a homebrew experimental ‘getting started’ server).

There are quite a few instructions missing from my emulator – mostly the floating point subset, which will be a major undertaking.

The emulator handles all the instructions needed by eForth. eForth itself will need its I/O code modifying to work with an iServer.

Once eForth is running, I have plans for higher-level languages targetting the Transputer…

… but what I have now is:

… to be continued!

Ah, the optimism of the 1st January!

As I reflected on 2018, it became apparent that ‘starting, not finishing’ is a big problem, chez M0CUV. My muse bestows plenty of interesting ideas, but some of them are a bit ambitious. I start, then things grind to a halt. This, coupled with chronic procrastination means a lot of churn, and a feeling of dissatisfaction, angst, and despair at not being able to find the time to do all this – or to prioritise better. A look back through the log shows a big gap of radio silence from June to October, a page of digital mode contacts, and not a single CW QSO throughout the whole year. On the software side, I hung up my own P2P stack after a baffling test failure wore me down. I do want to return to that.. However, I spent most of my hobby development time working on the Parachute project, which despite being really tricky, is going well. I never thought writing an assembler would be this hard. The devil is in the details.

So, after giving myself a good slap for a lacklustre radio year, 2019’s going to be goal-driven. Hopefully these goals are SMART (Specific/Stretching, Measurable/Meaningful, Agreed-upon/Achievable, Realistic/Rewarding and Time-based/Trackable). There are quite a few, and only the tech/radio-related ones are blogged about here. I’ve been using the Getting Things Done method for a while, and it stresses the importance of defining the Next Action on your activities..


  • 1 blog post/month, at least. Progress updates on projects, etc.
  • 1 CW QSO/month, or 12 in the whole year. This’ll probably be really tough.
  • 1 QSLable QSO/month, or 12 in the whole year, any mode/band. FT8 makes this much easier!
  • Try to contact each month’s special callsign for the Bulgarian Saints award from Bulgarian Club Blagovestnik. I’ve already bagged January’s, LZ1354PM via SSB on 1st Jan 🙂
  • Take the next step on the magnetic loop project: build the frame, house the capacitor. I bought some wood and a food container for this yesterday.
  • Box up the 30m QCX transceiver properly – then use it.
  • Keep up with magazines as they arrive rather than building a pile of them.
  • Fix the current bizzare bug in the Transputer assembler – then ship the first release on Windows, macos and Ubuntu/Raspbian
  • Convert the Parachute Node server to use the IServer protocol – then write the IO code for eForth.
  • Build a web application with elm. I’m thinking of a web-front-end to WSJT-X, to allow me to operate remotely.

Let’s see how I get on…!

Abstract: Oracle is shutting down Kenai and on April 28, 2017, and as one of the open source projects I’m a member of was formerly hosted there, we needed to move away. This move comprises source code and mailing lists; this post concerns the former, and is a rough note on how I’m migrating svn repositories to git (hosted on github), with the method, and a script that makes it easier.

It’s an ideal time to migrate your subversion repositories to somewhere else, and since git/github are the de facto/fashion standards these days, you may want to consider converting your entire history to git, and hosting it at github. (Disclaimer, I prefer mercurial and bitbucket, and some of the below could be used there too…)

To convert a svn repo to git, and push to github, there are several stages. I did this on OS X – I’d do this on some form of UNIX, but you may get results with Windows too.

I’m going to use svn2git, so let’s get that installed:

Following the installation instructions at

I made sure I had ruby, ruby gems, svn, git, and git-svn installed (these package names might not be precise for your system; they’re from memory)
I can do:

$ cd /tmp
$ mkdir foo
$ cd foo
$ git init
$ git svn
git-svn - bidirectional operations between a single Subversion tree and git
usage: git svn [options] [arguments]
… blah blah …


$ sudo gem install svn2git

The conversion from svn to git makes a lot of network access to the svn repo, and so to reduce this, let’s “clone” the svn repo onto the local system.
Mostly following the notes at, first, initialise a local repo:

$ mkdir svnconversion
$ cd svnconversion
$ svnadmin create svnrepo

Note that git’s svn code expects the subversion repo it converts to have a filesystem format version between 1 and 4, that is, up to Subversion 1.6. So if you have a version of the svn client that’s more recent than that, you’ll have to use the command:

$ svnadmin create —compatible-version 1.6 svnrepo

(see for details)

$ ls -l svnrepo
total 16
-rw-r--r-- 1 matt staff 246 1 Sep 22:58 README.txt
drwxr-xr-x 6 matt staff 204 1 Sep 22:58 conf
drwxr-sr-x 15 matt staff 510 1 Sep 22:58 db
-r--r--r-- 1 matt staff 2 1 Sep 22:58 format
drwxr-xr-x 12 matt staff 408 1 Sep 22:58 hooks
drwxr-xr-x 4 matt staff 136 1 Sep 22:58 locks

$ cd svnrepo

Now create the pre-revprop-change hook:

$ echo '#!/bin/sh' > hooks/pre-revprop-change
$ chmod 755 hooks/pre-revprop-change

Let’s prepare to sync the svn repo here:

$ svnsync init file:///tmp/svnconversion/svnrepo

Now let’s do the actual sync. This is what takes the time on large repositories…

$ svnsync --non-interactive sync file:///tmp/svnconversion/svnrepo
# Make tea…

OK, now we have the “clone” of the svn repo, so let’s convert it to git. The first thing you’ll need is an author mapping file. This converts the short author names used in svn commits into the longer “name ” form used by git.

Note there are many possible structures for svn repos, with the ‘standard’ layout having branches/tags/trunk. This page assumes that your svn repo looks like that. If it doesn’t, then see where there are many possibilities documented to aid your conversion.

See the svn2git github page for details of how to create this authors.txt file.

Converting to git is as simple as:

$ cd /tmp/svnconversion
$ mkdir gitrepo
$ cd gitrepo
$ svn2git —authors ../authors.txt file:///tmp/svnconversion/svnrepo

Then create a new repository using the GitHub web UI, add it as a remote, and push, mirroring all branches to the remote:

$ git remote add origin
$ git push --mirror origin

The following is a script I wrote to make it easier to perform the above steps repeatedly, as I had several repositories to convert. It assumes you have exported the GITORGANISATION environment variable.


usage() {
	echo "svn-to-git-conversion [syncsetup|sync|convert|push] http://url/of/svn/repository local-repo-dir-prefix ~/path/to/authors"
	exit 1

# syncsetup, sync, convert or push


# prefix of relative folder (eg jxta-c) where repository will be svnsynced to eg jxta-c-svn
# and of relative folder where repository will be converted eg jxta-c-git

# path to author mapping file

if [ "$PHASE" != "syncsetup" -a "$PHASE" != "sync" -a "$PHASE" != "convert" -a "$PHASE" != "push" ]

echo local svn repository url is $SVNREPOFILEURL

if [ "$PHASE" = "syncsetup" ]
	svnadmin create --compatible-version 1.6 $SVNREPONAME
	echo '#!/bin/sh' > $SVNREPONAME/hooks/pre-revprop-change
	chmod 755 $SVNREPONAME/hooks/pre-revprop-change

if [ "$PHASE" = "sync" ]
	svn propdel svn:sync-lock --revprop -r 0 $SVNREPOFILEURL
	svnsync --non-interactive sync $SVNREPOFILEURL
	echo Users in the SVN repository to be added to the $AUTHORS file:
	svn log --quiet $SVNREPOFILEURL | grep -E "r[0-9]+ \| .+ \|" | cut -d'|' -f2 | sed 's/ //g' | sort | uniq
	echo Top-level structure of the SVN repository: 

if [ "$PHASE" = "convert" ]
	svn2git --authors $AUTHORS $SVNREPOFILEURL

if [ "$PHASE" = "push" ]
	git remote add origin$GITORGANISATION/$GITREPONAME.git
	git push --mirror origin

Next Page »