Jump to content
IGNORED

Inmos/Sinclair TV-Toy Info


Recommended Posts

I was looking at the Wikipedia page for the transputer (used in the Atari ATW), and noticed some info about an attempted games console by Inmos+Sinclair called the TV-Toy (https://en.wikipedia.org/wiki/Transputer#Implementations).

It was abandoned in 1985 but I wondered if anyone knew about it?

The basic 16bit transputer core was around 20K transistors in size, for reference the Amiga chipset chips were 21K transistors, so feasibly these could've been produced cheaply.

http://public.callutheran.edu/~reinhart/CSC521/Week8/Transputers.pdf

 

I think that there were several reasons that the ATW failed to sell (a few hundred units only) - high system and CPU cost ($400, and you need several really as task switching is not then needed) coupled with poor marketing (Atari!), and the real kicker which is no C/Pascal compilers, and the system architecture was not mainstream, hence justifying the outlay was difficult.

 

Inmos did envision the transputer chips running in everything, as microcontrollers etc.

There is a what-if where Atari knew that they would produce a blitter for the ST and put a socket on every ST, and after Inmos approached them, used a T212 as a blitter instead in 87.

This changes the landscape for Inmos, as using the transputer as a coprocessor/accelerator fits better into the Atari lineup, and gives people a good introduction into the transputer, for many applications (graphics, 3D CAD, sound processing, floating point calcs etc.).

 

Technically, the blitter socket is a coprocessor socket as it can take over the ST bus with direct access to RAM, disk etc. You wouldn't get the transputer links as the socket doesn't support them.

 

In terms of speed, the T212 is around 10x the 68K for floating point (http://www.transputer.net/tn/57/tn57.html), and can probably blit as fast as the ST blitter (it does 10MIPS for 16bit ops), as far as what the chip can do I'd estimate it about the same ability as the SuperFX2 chip (which does 7-12mips but on a much slower bus setup on the SNES vs the ST http://anthrofox.org/starfox/superfx.html).

 

This is in 87, before the TT was made. I'm guessing by the timeline that I know, that the EST development was dropped, probably for the ATW (and the 020+Atari MMU wasn't as good a solution as the 030), and when that didn't sell, Roy Good took over to finish (reusing the EST graphics) in 1990.

Tbh the design of the Falcon was more innovative and compatible than the TT (https://mikrosk.github.io/sparrow/falcon_specification_19920826.html), but Atari cheaped out on fitting 2mb ram as standard, so to fit 1mb, the main bus had to be cut to 16bits. The COMBEL+VIDEL combination is great though, and for 87/88 that would've made a great TT, with the COMBEL blitter replaced by a full T400 32bit+DMA links to open parallel computing to the masses.

 

Further on, given that the 68K range died, the transputer could have well found a home in Atari machines as the main CPU, and probably the first real GPU (fitting several transputers on the same die) - Inmos could well have been what ARM+NVIDIA have become.

 

Anyway, random thoughts aside, I'd welcome any info on the TV-Toy chipset, just to see what Inmos had planned for their low-end offerings.

Cheers

  • Like 1
Link to comment
Share on other sites

Well, I can say only that your sources, which you linked here contain wrong info in many cases. I did not read them thoroughly, and I will not - because what saw at beginning was enough ...  For instance that mikro "falcon spec .." is pathetic (now some judge will come here and talk about how non polite I'm - well I stay behind what I say). Like about why main bus is cut to 16 bits - because 'to fit 1 MB RAM' - sorry but this is most ridiculous 'reasoning' I read in like last year.

Btw. known interesting fact is that MC68000 has about 68000 transistors. Hard to believe that some later CPUs, much more capable have less.

"Technically, the blitter socket is a coprocessor socket as it can take over the ST bus with direct access to RAM, disk etc. You wouldn't get the transputer links as the socket doesn't support them. " - wrong it is not coprocessor socket, and no direct access to disk (that even sounds soo low knowledgely ...).

We know what is blitter's purpose and how it is achieved. For instance CPU is slow with shift operations, and sometimes need to perform multiple ones in row to perform desired graphic effect. Blitter can do it all in few cycles because internal logic designed special for graphic operations.

Finally, I don't think that Transputer, whatever great it is can replace blitter, Combel or whatever. It is just CPU, and therefore not so fast as logic arrays.

And don't believe everything you read. I never heard about that Sinclair had plans with some game console. Maybe just quick idea ?

 

Link to comment
Share on other sites

Generally items on Wikipedia need to be backed up with evidence, so it's a fair assumption that there is some info about the TV-Toy out there.

As far as the rest goes, it's referenced, and if you choose to believe it, that's up to you.

What is true, is that many processors have a smaller transistor count than the 68K - the ARM2 is well documented to return 4+ MIPS on ~30K transistors (https://en.wikichip.org/wiki/acorn/microarchitectures/arm2 as just one ref), so no need to have a hard time believing it, there's plenty of documentation to the fact.

 

When I was talking about the blitter socket, I was referring to the hog mode that the blitter can use, where it shares the ST bus/memory equally with the CPU (http://info-coach.fr/atari/documents/_datasheets/BLITTER.TXT), certainly the blitter can do more than just graphic operations, and as such the socket/blitter can be regarded as a (limited) coprocessor - really this is just semantics.

 

In terms of the blitter speed, well the TT didn't include a blitter as the 030 can software blit faster than the ST blitter (https://www.atari-forum.com/viewtopic.php?t=12136 check the benchmarks), additionally the Archimedes didn't have even DMA because the load/store architecture was faster than most DMA engines of the time.

 

The bus width in the ST and TT (and eg. the Amiga A1200) does determine what memory configurations the machine can have - the A1200 and TT both came with 2mb ram as the minimum, I think the next ram configuration is 8mb for both machines due to addressing issues. The ST's configurations 0.5/1/2/4 were available as a result of the 16bit bus addressing. It is slight conjecture that Atari chose the bus size in the Falcon due to memory costs, but you haven't explained any reason for making the bus 16bit (and it is well acknowledged that 32bit would have been better for eg. 030 burst mode), what would your reasoning be?

 

Generally, it's good to provide explanations, answers, and references for an opinion.

Cheers

Link to comment
Share on other sites

I will not go in discussion about most of written here. I have better things to do, more useful things. + this seems as just another case of someone overestimating his knowledge level.

Just about influence of data bus width. In case of Falcon reason to chose 16 bit instead 32 is purely to reducing manufacturing cost - motherboard in first place.

RAM size determined with bus width ?  You can have for example 128 KB RAM in TT, with 32 bit data bus. It means 4x 8-bit sections, so each 32 KB. And there are 32 KB SRAM chips with 8 bit data. Dynamic RAM of 32 Kbits - Spectrum used such. Not really good idea because high TT CPU clock.

ST 16 bit addressing - actually early plans were to use 128 KB RAM as min - so 1 16 bit bank, but with 64  Kb chips instead 256 KB ones. Later STs used 4 bit RAM chips instead 1 bit ones - so 4x less chips for same capacity.

Btw. STs can have 2.5 MB RAM too.

What determines RAM size is total capacity of used RAM chips.  And as I remember in case of Falcon it was 4 MB min - normal for late 1992. Were there plans for 1 or 2 MB earlier - most likely.  Have you heard about RAM banks ?   No, easier is to "I think". 2 banks means 2x more RAM, not 4x .

Link to comment
Share on other sites

15 hours ago, alexisread said:

I was looking at the Wikipedia page for the transputer (used in the Atari ATW), and noticed some info about an attempted games console by Inmos+Sinclair called the TV-Toy

Hi,

 

If you want to start playing with Transputers for a low price, you can check what I did with an old PC:

 

https://gtello.pagesperso-orange.fr/transputer.htm

 

For less than 100€, I have a net of three transputers.

 

Guillaume.

Link to comment
Share on other sites

I pointed on your mistakes Mr. alexisread. But if you like more to call it trolling, to not learn in life, do it . There is people who deals with Atari ST family for over 30 years, with computers generally over 35 years. Obviously you don't care for it. You don't care even for logic, to think little how RAM can be solved in some retro computer. 

This is not bothering, this was attempt to share some knowledge. But that always needs 2 sides.

Next reply in same style goes to admin. 

 

Link to comment
Share on other sites

TBH you've ignored the questions on transistor size, socketing, blitter speed, and the actual question I was posing which was 'does anyone have any TV-Toy info?

On the bus selection, I'm aware the Falcon has two ram banks, to ref the wiki talk page: https://en.wikipedia.org/wiki/Talk:Atari_Falcon#16_bit_bus

 

>>To have a 32 bit wide DATA bus for the CPU and to keep same performances using interleaving, Atari would have to provide RAM configurations of 2 or 8 MBytes. 2 is not enough, and 8, at the time the machine was done, was too expensive.

 

I think that explains the approach, I'd be interested in some sort of technical refutation rather than an appeal to authority.

Lastly, the Falcon was offered in 1mb configuration http://www.muzines.co.uk/ad/2119 unlike your unsupported claim on 4mb only.

 

I'd appreciate it if you could stick to the post topic please.

Cheers

Link to comment
Share on other sites

On 7/3/2021 at 9:17 AM, ParanoidLittleMan said:

Well, I can say only that your sources, which you linked here contain wrong info in many cases. I did not read them thoroughly, and I will not - because what saw at beginning was enough ...  For instance that mikro "falcon spec .." is pathetic

It is not "Mikro falcon spec" - if you just look at the end of document, you will see that author is Atari Corp. employee John D. Horton, member of FALCON Design Team.

 

Mikro is collecting (and preserving) different Atari related documents. So that "pathetic" document is official Atari Corp. document, not Mikros.

 

On 7/3/2021 at 9:17 AM, ParanoidLittleMan said:

(now some judge will come here and talk about how non polite I'm - well I stay behind what I say). Like about why main bus is cut to 16 bits - because 'to fit 1 MB RAM' - sorry but this is most ridiculous 'reasoning' I read in like last year.

Rodolphe Czuba gave explanation why Falcon have a 16bit data bus (because of 1/4/14MB RAM configuration...).

 

If you bother to read: http://powerphenix.com/rodolphe.czuba.free.fr/CT2/english/technic.htm

 

quote: "The basic system is a FALCON 030 equiped of a 16 MHz MOTOROLA MC68030 with a 16 bits bus.  On this system, the ram is divided in 2 banks of 16 bits, 2 MBytes each. This makes a total of 4 MBytes adressed in 32 bits only by the video chip (VIDEL).  

 

The advantage of the 2 banks is the interleaving. On the memory mapping point of view, accessing to an even WORD ($00, $04, $08, etc) is done on bank 0, accessing to an odd WORD ($02, $06, $0A, etc) is done on bank 1. So the acces to sequential linear (in lots of cases), the processor acces to bank 0, 1, 0, 1, 0, 1, 0, 1 etc...  

 

But why ?

To avoid the loss of cycle durring PRECHARGE TIME. This precrache time is the time necessary between 2 DRAM acces. So, for a 60 ns, this is 40 ns; one 16 MHz cyle is enought. The entire cycle of this RAM is 110 ns ! The F030 RAM is a 80 ns (complete cycle is 150 ns).  

 

The question is why the FALCON has a 16 bit wide data bus. Here is the most probable answer:  

To have a 32 bit wide DATA bus for the CPU and to keep same performances using interleaving, Atari would have to provide RAM configurations of 2 or 8 MBytes. 2 is not enought, and 8, at the time the machine was done, was too expensive.  

 

The 030 of the FALCON accesses in 4 (16 MHz) cycles to a bank. A cycle is 62.5 ns long. This is 4 x 62.5 = 250 ns. This could be done with 80 ns ram."

 

("bolding" is mine)

I try to start discussion on few place regarding this Rodolphe C. claim, but so far I did not get any answer (alexisread, in #8 post, quote my writing from wikipedia talk page: https://en.wikipedia.org/wiki/Talk:Atari_Falcon#16_bit_bus but I did not get any answer, I just "manage" to get into flame discussion with Marty Goldberg ? )

 

So, I am still looking for explanation why you need to have 2MB or 8MB of RAM if you want to have maximum speed with interleaving memory on 32bit data bus (and you can have 1MB or 4MB on 16bit data bus)?

 

From Atari Corp. document (that is hosted on Mikros website) we can see that Atari did plan 32bit/64bit Falcon with 2MB or 8MB of RAM... (more precise: what come to market as Atari Falcon030 was "sparrow" codename project at Atari Corp. renamed to Falcon. Original "Falcon" was never released 32bit/64bit computer described in document from Mikros website: https://mikrosk.github.io/sparrow/falcon_specification_19920826.html)

 

Link to comment
Share on other sites

On 7/3/2021 at 9:17 AM, ParanoidLittleMan said:

I never heard about that Sinclair had plans with some game console.

 

Sinclair did have plans for game console. 

 

If you look at graph that I made long time ago https://www.atari-forum.com/viewtopic.php?p=213110#p213110 (under image of "cabbage" :D) you will find two Sinclair engineer that worked on "Loki" project (game console) - Martin Brennan and John Mathieson (they eventually bring "Jaguar project" to Atari.)

 

If they were "exposed" to Inmos Transputers back in 80s, then it is no wonder that one of them, John Mathieson, went to be one of key people in Nvidia...

 

EDIT: not to forget - Commodore also worked with Inmos: http://web.archive.org/web/20050205152433/http://amiga.emugaming.com/prototypes/transputer.html (also had plans to put Transputers in Amiga...)

 

Stumble on interesting link regarding question: "Should we privatize Inmos" in UK parliament https://hansard.parliament.uk/commons/1983-07-18/debates/f335d4e2-6e18-4ab2-8f74-c85f242196f3/Inmos :) 

Edited by calimero
Link to comment
Share on other sites

All that talk about possible RAM sizes is nonsense. + RAM was cheap at the end of 1992 - 8 MB RAM would not increase price so much - and price was already very high, and reason (together with big delay) why I did not buy it then.

Then influence of interleave - it can not make that CPU accessing RAM faster than what it's clock, data bus size determines - or in other words:  32 bit data bus at same CPU clock simply allows 2x bigger RAM bandwith. And CPU clock was not high - 16 MHz only (TT 32 MHz, 2 years earlier !) . Interleave is good if RAM access time is slower than CPU's RAM access cycle time - so, again, Atari saved on RAM (used slower one) - and they presented it as some advantage.

And here we are at main problem: why so many misleading info is presented ? Answer is simple - marketing, advertising. Who cares about hard facts (what only few people can understand) - what matters is that it sound good, using big numbers (sure, let's call machine with 16 bit bus 32/64 bit ...) .

It is known that Falcon is much slower than TT - and part of it is lower CPU clock, other part is 16-bit data bus.  And there is something more: the case - why they went with keyboard computer ? Again - to save on production cost - and that limited size of motherboard too. Certainly should go on 4 layers with 32-bit data bus at that size. (or if it is 4 layers on more (I did not look about what is really used).

Of course, who will say something like:  'we saved on manufacturing costs' .

 

Considering mikro Falcon page - it used for sure some available DOCs, and most of content is just copy from them. But I saw some errors right at start, and that was enough. It is sad if those errors are present in official Atari DOCs - but not surprise - after what we could see in DOCs about STs .

 

To add some oil on fire - Atari should instead this 'bigger number is better' approach (I knew that they called Jaguar 64 bit, and now see that even Falcon prototype had 64 in name (was it for DSP ?) focus on real performances. And what I learned over decades is that SW performance is one of weak parts here.

There is even case, that official DOCs give lower performance value than real (and I tested with all possible DMA chips - starting from early STs to TT DMA chip) - all it could 2 MB/sec, while DOCs stated 1 MB/sec, or some (ProfiBuch) 10 Mbit/sec.  Problematic SW was C-compiler for 68000 by DRI - it was just bad with some data sizes, types (unsigned integers), what resulted is some flaws in FAT16 filesystem (this is what I examined, probably there are other parts of TOS affected), and worst is that it was not corrected over years.

To the end of this long talk: what I wrote here (and on my site, other threads) is not based on what I read on different places, but on my own experience, made HW and SW experiments, projects - and that includes HW designs, diverse SW - all it tested by me and users.

Here is proposal for benchmark:  make raw CPU speed test with 68030 at same clock - one with 32 bit data bus, other with 16 bit data bus - using fast enough RAM, so no wait cycles (states). Test should use larger RAM ares (to avoid cache influence - short test will result using mostly internal cache) .  I guess that 32 bit data bus performance is bigger by some 30-40% .

Link to comment
Share on other sites

@Zogging Hell Were you thinking of this plugin card for the Mega ST? https://www.old-computers.com/museum/computer.asp?st=1&c=33

It plugs into the Mega ST expansion bus - I think the cartridge port has the bus write lines disabled?

If there is a cartridge version that'd be amazing as a coprocessor for any ST :)

 

@Calimero Do you think the Loki was the transputer games console partnership? That would explain why I can't find much on the web about it.

 

Thanks for responses :) 

Link to comment
Share on other sites

20 minutes ago, alexisread said:

@Zogging Hell Were you thinking of this plugin card for the Mega ST? https://www.old-computers.com/museum/computer.asp?st=1&c=33

It plugs into the Mega ST expansion bus - I think the cartridge port has the bus write lines disabled?

If there is a cartridge version that'd be amazing as a coprocessor for any ST :)

 

@Calimero Do you think the Loki was the transputer games console partnership? That would explain why I can't find much on the web about it.

 

Thanks for responses :) 

That must be the one, it's been a while since I saw it (like 15 years or so!), and my Atari collection is in a different country at the moment so couldn't check.

 

I suppose you could wire that into a normal ST (with some difficulty), as the Megabus isn't anything special hardware wise.

 

A cartridge version would have been amazing :)

Link to comment
Share on other sites

Mega ST internal expansion bus (connector) is present only in Mega ST, and is much more than cartridge port (with enabled write) - it has practically complete CPU bus accessible, so can put there diverse expansions. Cartridge port is not only read only, but with specific ROM area access. Making something else on cartridge port needs tricky HW and SW.   I designed IDE adapter for Mega ST expansion port, and even in that case there were not all needed lines, so it needs couple wires plus. Designed EPROM programmer for cartridge port (as my first Atari ST HW add-on), and some other things.

From some reason Atari went in later machines TT and Mega STE on VME bus.

Yes, everything what can do with Mega ST expansion socket (I call it rather so) can do in ST machines too - just need to solder a lot, or use intermediate sockets - on CPU, MMU ...

Link to comment
Share on other sites

On 7/5/2021 at 10:49 AM, alexisread said:

@Calimero Do you think the Loki was the transputer games console partnership? That would explain why I can't find much on the web about it.

I would say that it is in sense that Sinclair employee mentioned in my previous post, were “fans” of transputers idea.
I can not find that Sinclair had relations with Inmos (except they are both from same country, UK. State where (before Margaret Tacher) public money went to public interest (like to Acorn and BBC)). 

 

Anyhow, Sinclair employees went to create Jaguar and later to form VM Lab where they made Nuon console with custom hardware that was really impresive in terms of video manipulation (hence one of them ended up at Nvdia as a head). Before Jaguar they created video card for Inmos transputer so yes, they do have connections with Inmos but I can not find any solid document. 

Link to comment
Share on other sites

  • 2 weeks later...

That is an astonishing render speed for the time! I can see why the architecture is like that, I still think that the main problem is that novel architectures require mindshare, and a coprocessor-style arch is a softer lead-in for the full-fat arch later.

Ie. Learn the instruction set/compiler first, then see the parallel side later.

 

I have manged to find a link about the Sinclair/ I Inmos colab, so I guess there was definitely something, but maybe not the TV-toy per-se.

 

https://www.timexsinclair.com/article/secret-stuff/

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...