Transputer Programming - Revision history

Geekdot at 14:09, 9 May 2025

2025-05-09T14:09:34Z

← Older revision		Revision as of 16:09, 9 May 2025
Line 20:		Line 20:
	===== Programming the Transputer on the ATW800/2 =====		===== 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.<br>		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.<br>
	Because those compilers were shell tools (on all platforms), we'll also include the Atari executable <code>MUPFEL.PRG</code>, which is the shell from the Gemini GEM alternative desktop, and add some scripts to make live easier.		Because those compilers were shell tools (on all platforms), we'll also include the Atari executable <code>MUPFEL.PRG</code>, 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:		To give you a basic idea how it then works, here's an example:<br>
			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:

	<code>		<code>
Line 29:		Line 30:
	</code>		</code>

	iserver will then handle I/O like keyboard entries, print output to your console or load files from your disk.		''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		Because that's a bit clumsy, we made MUPFEL scripts like 'irun.mup', which reduces this example to
	~~Code: Select all~~

			<code>
	$ irun path\to\my_binary\program.btl		$ irun path\to\my_binary\program.btl
			</code>

	To compile a C source file, it would be e.g		To compile a C source file, it would be e.g
	~~Code: Select all~~

			<code>
	$ icc mysource.c		$ icc mysource.c
			</code>

	which uses environment variables and saves a lot of of typing.		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.		That was a very quick intro into direct host development. Udo Matthe has written quite a lot of nice [https://github.com/umatthe/vgaserver/tree/main/atw800_2 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.~~		===== Programming Transputers on Helios =====

	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.		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.
	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.
			===== 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.<br>

			One example is the Mandelbrot binary I've been using on every platform I made interfaces for ([https://www.geekdot.com/2nd-sample-video/ Apple IIgs], [https://www.geekdot.com/3rd-sample-video/ 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.		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 ;)~~		To discuss further questions feel free to contact us preferably [https://www.atari-forum.com/viewtopic.php?t=44714 in a specific forum thread like this one].

	~~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~~.

Geekdot: Created page with "Category:ATW800/2 ===== 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..."

2025-05-09T13:37:08Z

Created page with "Category:ATW800/2 ===== 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..."

New page

[[Category:ATW800/2]]

===== 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' [https://en.wikipedia.org/wiki/Occam_(programming_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 '''SEQ'''ential or '''PAR'''allel, 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.<br>
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. [https://www.geekdot.com/transputer-2/ 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.<br>
Because those compilers were shell tools (on all platforms), we'll also include the Atari executable <code>MUPFEL.PRG</code>, 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:

<code>
$ iserver -se -sr -ss -sc path\to\my_binary\program.btl
</code>

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.