T2C= Meine Transputer Karte "reloaded"

So, nach fast 13 Jahren war es an der Zeit... meine gefrickelte C64 Transputer-Karte musste mal "in Schön" gemacht werden.

Und wie das so ist, wenn man schon mal dabei ist, dann könnte man doch noch dies und das... und vielleicht auch noch hier ein wenig...

Herausgekommen ist die T2C= quasi "Eine für (fast) Alle".
Als (meines Wissens) erste 'Flipper Karte' für 8-bit Commies kann sie sowohl am C64, C128 als auch an der C264 Familie (C116, C16, plus/4) betrieben werden.
Einfach um 180° drehen und schwupp hat der Plus/4 bis zu 15 MIPS am port hängen 💪

Den kompletten Yadda-Yadda könnt Ihr bei Interesse hier nachlesen: https://www.geekdot.com/t2c/

PeterSieg: Solltest Du mal an eine Neuauflage Deines Buches denken, wäre das die Chance das Foto der hässlichen T2C64 auf S.139 zu ersetzen

Ich pack' das hier nochmal dazu (auch wenn's auf der Webseite steht): Es gibt noch keine sinnvolle (?) Software dazu. Nur kleine Demos und Tool-Schnipsel. Die Genialität kommt mit Deiner Arbeit Dein Commodore wird keinen Fitz schneller durch die Karte. Erst wenn man code für den Transputer geschrieben hat und dieser mit dem Commodore daten austauscht, wird es schnell... ein Beispiel ist hier das Mandelbrot Fraktal, das der Transputer berechnet und der C64 (nur noch) darstellt. Denkbar wäre auch Kompression oder wilder Mathe-Kram. Weiterhin ist zu beachten, daß so ein TRAM auch ganz gut Strom ziehen kann. Mein C64, C128 und Plus/4 kommen alle mit dem Standard Netzteil klar. Aber da steckt auch nur ein TRAM mit 128KB drauf. "Your milage may vary"

Zitat von nalkem

UIUIUIIIII

Wie bekommt ein unwissender an so ner Karte .... ?

So -> https://www.geekdot.com/t2c/#getting_one

(Aber neben der Karte brauchst Du halt auch noch ein TRAM zum "draufbappen" - bekommt man auch bei mir, kost' aber extra

Zitat von PeterSieg

Jetzt noch im Arduino Mega Formfaktor zum "draufbappen" => 3D Steckbar und Arduino "kompatibel".

Und/Oder mit PiHat für Raspberry Pi.

Nu ja - irgendwie ist das T2C= ja ein Gegenentwurf zum gefühlt 57. "Pi-Slap-on"... der Transputer ist zumindest "Zeitgemäß" und das wäre damals(tm) genau so möglich gewesen... wenn auch irre teuer (T414 lag bei 1500DM!)

Aber es ist ja nicht so, daß Vatti da nicht was in der Schublade hätte
Ein Size-2 TRAM für Arduino shields 🤪: https://www.geekdot.com/t2shield/ - würde auch auf's T2C= passen... absurder geht's fast nicht.

Zitat von Shadow-aSc

ich bin ja immer begeistert über Neuentwicklungen ..aber gerade hier seh ich das etwas skeptisch ...da wirds wohl auch in Zukunft relativ wenig Software dafür geben, die diese Karte auch nutzen kann ..mehr als n Mandelbrot wird schwierig

Absolut - das habe ich ja auch so beschrieben. Wir sind hier in einer Nische einer Nische.
Das ist kein Chamäleon, Ultimate-II+ oder so was praktisches. Hier geht's eher um Esoterik und Spaß am Exzentrischen.

Wobei man hier schon ein paar Dinge machen könnte:

• Bild Konvertierung (z.B. FLI's)
• Spiele, die Brainpower benötigen (Schach, Go, Schnick-Schnack-Schnuck )
• Hardcore Mathe-Gedöns (Raytracing, Fraktale)
• Mitteldolles Mathe-Gedöns (Eine "Mathe-Lib" die man vom C= aus befragt: "Gib ma' COS(7)" oder "Was'n LOG(42)?")

Zitat von detlef

Noch eine technisch Frage, weil ich von Transputern keine Ahnung habe: Da ist jetzt auf dem Foto ein Modul mit einem Transputer-Chip bestückt. Braucht man zum Parallelisieren dann zwei Module oder sind in dem einen Chip schon mehrere Kerne enthalten?

Ha! Er hat Kerne gesagt! Erstaunlich, aber wahr... der erste kommerzielle Multicore kam ~2001 mit dem IBM Power4 raus.

Aber im Ernst: Sehr gute Frage. Und die Antwort ist "Jein"

Die "Transputer Hochsprache" OCCAM sieht zwei Haupt-Konstrukte vor: PAR(allel) und SEQ(uentiell).
Wenn ich meinen Code also entsprechend strukturiere, dann wird dieser auf einem Transputer "quasi parallel" ausgeführt (Threaded).
Wenn ich mehr als einen Transputer habe und diesen für den Code freigebe (das "routing" kann man definieren), dann verteilt sich das über das Netzwerk.

Hier ein Beispiel. 2 "Prozesse" laufen parallel und holen sich über zwei "Channels" daten (a&b, x&y), tun etwas damit und geben das Ergebnis über einen weiteren Channel aus. Obacht! OCCAM arbeitet mit Einrückung wie Python! (War also auch schon alles mal da ;-))
Der Witz an der Sache ist, daß ein Channel bei nur einem Transputer eben virtuell (lokal) ist, bei Mehreren dann aber über einen physischen link geroutet wird und somit "echt parallel" ist.

PAR
  SEQ
    EKanal1 ? a
    EKanal2 ? b
    c := a * b
    AKanal1 ! c
  SEQ
    EKanal3 ? x
    EKanal4 ? y
    z := x + y
    AKanal2 ! z

Für die weniger Mutigen gibt es einen ähnlichen Konstrukt natürlich auch in "Parallel-C", Fortran, Pascal.... und irgendwo hab ich auch mal Ada gesehen

Nachteil(e):

Ein Transputer hat keine MMU. Prozesse können sich also gegenseitig killen, wenn der/die Programmierer/in nicht sauber gecoded hat.

Absolute Speichersicherheit ist also nur mit mehreren Transputern gegeben... ein Thread, eine CPU.

Bricht ein Transputer im Netz weg, muss sich dieses von selbst "heilen", das liegt in der Hand des allmächtigen Coders hier einen Watchdog o.Ä. am Start zu haben.

Zitat von geekdot

Wobei man hier schon ein paar Dinge machen könnte:

• ....

Das Allerwichtigste habe ich natürlich vergessen... MINIX!

IPCA : Parallel : Transputer : Software : OSes : Minix : Inmos

Allerdings muss da erstmal eine treue Seele einen iServer(*) für die Commies schreiben.

[Grillen zirpen...]

Also ich. Jaja, ich bin dran.

*) ein iServer ist/war das upload- und shell-tool von INMOS. Das übernimmt dann auch die Kommunikation zwischen Transputer(-netz) und Host.
Ist also etwas komplexer als stumpf ein binary hochzupumpen.

Zitat von stefan307

Wäre es evtl. "sinnvoller" einen Transputer als FPGA nachzubilden? Anstatt das in Software via Arduino Raspi oder was auch immer zu machen...

Einen Transputer in Software macht hier sowieso keiner (ja,es gibt einen Emulator, der braucht aber auch ordentlich Dampf).
Mein "Arduino shield TRAM" ist/war dazu gedacht - nomen est omen - Arduino shields für Transputer nutzbar zu machen. Also z.B. sd-card reader, ethernet etc... leider hat sich auch hier noch nicht die Zeit gefunden, einen sauberen SPI master in VHDL/Verilog zu gießen.

Einen Transputer in FPGAs zu packen erfordert zunächst mal einen Kern. Im Gegensatz zu den gängigen CPUs (68k, 650x, z80, x86 etc.) gibt's da aber nix von der Stange. Aber so viel sei gesagt, man arbeitet daran und ist auch schon recht weit gediehen...

Ich bin aber der Geist der vergangenen Weihnacht und beschäftige mich bewusst nicht mit "alten Kernen in neuen Schläuchen".

Zitat von e2k

Ich dachte, dass sich paar Leute mal daran gemacht haben, die Transputer im FPGA nachzubauen, aber alles stoppte vor paar Jahren.

Kennst Du noch Projekte, die gepflegt werden?

Yup. Die Entwicklung zweier VHDL Kerne läuft schon seit Jahren langsam aber stetig .

Einer (der von Claus) hat nun zumindest vorsichtig die Nase ins Licht gestreckt und kann auf einer handverlesenen Platform ausprobiert werden.

Wir Transputer-Onkels sind aber alle so alt, nerdig und verschroben, daß wir uns in newsgroups austauschen

Guckst Du also z.B. hier:
Performance: https://groups.google.com/g/co…n47f0xuvtE/m/Xs7xWGlnAAAJ
Online Testen: https://groups.google.com/g/co….transputer/c/bXNn7Wt9aM8

TLDR;
"The Digilent Genesys2 board provides a fast Kintex FPGA in which the design can run at 160MHz without over-clocking and up to 200MHz with over-clocking the FPGA. The DDR3 RAM on the board is accessed by a the MIG core and I placed a first and a second level cache between the CPU and the memory core.

I started with the lower cost Arty board which has a DDR3L and offers less performance than the Genesys2 board.

My design can run on a CMOD A7 too, at 90MHz and 512MB five cycle external SRAM. Thus the Transputer might be nice alternative if one refuses to work with a RISC-V

I had a lot of fun with this project over the last two years. I was greatly supported by Gavin who shared his C-code implementation of the FPU with me. Many thanks to Mike and Uwe for their support. They both know the Transputer much better than I do and have collected all material available."

Die Dokumente, die funkenzupfer verlinkt hat, stammen von Uwe Mielke, der an einem sehr exakten T8xx Kern arbeitet.