Ok, you read/heard about the STG[A]TW and want to know more about how to use it and -most importantly- for what it’s good for?
First and foremost, a Transputer is a computer-system of its own connected to a host. In this case an ATARI Mega ST.
But given an available host-adapter that could also be e.g. a Unix machine, a classic PC, an Apple II or even a Commodore C64, C128 or Plus/4…
That host communicates with the Transputer over a link-interface using specific memory addresses or, if available, a library. That way the host can send executable binaries to the Transputer, send or receive data to/from it and control it (boot, debug, etc.).
Because each host system is different, these addresses are different, too. But the transfer protocol and Transputer executables are always the same. So looking at this BASIC code example for the C64 gives you an idea, how it works – the steps are the same for every host-communication no matter which host-system used.
| As usual, here’s a table of contents for those being in a rush.. |
Quick intro about standards & history
Yes, there have been very different ATARI ST and Transputer interfaces in the past. “Two and a half” systems were most prominent – let’s have a look at them before we go into details of the STG[A]TW.
The Atari Transputer Workstation aka ATW800
I think I’ve already wrote a lot about the ATW800 in several post on this page, even designed an expansion card for it – despite I don’t own an ATW myself.
To make a long story short: This is basically a design, where the ATARI Mega-ST is used as a boot device and after that just handles file- and user-I/O. The Transputer is attached to the ST via DMA and runs the Helios OS and has direct access to the graphics controller called ‘Blossom’. Totally different concept.
KUMA K-MAX
The KUMA K-MAX was a box connected to the ATARI ROM-module port and thus acted as pure ‘number cruncher on a leash’.
There are two reviews still available: The English review of atarimagazines.com and the German ST-Computer article even showing some photographs of which I ‘borrowed’ this:
Transfertech
Outside “the scene” this is a relatively unknown German company which actually made a lot of Transputer-centric hardware.
For the ATARI series they had 3 host interfaces:
- A ROM port interface (all ST models)
- A Mega ST bus interface (ROM port design botched onto the bus)
- A VME-card (Mega-STE, TT)
Like the KUMA K-MAX, this design also attached the Transputer(s) as number cruncher.
As I own all of them, I might write a dedicated post about them some day.
This is how we do it
As all of the above did their own thing, there is and was no standard for interfacing the ATARI ST series – So I defined one with the other ATARI ST Transputer enthusiast André Saischowa, who did some intense ATARI Transputing fiddling back in the days.
In case of the ATARI ST the link-interface ( e.g. STG[A]TW) ‘lives’ at the base address 0xFFFAC0 and uses 18 bytes from there up to 0xFFFAD2. So the complete adress-range looks like this (uneven, so we can address the lower byte of a 68000 word):
#define base 0xfffac0 #define inreg base+1 /* C012 */ #define outreg ((base)+3) #define instat ((base)+5) #define outstat ((base)+7) #define reset ((base)+17) /* writing*/ #define analyse ((base)+19) #define errflag reset /* reading*/
But you don’t have to bother with those as we provide two more convenient ways to talk to a Transputer.
☝ Some words of warning to the programmers:
- While the 68000 in your ATARI is big-endian, Transputers are little-endian. So data being send back and forth might need conversion.
- Floating-point variables used by the Transputer are IEEE 754-1985, thus 32 Bit (single precision) or 64 Bit (double precision).
Some compilers like Turbo/Pure-C on the ATARI ST use 80bit doubles.
Those need to be converted by e.g. thexdcnvcall from the PCFLTLIB library.
The static way
The raw-way is using an include file called “trproc.h”. It’s – like everything else – included in the program archive, located in the “DEVELOP” folder.
This include-file provides you these calls to receive (get) or send (put) data to/from your Transputer:
| get/puttrchar(char) | read/send one byte |
| get/puttrshort(short) | read/send a short (2 bytes) |
| get/puttrint(int) | read/send an integer (32 bytes) |
| get/puttrlong(long) | read/send a long (32 bytes) |
| get/puttrfloat(float) | read/send a float (32 bytes) |
| get/puttrdouble(double) | read/send a double (64 bytes) |
| get/puttrraw(char *array, int length) | read/send an array of length |
The calls marked blue are doing the endian-conversion for you.
Additionally there’s a call to check for an available Transputer: checkTransputer(int checkType)
If checkType is ‘0’, this function will return ‘1’ if it was able to find a Transputer or ‘0’ when not.
Setting checkType to ‘1’, the return value will give you the “family” of the found Transputer:
0 – No Transputer found
1 – Found a C004 link-switch
2 – A 16bit T2xx Transputer was found
4 – A 32bit T4xx/T8xx Transputer was found
-1 – Found something unknown
The elegant way – TBIOS
The much more elegant way is provided by André who extended the ‘ALIABIOS’ from a project published in the German computer magazine c’t back in 1989.
It’s a GEMDOS driver called “TBIOS.PRG” and can be put into your AUTO folder or called manually when needed. This driver has all the bells’n’whistles like a proper XBRA-ID etc.
DOS# call-name - result (D0=0 Ok) 100 SetLinkAdr(Adr:W) D0 =-1 not ready 101 ByteToLink(Value:W) D0 =-1 Timeout 102 ByteFromLink() D0 =-1 " 103 LongWordToLink(Value:L) D0 =-1 " 104 LongWordFromLink((Value):L) D0 =-1 " 105 SliceToLink((Buf):L,Len:L) D0 RealLen 106 SliceFromLink((Buf):L,Len:L) D0 " 111 TestError() D0 =1 Transputer Error 112 SetReset() D0 =0 113 SetAnalyse() D0 =0 114 BootRoot((FileName):L) D0 <0 Error 115 NewFunkOk() D0 ="ELK1" functions available 116 BlockToLink((Buf):L,Len:L) D0= sent bytes 117 BlockFromLink((Buf):L,Len:L) D0= sent bytes - 118 BlockFromLink((Buf):L,XLen:L,YLen:L,Offset:L) without timeout 119 GetCommand(Buf) D0 =-1 no command found (as SliceFromLink but shorter timeout)
👉 Need short coding examples here
Programs and demos
As ATARI never planned something like this card, there’s no ready-to-use software… it’s up to you to create miracles 😊
But compared to my 8bit Transputer adapters, there’s quite some stuff to start with:
💾 Visit the Atari Transputer Software repo at GitHub (most recent) or get this ZIP archive containing everything discussed below.
Basic Testing
Yes, literally, we’re testing if your Transputer is working correctly using a BASIC program called T_TEST.GFA – so right, it’s GfA Basic in this case. But in essence it’s nearly the same used for my C64 or Apple II interfaces.
This little Program checks if it can find a link-interface, a Transputer and if so, which kind (16 or 32 bit). If that went OK, it does a little coms-speed test by reading 4KB from the Transputer and times that.
Mandelbrot fractal
You knew that this has to be the first thing to be written 😜
There are two Transputer binaries…
TMANDEL.PRG – the evil, dirty, down-to-the-metal, direct-to-screen-writing version.
This is good for getting an idea of how fast data is being pushed to the Atari ST without much handling overhead.
As this writes to the Screen directly, it only runs in “ST-High” resolution (i.e. 640x400x1).
GEMMAN.PRG – The well behaving GEM version.
It opens a window max’ed to the current resolution and starts plotting the fractal in 16 colors. This takes longer than TMANDEL, as it does quite a bit of GEM juggling before plotting a pixel…
Getting serious
So, this is the part for doing serious things with your Transputer(s) and specifically André Saischowas domain.
He did not only port all needed INMOS tools like iserver to run all the available development tools from back in the days (OCCAM, C, etc) but also ported the Helios server, i.e. the software which runs on the host (i.e. your ATARI) and communicates with the Helios Kernel(s) running on your insane Transputer Farm!
This is a good 75% of what the ATW800 offered – the missing 25% are the graphics which ran on the Blossom chip and was only accessible by the Transputer.
That said you’ll currently find 2 folders in the archive:
- C-Code – contains the Mandelbrot demos
- Andres – the serious stuff containing
- AUTO – the TBIOS driver and stuff needed during ATARI bootup
- BIN – the INMOS tools like
iserveras well as the always-neededispyutility - D72UNI – contains the transputer hosted compiler environment based on d7205a (OCCAM) and d7214c (C-Compiler). Visit transputer.net for plenty of documentation on those. See the README in that folder.
- HELIOS11 – well, that’s the Helios v1.1 distribution. It’s way smaller than the v1.3 and good for an initial try. You can later switch to v1.3.1 following these steps.
There you have it (for now) – the ATARI ST is therefore the currently third best supported host platform after the PC running DOS or Windoze NT(!) or SPARCStations running Solaris 2.