Transputer Programming

Preface

While Transputers are more or less forgotten these days, they once were the hottest thing on the market. Many companies had their labs experimenting with them and certainly every university which had an IT faculty. Obviously mostly British, still European mainland was on their heels.

Thus, there's still(!) tons of documentation and mostly all fancy programming languages of that era (C, Pascal, Forth, Ada,..) were ported. This was mostly due to the fact, that the Transputers 'native language' OCCAM had a hard time outside of academia.

That said, OCCAM is the language of choice if you plan to get the most speed and efficiency out of a Transputer - the language was tailored by INMOS to the CPU and its parallelism. Something you need to slap-on onto other languages to make them e.g. into "Parallel C". And because OCCAM is as British as the Transputer is, it's..well... different :wink: It uses indention which just became en vouge again thanks to Python. It uses the concept of code-parts being SEQential or PARallel, it uses IN and OUT (using "?" and "!" as command) to communicate with other Transputers over their 4 links. Assembly language is possible but will be something for the adventurous. Transputers don't use registers, they are stack based (3 levels) and use UPN like your old HP pocket calculator. And they have short on mnemonics, so the code is hard to read and tedious to write.

Compilers (C, OCCAM etc) are often described as native- or cross compilers. Some are exclusively one or the other, some were available in both variants. One example is INMOS' latest C-Compiler which is offered in both variations.

INMOS started with the TDS (Transputer Development System), a complete IDE as native-only, because PCs used a 8086 or 80286 processor at best which were much slower than the Transputer. Later they offered a cross compiler and dropped the IDE which also included a folding Editor. The last OCCAM compiler was cross-only.
All cross compilers ran/run on systems of those days: MS-DOS or SUN Solaris, sometimes VMS, rarely Windows 95. So for those, you'll need a virtual machine or make yourself a setup. I'm providing a "SDK VM image" which you can use to do some tinkering.

Programming the Transputer on the ATW800/2

As for the ATW800/2, we will provide an archive containing Atari drivers, tools, demos and a full fledged Transputer environment plus Helios and X11. This also includes the latest native compilers, so you can run them on the ATW800/2's very own virtual Transputer.
Because those compilers were shell tools (on all platforms), we'll also include the Atari executable MUPFEL.PRG, which is the shell from the Gemini GEM alternative desktop, and add some scripts to make live easier.

To give you a basic idea how it then works, here's an example:
INMOS had a so called 'server' or 'loader' named iserver which uploads executables from the host (ATARI) into the Transputer. So you call iserver from the shell and add the binary it shall start. Optionally add some parameters, too:

$ iserver -se -sr -ss -sc path\to\my_binary\program.btl

iserver will then handle I/O like keyboard entries, print output to your console or load files from your disk. Because that's a bit clumsy, we made MUPFEL scripts like 'irun.mup', which reduces this example to

$ irun path\to\my_binary\program.btl

To compile a C source file, it would be e.g

$ icc mysource.c

which uses environment variables and saves a lot of of typing.

That was a very quick intro into direct host development. Udo Matthe has written quite a lot of nice OCCAM demos for the ATW800/2 which he made available in his github.

Programming Transputers on Helios

Helios is a full blown UNIX'ish operating system. Besides the I/O which is handled by the host (i.e. your Atari) everything else runs natively on the Transputer. Like every proper OS it comes with it's own native ANSI C compiler (no OCCAM here!). There's no cross compiling and it has its own bash-like shell etc.

Using the Transputer from your TOS/GEM program

Finally, you can also talk to the Transputer(s) directly out of your ATARI code (e.g. Pure-C or GfA Basic). As the Transputer link-interface is memory mapped, it's more or less just a matter of PEEK'ing and POKE'ing.

One example is the Mandelbrot binary I've been using on every platform I made interfaces for (Apple IIgs, C64 or C16). The code for it was written in OCCAM and compiled. The resulting binary was then integrated into the native programs as an array and is uploaded as soon as the program starts. Then the program is just handling the "incoming pixels" and plots them onto the screen.

To discuss further questions feel free to contact us preferably in a specific forum thread like this one.