Tag Archives: Transputer

Handling TRAMS

General caveats

TRAM pins are thinner than normal PCB-Pins e.g. those you may know from Arduino shields and thus they are, well, quite fragile. That’s a problem (by design) with all TRAMs. So be very careful when handling TRAMs, i.e. removing/plugging them from/into your TRAM carrier e.g. a IMS B008.

And you can’t repeat this enough: Ground yourself! Electrostatic discharge will kill your TRAM as well as any other electronic device.

How do I do it? My main and single tool for handling TRAMs is this pair of straight tweezers:

Pliers

This works quite well for carefully removing TRAMs from its socket by putting it between TRAM and socket like this and gently lever the TRAM – not too much! Else you will bent the pins on the other side – repeat on the other side. Done.

The Transputer

If you got you TRAM without a Transputer plugged in, you might figure that it’s quite difficult to plug in the CPU. My suggestion:

Put the back of the TRAM (the socket pins only – refrain from putting any force onto the TRAM pins) on a medium-soft item, e.g. a block of wood or like I usually do it, onto the rim of a sticky-tape roll, and press the CPU using even force into the socket with your thumb.
Double check that all CPU pins are straight and are sliding into the socket holes without force and fiddling. Also, mind the CPU orientation!
Again, never push the Transputer into its socket without support underneath the socket, your TRAM will bend and traces might break rendering it useless. At minimum the TRAM-pins will be damaged.

CPUpress

It’s worse when you’re in need of removing the CPU. Sometimes the ceramic packaging is extremely brittle and the CPU pins do sit very tight in the socket.

Again, use a straight tweezer, gently pushed between the socket and the CPU and carefully lever the CPU for a millimeter max.

CPUlever2

Repeat on all four sides of the CPU…

CPUlever1

The AM-B404

Here it is, my latest baby, the goal I was aiming for since years (4 to be exact) – not only to get more TRAMs for my systems but also to break the insane price spiral developing in the last years on ePay and other places. >300$ for a TRAM is crazy. Do not pay that amount! Even $100 is too much.

Update: Final version finished! Click here or scroll down for more.
Update 2: You can buy one, if you like…

AMB404-Front-small

My first CPU TRAM called AM-B404 in reminiscence to the IMS-B404 which comes closest to its specs:

  • Size-1 TRAM
  • 2MB low-power SRAM
  • 2 LEDs showing the Transputers status (running and error)

Well, the original Inmos B404 had 2MB DRAM, too (and additional 32k SRAM) but was a Size-2 TRAM and LEDs weren’t available on any Inmos TRAM… and we all know how important LEDs are! 😉 Contrary to the IMS-B404, the AM-B404 is low-profile, SRAM-only, so the whole RAM is accessed at 3-cycles vs. the IMS-B404 4-cycle DRAM.
Using a 6-layer PCB and all-modern SMD parts (well, as modern as 5V parts can get) the power consumption is a bit lower, too. I’d say about 100mA for the whole Board (no Transputer of course). Finally, there’s an easy access solder-bridge on the backside to set the CPU clock (20/25MHz).

AMB404-Back-small

This is just the 1st prototype. After thorough testing, I will optimize its layout a tiny bit and give it the proper shape of a TRAM. When that’s done, we’ll see how I can make you a realistic price offer.

UPDATE:

From Shenzen with love. The final PCB designes arrived and the first test went perfectly fine.

AM-B404stack

And here are the first 4 PCBs waiting to be finished with the Trough-Hole parts (i.e. Transputer Socket and TRAM Pins)… 100 solder-points in total… per TRAM. That’s quite a bit to solder :-/

First4

Video

Finally, here’s a short video showing the prototype AM-B404 in action (running Helios on my Inmos B020). The “exciting” thing is the blinking green LED which shows the CPUs activity. There’s even some brief red LED access (error) during boot-up which is triggered by Helios scanning the Transputer network.
The bright blue LED to the left is the T2i2c TRAM, so all TRAMs on the B020 are built by me now 😉

Want one?

If you hate the greedy ePay prices like I do, drop me a mail. I might have some AM-B404 left… even with T425/T800 Transputers.

Can I have the schematics?

No, not yet. Sorry. I have to break-even on this first…
Since people discovered there’s serious money in the retro-scene, some ‘smart guys’ started to clone every PCB they can get their hands on and thereby steal the initial investment which the original creators made.

I sell them a bit over the price they cost me to produce. And trust me, you won’t be able to go lower than me:
It’s a 6 layer PCB. ENIG Gold.
Sadly SRAM did not get cheaper, really. Especially the (obsolete) 5V 512kx8 I’m using were lately discovered by other projects to be very convenient and so the battle for SRAM was on. If you’re lucky you might get one for 4€… and you need 4 of them.
The 16 pins used to connect the TRAM to its carrier are very special. You have to buy them by the 1000s – 0.15€ a pop… you do the math.

Hati

This is the 2nd phase following “Sköll”. Hati is the other wolf who chases the moon – less mystic, this means getting the “Helios-Sköll” sources to compile on Linux – still targeting Transputers, though.

Some tools already do compile, e.g. the Transputer Crosscompiler ‘nc’ (i.e Norcroft-C) but most others are still missing.

Status:

There’s a hati branch in the GitHub repository. I suggest to leave it branched until at least the hostutils are compiling fine.
NB: Because I really badly hacked the nc files to get them to compile I did not include the changes to the branch. If you’re getting to this part of the code, I’m happy to tell/send you what I did, but I assume there are people out there doing a better job than I did 😉

This branch only includes ‘makeinc/makelinux’ and ‘makeinc/LINUX.mak’ and a new makefile here and there.
For now calling ‘. makeinc/makelinux hostutil’ will get stuck in building ‘cmds/com/sysbuild.c’ because of some include-path mish-mash – that’s where we have to start working.

Rough todo:

  • Create a proper Makefile. e.g. LINUX.mak currently has a lame workaround to point to GCCs include path
  • Probably many optimisations for recent GCC and gMake versions ahead!

Sköll

This is the first and ongoing phase (as of Mar. 2014). While the main purpose of Sköll is to generally get the original source to compile on Solaris (v8) it also has several sub-tasks:

Compile
100%
Clean-up code
5%
Smooth edges
1%

Compile the original source

Several makefiles needed some adjustments to work with gcc (instead of suns own cc), also some tricky formatting f*ck ups needed to be corrected – (gnu)make is much more picky about this than whatever make they used back then.

Strip unnecessary parts

It’s not identified which parts are completely unnecessary, but the TI DSP code is something which can definitely go.
Other points might need to be discussed, e.g. what should happen to some very special servers (i.e. Terminalserver in Helios lingo) like SUN3 or ACORN R140?

Smoothing the edges

There are multiple strange code-constructs which should be cleaned – they lead back to buggy and awkward MSDOS compilers which needed some workarounds

Here are some examples:

The code is full of #define eq == defines. I was told that was a workaround for the “==” vs “=” issue in conditional expressions. Modern compilers warn you when a condition looks like an assignment, the Microsoft compiler they were using at the time didn’t.. Doh!

Then there’s #define elif(x) else if(x). WTF!? Well, this roots from BCPL, the ancestor of C. Most of the core-devs at Perihelion studied at Cambridge University where BCPL was invented and was used well into the 1980s. In addition to the standard if() and while() constructs, it also had unless() and until() statements, as well as elif().
To them used to these constructs, the code was more readable and boy, they do get used throughout the Helios sources way too much.

 

The Plan

Welcome fellow reader of ‘el Reg’... you might have come here due to this The Register post from Dec. 6th 2021… thanks for the free ad chaps!

Yeah, it is a somewhat dusty project but that might be due to the fact that I’m working on this alone. Since years. On and off… more off than on honestly. Because there’s no fun in soliloquies.
But I will be happy to chime in again as soon I see active forks on github

So have fun browsing this time-killing page… 150+ posts are waiting to make you wonder where the time went 😉

There’s a rough schedule where this project should go, given there are enough clever people joining in or at least display a certain degree of interest. So there’s a skech of the main-phases, aka “The Plan”  (without dates):

Sköll

As said in the intro, Sköll is about “catching” the sun, i.e. get the original Helios 1.31 sources to compile on Solaris. This includes

  • cleaning up the code
  • weed out unneccesary parts (e.g. the TI DSP code)
  • smooth the edges (There are multiple strange code-constructs which should be cleaned)
  • get a general understanding of it all

Hati

Next phase/release/step after that will be “Hati”, the other wolf who chases the moon – less mystic, this means getting the “Helios-Sköll” sources to compile on Linux.
Some tools already do, e.g. the Transputer Assembler ‘as’… the Norcroft-C compiler is another story.

And as we all know, when Sköll and Hati finally managed to hunt down the sun and the moon, the world will be destroyed and reborn:

Ragnarök!

It’s certainly not the end of the world. I leave it open for now what that means in terms of Helios, but maybe there will be a critical mass of participants in the community to push “Helios-Hati” forward into version 1.4 running on x86 or current ARM implementations like Raspberry Pi and the like?

Secondary theater of War

Well, then there’s another part of Helios which needs some attention: The server.
This is the piece of software handling the communication between the Host (e.g. your DOS Box) and the connected Helios System (e.g. your Transputer(farm)).
There are several Server sources in the [HeliosRoot/]ioproc/server folder like DOS, Windows, RS6000, HP9000, Interactive UNIX, Sun3/4/i386, SCO etc… obviously all supporting very old versions of their OSes, e.g. Windows 3.x or Solaris 2.

So this part will need some love, too. I will mainly concentrate on DOS (that’s the [HeliosRoot/]ioproc/server/ibm folder), because that’s what I use to talk to Helios.
To support more recent ways of communication than ISA/SBUS/VME-cards, we have to create a new server, for example for Mikes USB-Link Interface.

Troubleshooting

This post is constantly growing, it’s mainly for me remembering not making some fu**ups again… but it might be useful for you, too 😉

Debugging the server

Booting Helios with server.exe you can provide a couple of debugging switches to see what’s going on:

  • A – All. Either enable all debugging, or disable any debugging which is currently active.
  • B – Boot. Give a progress report while the root processor is being booted.
  • C – Communications. Monitor transmissions to and from serial lines and similar devices.
  • D – Delete. List all files and directories being deleted.
  • E – Errors. Report any error messages generated by the I/O server.
  • F – File I/O. Give details of miscellaneous file I/O activities such as renaming files.
  • G – Graphics. Report any graphics transactions.
  • H – Raw disc. List sector reads and writes on a raw disc device.
  • I – Initialisation. Give a progress report as the I/O server initialises its various component servers.
  • J – Directory. Show details of any directory accesses.
  • K – Keyboard. Report any key presses.
  • L – Logger. Cycle the error logging destination between screen-only, file-only, and both screen and file.
  • M – Message. Report all messages sent to and from the I/O server.
  • N – Names. Show the names of objects Helios is trying to access.
  • O – Open. List all files that Helios is trying to open.
  • P – Close. Report any file close requests sent by Helios.
  • Q – Quit. Give a progress report when the I/O server tries to exit.
  • R – Read. Monitor any file reads.
  • S – Search. Report all distributed searches arriving at the I/O server.
  • T – Timeouts. Report any stream timeouts that may occur.
  • U – Nopop. In the Server windows system, toggle between pop and nopop mode.
  • V – OpenReply. Give details of replies to Open, Create, and Locate requests.
  • W – Write. Monitor any file writes.
  • X – Resources. Produce a snap shot of what the I/O server is currently doing.
  • Y – List. Give details of all debugging options.
  • Z – Reconfigure. Re-read the configuration file host.con

Those switches can be combined, e.g. server -rw

Cool: If the debug-output becomes too much to read (i.e. on screen) you can toggle the setting by pressing ctrl-shift plus the corresponding character. E.g. “c” to mute all the traffic on the serial line.

Logging

Now that we get some info about what’s going on internally, it might be a bit too much to follow on the screen (and you can’t redirect the output with “server > output.txt”). But don’t despair, there’s a way to define a logfile in HOST.CON:

logging_destination = [screen | file | both]
logfile = logbook

So simply define where you want the logging to go (screen or file or both) and define a logfile name. In this case it will be written inlogbook in the Helios root directory.
Please mind that the logfile will be overwritten (not appended) each time you reboot!

Config-Files

I cannot repeat it often enough: ALL config files (but HOST.CON) are Unix-Formatted, ie. LF instead of LF+CR. So each time something is behaving strange, check your config files for proper formatting!
I’ve spent hours of debugging just to find out I had (again) “tainted” a config file by quickly having a look with edit.exe :-/

Running X Window

This is probably the pinacle of what you can do with Helios… literally, as there are probably just a handfull of people left having the needed hardware.

HELIOSX

This is because the Helios X Window System only features drivers for two “graphic cards”: The INMOS IMSB020 ISA card or the IMSB419 (or similiar) TRAM. Both sporting the INMOS G3xx framebuffer chip.

Low-level stuff

The G3xx controls the displaying device in a very low-level manner – back in those days these devices were classic cathode ray monitors and high refresh intervals guaranteed a stable, non-flickering picture (>70Hz up to 100Hz an more). Today a TFT/LCD display is the common display and those are quite picky about the refresh interval being fed into them (60-70Hz).

It might be difficult to find a TFT display which is able to “catch” the G3xx signal. But thanks (again) to Michael Brüstle, there’s a super-great tool to calculate the correct values needed to configure the G3xx to match your display… or get close to it.
You’ll need certain values for your display later in this chapter, here’s a list of them – actually that’s my setting:

screen_width = 1024
screen_height = 768
video_clock = 65 #MHz
line_time = 336
half_sync = 17
back_porch = 40
v_sync = 12
v_blank = 52
v_pre_equalise = 6
v_post_equalise = 6
transfer_delay = 21

Also, a mouse is very much needed to use X Window (surprise!). So make sure your host OS (e.g. DOS) is actually running a driver for that – I recomment CuteMouse, very small, very complete.

Because it is essential that the X server runs on the same TRAM the framebuffer/graphic controller is located. This has some influence on how to configure the system.

Using an IMSB020 aka “BOZO”

Without any TRAM installed on your BOZO, make sure to run single_user! (check /etc/nsrc)

If you’re planning to run in multiuser mode the onboard CPU must not be the root processor!
So change the links using the on-board “Linkswitch” like this:

c:\>debug.exe
o 16C 3 (i.e. set bit 0 and 1 on port 0x16C)
q

This makes the TRAM in slot 0 root processor running the network server (/00) and the onboard T805 becomes /01

Files to edit

Edit “startx” in the Helios root directory. In line 22 it reads:

  remote -d 00 run xhelios

change this to

  run -d xhelios

Now read on at “General Setup”

Using a “remote” display TRAM (like IMSB419/437/438)

Like the comment in the startx file says “If you have a multi-transputer network you must make sure that the X server is started on the processor that has the grahpics hardware.”

Files to edit

Edit “startx” in the Helios root directory. In line 22 it reads:

  remote -d 00 run xhelios

modify this to match your TRAM setup, eg. if your IMSB419 is connected to link 3 of your current (working) Transputer, it should read

  remote -d 03 run xhelios

General Setup

Check your host.con file. Around line 41 you’ll find this section:

Xsupport
mouse_resolution = 2
mouse_divisor = 2

Make sure Xsupport is uncommented. The mouse settings seemed to be fine with all my tests – you milage may vary, so play around if needed.

Copy the file
newxrc from /local/xsrc/devices to /etc
and
twmrc and/or “mwmrc” from the root folder to your home (/users/root)

Now edit newxrc to match your display values as described in the beginning of this chapter. Also check the display hardware entry in line 293 (newg332.d).
If you’re using a IMSB020, you can enable native keyboard support in line 301.
Below that are keyboard layouts (US/GB/D) and number of mouse buttons. I’m not really sure if the “processor” and “progname” values are really used – I think they’re ignored.

Feel free to edit twmrc if you like more applications to start automatically etc.

Finally, if you are running a TCP/IP network stack (i.e. tcpip and inetd are sucessfully running) you don’t have to do anything further.
If you don’t run TCP/IP you have to append “notcp” in your startx line 22, eg:

run -d xhelios notcp

You’re Done. Now start X11 calling startx from the root directory.

Going Multiuser

Yup, Helios is a Multitasking-Multiuser OS… but not quite as you might got used to it using UNIX(ish) OSes in recent times. There are some caveats:

Theory

As Helios is running on Transputers (mostly) and Transputers do not feature an MMU, there’s no ‘protected’ multitasking, i.e. a badly written application can kill (at least) the Transputer it is running on, if not the whole network. This might bring back memories of Apples System 7.x “Multi Finder” or Windoze 95 and other cooperative multitaskting solutions.
The only half-way robust way to really protect Helios processes is to ‘lock them away’ into a dedicated Transputer.

Running Multiuser (ie. providing remote login etc.) means you need at least 2 Transputers. To protect certain essential services like ‘netserver’ and ‘sessionmanager’ those have to run on the “root Transputer” (/00) which is not accessible to any user – including root. Logging in from the console on your PC will automatically put you onto the next Transputer in-line, eg. /01.
In consequence, if you like to have another user logging in over ‘telnet’ or serial console you’ll need another Transputer for that user (making it 3 in total).

Practice

So what do we need to configure to go Multiuser? First you should have your Transputer network configured and running as described 2 posts before this.
Then we check the nsrc file found in Helios’ /etc folder. Because I couldn’t say it better, I’ll copy from the Manual:
The nsrc file contains a list of options for the networking software, like the host.con
file which has a list of options for the I/O server. The nsrc file is read by the startns
program when networking software is started up, and passed in the environment to
the network server and/or Session Manager.”
(Just a refresher: network, networking and server means Transputer networks, no TCP/IP stuff and such.)

It should look somehow like this:

# root_processor = /Bozo/01
# single_user
# password_checking
# processor_protection
# no_taskforce_manager
share_root_processor
preload_netagent
waitfor_network
# 30 seconds is the default interval, -1 disables network monitoring
#monitor_interval = 10

I won’t go into every detail of each setting – there’s a Manual for that (p.58). Just make sure that ‘single_user’ is commented. For the curious amongst you: share_root_processor means the taskforce-manager, network-server and session-manager may run on the same CPU. If Helios runs in Multiuser mode like we are going to do, this is ignored anyway.

That’s it. If everything worked as described, Helios will boot all processors (but showing only /01 and /02) and logging in locally on your host machine will put you on Transputer /01. Users logging in via telnet will automatically put onto Transputer /02. This is a ps output entered in a telnet session:

% ps /00 /01 /02
Processor 00
ProcMan.0           Loader.1            netserv.4
Pipe.5              session.7           login.9
Processor 01
ProcMan.0           Loader.1            tcpip.3
inetd.4             Pipe.6              tfm.27
shell.28            telnetd.31          ttyserv.32
login.33
Processor 02
ProcMan.0           Loader.1            tfm.3
Pipe.4              shell.5             ps.7

The (inaccessible) Root-Transputer /00 is running the netserver and session-manager.
Processor /01 does the TCP/IP, inetd and telnetd handling, runs a shell (local login), cares for tty and runs a taskforce-manager (needed for parallel programs).
Finally processor /02 is the one the telnet-user actually lives and triggered the ps command from its shell.

So after all this configuring we have multiple Transputers running, TCP/IP is there and we can host multiple users (given we have enough Transputers to host them)… next and final step: X-Window!

3rd party TRAMs

Well, INMOS wasn’t the only company manufacturing TRAMs. This is a -more or less random- collection of TRAMs I was able to find in the WWW.

Because some TRAMs are of unknown origin, I’ll sort them by size…

Size-1 TRAMs

This is my 2nd smallest TRAM by RAM size. 128KB SRAM. The silk-print says “TRAM-1-B” on the front and “TRAM-1-L” on the back. I guess they’re made in Germany as it’s usual to mark the front with B (“Bauteilseite”, component-side) and L (“Lötseite”, solder-side).

TRAM1_32k

This seems to be a very early design, featureing a 16-bit T212 and some original INMOS SRAMs

Unknown_T212A_Module

This is my “standard 1MB” TRAM. It’s labeled “ARADEX T805S“. It seems that the German ARADEX AG, originally manufacturer of cardbox packaging machines built their own TRAMs for their systems. It’s pretty highly integrated. Some but not all of them feature an ALTERA EMP5016 PLD which hold extra logic for the additionally fitted subsystem pins..

ARADEX_T805S_1M_1

Transtech was a quite big manufacturer of all-things-Transputer. They had a big range of TRAMs in their catalogue. Pictured below are the TTM-1 (32KB SRAM), TTM-3 (1MB DRAM) and its successor TTM-7(1MB DRAM).

Transtech_TTM1

Transtech_TTM3

Transtech_TTM7

Here’s another image of which I think it’s an TTM7:

UnknownT1_1MB

The final TRAMs of Transtech were the TTM15(e) and TTM19(f), both using the SMD package of the T800 as well as the rest of the ICs.

The TTM15E uses some interesting “Enhanced DRAM” from Enhanced Memory Systems Inc.. These include 2K SRAM in each 4Mbit DRAM chip, which increases the access speed to 12ns.
Very neat, very hard to get-by today. Restoration impossible. Mind all the jumpers on the backside – obviously a lot is configurable here.

TTM15E

The TTM19F uses what looks like modern (S)DRAM – need to evaluate that more…

TTM19F

This is a special one: Two Transputers but no RAM. It’s labeled Alcor 2T. Very nice if you need lot’s of CPU-power and can live with the 4K RAM inside the Transputer.

Alcor_2T_no_memory

Sundance was another manufacturer concentrating on the Transputer business. They made lots of TRAMs, this SMT213 is comparable to the Alcor 2T but features two T805 Transputers in SMD as well as 1 or 4MB DRAM per Transputer (on the back) and was built in 1993 which is near the end of the Transputer era. With 4MB I’d consider this to be the “Rolls-Royce of the TRAMs”. Yummy!

Sundance SMT213

The SMT222 is an EPROM boot TRAM. You can see the socket for a 64-512KB EEPROM, inside the socket is a C011 to provide the DS-Links to the Transputer network.

Sundance SMT222

This is the SMT220, Consisting of a Z80 compatible micro controller (Z80180), a 32KByte SRAM data buffer, 512bytes of firmware and two C011 Link adapters, this TRAM is what I call an “RS232/485 interface overkill” – but I guess some industrial use required that.

Sundance_SMT220

 

Another TRAM, using seldom used AAA4M204 SOJ DRAMs (4x1Mbit). The label says “Douglas Engineering TTM 15A/7A” (Not sure about the last number given the blurred picture I found).
This one is interesting  in so far, that it is more or less a standard SIMM-on-a-TRAM. This would make a worthwhile retro-project to recycle all those 30-pin SIMMs sleeping in our drawers 😉

DouglasEng_TTM15a_front

DouglasEng_TTM15a_back

MSC (“Microcomputers Systems Components GmbH”) another pretty much unknown Transputer device manufacturer from Germany also made a SIMM-style TRAM and called it the B1T8-4M/A1.
As with the TTM15E, some settings can be configured by jumpers on the backside.

MSC-B1T8-4M_1A

Size-2 TRAMs

Next up, the STM228, a SCSI TRAM… something you want to get the most performance out of Helios or file-through-output in general.

Sundance SMT228 SCSI TRAM

The SMT229 would be the other TRAM you want for a professional system. This is the most modern ethernet controller available.

Sundance SMT229 Ethernet TRAM

The Transtech TTM-6 is a comparably boring 2MB computing TRAM. It’s an older design, like the IMS B404.

Transtech TTM6

This seems to be some sort of I/O TRAM… lots of 74FCT buffers and a T225. It’s called FMX D1032.

FMXD1032

This is an interesting one: A TRAM of unknown origin using SIPPs – as memory(-expansion)!

Very cool, as you could expand its RAM up to 64MB given all addresslines are used. Downside is that this TRAM is building pretty high…

TRAM_mit_SIMM_F

and the back:

TRAM_mit_SIMM_B

Size-4 TRAMs

We’re now coming to the “Big Guns”. Starting with TTM11, another SCSI interface. It’s older than the nice SMT229, so it only has a 16-bit T222 and some old SCSI controller (my guess it’s a WD93xx chip).

Transtech TTM11

This is the Sundance SMT214, a “large memory TRAM”. It was available with 16, 24, 32 or 64MB DRAM including a T805 at 25MHz. This should be sufficient for every Transputer application… as long as nobody ports Windoze to Transputers 😉

Sundance SMT214

The SMT219 was the commercialized version of the HARP1 project, called HARP2 then. It’s a T425 Transputer connected to an FPGA which could be programmed for any task you needed to get done… a C64 emulator for example 😉

Sundance SMT219

This is where it starts getting funny. Because Inmos was struggling with the next Transputer generation, other CPU manufacturers presented new quite fast  competitors, like the PowerPC from Motorola. This Transtech TTM610 featured not only a T805/25 but also a 200MHz PPC603 or 604 with 16 or 32MB of RAM.

TTM610 PowerPC TRAM

Parsytec thought the same and presented the ‘PowerTRAM’, an 80MHz PPC601 on a TRAM. Well, and there’s a T425/25, too.
If you like to know more, the Parsytec PPC systems have their own post over here.

Size-6 TRAMs

This is an graphics TRAM from “Division Ltd.” probably called DBT020/01. It features a T425 with its own 1 or 4MB RAM and 2 Toshiba TC8512 “Gouraud shading processors”, some VRAM and most likely an Inmos IMS Gxxx graphics controller.

DBT020 - unknown graphic TRAM

Size-8 TRAMs

This huge beast is a TTM220 with 16 or 32 MByte DRAM coupled to both an Intel i860XP  processor, and a T805 transputer. There was a bit smaller (size-6) version called TTM110, too.
All in all it provided the same features like the DSM860 cards (well, despite the 32bit Transputer).

TTM110 TTM220 i860 TRAM

(To be continued)

HTRAMs

As the T9000 had so many new features and architectural differences the “classic” TRAM wasn’t enough to support all that. So INMOS went to enhance the TRAM-model…

And they meant it! Instead of DIL 16 Pins of a “classic” TRAM, HTRAMs could use up to 160(!) pins to communicate to the outside world. Besides the classic 5V, also 3.3V was supplied on one pin as a tribute to the technical progress. Due to the introduction of the DS-Links (vs. OS-Links within the T4xx familiy), each of the four links of the T9000 now required 4 pins per link, resulting in 16 pins for the links alone. Plus many other special links for Events, ConfigUp/Down etc. a minimum of 60 pins were used.
Also each HTRAM now featured a PROM so it could be identified by software.

This is the pinout of an HTRAM extracted from the most recent source (SGS-Thomson B92x HTRAM datasheet, Nov. ’94)

HTRAM

Pin Row a Row b Row c Row d Row g Row h
1
2
3
4
5
ClkIn
L0SIn
L0DIn
L0DOut
L0SOut
N/C
GND
N/C
V3V3
N/C
TDI
V5V0
CupSIn
GND
CUpDIn
notTRST
L2SOut
L2DOut
L2DIn
L2SIn
EventIn0
EventIn1
EventIn2
EventIn3
EventOut0
EventOut1
EventOut2
EventOut3
9
10
11
12
13
L1SIn
L1DIn
L1DOut
L1SOut
Reset
N/C
V5V0
N/C
GND
TMS
CUpDOut
GND
CUpSOut
V3V3
TCK
L3SOut
L3DOut
L3DIn
L3SIn
V5V0
1
2
3
4
5
N/C
N/C
N/C
N/C
N/C
TDO
GND
CDnSOut
V3V3
CDnDOut
9
10
11
12
13
N/C
N/C
N/C
N/C
N/C
CDnDIn
V5V0
CDnSIn
GND
N/C

While many (i.e. 100) pins left unspecified in this pinout-map (e.g. Block 2 rows c & d, Block 3 rows e & f and the complete Block 4), they’re all used on the HTRAMs I own.
My guess is that those were used for the memory-bus, at least in the case of my Quintek board.

Here’s an original INMOS HTRAM, with a 15MHz T9000 engineering sample mounted, plus a T9000 (backside) next to it:

HTRAMandT9k

For a quickstart here are the 3 HTRAMs from Quintek which I own:

QT9A

The QT9A (Rev.C in this case) is a processor HTRAM of (yet) unknown clock-speed and memory-size – I think it’s 4MB. Because the T9000 ran really hot in the prototype stage (which he never left), all of them required a compariby big heat-sink. I do not dare to remove it, given the (collector) value.

QT9A_front

…and the backside for completeness 😉

QT9A_back

QT9H

This is a display HTRAM featureing a Bt485 RAMDAC, 2MB VRAM but no video-output part. The video signal is delivered to a pin-row which is going connected to a VGA-featurebus on a graphics card. It’s a Rev.C part, like the QT9A.

This and the following HTRAM were fitted into Slots 5 and 5 on the HTRAM-board which are quite special slots: They don’t offer the pin-blocks 1 & 2, i.e. no DS-Links etc.! That said they do feature fully populated pin-blocks 3 & 4 which underlines my assumption that those pins are meant for direct memory-mapping.
In the case of a Video & Encoding HTRAM this makes totally sense because it gives the Transputer even faster access to the Video-RAM than pumping all the data over the Links.
Which leaves yet-another-riddle-to-be-solved: Where are those HTRAM mapped into the T9000s memory?

QT9H_front

…quite a lot is happening on the back-side, too:

QT9H_back

QT9C

A video digitizing HTRAM using the BrookTree/Conexant Bt812 chip and having 2MB VRAM, too… this time “Rev.B”.

QT9C_front

and the back side…

QT9C_back

To be continued…