Transputer/occam flag simulation

This code is a "demo" for a very specific computer configuration: an IBM PC or PC compatible with the ability to display CGA graphics, running DOS, with a network of 32-bit transputers fitted and accessible at I/O addresses starting from 0150h with the help of an INMOS C012 link adaptor chip. An INMOS B008 transputer module motherboard ISA card is an ordinary way of achieving this setup.

The demo performs a simulation of a flag flying in a breeze (note: the image links to a brief YouTube teaser video that shows the flag flying):

The colouring and pattern on the flag can be changed in a few different ways, although the limited colour palette CGA makes available for its higher-resolution graphics modes makes it difficult to reproduce most flags in a satisfying or even recognisable way.

Most of the demo's code is in the occam programming language, a clever language designed for programming transputers that's now mostly forgotten. A much smaller program written in x86 assembly language runs on the PC side, copying transputer-produced graphics into the PC's video memory.

Why is this README so long? A long README or manual is something of a personal trademark, but I also really enjoyed this project and wanted to make every opportunity for the reader to discover the same pleasure I found in exploring such a nicely-designed computing system. I hope this README is an effective way for me to go back and leave some breadcrumbs along my path.

Contents

• Quick-start guide
• Usage
• Background about the transputer
• Why this demo
• How the flag flies (in other words: theory of operation)
• How else does this flag fly?
• Learning more: touring the code
  • Some notes about occam for the casual reader
  • A tour itinerary
• Nobody owns this demo
• Acknowledgements

Quick-start guide

Transputer installations are quite varied, making it difficult to devise broadly-applicable instructions for the casual user. Here is a best-effort attempt. The first requirements are:

• Your transputer setup is installed in a PC compatible computer running DOS, capable of displaying CGA graphics.
• You must have INMOS's iserver program (or someone's derived iserver) in your PATH.
• You have INMOS's rspy program (or someone's derived rspy) in your PATH.

Up-to-date versions of both are available for DOS systems from here.

Method 1: If you have an INMOS B008 ISA expansion card transputer backplane (a) with at least seven 32-bit transputers fitted, (b) with all of the hardware configuration options (i.e. jumpers and switches) in the INMOS factory configuration, (c) without the built-in INMOS C004 crossbar switch introducing any more connections beyond the backplane's hardwired chain topology, and (d) with the transputer in slot 0 having at least a few hundred kilobytes of RAM, then: just execute flag.bat.

Method 2: If most of the above applies except your B008 is configured to use a different I/O address than the default 0150h, or if it uses some other means of communicating with the PC, then:

• Run rspy to reset the entire transputer network.
• Run iserver /sb flagb8.btl.

Method 3: If the closest you can get to the Method 1 configuration is a single "root" transputer, and if that transputer is accessible at I/O addresses starting at 0150h --- a configuration that might apply to a B004 single-transputer expansion card --- try executing flagsngh.bat.

Method 4: If most of the Method 3 conditions apply except your card is configured to use a different I/O address than the default 0150h, or if it uses some other means of communicating with the PC, then try running iserver /sb flagsngl.b4h.

Usage

If you've successfully started the flag simulation, you should see a bunch of drifting dots on the display. That's the flag --- and while it looks a little unnatural when it first starts moving, it'll start to seem a lot more flag-like in a few minutes.

If you've used Method 1 or Method 3 to start the simulation, you can use the number keys on the main keyboard (i.e. not the keypad) to change the pattern displayed on the flag. When you're finished with the simulation, use the Esc key to return to DOS.

If you've used Method 2 or Method 4 to start the simulation, there is no option to change the flag's pattern. Press any key to return to DOS.

Background about the transputer

Transputer was the name for a series of unique microprocessors designed and made by INMOS, a semiconductor manufacturer headquartered in Bristol, England. Produced from roughly the mid-1980s to the mid-1990s, these processors had innovative features intended to make them useful for multiprocessor applications. The idea was that you would build computing systems for diverse needs by assembling transputers together like building blocks. (In fact, the name "transputer" is a portmanteau of "transistor" and "computer" per this conceptualising text, which includes a section entitled "THE TRANSPUTER AS A UNIVERSAL COMPONENT".) Some of these features for multiprocessing included:

• Four 20-megabit serial communication links built into each transputer, allowing straightforward construction of multiprocessor networks.
• Process scheduling and multitasking built into the processor (ordinarily, operating system software performs process management).
• At least 2 KiB of on-chip RAM, further simplifying system design for settings where a lot of computing must be done on a limited amount of data.

Innovative design extended beyond the silicon: David May, lead architect of the transputer, also designed the occam programming language for developing transputer applications --- and in some ways for developing transputers themselves (e.g.). The occam language includes built-in constructs and checks that simplify the development of programs that have processes that run in parallel. Multi-threaded programs are notoriously challenging to write well: while occam couldn't guarantee that it would keep the programmer from introducing critical bugs related to parallel programming, it did make a number of common pitfalls impossible. Some of its design features are found today in widely-used programming languages like Go.

When they were introduced, transputers were quite fast in comparison to many other microprocessor offerings -- and easy to assemble into ensembles that were faster still. Commodity computer systems eventually eroded this advantage, and general-purpose transputers retreated from the market in the mid 1990s. The final descendants of the transputer lived on into the 2000s as specialised controllers for TV set-top boxes. Some modern microcontrollers by XMOS, whose founders include David May and other INMOS alumni, retain transputer-like features.

Why this demo

There was a time when the transputer concept was inspiring to a lot of people working in computing (e.g. 1, paywalled, Elsevier unfortunately, e.g. 2), and why not? If microprocessors made computing cheap, then multiple microprocessors could make big computing cheap: you just needed to figure out how they would all work together. The thoughtful features built into transputers and occam seemed to offer an answer.

Today's most common kind of parallel computing (the "cloud" kind) is not unlike transputing: in place of linked transputer modules, you have vast racks of networked individual computers. Processes "live" on only one computer: instead of somehow diffusing transparently throughout the cloud, applications on many cloud platforms often build on the abstraction that individual processes will use networking to collaborate with vast squadrons of identical clones, each one running on a computer ("node") of its own. (Even processes running on the same cloud node tend to run in private address spaces, with interprocess communication often using some kind of channel- or pipe-like interface.) Metaphorically, application software often "thinks" on the level of what individual bees do rather than what actions the entire hive is taking.

At least with occam and the rest of INMOS's tools, transputers are also programmed in the "bee" way rather than the "hive" way. What makes occam and transputers special is that they were built to be bees from the start! The computer and software architectures that underlie most cloud systems evolved from settings where there was only ever one co