Clustered Pi Picos made to run original Transputer code The astonishing PicoPuter emulation project can run a transputer emulator on multiple Raspberry Pi Picos, and clustering them using the transputer's native inter-processor link protocol. The Raspberry Pi Pico is a surprisingly capable device at $4 apiece, and one of its less well-known features is its eight programmable IO …
I've got a chip that I crowdfunded which I thought was something close to a transputer but 30 years on - relying on fast interprocesser communications to get the real grunt. Unfortunately its in a 16thC intricately carved oak cabinet thingy and a door has jambed so I cant get to it to reveal its true name*. It is interesting to see that people are looking down this path again. We should have enough data/code sets to get an idea it its useful.
*the cabinet might** be worth more than my house so I'm not going to try and break into it.
** I saw something with the same style of carving on it go for £15k and it would fit into the small bit I cant open!!
I ran linux on a 4MB 386 and it functioned quite well on some tasks, the swap disk being a bit slow. I've played with minix and its quite capable though it does lack shit to play with. If this is stable then there's a whole new world of pocket computing that even MPs cant compete with.
While risking sounding like one of the "4 yorkshiremen" then ... 4MB ...you were lucky, I started computing with 1kB RAM (I remember the rush at school to build a 4kB memory *card* so we could play "star trek" on a 6800 system) - and forget about swapping - storage was a 1200baud casette... to think that now my PC has 16GB of RAM and 2-3TB of SSD (my first PC had a 40MB disk .... I was pretty irritatetd off that that was the smallest I could buy as a 10MB disk was about the size I felt I'd ever need)
As someone who worked on the transputer and its "successor" ST20 valiantly fighting agaisnt the rise of ARM then my response to this person is "desist immediatley"!
(On the other hand, one of the reasons I applied to INMOS was having encountered occam my immediate thought was "how can I implement this on my Acorn Atom"!)
I still vividly remember the day I wandered around at BTRL and in the lift well, on pallet with a trolley under it stood a 1024 transputer hypercube. No one around. It was a good 10 minutes before I managed to stop myself trying to work out how to get it into my car and there was still no-one else around!!!!
Blimey, this brings back memories!
When I was at uni we had a Meiko Computing Surface, which was a big box of Transputers, both T414s and T800s (one model had a FPU, the other didn't). By the time I got to use it they'd developed the MK083 on-board SPARC workstation and a virtualisation layer that allowed you to program transputers in C, not just Occam.
And the definitive book on Occam was written by Roy Dowsing, who taught us parallel processing in the second year at uni. I still have my copy. :-) https://www.amazon.in/Introduction-Concurrency-Aspects-Information-Technology/dp/0278000592
I seem to recall that Meiko, and indeed the whole Transputer thing, failed largely because writing stuff in Occam blew everybody's brains out.
I joined a waferfab equipment company which had set up a branch in the next Welsh Valley along to meet the predicted growth of the Inmos plant. Never got to call on that particular customer, though, just drove past it regularly on the motorway.
Before that, as a kid in Sheffield, Yorkshire in the 1960s (true), I used to build my own transistors out of dead boll weevils (false). I never got past 64 nibbles of RAM, a nibble being 4 bits, i.e. half a byte (true). We were reet miserable an' 'ungry, t' family 'u'd break inter me tea chest an' eat all t' weevils (false).
My sole experience of Occam was writing an program in it for an assignment at the University of Essex back in t'day. The whole concept of defining program structure by the number of spaces at the start of a line struck me as THE MOST obsessive nonsense ever.
This is probably why I've never got on with Python.
The whole transputer thing dies because Intel cracked what was at the time a clockspeed barrier of 30MH. Once Intel started bashing out 100MHz CPUs (and faster), there was no looking back. Everything could be single threaded and if it wasn't fast enough wait 6 months and buy another PC. The demand for complexity disappeared.
It also did not help that (at least on things that weren't a Meiko) Inmos's tools were dire. Debugging in Borland C was a dream. Debugging Transputer code was a nightmare.
Amusingly, the concept (Comminicating Sequential Processes) is making a comeback in Go, Rust. And todays CPU architectures are a bit like Transputer networks with an artificial SMP environment layered on top. There's now several layers of abstraction between code and actual hardware....
Roy was a good bloke. I always remember his resilient parallel OS demo where he had 4 cpu boards plugged into an 8 slot backplane and would in turn pull each board and move it 4 slots up and the OS kept happily running.
There was a long running departmental argument about whether or not to teach the undergrads debugging as a specific skill - the 4 of us who'd been practical programmers (Roy, Luke, Martin and me) argued for, the rest of the department who were pure CS (or frustrated mathematicians) argued against on the grounds "students would pick it up as they needed"(*). I left for industry in 1984 but I suspect the argument went on long afterwards.
(*) Which wasn't my experience in the 2nd and 3rd year labs.
We had a Computing Surface at uni as well (maybe it's the same one - the Octagonal Tower mean anything to you?). As part of my degree course we had a short series of lectures on Occam and were allowed to look at (but not touch!) the Meiko running full-motion real-time fractal generation (this was 1990ish).
The reference to A Fire on the Deep confused me somewhat. It is a superb book which I have read several times but I did not recognise the use in that book. Turns out the extended quote is actually from "A Deepness in the Sky" - the second book in the universe of AFotD.
They were called transistor radios to differentiate them from valve radios. As my parents had one of the later which had about 6 separate selectable bands on the "dial" (It wasn't so much a dial about about 2 foot long and 6 inches high, with helpful station markings such as 'Hilversum'), and came complete with a gramophone capable of playing 17, 33, 45 and 72 rpm records, I was well aware of the difference.
It is possible there were portable valve radios, but 'transistor radio' sounded way cooler and more modern than 'portable radio' at age 12.
And tranny is an unsurprising contraction of that - especially as transvestitism wasn't really something one even knew about at that tender age in those days.
17, 33, 45 and 72 rpm records
Not 17, but 16⅔ - half 33⅓.
Despite living through the entire cycle, from 78 rpm onwards, I have never seen a 16⅔ rpm record.
It is possible there were portable valve radios
Indeed, my grandma owned one. ISTR it contained a huge Ever Ready battery that didn't last long and couldn't be recharged, so listening to it was probably an expensive activity.
Indeed there were portable valve radios, with a 90v HT battery and a low voltage (1.5?) for the heaters. In our 1962 Rover we had a hybrid car radio with both valves and transistors, and I seem to remember the valves were special low voltage ones, but can't remember what - I was only 12.
Bene involved on projects with parallel processors
including back in the 80's a big mil one with transputers,
The problem that I keep seeing , is resources
people,
Its like "RTL" design, VHDL / System Verilog etc,
these are really parallel,
and need a mind set to program efficiently
that's very different to C++ programmers.
In RTL world, there are for ever new ideas as how to take C++ and make RTL
they all have there place, but are generally "CR**" . not that good
Transputrers were fantastic
we just could not get the programmers to think parallel
as such the tools concepts were just alien to them,
If some one can invent a way to program in C++
and it run efficiently on parallel processors,
they would make a fortune,
It should be a lot easier these days - in fact IIRC I read a program in a Prolog book that solved a similar problem as it really is just another aspect of resource management and logistics and, while I never quite got round to picking apart GPU code I'd imagine its been done for that so is probably available for C++ already.
In the late 1970s I introduced some of our hardware design engineers to my hobby Motorola 6800 development board. That came with a very thick tome detailing how to use it in place of discrete hardware logic for handling things like bar code readers, keyboards, etc. The engineers were surprised - they had thought microprocessors would be used as small computers viz PCs. However a very bright youngster drew up a theoretical design that used a quantity of microprocessors organised in a regular matrix of communication links. In hindsight it seems like he was anticipating transputer architecture.
Not sure about the commercial failure bit, but i do know that most of the UK navy sonar's relied on them in the 80's (and probably still would have if the T9000 hadn't been such a cluster f**k
The greatest thing about them was their scalability. You could do your development on 1 chip, with 16 processes and then run the same software on hardware with 16 processors without changing a thing. Well ahead of its time and great fun.
Nice to see there is still some love out there
That "no code change" is something that I treasure today, and go to some lengths to replicate if needs be.
I quite like ZeroMQ for its diversity of sockets, ranging from in-process to cross network. Just change the connection strings, no other changes. If it implemented CSP instead of just the actor model, it'd be perfect.
One of the pities about things like OpenMPI and OpenMP is that they don't play nicely. If you parallelise an algorithm using OpenMP you then can't easily scale up with OpenMPI.
I went for an interview with Perihelion a very long time ago. I wasn't aware they developed the transputer until they said it and I geeked out about the Atari Abaq. They had a converted old building out in the middle of nowhere where they did their work. They seemed like nice folks. Got a pub lunch out of them although I didn't get a job.
I did post grad research in the mid '90s on an Atari Transputer Workstation. Initial boot was Atari OS on Motorola 68000, which then handed over to a single T800 master running Helios with X-Windows
Had 3 'farmcards' each with 4 T800s for a total of 12 workers. Was writing image processing routines to take advantage of the parallel processing. The T800's were quite fast at actual processing when compared to the single CPU machines we had (SPARC 2 and Intel 386), but was let down by slow io between the processors.
It came with an 80MB hard drive (that is not a typo - eighty megabytes). I think we paid about £1000 to upgrade the disk to a whopping 100MB
For us the Transputer links were both it's strength and weakness. We worked with INMOS and liked the product as it seemed ideal for our parallel processing but when we did the data simulation we found that due to the volume of data we needed to process in a fixed unit of real time and the link bandwidth supported we were I/O bound rather than CPU bound. There were much faster ways of getting data to an array processors so we went with another RISC CPU that was about to start production.
Happy days playing with the T414, developing a thermal print array based chart recorder (replacing wiggly pens). The (anticipated) product range went from 10cm wide at about 10mms/sec to 100cm wide at 100cm/sec. Transputer seemed ideal though it never got past the low end device which would have been far easier using a 68000 than the Transputer with its IO chip and a bunch of PIC microcontrollers doing the IO. Happy days, much better than the shite financial services systems (monstrosities) in Java nowadays.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
