Linked by Thom Holwerda on Fri 21st Mar 2014 22:58 UTC, submitted by axelmuhr
OSNews, Generic OSes

This is a project for breathing new live in Helios, an OS from the 90's. Helios was developed by the (now defunct) company called Perihelion Ltd., mainly targeting the INMOS Transputer but later adding other CPUs like the ARM series or TMS320c4x DSPs when INMOS' decline became clear.

The project's website has more details.

Order by: Score:
pwawrzyniak
Member since:
2014-02-01

When we’re talking about INMOS Transputer we cannot say nothing about famous Atari ATW-800, also known as ATW (Atari Transputer Workstation) or Abaq. This was really interesting piece of hardware. It was first presented on COMDEX expo in 1987 under the name Abaq, in fact. It was just two years after introduction of Atari ST – the first 16-bit Atari computer developed under the new brand owner – Jack Tramiel. These two machines are related to each other, because Atari ATW-800 consists of three main components:

1) the main motherboard containing a T800-20 transputer and 4MB of RAM (expandable to 16MB)
2) a complete miniaturized Mega ST acting as an I/O processor with 512kB of RAM (which is in fact a variation of regular Atari ST)
3) the Blossom video system with 1MB of dual-ported RAM (in late 80’s its graphic capabilities were stunning)

The Abaq’s bus was also available externally, allowing several ATWs to be connected into one large farm – a great thing when we think about distributed computing in late 80’s and early 90’s. Moreover, turning off an ATW would not affect the overall farm, the tasks would simply move to other processors on other systems. Also, there were only 350 units produced.

Please note, that Atari ATW-800 was driven by HeliOS, of course!

Finally, let me explain that I just had to add this comment, because on so many occasions we refer to Amiga here on OSNews.com. This time it is a good occasion to remind Tramiel’s Atari achievements.

It is important, as I believe, because at the time Atari 16/32-bit computers were considered to be direct competitors of Amiga machines. Although, the first Atari ST was aimed to compete with Macintosh (hence its name: Jackintosh) – and have more hardware/software similarities to this computer than to Amiga 1000 of this time.

"Power Without the Price"! :-)


Source of information:
http://en.wikipedia.org/wiki/Atari_Transputer_Workstation

Some more information on Atari-Forum Wiki:
http://www.atari-forum.com/wiki/index.php?title=ABAQ_ATW_800

A very nice video on ATW:
http://www.youtube.com/watch?v=U4uNBQUA-iM

A site collected by a person who restored ATW - there are some interesting photos under the Images link:
http://atw800.complicated.net/


Best regards,
Pawel Wawrzyniak
http://turingsman.net/

Reply Score: 11

Kochise Member since:
2006-03-03

Nothing to add, great post.

Kochise

Reply Score: 2

Atari vs. Amiga
by cybergorf on Sat 22nd Mar 2014 03:20 UTC
cybergorf
Member since:
2008-06-30

The war never ends.... ;-)

Also the Amiga 2000 and 3000 were were targeted for a Transputer workstation. Conveniently done by the AVALON Card for the self-configuring ZorroII and ZorroIII port.

http://www.amigahistory.co.uk/prototypes/transputer.html

Reply Score: 7

RE: Atari vs. Amiga
by Doc Pain on Sun 23rd Mar 2014 00:38 UTC in reply to "Atari vs. Amiga"
Doc Pain Member since:
2006-10-08

The war never ends.... ;-)


For a historical lesson: East vs. West, or should I say "West inside East"?. :-)

At the end of the GDR (1990), robotron introduced the EC1835 Transputer, consisting of the EC1835 host computer, based on an Intel 80386 CPU at 25 MHz, usually 20 or 40 MB hard disk, a 5.25" floppy drive with 1.2 MB capacity, and VGA graphics. The important part was a BRK connector card using an INMOS T800 at 20 MHz with 4 MB RAM. A separately attached box EC1835-TR transputer array (8 slots) could be equipped with 2 x T800 or T414 for the transputer cards. 2 - 16 node processors were possible, along with memory configurations of 8 - 64 MB RAM. This configurations could reach 8 - 64 MIPS (VAX) in a freely programmable topology.

The device itself didn't look any impressive:

http://www.robotrontechnik.de/bilder/PCs/EC1835/EC1835_transputer_k...

Nice intention, but too little too late. It never got any customers using it.

Reply Score: 4

Fascinating.
by lproven on Sat 22nd Mar 2014 11:10 UTC
lproven
Member since:
2006-08-23

[/Spock]

More info than I've ever read about Helios before. I didn't realise it lacked memory protection and was essentially one-task-per-Transputer before. That is more limited than I realised.

But still... I wonder if it could be ported to run on a Tilera chip?

http://www.tilera.com/products/processors/TILE-Gx_Family

Reply Score: 3

RE: Fascinating.
by BlueofRainbow on Sat 22nd Mar 2014 12:18 UTC in reply to "Fascinating."
BlueofRainbow Member since:
2009-01-06

I don`t see why one-task-per-Transputer is limiting.

No matter how one cuts the proverbial hair, a processing unit can only execute one task in a given unit of time.

Multi-tasking carries a pricey overhead related to task-switching. Now, if the tasks are associated to processing units on a one-to-one relationship and there is an efficient and safe management scheme for the common resources (I/O, physical memory, virtual memory), then who knows?

From what I remember, efficient inter-Transputer communication was necessary and Inmos came up with a number of innovative technical solutions - some of them still with us. I believe that there is one IEEE standard based on Inmos solution - don`t remember the details though.

Reply Score: 2

RE[2]: Fascinating.
by jockm on Sat 22nd Mar 2014 15:02 UTC in reply to "RE: Fascinating."
jockm Member since:
2012-12-22

That is a fair point when there are transputers in the world. But ported to a modern architecture that would mean Helios could run 4-12, processes at a time ... without a memory manager.

A big part of why Helios could get buy with a MMU was because it relied on the message passing architecture of the Transputer and thus limiting the areas where were apps could overwrite other apps memory (though far from entirely)

Helios would be rather interesting on the Cell processor, or Tilera chips mentioned elsewhere, or the XMOS stuff (if they ever allow more than 64K per chip).

But on the kinds of architectures most people would run it on, that kind of one process per core approach is going to be very liniting

Reply Score: 5

RE[2]: Fascinating.
by tylerdurden on Sat 22nd Mar 2014 21:04 UTC in reply to "RE: Fascinating."
tylerdurden Member since:
2009-03-17


No matter how one cuts the proverbial hair, a processing unit can only execute one task in a given unit of time.


That depends on how you define processing unit, execute, and task.

Furthermore, although context switch overhead was a significant factor way back in the single/low double digit MHz era, in the GHz designs of today the number of instructions between interrupt ticks is so large that context switch overhead is basically noise.

Reply Score: 6

Transputers
by Treza on Sat 22nd Mar 2014 18:27 UTC
Treza
Member since:
2006-01-11

I have fond memories of Transputers.
I once created carrier cards and interfaces for TRAMs (Transputer Modules) for a Radio Astronomy lab.
The Transputers were eventually replaced by Analog Devices SHARC DSPs whose 6 link ports were similar to Transputer links. Because the T9000 failed.

Our parallel computer had >40 SHARCs daisy chained...

Transputers pioneered many original concepts, for example the OCCAM language for parallel / dataflow processing.

Maybe there is currently a revival of parallel computers with NOCs architectures.

Reply Score: 4

RE: Transputers
by Kochise on Sat 22nd Mar 2014 20:12 UTC in reply to "Transputers"
Kochise Member since:
2006-03-03

T-800 failed, T-1000 failed, no wonders T-9000 failed as well to kill John Connor.

Kochise

Reply Score: 4