Worked with a transputer based embedded system for a life sciences instrument. Checking if code was running was fun. You’d send the messages for poke and peek and check if the poke worked. If it did the program wasn’t loaded so you would send it over the transputer network. If it was the program would return a different value for peek.

Later when PCs with an ISA bus became less common we developed a USB interface to the device. Still needed to source the C011 transceiver chips but we got those free issue from the instrument manufacturer.

Yes, I think this was part of the problem, and that's why the original article I submitted says that part of the OS is in hardware.

It was not friendly to users who wanted a free choice of languages.

The fact that some languages (and OSes back then) were not well-suited to parallel processing, and thus programming parallel programs, which you needed to make effective use of transputer systems, did not get across to people.

Now, I suspect most people think we have a very wide, free choice of programming languages -- but the truth is that for 25+ years, mainstream CPU designs are C-centric, designed to be easily programmable in C and to run OSes implemented in C.

This wasn't true in the 1960s-1980s, when there were, for example, many 9-bit, 12-bit, 18-bit, 24-bit and 36-bit machines, on which C did not sit well at all.

The transputer arguably came in a bit too early for widespread adoption of parallel multicore computers, but also was paradoxically too late, as it needed non-C-like languages and some of its own OSes for most effective use.

Occam polarised people. Some people liked it, but many hated it.

Interesting, the transputer OS Helios later got ported to other architectures: https://github.com/axelmuhr/Helios-NG