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 of Atari drivers, tools, demos and a full fledged Transputer environment plus Helios and X11. This 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 'loader' called iserver which uploads code from the host (ATARI) to the Transputer. So you call iserver from the shell and add the binary it shall start. Maybe 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 Code: Select all

$ irun path\to\my_binary\program.btl To compile a C source file, it would be e.g Code: Select all

$ 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 (umatthe) has written quite a lot of nice OCCAM demos for the ATW800/2 which he made available in his github.

Helios on the other hand is a full blown UNIX'ish operating system. So it comes with it's own native C compiler (no OCCAM here!). There's no cross compiling and it has its own bash-like shell etc.

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, 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 will be uploaded as soon as the program starts. Then the program is just handling the "incoming pixels" and plots them onto the screen.

Finally, yes, there will be a developer manual explaining all this plus how to talk with Seurat just in case you're planning to run your own graphics drive ;)

Phew, that became longer than planned. Anyhow, this is a good place for asking your development related questions. I'm sure the team will chime in when time allows.