Tag Archives: Transputer

IMSB012 C004 replacement

The IMSB012 is my favorite TRAM carrier board. Room for max. 16 (size-1) TRAMs and plenty of external connectors. The perfect platform to build a successor of the ‘Tower of Power’.

Like with all TRAM carriers having more than 8 slots, it was a good decision to put at least one C004 link-switch onto the board.
While that’s generally a good feature, you (and me) might not need the option to reconfigure your Transputer network several times a week… And if you’re completely sure how you like your network it would be better to set if once and for all without the signal delay penalty you have to pay using one or even two C004s.

So in my case, I’m perfectly fine with the 4×4 matrix mentioned in the B012 manual (and also used as an example in my C004 post). So instead of using the clumsy MMS tool and having an extra link used into the T212, I planned tp remove the T212 and the two C004s and replace them with two dummies. Pretty much the same way like Parsytec did it with their x’plorer.
First I had to chew myself through the B012 schematic to understand the connection of each TRAM slot into the C004s. After that it was time for some intense cable plugging:

C004 dummy test

If you plan to do so, please be aware that the socket holes are too thin for a normal (0.63mm?) jumper cable. You might ruin your socket if you use force to plug them in!
I created a interpose socket by using single row pin header sockets which itself had thin enough pins to fit into the original B012 socket.

After some corrections, the buzzing-through of all 16 slots went fine and the schematics went to the PCB house (I have some PCBs left, ask for a quote if you need some).

And this is how the C004 replacement PCBs look when completed:

IMSB012 C004 dummies

Again, to solder in the pins, you’ll need really thin ones. Thinner than 0.5mm that is. Also, you don’t need to populate all 84 pins, I only use 51 per dummy (bridging some gaps).

Additionally, I strongly advise to isolate each dummy’s top with some kind of tape to avoid (electrical) contact to the TRAM placed above it. This is how they look seated on the B012 underneath slot 6 and 14 – the T212 under slot 7 not yet removed:


Transtech TMB316

The Transtech TMB316 never really seemed to see the light of day and is probably one of the last Transputer developments of AG Electronics for Transtech. Internally it’s also been called the “MTPA-0001”, MTP translates into Multi Transputer Platform, most likely “A” for 2MB and version 0001.

It’s a triple-height Eurocard board featuring 16 T805 at 25 or 30MHz, each with 2 or 4MB RAM. This is the card in full beauty:


As you can see, it’s not totally cramped with parts and actually has quite uncongested areas. The reason for that is, that this model (Called TMB316-2-25) only uses 2MB of the possible 4MB RAM per Transputer and while all Transputers are placed on the top side of the PCB, every second Transputer has its RAM on the bottom side, right beneath the ‘free space’ visible on the top. This is the back side (flipped horizontally):


It becomes more obvious, when we zoom into a Transputer section of the board:


I coloured each Transputer (green and orange) with its RAM area. The red area shows the CPLD which is shared between the two Trasnputers and handles the DRAM control and such.
Also visible on the cards front panel are 8 of totally 16 LEDs which display each Transputers status.

Obviously meant for a bigger systems, Transtech/AG Electronics planned the TMB316 for big deployments, i.e. more than one card. So each card uses four C004 link switches which connect the 16 T805 to each-other as well as to the outside world via the DIN connectors at the back of the card (totally non-standard pinout). This is fine if reconfiguration of the T-network is important but there’s no alternative but using dummy PCBs if all you need is speed. And being an avid GeekDot reader, you know my view on C004’s 😉

TMB316_C004This is where the C004s were meant to live.

Just in case you really want to know, here’s how the Transputer nodes are connected to the 4 C004 and to the backplane connectors:


Basic Transputer Tools

Ok, so you have your shiny (not so) new Transputer system installed/connected and you really like to know if it works and at least see some results… you’re in need of basic Transputer tools to get started.

First, download the Geekdot “Transputer Tool Kit” from my Transputer software page (New releases are possible, mind the version number).
Each tool introduced here has its own folder in the archive.


Even it’s historically not the first application ever developed for Transputers it’s for sure one of the most used.
It started as ‘check‘ and at some point got renamed into ‘ispy‘ – whatever the name is, the technical term would be “network worm”. This means it’s a special piece of code which a) sniffs around in a transputer (what kind, number of links and their speed) and b) replicates itself over all links it previously found.
When done, it outputs a network map like this example:

Using 150 ispy 3.23
 # Part rate Link# [ Link0 Link1 Link2 Link3 ] by Andy!
 0 T800d-25 292k 0 [ HOST   ...   ...   1:0  ]
 1 T425c-20 1.6M 0 [  0:3   2:0   3:0   ...  ]
 2 T400c-20 1.8M 0 [  1:1   ...   ...   ...  ]
 3 T400c-20 1.7M 0 [  1:2   ...   ...   ...  ]

ispy is used on geekdot.com extensively, so any time I write about Transputers you will see some sort of ispy output for sure.
There are several versions of ispy included in this kit. This is because some versions behave more stable than other in certain circumstances. E.g. the most recent version 3.23 does not work very well with the C004 link-switches.

“The other part” of ispy is called mtest. mtest takes ispys output and runs an indepth memory test/report on all Transputers found.


iserver is part of what INMOS called “itools” – long before Apple discovered the “i” for themselves 😉 – there were many others, mainly development focused (e.g. idebug, icconf etc.).
It is more or less the successor to the godfather of all Transputer booting tools “afserver” (1988). Well, it has to be, being the on INMOS supplied with all their other tools and languages.
The possible options are quite self-explanatory and printed to stdout when omitting any option:


Basically if you see a *.btl, *.b4 or *.b8 file it’s most likely meant to be executed with iserver. Before running successfully iserver need some environment variables set to successfully to be used:

set IBOARDSIZE=#100000

These two settings tell all itools how much RAM the Transputer has to work with and at which port address it can be found (0x150 is default anyway). The archive contains V1.42h from Nov. 1990 which is the most recent as far as I know.


The “CSA Mandelzoom Version” is one of my favorite benchmark tools. I like it so much, that I run it once a while just for fun.. and to extend my benchmark table which I’ve collected over the time using it.

It is nice because it features integer (T4xx) as well as floating point (T8xx) versions of the calculation ‘slave processes’ and scans the network itself. No external tool needed. It’s also possible to let the host (i.e. your PC) calculate the Mandelbrot fractal to get an idea, how much faster/slower your Transputer network is – the archive contains a little benchmark result text file which I accumulated over the years.
Also there are some handy switches available (‘-h’ for help):

  • -v : Use VGA graphics
  • -t : Run on host instead of Transputers
  • -a : Autozoom, loads  a list of coordinates from man.dat and start calculating them without manual interaction.
  • -b : Use a different base address (instead 0x150)
  • -x : Verbose output of the Transputer initialization process (added by me)

After a while I got tired of manually time a calculation run and also ran into problems with large networks which simply became to fast to hand time. So I extended the code of Mandelzoom with a high precision timer (TCHRT, shareware, can’t remove the splashscreen, sorry) which prints out a timer summary when run with the “-a” parameter. I provided my default “MAN.DAT” file, which contains 2 coordinates to calculate (1st & 2nd run) and used for all my benchmarks.

csa_mandel_timerThese are the results of my DOS host system running in VirtualBox.

Caveat: It breaks if there’s a T2xx in the network (e.g. B008/B012) 🙁 And as always: Read the F-ing README.txt!

Since I started to heavily modifying the source, I wrote a post of its own about it as well as put everything on github, so you can join the fun 😉

Other Tools


iskip can be very handy, when ‘talking’ directly to (externally) connected links, e.g. another network which is connected to your root Transputer. Here’s a good example:
You like to put code directly onto “processor 1” which is connected to link 2 of your root Transputer:


So you call

iskip 2 /r /e

This sets up the system to direct the program to the target network over the top of the root transputer and starts the route-through process on the root transputer. Options ‘R’ and ‘E’ respectively reset the target network and direct the host file server to monitor the halt-on-errorflag. The program can then be loaded ‘through’ the root Transputer directly onto processor 1 using:

iserver /ss /se /sc test.btl


Yes, I do mean the comes-with-DOS debug.exe. Well, you can use any debugger you like as long it can read/write to port addresses.
Obviously this means [MS|PC|Open|Free]DOS only. You won’t get far with this on Linux, any Windows or OS/2. At least for initial debugging and testing I strongly recommend to use the “bloated interrupt manager” known as DOS.
First of all, you have to know the port addresses the C012 registers are mapped to . There’s a de-facto industry standard which INMOS introduced with the IMSB004. Its been adopted by 90% of all 3rd party products, even with certain ISDN cards using Transputes.

The base address normally is at 0x150 (which can be configured to other addresses in some cases). From this base adress the offset is always the same:

Base Adress Register Comment
+0x00 C012 input data  read
+0x01 C012 Output data write
+0x02 C012 input status register read = returns input status
write = set input interrupt on/off
+0x03 C012 Output status register read = returns output status
write = set output interrupt on/off
+0x10 Reset/Error register write: Reset Transputer & C012 and possibly subsystem (check manual)
read: Get Error status
+0x11 Analyse register  (un)set analyse

So here’s a clean Transputer setup ‘conversation’ using debug (comments are just for clarity, not supported in debug):

 -o 160 1         # Assert RESET
 -o 161 0         # Deassert ANALYSE
 -o 160 0         # Deassert RESET ... init B004/IMSC
 -o 152 0         # Clear Input  Interrupt enable
 -o 153 0         # Clear Output Interrupt enable
 -i 152           # Read Input Status
 00               # Bit 0 = 0 -> no Data waiting
 -i 153           # Read Output Status
 01               # Bit 0 = 1 -> ready to send 
 -i 160           # Read Error
 00               # Bit 0 = 0 -> ERROR not signaled
-o 151 1          # send POKE
-i 153            # Read Output Status
01                # Ready -> POKE Ack (00 = BAD no Transputer) 
After that you’re fine to send and receive bytes through 0x151/0x150. Doing so, you’re completely free which programming language to use. Here are some examples in AppleSoft Basic or even Python.

QFP Adapter

Again, a man had to do, what a man has to do…
My good friend Udo gave me some Transputers in QFP package, most of them previously used and unsoldered from some PCB. Nobody knows, if they are still OK or already braindead – so I needed a QFP Adapter.

As fate goes, some fine day I stumbled across a nice 100pin QFP burn-in socket from Yamaichi on ePay. Yamaichi is “the other company” producing burn-in sockets besides 3M with their Textool brand range.
Normally those sockets are insanely expensive (100US$++) but this was a lucky buy – well for the “price” that it was an EOL model… for many years. This means no documentation available. But the very kind sales team of Yamaichi Germany (Vielen Dank Frau Howe!) was able to dig out a hand drawn blueprint of this very socket, model #IC51-1004-139.
This valuable Information at hand I was able to create my own Eagle CAD device for this Socket – not an easy task as most measures were not directly given but had to be calculated using other documented distances. After some hours I ended up with two PCBs, one for the burn-in socket which again will be mounted onto a PGA-Pin adapter PCB.
When done it was time for another “first”: Try the DirtCheapPCBs service. 2 Layers, 10x10cm PCB, 10 pieces for just US$25 (incl. shipping) – almost cheaper than doing it yourself.
After two and a half weeks I had two stacks of 10 PCBs each. Anxiously I tried if the socket with its tiiiiiiny pins will fit…. and… it… did! Hooray!! I didn’t expected that but everything fit perfectly, even the silkscreen. Soldering the 0.025″ pitch was another story…

But see for your self. Upper left corner you see the burn-in socket already soldered. At the right edge, the lower PCB it waiting to get 84 Pins soldered for the PGA socket… and another 100 to connect to the upper PCB.


Feel free to contact me, if it happen to be that you also found an IC51-1004-139 socket and need the Eagle lib or even the PCB for it… I have 9 of them left 😉

Handling TRAMS

General caveats

TRAM pins are thinner than normal PCB-Pins e.g. those you may know from Arduino shields and thus they are, well, quite fragile. That’s a problem (by design) with all TRAMs. So be very careful when handling TRAMs, i.e. removing/plugging them from/into your TRAM carrier e.g. a IMS B008.

And you can’t repeat this enough: Ground yourself! Electrostatic discharge will kill your TRAM as well as any other electronic device.

How do I do it? My main and single tool for handling TRAMs is this pair of straight tweezers:


This works quite well for carefully removing TRAMs from its socket by putting it between TRAM and socket like this and gently lever the TRAM – not too much! Else you will bent the pins on the other side – repeat on the other side. Done.

The Transputer

If you got you TRAM without a Transputer plugged in, you might figure that it’s quite difficult to plug in the CPU. My suggestion:

Put the back of the TRAM (the socket pins only – refrain from putting any force onto the TRAM pins) on a medium-soft item, e.g. a block of wood or like I usually do it, onto the rim of a sticky-tape roll, and press the CPU using even force into the socket with your thumb.
Double check that all CPU pins are straight and are sliding into the socket holes without force and fiddling. Also, mind the CPU orientation!
Again, never push the Transputer into its socket without support underneath the socket, your TRAM will bend and traces might break rendering it useless. At minimum the TRAM-pins will be damaged.


It’s worse when you’re in need of removing the CPU. Sometimes the ceramic packaging is extremely brittle and the CPU pins do sit very tight in the socket.

Again, use a straight tweezer, gently pushed between the socket and the CPU and carefully lever the CPU for a millimeter max.


Repeat on all four sides of the CPU…


The AM-B404

Here it is, my latest baby, the goal I was aiming for since years (4 to be exact) – not only to get more TRAMs for my systems but also to break the insane price spiral developing in the last years on ePay and other places. >300$ for a TRAM is crazy. Do not pay that amount! Even $100 is too much.

Update: Final version finished! Click here or scroll down for more.


My first CPU TRAM called AM-B404 in reminiscence to the IMS-B404 which comes closest to its specs:

  • Size-1 TRAM
  • 2MB low-power SRAM
  • 2 LEDs showing the Transputers status (running and error)

Well, the original Inmos B404 had 2MB DRAM, too (and additional 32k SRAM) but was a Size-2 TRAM and LEDs weren’t available on any Inmos TRAM… and we all know how important LEDs are! 😉 Contrary to the IMS-B404, the AM-B404 is low-profile, SRAM-only, so the whole RAM is accessed at 3-cycles vs. the IMS-B404 4-cycle DRAM.
Using a 6-layer PCB and all-modern SMD parts (well, as modern as 5V parts can get) the power consumption is a bit lower, too. I’d say about 100mA for the whole Board (no Transputer of course). Finally, there’s an easy access solder-bridge on the backside to set the CPU clock (20/25MHz).


This is just the 1st prototype. After thorough testing, I will optimize its layout a tiny bit and give it the proper shape of a TRAM. When that’s done, we’ll see how I can make you a realistic price offer.


From Shenzen with love. The final PCB designes arrived and the first test went perfectly fine.


And here are the first 4 PCBs waiting to be finished with the Trough-Hole parts (i.e. Transputer Socket and TRAM Pins)… 100 solder-points in total… per TRAM. That’s quite a bit to solder :-/



Finally, here’s a short video showing the prototype AM-B404 in action (running Helios on my Inmos B020). The “exciting” thing is the blinking green LED which shows the CPUs activity. There’s even some brief red LED access (error) during boot-up which is triggered by Helios scanning the Transputer network.
The bright blue LED to the left is the T2i2c TRAM, so all TRAMs on the B020 are built by me now 😉


This is the 2nd phase following “Sköll”. Hati is the other wolf who chases the moon – less mystic, this means getting the “Helios-Sköll” sources to compile on Linux – still targeting Transputers, though.

Some tools already do compile, e.g. the Transputer Crosscompiler ‘nc’ (i.e Norcroft-C) but most others are still missing.


There’s a hati branch in the GitHub repository. I suggest to leave it branched until at least the hostutils are compiling fine.
NB: Because I really badly hacked the nc files to get them to compile I did not include the changes to the branch. If you’re getting to this part of the code, I’m happy to tell/send you what I did, but I assume there are people out there doing a better job than I did 😉

This branch only includes ‘makeinc/makelinux’ and ‘makeinc/LINUX.mak’ and a new makefile here and there.
For now calling ‘. makeinc/makelinux hostutil’ will get stuck in building ‘cmds/com/sysbuild.c’ because of some include-path mish-mash – that’s where we have to start working.

Rough todo:

  • Create a proper Makefile. e.g. LINUX.mak currently has a lame workaround to point to GCCs include path
  • Probably many optimisations for recent GCC and gMake versions ahead!


This is the first and ongoing phase (as of Mar. 2014). While the main purpose of Sköll is to generally get the original source to compile on Solaris (v8) it also has several sub-tasks:

Compile the original source

100% done

Several makefiles needed some adjustments to work with gcc (instead of suns own cc), also some tricky formatting f*ck ups needed to be corrected – (gnu)make is much more picky about this than whatever make they used back then.

Strip unnecessary parts

5% done

It’s not identified which parts are completely unnecessary, but the TI DSP code is something which can definitely go.
Other points might need to be discussed, e.g. what should happen to some very special servers (i.e. Terminalserver in Helios lingo) like SUN3 or ACORN R140?

Smoothing the edges

0% done

There are multiple strange code-constructs which should be cleaned – they lead back to buggy and awkward MSDOS compilers which needed some workarounds

Here are some examples:

The code is full of #define eq == defines. I was told that was a workaround for the “==” vs “=” issue in conditional expressions. Modern compilers warn you when a condition looks like an assignment, the Microsoft compiler they were using at the time didn’t.. Doh!

Then there’s #define elif(x) else if(x). WTF!? Well, this roots from BCPL, the ancestor of C. Most of the core-devs at Perihelion studied at Cambridge University where BCPL was invented and was used well into the 1980s. In addition to the standard if() and while() constructs, it also had unless() and until() statements, as well as elif().
To them used to these constructs, the code was more readable and boy, they do get used throughout the Helios sources way too much.


The Plan

There’s a rough schedule where this project should go, given there are enough clever people joining in or at least display a certain degree of interest. So there’s a skech of the main-phases, aka “The Plan”  (without dates):


As said in the intro, Sköll is about “catching” the sun, i.e. get the original Helios 1.31 sources to compile on Solaris. This includes

  • cleaning up the code
  • weed out unneccesary parts (e.g. the TI DSP code)
  • smooth the edges (There are multiple strange code-constructs which should be cleaned)
  • get a general understanding of it all


Next phase/release/step after that will be “Hati”, the other wolf who chases the moon – less mystic, this means getting the “Helios-Sköll” sources to compile on Linux.
Some tools already do, e.g. the Transputer Assembler ‘as’… the Norcroft-C compiler is another story.

And as we all know, when Sköll and Hati finally managed to hunt down the sun and the moon, the world will be destroyed and reborn:


It’s certainly not the end of the world. I leave it open for now what that means in terms of Helios, but maybe there will be a critical mass of participants in the community to push “Helios-Hati” forward into version 1.4 running on x86 or current ARM implementations like Raspberry Pi and the like?

Secondary theater of War

Well, then there’s another part of Helios which needs some attention: The server.
This is the piece of software handling the communication between the Host (e.g. your DOS Box) and the connected Helios System (e.g. your Transputer(farm)).
There are several Server sources in the [HeliosRoot/]ioproc/server folder like DOS, Windows, RS6000, HP9000, Interactive UNIX, Sun3/4/i386, SCO etc… obviously all supporting very old versions of their OSes, e.g. Windows 3.x or Solaris 2.

So this part will need some love, too. I will mainly concentrate on DOS (that’s the [HeliosRoot/]ioproc/server/ibm folder), because that’s what I use to talk to Helios.
To support more recent ways of communication than ISA/SBUS/VME-cards, we have to create a new server, for example for Mikes USB-Link Interface.


This post is constantly growing, it’s mainly for me remembering not making some fu**ups again… but it might be useful for you, too 😉

Debugging the server

Booting Helios with server.exe you can provide a couple of debugging switches to see what’s going on:

  • A – All. Either enable all debugging, or disable any debugging which is currently active.
  • B – Boot. Give a progress report while the root processor is being booted.
  • C – Communications. Monitor transmissions to and from serial lines and similar devices.
  • D – Delete. List all files and directories being deleted.
  • E – Errors. Report any error messages generated by the I/O server.
  • F – File I/O. Give details of miscellaneous file I/O activities such as renaming files.
  • G – Graphics. Report any graphics transactions.
  • H – Raw disc. List sector reads and writes on a raw disc device.
  • I – Initialisation. Give a progress report as the I/O server initialises its various component servers.
  • J – Directory. Show details of any directory accesses.
  • K – Keyboard. Report any key presses.
  • L – Logger. Cycle the error logging destination between screen-only, file-only, and both screen and file.
  • M – Message. Report all messages sent to and from the I/O server.
  • N – Names. Show the names of objects Helios is trying to access.
  • O – Open. List all files that Helios is trying to open.
  • P – Close. Report any file close requests sent by Helios.
  • Q – Quit. Give a progress report when the I/O server tries to exit.
  • R – Read. Monitor any file reads.
  • S – Search. Report all distributed searches arriving at the I/O server.
  • T – Timeouts. Report any stream timeouts that may occur.
  • U – Nopop. In the Server windows system, toggle between pop and nopop mode.
  • V – OpenReply. Give details of replies to Open, Create, and Locate requests.
  • W – Write. Monitor any file writes.
  • X – Resources. Produce a snap shot of what the I/O server is currently doing.
  • Y – List. Give details of all debugging options.
  • Z – Reconfigure. Re-read the configuration file host.con

Those switches can be combined, e.g. server -rw

Cool: If the debug-output becomes too much to read (i.e. on screen) you can toggle the setting by pressing ctrl-shift plus the corresponding character. E.g. “c” to mute all the traffic on the serial line.


Now that we get some info about what’s going on internally, it might be a bit too much to follow on the screen (and you can’t redirect the output with “server > output.txt”). But don’t despair, there’s a way to define a logfile in HOST.CON:

logging_destination = [screen | file | both]
logfile = logbook

So simply define where you want the logging to go (screen or file or both) and define a logfile name. In this case it will be written inlogbook in the Helios root directory.
Please mind that the logfile will be overwritten (not appended) each time you reboot!


I cannot repeat it often enough: ALL config files (but HOST.CON) are Unix-Formatted, ie. LF instead of LF+CR. So each time something is behaving strange, check your config files for proper formatting!
I’ve spent hours of debugging just to find out I had (again) “tainted” a config file by quickly having a look with edit.exe :-/