Talk:Atari Transputer Workstation

Computing Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.

Video games Low‑importance

This article is within the scope of WikiProject Video games, a collaborative effort to improve the coverage of video games on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Video gamesWikipedia:WikiProject Video gamesTemplate:WikiProject Video gamesvideo game articles

Low

This article has been rated as Low-importance on the project's importance scale.

Summary of Video games WikiProject open tasks:

Summary of Video games WikiProject open tasks

AfDs

Merge discussions

Other discussions

No major discussions

Why? How much? Where'd it go? But no, really, why?[edit]

I see the article already takes a stab at the biggest question: why the heck would Atari take on such a machine (its answer: "It is not entirely clear" -- thank you, Magic 8-ball!). But it would be interesting to know a little bit more. This was a Tramiel-era project, right? How did they go about selling it, or did they just throw it out there at Comdex and hope someone would bite?

The article also doesn't mention the price, although I think one of the references mentions a $10K price point, which seems to be very competitive for a machine of its specs in that era.

And more questions: How long did they seriously pursue this? Why did it ultimately fail? I can think of some pretty obvious suspects: lack of proper marketing, no in-house expertise in its target markets, no applications, no follow-on products in the pipeline, entrenched competition, no credibility in that space... all of which take us back to Question 1. But what ultimately got them to realize that this was way, way out of their league? --NapoliRoma 14:32, 21 August 2006 (UTC)[reply]

All good questions. I think it basically fell in their lap, after everyone else gave it a pass. Atari had nothing else in the pipeline after ST gutted engineering, so I guess it seemed like a cheap way to get back into the high end.

IIRC the story correctly, Kodak bought a bunch, 250 I think, to use as some sort of supercomputer cluster for image processing. That was the only big sale, and I don't know what happened to that system. I couldn't find a real ref for the Kodak use though, so I didn't put it in. Maury 13:10, 9 September 2006 (UTC)[reply]

Some links about price and using of Kodak: Pricelist: http://www.atari-explorer.com/16bit/transputer.html Hint that a Kodak employee know well about transputers: http://portal.acm.org/citation.cfm?id=103667 Another price: http://alive.atari.org/alive7/transput.php

There was two companies wich start with the same name (Perihelion)? Later they merged? I just try to translate your article in german language.

An ex-Perihelion and Atari employee writes: there were two Perihelions. Perihelion Software in Shepton Mallet wrote HeliOS. Perihelion (Hardware) was in Cambridge and developed the ATW, and also did some other software development under contract to Atari. — Preceding unsigned comment added by 81.98.255.115 (talk) 10:48, 30 November 2012 (UTC)[reply]

Lack of memory protection "not an issue"?[edit]

So I realize this question might be a little past its day of relevance, but exactly why would lack of memory protection not be an issue? The article mentions the stack-based architecture, but did this really somehow provide an uncrossable barrier between privileged and non-privileged memory? --NapoliRoma 14:36, 21 August 2006 (UTC)[reply]

In case anybody else wonders about this: You might want to start by reading about the Occam_programming_language, which is what the Transputer was programmed with. In short, multiple processes communicate over well-defined channels, rather than using shared memory, as in a conventional UNIX system. Since processes (including OS processes) have no access to the memory of other processes, lack of memory protection doesn't necessarily lead to the kinds of problems you might expect. Mbessey 06:54, 9 September 2006 (UTC)[reply]

Yeah, Mbessey nailed it. But I realize in retrospect the article really does need to explain this. Mbessey, would you mind taking a crack at it? Maury 13:10, 9 September 2006 (UTC)[reply]

It's a while since I've programmed Transputers (ok, over ten years :)), but I'm almost certain that any process on one transputer had access to all memory on that processor, so they certainly could trash memory used by other processes if they were running on the same processor... just use a duff pointer and you've corrupted some other process. It's obviously far less of an issue if each process is running on its own transputer, and having all local variables accessed relative to the workspace pointer would help somewhat too (if the workspace pointer isn't corrupted then the process shouldn't write to invalid addresses). Mark Grant 15:54, 23 September 2006 (UTC)[reply]

workspace relative addressing[edit]

I just checked the assembly programming manual of the transputer: "transputer instruction set, a compiler's writing guide" The situation might be better with properly used occam, but the assembler instructions to address relative to the workspace (stl) would certainly allow to trash the whole of the memory a program is running on. This is especially true as negative offsets are allowed too, (they actually indicate some special locations). Absolute addresses (stnl)no doubt are not constrained at all. I cannot make sense of the sentence about the stack counteracting any trashing of memory not belonging to a process. 80.100.243.19 (talk) 14:17, 18 December 2010 (UTC)[reply]

The TT was not an '030[edit]

I had an ST, and read ST User and ST Format, and I remember a front page of one of the above showing the new TT, which was originally a massive thing. It said it used, not an '030, but the Inmos Transputer T800. Inmos made also the T212, which was only 16bit, and the T414, which was less powerful, and had a smaller cache. The T800 had some success, in the TT and also in the more successful Meiko Computing Surface. Later they released the T9000, which was unsuccessful, and was the end of the Transputer line. If you read other Atari Wikipedia articles, they say that the TT had a Motorola 68030. No, thatwas the Falcon. The T800, and I believe the others, were designed to be inherently parallel. They ħad four external buses. Some systems arranged them into a hyper-cube. Maybe that's why the TT had 4 serial ports? Edmund Xathrusz (talk) 04:22, 13 December 2018 (UTC)[reply]

You can easily verify that the TT was indeed a 68030-based product, not just by reading Wikipedia articles but also following the references to publications describing the machine. For example, STart Magazine's February/March 1991 issue which has a review of the TT030, as it was known. Or you can read Atari's own documentation which reads as follows: "The TT (Thirty-two/Thirty-two bit) and TT/X (Unix Engine) are a new series of Atari computers designed as enhanced versions of the existing ST and MEGA family. The TT series maintains compatibility with the ST/MEGA architecture, but uses the Motorola 68030 microprocessor and provides enhanced graphics and sound."

The ATW was a completely separate product from the TT, although you could say that they were both part of a strategy to make workstation products. The TT was meant to provide a conventional Unix system, whereas the ATW was somewhat unconventional, particularly as a standalone system. PaulBoddie (talk) 17:08, 22 February 2024 (UTC)[reply]