I've developed an ISA board to test some transputer boards (TRAM) I bought in eBay, I started with a prototype wired board on an ISA development card, and then I made a proper PCB in three iterations as I solved some bugs.
The ISA connector was just because I have several old PC motherboards (80286, 80486, a Pentium MMX, and a AMD K5)
The history of development is available at https://nanochess.org/transputer_board.html
The schematics and PCB are available at https://github.com/nanochess/transputer/pcb
In the same git you can get my operating system developed in 1993-1996.
On 7/4/2025 3:30 PM, Oscar Toledo G. wrote:
I've developed an ISA board to test some transputer boards (TRAM) I
bought in
eBay, I started with a prototype wired board on an ISA development
card, and then I made a proper PCB in three iterations as I solved
some bugs.
The ISA connector was just because I have several old PC motherboards
(80286,
80486, a Pentium MMX, and a AMD K5)
The history of development is available at
https://nanochess.org/transputer_board.html
The schematics and PCB are available at
https://github.com/nanochess/transputer/pcb
In the same git you can get my operating system developed in 1993-1996.
Excellent! What did you learn from the experience (besides the
perils of rushing a PCB)? I.e., what value (or lack thereof) did the transputer offer?
Could you, perhaps, have used a small SBC (arduino, rPi, etc.) and
used GPIOs to twiddle the hardware -- and a USB interface to talk
to it? Or, was the ISA bus an important asset?
Hi there.
I've developed an ISA board to test some transputer boards (TRAM) I bought in eBay,
I started with a prototype wired board on an ISA development card, and then I made
a proper PCB in three iterations as I solved some bugs.
The ISA connector was just because I have several old PC motherboards (80286, 80486, a Pentium MMX, and a AMD K5)
The history of development is available at https://nanochess.org/transputer_board.html
The schematics and PCB are available at https://github.com/nanochess/transputer/pcb
In the same git you can get my operating system developed in 1993-1996.
Enjoy it!
In a previous life I had quite huge a T800 Tranputer cluster and also
did some designs that connected to it.
The ISA bus was not important, but there was a link adaptor
chip (C11? - where is my bottle of Gerontol Forte?) that had a
SRAM-alike "foreign" side that made it easy to handle.
In <https://www.flickr.com/photos/137684711@N07/52631074700/in/datetaken/lightbox/ >
the link chip is between the Western Digital SCSI controller and the
VLSI serial/par IO chip.
Complete industrial PC/AT with Multibus2, lots of DRAM, disks, floppy, ... Thanks Goddess I had someone to do the board layout in DOS Orcad STD
on a Compaq 286 :-)
Occam was fun. Maybe nowadays it would make a bigger impact with a substantial number of CPUs on a chip.
In a previous life I had quite huge a T800 Tranputer cluster and also
did some designs that connected to it.
The ISA bus was not important, but there was a link adaptor
chip (C11?� - where is my bottle of Gerontol Forte?) that had a
SRAM-alike "foreign" side that made it easy to handle.
In
<https://www.flickr.com/photos/137684711@N07/52631074700/in/datetaken/lightbox/ �>
the link chip is between the Western Digital SCSI controller and the
VLSI serial/par IO chip.
Complete industrial PC/AT with Multibus2, lots of DRAM, disks, floppy, ... >> Thanks Goddess I had someone to do the board layout in DOS Orcad STD
on a Compaq 286� :-)
Occam was fun. Maybe nowadays it would make a bigger impact with a
substantial number of CPUs on a chip.
But there have been countless (for small values of countless) concurrent
and parallel programming languages (as well as languages with memory
models that can usurp that ability).
People seem largely incapable of decomposing "programs" into concurrent >activities *within* a language and, instead, seem to rely on mechanisms >outside the language (e.g., OS-hosted). My take on it is that
fine-grained concurrency is "too much detail" for most developers to
manage (except on special case applications).
[Of course, applications that are inherently SIMD/MIMD can be special-cased. >But, the market has a sh*tload of applications that aren't so obviously so >and should be able to benefit from concurrency and parallelism. Designing
an application to fit WELL a multicore processor is a lot harder than it >seems it should be!]
Hence, we let compilers sort out where things can happen "in parallel"
and free ourselves from that minutiae. Looking at parallelism/concurrency
in the model *design* at a higher level of abstraction, instead.
As for the transputer hardware, it seemed to not provide enough, soon enough.
Another idea that was bulldozed away by less sophisticated -- but more
widely available -- solutions.
[E.g., why did the "pure" memory segmentation model fail to evolve beyond
the limited implementations initially offered? Why paged MMUs? etc.]
Since CPU cores are trivial nowadays - they cost a few cents each -
the transputer concept may make sense again. We rely on an OS and
compiler tricks to get apparent parallelism, and the price is
complexity and bugs.
Why not have a CPU per task? Each with a decent chunk of dedicated
fast ram?
Hi there.
I've developed an ISA board to test some transputer boards (TRAM) I bought in eBay,
I started with a prototype wired board on an ISA development card, and then I made
a proper PCB in three iterations as I solved some bugs.
The ISA connector was just because I have several old PC motherboards (80286, 80486, a Pentium MMX, and a AMD K5)
The history of development is available at https://nanochess.org/transputer_board.html
The schematics and PCB are available at https://github.com/nanochess/transputer/pcb
In the same git you can get my operating system developed in 1993-1996.
Enjoy it!
On Sun, 6 Jul 2025 04:58:09 -0700, Don Y <[email protected]d>
wrote:
In a previous life I had quite huge a T800 Tranputer cluster and also
did some designs that connected to it.
The ISA bus was not important, but there was a link adaptor
chip (C11? - where is my bottle of Gerontol Forte?) that had a
SRAM-alike "foreign" side that made it easy to handle.
In
<https://www.flickr.com/photos/137684711@N07/52631074700/in/datetaken/lightbox/ >
the link chip is between the Western Digital SCSI controller and the
VLSI serial/par IO chip.
Complete industrial PC/AT with Multibus2, lots of DRAM, disks, floppy, ... >>> Thanks Goddess I had someone to do the board layout in DOS Orcad STD
on a Compaq 286 :-)
Occam was fun. Maybe nowadays it would make a bigger impact with a
substantial number of CPUs on a chip.
But there have been countless (for small values of countless) concurrent
and parallel programming languages (as well as languages with memory
models that can usurp that ability).
People seem largely incapable of decomposing "programs" into concurrent
activities *within* a language and, instead, seem to rely on mechanisms
outside the language (e.g., OS-hosted). My take on it is that
fine-grained concurrency is "too much detail" for most developers to
manage (except on special case applications).
[Of course, applications that are inherently SIMD/MIMD can be special-cased. >> But, the market has a sh*tload of applications that aren't so obviously so >> and should be able to benefit from concurrency and parallelism. Designing >> an application to fit WELL a multicore processor is a lot harder than it
seems it should be!]
Hence, we let compilers sort out where things can happen "in parallel"
and free ourselves from that minutiae. Looking at parallelism/concurrency >> in the model *design* at a higher level of abstraction, instead.
As for the transputer hardware, it seemed to not provide enough, soon enough.
Another idea that was bulldozed away by less sophisticated -- but more
widely available -- solutions.
[E.g., why did the "pure" memory segmentation model fail to evolve beyond
the limited implementations initially offered? Why paged MMUs? etc.]
Since CPU cores are trivial nowadays - they cost a few cents each -
the transputer concept may make sense again. We rely on an OS and
compiler tricks to get apparent parallelism, and the price is
complexity and bugs.
Why not have a CPU per task? Each with a decent chunk of dedicated
fast ram?
Oscar Toledo G. <[email protected]> wrote:
Hi there.
I've developed an ISA board to test some transputer boards (TRAM) I bought in eBay,
I started with a prototype wired board on an ISA development card, and then I made
a proper PCB in three iterations as I solved some bugs.
The ISA connector was just because I have several old PC motherboards (80286,
80486, a Pentium MMX, and a AMD K5)
The history of development is available at
https://nanochess.org/transputer_board.html
The schematics and PCB are available at
https://github.com/nanochess/transputer/pcb
In the same git you can get my operating system developed in 1993-1996.
Enjoy it!
Great job!
My agenda includes mastering kicad 9 - including its interface to
ngspice - as soon as possible. My passion these days is exploit Zynq
7000 SoCs to virtualize both lab instruments and radios.
Here's a sneak peek at my retro RF double balanced mixer work in progess: <https://crcomp.net/mixer/> Although its hardware lash-up
was finished in no time, its webpage and rhetoric still need work.
Danke,
john larkin <[email protected]> wrote:
Since CPU cores are trivial nowadays - they cost a few cents each -
the transputer concept may make sense again. We rely on an OS and
compiler tricks to get apparent parallelism, and the price is
complexity and bugs.
Why not have a CPU per task? Each with a decent chunk of dedicated
fast ram?
Intel tried that:
https://en.wikipedia.org/wiki/Xeon_Phi
(obviously using x86 was a bad idea, but apart from that...)
The issue is one of memory capacity and bandwidth. Many applications have a >large (GB) dataset that doesn't partition nicely up between multiple nodes.
Even the largest FPGAs tend to have MB-scale amounts of memory on them, not >GB, because the memory density of a dedicated DRAM chip is so much better >than making on-chip BRAMs. It turns out to be more efficient to use a large >external DRAM and drive it in a highly parallel way, pumping data through a >GPU-style core, than it is to have lots of little cores individually
fetching single words from their local BRAM. With that model you also need
a fabric for the little cores to communicate, while with a big DRAM you get >inter-core/thread communication for free - you just arrange to a write to a >different part of the shared dataset and the next consumer picks it up.
You can of course put GDDR or HBM on an FPGA, but it's the same problem - >only a few devices must be shared by numerous cores. Ultimately memory >throughput beats latency hands down, especially for large datasets. This
was not such a problem in the Transputer's day, which is why that >architecture made sense.
Theo
The issue is one of memory capacity and bandwidth. Many applications have a large (GB) dataset that doesn't partition nicely up between multiple nodes.
You can of course put GDDR or HBM on an FPGA, but it's the same problem - only a few devices must be shared by numerous cores. Ultimately memory throughput beats latency hands down, especially for large datasets. This
was not such a problem in the Transputer's day, which is why that architecture made sense.
Don wrote:
Oscar Toledo G. wrote:
Hi there.
I've developed an ISA board to test some transputer boards (TRAM) I bought in eBay,
I started with a prototype wired board on an ISA development card, and then I made
a proper PCB in three iterations as I solved some bugs.
The ISA connector was just because I have several old PC motherboards (80286,
80486, a Pentium MMX, and a AMD K5)
The history of development is available at
https://nanochess.org/transputer_board.html
The schematics and PCB are available at
https://github.com/nanochess/transputer/pcb
In the same git you can get my operating system developed in 1993-1996.
Enjoy it!
Great job!
My agenda includes mastering kicad 9 - including its interface to
ngspice - as soon as possible. My passion these days is exploit Zynq
7000 SoCs to virtualize both lab instruments and radios.
Here's a sneak peek at my retro RF double balanced mixer work in
progess: <https://crcomp.net/mixer/> Although its hardware lash-up
was finished in no time, its webpage and rhetoric still need work.
Don,
You do need to use the center tap on TR2 to get anything
but a sophisticated short circuit.
Seems a shame to have an x86 core wasting time handling ethernet and
printers and mice and memory sticks when they could be doing better
things like running Spice.
My Windows 11 thing is running hundreds of processes right now. That's
crazy.
Computing is a mess. A new hardware architecture would at least
suggest a fresh start.
john larkin <[email protected]> wrote:
Seems a shame to have an x86 core wasting time handling ethernet and
printers and mice and memory sticks when they could be doing better
things like running Spice.
Many of those things are already happening outboard anyway - all those
things have processors in them. What the CPU is doing is largely managing >the data transfer to and from the device. eg the printer speaks PCL or >Postscript and the OS's workload is limited to firing the job at the printer >(USB/network) and the printer's CPU then decides where to put the ink on
the page.
You can delegate that management oversight to another core if you like, but >then you need management oversight of *that* core.
My Windows 11 thing is running hundreds of processes right now. That's
crazy.
Windows problems :-) But many of those things don't need to take much CPU - >they're ready to handle print jobs when you press Ctrl-P, but the rest of
the time they're ticking along in the background not taking much resources >because they don't need them.
The OS is running thousands of kernel threads, but they're mostly blocked >(not scheduled) until they need to do something. One thread per 'thing', >more or less. All that thread needs is a few hundred bytes for its register >state so the impact is small.
Computing is a mess. A new hardware architecture would at least
suggest a fresh start.
Non-Windows, non-x86 architectures are available...
Theo
On 08/07/2025 11:10, john larkin wrote:
On 07 Jul 2025 17:21:11 +0100 (BST), TheoMaybe "just for fun" but it might give them a stronger position
<[email protected]> wrote:
john larkin <[email protected]> wrote:
Seems a shame to have an x86 core wasting time handling ethernet and
printers and mice and memory sticks when they could be doing better
things like running Spice.
Many of those things are already happening outboard anyway - all those
things have processors in them. What the CPU is doing is largely managing >>> the data transfer to and from the device. eg the printer speaks PCL or
Postscript and the OS's workload is limited to firing the job at the printer
(USB/network) and the printer's CPU then decides where to put the ink on >>> the page.
You can delegate that management oversight to another core if you like, but >>> then you need management oversight of *that* core.
My Windows 11 thing is running hundreds of processes right now. That's >>>> crazy.
Windows problems :-) But many of those things don't need to take much CPU -
they're ready to handle print jobs when you press Ctrl-P, but the rest of >>> the time they're ticking along in the background not taking much resources >>> because they don't need them.
The OS is running thousands of kernel threads, but they're mostly blocked >>> (not scheduled) until they need to do something. One thread per 'thing', >>> more or less. All that thread needs is a few hundred bytes for its register
state so the impact is small.
Computing is a mess. A new hardware architecture would at least
suggest a fresh start.
Non-Windows, non-x86 architectures are available...
Theo
The x86 is nearly the peak of the silly concept that the CPU is a big
deal. Intel is heavily invested in that idea. ARM and Risc-V cores are
fast and cheap and basically trivial amounts of silicon. We can have a
zillion CPUs on a chip so don't benefit from the brutal complexity and
inefficiency of trying to share just a few big ugly CPUs among
hundreds of processes.
We use the RP2040 chip in some products. It's a dual-core 133 MHz ARM
with lots of cute peripherials, including hardware state machines.
It's 75 cents in any quantity. On the new version, the RP2350, they
threw in a couple of RISC-V cores just for fun.
when negotiating royalty rates with ARM.
John
Many of those things are already happening outboard anyway - all those
things have processors in them.
What the CPU is doing is largely managing
the data transfer to and from the device. eg the printer speaks PCL or Postscript and the OS's workload is limited to firing the job at the printer (USB/network) and the printer's CPU then decides where to put the ink on
the page.
You can delegate that management oversight to another core if you like, but then you need management oversight of *that* core.
Windows problems :-) But many of those things don't need to take much CPU - they're ready to handle print jobs when you press Ctrl-P, but the rest of
the time they're ticking along in the background not taking much resources because they don't need them.
The OS is running thousands of kernel threads, but they're mostly blocked (not scheduled) until they need to do something. One thread per 'thing', more or less. All that thread needs is a few hundred bytes for its register state so the impact is small.
In the same git you can get my operating system developed in 1993-1996.
Excellent! What did you learn from the experience (besides the
perils of rushing a PCB)? I.e., what value (or lack thereof) did the
transputer offer?
The transputer doesn't offer any value actually. I only did it to re-run my old software, and because I had curiosity about running Occam. Installing Occam and trying to get things runnings was not a so amazing experience as I expected.
Once the Pentium was out, the transputer was basically obsolete.
Could you, perhaps, have used a small SBC (arduino, rPi, etc.) and
used GPIOs to twiddle the hardware -- and a USB interface to talk
to it? Or, was the ISA bus an important asset?
It is my first "complicated" circuit board, so I didn't want to munch more than necessary.
The ISA is an important asset, because there's no point on putting a transputer board on a Pentium machine, but I have a 80286 where the transputer
speed is obvious.
My point, though, was as to whether going with a USB-based interface
might have made your effort easier? I.e., use a COTS board (Arduino, etc.) >> to GIVE you the interface to the host PC (so you don't have to develop your >> own USB stack) and just make a small adapter board that goes from the (e.g., >> Arduino) to the transputer.
Or, use a network interface on such a COTS board to talk to the MCU and
let it talk to the trnsputer.
[I've no idea how fat a pipe the transputer needs to do anything meaningful >> on the PC]
The advantage of either approach would be your "interface" would be more
portable to different machines -- even non-PCs.
I get now your point. I never thought about it. But I published the schematics
in case someone wants to do another type of interface.
The multiplatform ability currently is my transputer emulator in Javascript. It runs on PC, Mac, or Linux, just visiting my webpage at https://nanochess.org/transputer_emulator.html
I think there is already a very good Raspberry Pi project for transputers where you can connect a transputer, or use a Pi to emulate the transputer.
Maybe it could be a mathematical coprocessor for Arduino, but it would be too expensive.
On 6/07/2025 11:44 pm, john larkin wrote:
On Sun, 6 Jul 2025 04:58:09 -0700, Don Y <[email protected]d>
wrote:
;In a previous life I had quite huge a T800 Tranputer cluster and also
did some designs that connected to it.
The ISA bus was not important, but there was a link adaptor
chip (C11? - where is my bottle of Gerontol Forte?) that had a
SRAM-alike "foreign" side that made it easy to handle.
In
<https://www.flickr.com/photos/137684711@N07/52631074700/in/datetaken/lightbox/
the link chip is between the Western Digital SCSI controller and the
VLSI serial/par IO chip.
Complete industrial PC/AT with Multibus2, lots of DRAM, disks, floppy, ... >>>> Thanks Goddess I had someone to do the board layout in DOS Orcad STD
on a Compaq 286 :-)
Occam was fun. Maybe nowadays it would make a bigger impact with a
substantial number of CPUs on a chip.
But there have been countless (for small values of countless) concurrent >>> and parallel programming languages (as well as languages with memory
models that can usurp that ability).
People seem largely incapable of decomposing "programs" into concurrent
activities *within* a language and, instead, seem to rely on mechanisms
outside the language (e.g., OS-hosted). My take on it is that
fine-grained concurrency is "too much detail" for most developers to
manage (except on special case applications).
[Of course, applications that are inherently SIMD/MIMD can be special-cased.
But, the market has a sh*tload of applications that aren't so obviously so >>> and should be able to benefit from concurrency and parallelism. Designing >>> an application to fit WELL a multicore processor is a lot harder than it >>> seems it should be!]
Hence, we let compilers sort out where things can happen "in parallel"
and free ourselves from that minutiae. Looking at parallelism/concurrency >>> in the model *design* at a higher level of abstraction, instead.
As for the transputer hardware, it seemed to not provide enough, soon enough.
Another idea that was bulldozed away by less sophisticated -- but more
widely available -- solutions.
[E.g., why did the "pure" memory segmentation model fail to evolve beyond >>> the limited implementations initially offered? Why paged MMUs? etc.]
Since CPU cores are trivial nowadays - they cost a few cents each -
the transputer concept may make sense again. We rely on an OS and
compiler tricks to get apparent parallelism, and the price is
complexity and bugs.
Why not have a CPU per task? Each with a decent chunk of dedicated
fast ram?
So all tasks are created equal? And dedicating a CPU to every last one
of them isn't an over-kill for most of them?
https://en.wikipedia.org/wiki/Transputer
does offer a slightly more sophisticated insight into why Inmos
eventually went bust - actually it was sold to SGS-Thomson (now >STMicroelectronics).
Parallel processing and multitasking are both a complicated subjects,
and one-size-fits-all-solutions don't seem to exist.
People who do special purpose electronic design do tend to have a
grab-bag of techniques developed to solve other problems for other
customers - John Fields could solves lots of problem with a 555, but my >feeling was that a lot of his solutions were sub-optimal.
--
Bill Sloman, Sydney
Why not have a CPU per task? Each with a decent chunk of dedicated
fast ram?
So all tasks are created equal? And dedicating a CPU to every last one
of them isn't an over-kill for most of them?
This doesn't take into account the architecture of the CPU.
There is no need to dedicate a CPU to task, because multiple
task can be mapped within one CPU.
https://en.wikipedia.org/wiki/Transputer
does offer a slightly more sophisticated insight into why Inmos
eventually went bust - actually it was sold to SGS-Thomson (now
STMicroelectronics).
The nodes in a parallel system, shouldn't be low level but at
a par with the most cost effective CPU in the era.
There was no investment in a 4 Ghz T8000 (64 bit) with 1 Gbyte links
and I bet that it could have at least have a niche for itself.
I was involved in a geology simulation system with interactive
graphics for the Shell (1990). The alternative was the Cray,
and the difference in costs were staggering.
I made a twin counting program as a demonstration. We (HCC)
had a heterogeneous bunch of in total 60 transputers.
I borrowed from military and educational institutes for a total
cluster of 180 transputers. They worked well together, a hotspotch
of power supplies and transputer boxes. Imagine 180 386 boxes
working together.
https://home.hccnet.nl/a.w.m.van.der.horst/transputer.html
The Fortg compiler available through this page, should work
as long as a transputer link is operational.
Parallel processing and multitasking are both a complicated subjects,
and one-size-fits-all-solutions don't seem to exist.
People who do special purpose electronic design do tend to have a
grab-bag of techniques developed to solve other problems for other
customers - John Fields could solves lots of problem with a 555, but my
feeling was that a lot of his solutions were sub-optimal.
I'm firmly convinced that the transputer route is not fully
explored. HuaWei beats nvidia with ai, not with superior cpu's
(although that is coming), but with superior inter cpu communication.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 165:53:47 |
| Calls: | 12,096 |
| Calls today: | 4 |
| Files: | 15,001 |
| Messages: | 6,517,807 |