Some here really love the Transputer, so this may be of interest: Jamel Tayeb (@Jamel) has started what promises to become a pretty comprehensive series on the Transputer on his blog.
Here’s part 1 (includes nice images and a video):
5 Likes
In the late 80’s I moved from Edinburgh to a Gloucestershire based engineering company who were using Transputer boards as part of a factory automation system. We networked them using IBM Token Ring, but used Transputer links for in-box communications (multi-card system with compute and IO cards, each with a Transputer or simple link sequencer engine), but that didn’t last long, so along with some others, we moved to Bristol to the company who was actually making those boards - called Meiko Scientific - one of a few start-ups kicked off by former Inmos employees.
They were making MPP - Massively Parallel Processing supercomputers - such as they were at that time. It was a fun time, but as always, you’d make a system for a customer and almost the next day they’d ask for more memory or a faster CPU as their models just expanded to fill the RAM and CPU cycles - much as modern games, etc. do today…
By the early 90’s the Transputer just wasn’t fast or competitive enough and our customers were always wanting more, so the Transputer was relegated to being nothing more than a mere communications engine to link boards with dual i860’s (40Mhz, floating point multiply + add in a single cycle - ish) and then Sparc CPUs with the Transputer being left behind.
The concept of parallel processing and high speed point to point communication still lives on though - inside a GPU in your PC to todays supercomputers. All good stuff!
Image is a last-generation Meiko Transputer CPU card. 4 x T805 Transputers (gold top chips), 4 x Meiko custom ‘supervisor chips’ which did board level control and control of the 4 custom Meiko link switch chips (the 4 sockets square ones on the upper left) Each Transputer on that board has 8MB of RAM which was a lot in the early 90’s. The board is about 14" square…
Cheers,
-Gordon
2 Likes
Gordon,
BBC Research bought a Meiko computing surface in 1990 IIRC hoping that it could be used for image processing and modelling various HDTV compression and transcoding schemes.
A large full height rack arrived, which contained initially only 4 transputers.
The biggest problem was the Occam language. BBC Research were almost exclusively doing their batch image processing in FORTRAN at that time on VAX 11/780 and MicroVAX machines.
Only one engineer became fluent in Occam, and so the usefulness of the Meiko machine to the department was limited by his programming bandwidth!
As a result of this, the Meiko machine was a very under-utilised resource until at some later date we bought a FORTRAN compiler.
2 Likes
That’s interesting about Occam… In all my time with the Transputer, I only ever wrote one Occam program. Everything else I did was in C (and assembler) as Meiko had developed a very good C compiler for it which I was using in 1988, initially at the Engineering firm… There was a FORTRAN compiler for it too and I remember facing the same issues that BBC Research might have been facing when I was shipped out to Canberra, Oz, to help install and run a brief training course for their national broadcasting company who were doing the same thing by the sounds of it… I taught them C and did run one very brief afternoon with FORTRAN after they pestered me for several days to do FORTRAN on it! (I was rarely “customer-facing”, but I wasn’t going to turn down the chance of a trip down-under at the time 
And that was one of the biggest challenges that Meiko (and I’m mant sure others) faced: More than once I’ve heard: “I have this 20+ year old FORTRAN program: Make it go faster”.
Parallel processing was (and still is) hard. You really need to re-write and often re-think your problem and algorithm and sometimes it’s not obvious.
What Meiko (and others I worked with) did was to write the standard math/algebra libraries (Blas, Linpack, etc.) to make as full use of the system as possible, then link that into the clients code - which was a good solution, but would never be as good as a total re-write.
-Gordon
1 Like
Gordon,
FORTRAN was very much ingrained in BBC R&D culture in the late 1980s.
Our computer manager was in his late 50’s at that time, and FORTRAN had probably accompanied him all of his professional life - and protecting his precious mainframe from hostile users was his raison d’etre.
I joined the department in September 1986, and image processing was done overnight or over weekends - depending on the size of the job.
We often used small monochrome images of just 64x64 pixels and further broken down into 8x8 pixel blocks - in order to get a decent rate of iteration. Image processing involved 2D FFTs and these were very slow on the VAX.
These models led to a variety of different transcoding algorithms, and we had European partners both in industry and other broadcast research institutions. The commercial partners wanted to come up with a HDTV decoding algorithm for set top boxes - that would not require “a bathroom mirror worth of silicon” to implement.
At that time the BBC’s input was to ensure that picture quality for the viewer was maintained. The commercial partners had other ideas, often profit motivated, so we fought tooth and nail with a well known Dutch electronics company - in order to maintain picture quality.
Following one of the many rounds of HDTV subjective tests, the results from the BBC were conveniently lost, as they showed the commercial algorithms in a very bad light.
This is why even today, if you look at HD football on a large screen TV, the motion of the running players is often a blur and the crowd in the background are just blobs. Having seen full bandwith HDTV in the early 1990s - what we have now delivered to out living rooms and laptops is somewhat mediocre.
There was a lot of politics surrounding the implementation of HDTV around Europe at that time. Disenchanted with a series of management reorganisational changes to the corporation, I left the BBC in 1994 and branched out into various industrial fields.
None of them involving mainframes or FORTRAN!
3 Likes