The Hema TA2 is some very special specimen of ISA interface cards. IMHO it’s the last and most sophisticated interface you can run in an ISA bus. These are the feature highlights:
16 bit ISA interface
half-size card
4 TRAM sockets
TTL and RS422 link connectors (if RS422 drivers are fitted, TTL is not usable)
B004 compatible ‘Fast Mode’ as well as 100% vanilla ‘Slow Mode’
The TA2 implements an Idea which can be found in some documents from those days, about getting the maximum speed from the sluggish ISA bus and a link-interface chip like the IMS C011/012:
Overlapping acknowledge by using FIFO buffers and a controlling FPGA.
This is how the TA2 looks like:
I’ve marked the the important parts with colors/arrows:
red arrow – the IMS C012
orange arrow – the IMS C011 connected to
blue – two 1KB FIFOs controlled by
yellow – a MACH 110 CPLD and
green arrow – a PAL
purple – a XILINX 3030 FPGA doing the control logic
cyan & magenta – TTL and RS422 link connectors
And here’s the block-schematic using the same colors:
The schematic also mentioned the two other cool features of the Hema TA2:
Four TRAM slots and the “hema LINK-Bus”, a proprietary two row DIN 41612 connector which provides all links/subsystem which were used otherwise by the 4 TRAMs.
Finally there is a 4-bit microswitch (upper right corner) to set a unique ID for the card so you can identify up to 16 cards in a single system.
Software
Using the provided control program “CTA2” everything can be set by software, e.g.
Base addresses for the fast- and slow link (0x150/0x158 by default)
Swapping fast/slow link configuration
Linkspeed for every link (fast/slow/TRAM/hema-bus)
Up- /Down-subsystem control
Interrupts per link
Waitstates
All the hardware wise ‘jumping through hoops’ still doesn’t do the job alone. To reach the ultimate ISA speed (the docs are talking about up to 1mbps) the communication needs to be tuned, too.
Lets talk a bit x86 assembler here (ahhhh), and DOS-only for sure:
It’s not enough to use simple in and out port instructions and constantly poll the C011/12 status register – that’s way too slow. You’ll need to go for the string variant(s) ins[b|w|d] combined with the rep instruction. Here’s an example for a C insb wapper function:
void insb(UINT16 port, void *buf, int count) { _ES = FP_SEG(buf); /* Buffer Segment */ _DI = FP_OFF(buf); /* Buffer Offset*/ _CX = count; /* Bytes to read*/ _DX = port;/* from Port xy */ asm REP INSB; }
Same goes for outs[b|w|d] respectively. But there’s another extra to care for: The TA2 provides special registers to give you deeper insight into its status, e.g. FiFo fill-rate (empty, half-full, full), FiFo interrupt settings.
So in effect, you couple the fast ins/outs instructions with interrupts attached to e.g. input half-full and output full.
That said, there are some caveats. ins[b|w] and outs[b|w] are supported from the i8018x and V20 on. insd and outsd needs a 386.
And then there are possible speed penalties with 32nit processors (i.e. 386 and up) as they optimized the port instructions for virtualization (Virtual 8088 mode, not todays VM!) resulting in 100+ cycles per call.
So when everything is 100% optimal, hema says in its documents these are the possible transfer speeds to reach:
Function/Array size
1K
10K
100K
1MB
Read FiFo
150kB/s
390kB/s
570kB/s
615kB/s
Read Polled
160kB/s
160kB/s
160kB/s
160kB/s
Read Direct
600kB/s
610kB/s
610kB/s
610kB/s
Write FiFo
565kB/s
600kB/s
610kB/s
610kB/s
Write Polled
160kB/s
160kB/s
160kB/s
160kB/s
Write Direct
610kB/s
610kB/s
610kB/s
610kB/s
FiFo – Using interrupts and syncing status of fill level.
Polled: Each byte is synchronized with the C012 status
Direct: Like FiFo but no syncing.
Well, this has to be proved yet. Seem I need to write a benchmark… someday 😉
This is the collection of other Transputer interfaces and cards (i.e. not from the usual suspects) I came by here and there. And no, I don’t actually own them all.
Some are rare, some are odd, may are cool and most are all three of them 😉
This post will be irregularly updated as new finds come along…
Pixar Transputer Card
Yes, that’s true. Pixar built its own Transputer interface back in the days, simply called “Render Accelerator”. Nomen es omen 😉
In constant search of raw computing power they tried out everything, eg. Intels i860 and others. It was just another logical step to try speeding-up Pixars Renderman package by using a Transputer farm. As an early adopter, they had to build their own stuff to suit their demands. Here’s a very interesting read about the long way Renderman came from and which hardware they’re were using. This article about texturing techniques is mentioning this card on pp.16.
The mentioned Jeffrey Mock was also quite busy during his Pixar days in helping Logical Systems (LSC) by writing a concurrency library for their C-Compiler.
Here’s the front of the full-size 8bit ISA card – filled up to the brim.
It features two T800-20 Transputers, each having its own 4MB of RAM. Two links are facing the outside-world – I presume it’s been meant like a up- and down-link to the next card.
The rest is standard early-days ISA bus, C012, Transputer DRAM design.
No much to say about the back side. The silkscreen is a bit uncommon, but it’s nice when it comes down to repairing… and some “burning” shows, that seemed to be the case with this specific card.
The Quintek T9
This is a very manly approach into transputing matters… don’t give me that step-by-step upgrading of an Transputer array. Just do it once and do it right 😉
Yes, that’s 9 Transputers, each with 1 or 4MB RAM and a C004 all directly soldered onto that 8-bit ISA card. It sure was expensive…
While there’s a C004 (the 6th golden IC from left), there’s no T2xx to control it. So I assume that one of the T800 is in charge to configure it… or this is done through the ISA link-interface as there are two C012 on the card,
The YARC ProTran
This is a fullsize 16-bit ISA card from YARC. It features 4 Transputers with the option of supporting them with a (for the time) big amount of RAM.
The ProTran board can be equipped with 1 to 4 Transputers. The root Transputer (the rightmost) can have acces to 1-16 megabytes of RAM – it’s 8 in this picture. Each of the other three can be configured with 1 to 8 MB. That was very serious stuff back then.
What’s most interesting about this card is that YARC didn’t gave much about standards and went a proprietary route in many places:
A proprietary bus interface is said to provide a peak I/O speed exceeding 1 MB/sec
All links, event inputs and subsystem control signals are fed to a proprietary pin-field array.
The memory design uses a multibank and interleaving technologies to achieve zero wait state performance
All this explains the excessive use of GALs in the lower half of the card. Beside the proprietary approach the ProTran offered a compatibility mode (read: B004 interface) to use standard INMOS tools.
CSA
CSA (Computer Systems Architects) was big in the educational market and produced smaller, better integrated B004 compatible Transputer cards. The higher integration of DRAM parts allowed half-length ISA cards meant for evaluation or as a starting point for building bigger systems later. (The following pictures are courtesy “the PCPUTER” page. Permission to repost them were kindly granted)
Meet the “Transputer Kit PC Card” – They came bundled with a slightly restricted version of the Transputer Toolset, together with a great manual which described lots of different programming and hardware interfacing lab-type experiments. These cards used standard multi-pin circular DIN connectors/cables to route the link and reset signals, and provided the first hands-on introduction to distributed parallel processing for many people. They included a “budget” T400A 32 bit non-floating point processor, and off-processor memory was an option
This is th PART.1 four processor board – mainly a carrier for CSAs proprietary Transputer Modules (like INMOS’ TRAMs), and the single processor PART.2 board featuring a PC interface.
The “Gerlach card”
The card from the book “Das Transputerbuch” from A. Gerlach is a typical example. It has its own post on this page.<
Very simple design but only 2 layers and completely documented in the book.
Parsytec BBK PC-2
As ususal, Parsytec did things a bit different than most others.
Their ISA interface “BBK PC-2” has two RS422 interfaces using their ‘standard’ Lemo connectors (see the the post about the x’plorer for more about these)
All Parsytec interfaces, no matter which bus-system were called BBK and having a number attached, telling you how many link interfaces were provided, e.g. the Sun SBUS card was called BBK-S4…
Like the HEMA card, this one has SRAM buffers, too. Also it looks like it’s using a 16-bit interface to the ISA bus.
Ingenieurbüro Ingo Mohnen (aka “IB Mohnen”)
This “engineering office” is pretty unknown in the already small Transputer community, even more outside Germany.
But they did very sophisticated Transputer interfaces. Actually they were the OEM for Parsytecs PCI BBK but offered other cards, too.
For example the PCI-008 series. Obviously a IMSB008 for the PCI bus. I have pictures of the V2.0:
…and V3.1:
Both versions seem to be primarily meant as OS-Link interface, while they offer space for an onboard Transputer and RAM both weren’t populated with these.
V3.1 also seem to implement the C011 into the FPGA while switching back to a PGA Transputer while having used a TQFP package in version 2.
Then there was the already mentioned BBK line of cards. Starting with the BBK-PCI light of which I don’t have a better picture than Ram does on his page (Fun fact: Also Sundance OEM’ed this card from IB Mohnen). Basically it’s a IMSB004 compatible interface for PCI. Sweet, want one!
The bigger brother is the BBK-PCI, featuring 4 full blown OS-Links and acting as PCI bus-master. Definitely the high-end of PCI link-interfaces. I do own one of these but need to make some nice photos… so in the meantime use the link to Rams page 😉
Meet The Cube – this is the Transputer Power-House successor to the Tower of Power, which was a bit of a hacked frame-case and based on somewhat non-standard TRAM carriers with a max. capacity of just 24 size-1 TRAMs…
The Cube hardware
This time I went for something slightly bigger 😎 …A clear bow towards the Parsytec GigaCube within a GigaCluster. The Cube uses genuine INMOS B012 double-hight Euro-card carriers, giving home to 16 size-1 TRAMs – Parsytec would call this a cluster and so will I.
Currently The Cube uses 4 clusters, making a perfect cube of 4x4x4 Transputers… 64 in total. Wooo-hooo, this seems to be the biggest Transputer network running on this planet (to my knowledge)
If not, there still room left for more 😯
Just to give you a quick preview, this is what ispy responds when ran against the Cube:
32 x T800@20MHz/1MB (mainly TRAMs from MSC and ARADEX)
-> 96MB of total RAM
-> 70-130 MFLOPS (single precision)
~800MIPS combined integer power
~60Amps @5V needed (That’s 300W 😯 )
So we’re talking about 70-130 MFLOPS here – depending which documentation you trust and what language (OCCAM vs. Fortran) and/or OS you’re using. That was quite a powerhouse back in 1990 (Cray XM-P class!)… and dwarfed by a simple Pentium III some years later 😉
Just for to give you an comparison with recent hardware (Linpack MFlops):
Raspberry Pi Model B+ (700 MHz)
~40 DP Mflops
Raspberry Pi 2 Model B (1000 MHz – one core)
~134 DP Mflops
Raspberry Pi 3 Model B (1200 MHz – one core)
~176 DP Mflops
Short break for contemplation about getting old…
Ok, let’s go on… you want to see it. Here it is – the front, one card/cluster pulled, 3 still in. On the left the mighty ol’ 60A power supply:
Well, this is the evaluation version in a standard case, i.e. this is meant for testing and improving. I’m planning for a somehow cooler and more stylish case for the final version (read: Blinkenlights etc.).
And here’s the IMHO more interesting view… the backside. It shows the typical INMOS cabling.
As usual, I color coded some of the cables.
The greenarrow points to the uplink to the host system to which The Cube is connected to. Red are the daisy-chained Analyse/Reset/Error (ARE) signals. The yellow so-called jumper-cables connect some of the IMSB004 links back into the boards network. And in the upper row (blue) four ‘edge-links’ of each board are connected to its neighbor.
This setup connects four 4×4 matrices (using my C004 dummies as discussed here) into a big 4×16 matrix. Finally I will ‘wrap’ that matrix into a torus. Yeah, there might be more clever topologies, but for now I’m fine with this.
Building up power
For completeness, here’s a quick look at how things came together.
The 4 carriers/clusters with lots of size-1 TRAMs… upper right one is the C004-dummy test board (now also fully populated). Upper left is pure AM-B404 love <3
Fixing/replacing the broken power-supply (in the back), including the somewhat difficult search for a working cooling solution:
The Cube software
Well there isn’t any specific software needed to run The Cube, but it definitely cries out loud for some heavily multi-threaded stuff.
So the first thing has definitely to be a Mandelbrot zoom. As usual, I used my very own version with a high-precision timer, available in my Transputer Toolkit.
Here’s the quick run in real-time – you can still figure out visually each Transputer delivering its result:
So this is running fine – using internal RAM only. On the other hand, it seems that the current power supply has some issues with, well, the electric current.
When booting Helios onto all 64/65 Transputers which uses all of the external RAM, very soon some of them do crash or go into a constant reboot-loop.
By just reducing the network definition (i.e. not pulling any Transputers) to 48, Helios boots and runs rock-solid.
Because measuring the voltage during a 64-T boot shows a solid 5.08V on all TRAM-slots it most likely means the power supply either can’t deliver the needed amount of Amps (~60) or produces noise etc. 😥
So this is the next construction site I have to tackle.
This is yet another i860 accelerator card – this time from good ol’ blighty: The Myriad DASH!860 (I’ll call it the Dash from here on) was made by Myriad Solutions Ltd. from Cambridge.
Here’s the copyright in detail:
What I’ve got is actually a double “sandwich” card, i.e.
The actual Dash card is one 16bit ISA card featuring the i860 CPU at 25MHz and its RAM consisting of 8 SIMM banks, which is connected to
the second ISA card is piggybacked onto the DASH!860 and is actually a graphics card using an INMOS G300 graphics controller and giving room for a maximum of 4MB VRAM – this one is called the “ShadeMASTER”
Mhh, this setup very much reminds me of the SPEA Fire, which uses the same core parts but thanks to its higher SMD integration manages to squeeze everything onto one ISA board.
Hardware
But let’s start in the good old GeekDot tradition having a closer look at each of the cards.
The Myriad DASH!860
Here’s the left side of the Dash:
Having seen the other i860 accelerator cards, this isn’t that much different: The 64bit wide memory interface of the i860 is fed by 8 SIMM slots, each containing 1MB of RAM.
SMD parts prove that this card is a more modern design…
…while looking at the right side of the Dash shows, that its design is somewhat between the worlds:
Lots of DIL PALs has been used. Also the huge array of 8bit latches and buffers would have probably been replaced by 16bit versions later in time.
The most interesting fact in my eyes is the choice of the CPU… why did they pick the 25MHz model? The quality check on the back says 1993! In that time, 40MHz models where broadly available – maybe this was a cost reduced version of the Dash? Some sources on the web mention a 40MHz version at least.
The long pin-rows on the top- and bottom-edge as well as vertically next to the rightmost SIMM slot are the data/address lines exported to the sandwiched graphics card, called…
The ShadeMASTER
Let’s start with the left side of this card:
Most prominent are the 16 VRAM memory ICs in ZIP package. They’re 1Mbit, so we’re looking at a whopping 2MB here.
Looking closer you’ll spot there’s room for another 16 ZIP ICs and more buffers – so the video memory can be upgraded to 4MB fairly easy (adding some more flipflops, too).
The connectors to the Dash card can be identified quite good here, too.
On the right side of the ShadeMASTER there are a lot of PALs again – like with the DASH!860. The golden IC is an INMOS G300 graphics controller and the smaller black PLCC chip is an INMOS G176 CLUT. This one has a 6bit DAC which -theoretically- limits the ShadeMASTER to a max. of 262,144 colors (18bit). With its 2MB it could display 1024×786@16bit, or 1280×1024@8bit. With 4MB that resolution would even possible at 24bit true color…
The two transparent thingies in the top-right corner are relays to switch the video signal, i.e. there are two video (VGA) connectors at the cards edge. One 9pin input for looping in the PCs VGA signal and a 15pin output which is normally looped-through.
No signals are used on the 8bit ISA slot connector. It’s just for fixing the card in place and power-supply.
Software
While the DASH!860 seemed to be sold separately as a “general purpose application accelerator” the combination of both cards was mainly targeted at the medical 3D data visualization market.
My cards came from the Bio-Rad ThruView PLUS package which included the Dash/ShadeMASTER combo with the ThruView software.
I have a copy of the software but it’s copy-protected by a dongle, so I won’t pursue it any further (for now ;-)).
See the next chapter handling that software.
The OS – meet XNIX
What’s more important, and IMHO the most exciting fact about the Dash is the OS they run on it:
They called it XNIX. Yeah, that sounds very UNIXish, doesn’t it. A quick inspection of the kernal file shows its a i860 COFF binary and sports many POSIX calls… I was instantly hooked 😯 .
This is the parameter screen of the loader called “x.exe“:
Obviously, there are different modes to run it, depending the mode DOS is running in. As you can see, “/e” forces the enhanced-mode, while “/r” does the same with real-mode.
So either
A) you boot your DOS into real-mode by un-commenting the device = emm386.sys
line. But leave himem.sys in there. (This will provide XMS RAM access, which is needed by XNIX)
or
B) Try running “X.EXE” with the “/r” switch.
It still might not work, as I found this line in the binary-code:
“A DASH!860 E or J card is required for ‘real mode’ operation” – most likely a Revision Code.
The most interesting and useful switch is “/d” to get the 2 pages of debug output:
This gives you some crucial information:
General resources of your PC
Your DASH!860 capabilities
The I/O port used (0x160)
The shared memory area (0xD0000, 64KB up to 0xEFFFF)
Kernal size and location
In [standard] mode, I get this screen afterwards:
That’s a bit puzzling, as it seems to not using XMS RAM.
Also, this shows an evil behavior: “X.EXE” will wipe your “\tmp” and “\usr\tmp” folder… unasked. Yikes! 👿
For now, I have no clear idea, how to load an i860 binary to XNIX. In another paper I found these lines: “The i860 runs a Unix like operating system called Xnix. This is a Terminate and Stay Resident utility which allows many standard Unix applications to be executed on the i860 whilst the PC is running MSDOS. Xnix sleeps until a Unix development tool or the i860 requires servicing whereupon it wakes up and performs the required service.”
This hints towards a library to be compiled into a DOS executable, which calls XNIX kernel services.
I will have to disassemble some of the ThruView binaries and see, if thera are some calls in there which might support that theory (See the ShadeMASTER chapter below).
Config file
XNIX has a central config file. Having a look into it, it shows this:
[real] kernel=C:\TVPLUS\kernel stub=C:\TVPLUS\rstub.exe startup=C:\TVPLUS\startup.rmx translate={txt;doc} bus= end
The called binaries are 66% clear yet:
kernel is XNIX itself – ~200KB in size
startup.rmx is the bootstrap code for the real and standard mode.
stub (a DOS executable) – not totally sure. An included (compiled) BAT file calls this after “x.exe”, using the ThruView x86 binaries as parameters. Maybe a loader of XNIX/COFF binaries ?
But going through the kernel binary’s strings, there’s much more to configure:
Possible sections:
[enhanced]
[standard]
[real]
Pretty clear, aren’t they? DOS enhanced/real-mode setting and a section valid for both. Then there are plenty keys to fiddle around with:
387faults=
A20lock= global
Break=
HZ= %ld
SMA= %lx (NOTE: Shared Memory Address. Use '/s' for an output)
SysRq=
^C=
addressing=
bus=
cache= compaq (From the code: "The option 'cache=compaq' has been superseded by the supplied driver. Use the option: 'cache=c:\usr\860\lib\compaq.drv'")
checksum=
comms=
dashsize= /* Memorysize of the DASH!860*/
debug=
diskcache=
dma= %d
environ=
exe860=
extended=
fixA20=
floppy=
himem= /* how much XMS RAM to be used by XNIX */
hirestimer=
ioaddr=
kernel= %s
membot=
meminstalled=
memtop=
real=
reloadkernel=
shadow=
startaddr= %x
startup=
stderr=
stub=
tmpdir=
translate=
video=
watchdog=
window=
xargs= %c
Not an elegant way using absolute paths and hiding trivial calls in an .EXE file, but getting over it, this helps to understand the start process in further investigations.
The ShadeMASTER card uses a config-file itself, the provided one is called “mode” and contains:
[mode false800x600] true_colour=false This is the Kosher one for 35kHz scan rate line_length=1138 hresolution=800 vresolution=1200 hsync=142 vsync=4 hbackporch=120 <-This parameter may require tweaking for centralising vbackporch=40 the image on some monitors transfer_delay=18 clock=5 mem_init=1006 short_display=76 broad_pulse=130 sync_to_VGA=true set_G300_sync=true eight_not_six=true overlay_mode=0 overlay_mask=0xff palette=1 pixel_mask=0xff line_start=0 top_of_screen=0 interrupt=false vga_palette=false shadow=false delay=0x600
Many of these keys are very common with most INMOS G3xx devices e.g. the IMS B020.
With the DASH!860/ShadeMASTER combo came the software package “ThruView” (this is the sales brochure).
Sadly -and usual in those days- it’s protected by one of those nasty dongle keys plugged into the PCs parallel port. If you were into computers in the 80s/90s you surely remember them, most likely full of hate:
They were flaky sometimes, didn’t reliably work with the printer looped through them and there was a 50% chance they refrain from working when upgrading your PC.
Running ThruView
Anyhow, starting ThruView, it greets you with a friendly
Ok. Thanks for that ma’am. Here we are. 25 years later and the last dongle for it probably went the way of the Dodo.
But you wouldn’t be at “the home of real mens hardware” when you wouldn’t do, what a man has to do in this case…
Out went the Disassemblers. I recommend IDA Pro for comfortable work on your recent Windoze workstation and SoftICE to work on the bare metal itself.
Ahh, finally, cracking time again. Missed that during the last years…
Half a day later, Thru-View greets me with this:
Yay. One hurdle taken… here’s the next one: You have to open an image file. In the ubiquitous PICtor format. doh! (So I thought…)
Ok, somewhere I was able to get some sample .PIC files… select that and open the damn thing, click OK and…
…followed by…
As far as I can see, XNIX is loaded correctly. For now I have the suspicion that there are communication issues with the DASH!860 due to my PC workhorse is a ‘modern’ Pentium 1 MMX… and we all know how lazy programmers were back in the days when it came to delay-loops etc..
Ok, on my 486-PC I was able to successfully load the XNIX kernel in real-mode (‘x.exe /r’) and using the debug-flag I saw some errors about config-files not found in C:\TVPLUS… wtf? All paths are set in the .cfg file but it seems some are just ignored and hard-coded.
Ok, so I created that folder and copied everything over and called ‘rstub ___tv1’ again… and this time it worked!
So let’s open that PIC file… it reads and reads and:
Ohhhh-kayyyy. So my assumption that ‘.pic’ meant a PICtor file was wrong. Some intense Google’ing later I’ve learned that the file format is the “Biorad PIC“. I could have guessed that before. Those times were the times of proprietary formats. How to get such a file to play around with it?
Luckily others had the same problem. ImageJ seems to be the main tool for converting scientific visual data, and it has a native support for reading Biorad PICs. But how to create one?
Well, thanks to this tool, you can create it when creating .raw files before using ImageJ. A bit cumbersome – but hey at least something.
…another day later…
Alrighty – that brought me a bit further: As far I can see, ThruView is working! My self-built file was successfully loaded and I was able to play with all modules. Here’s a slideshow, showing the available modules (loader, builder, animator):
While my file loads fine, I wasn’t able to get a picture on the ShadeMASTER VGA output yet. I can hear the relay switching the outputs and my LCD display catches the signal correctly (dimensions as well as refreshes) but it’s just black.
Here’s another “finally!”: Loading my Z-Stack PIC file takes 4.7MB of the DASH’s RAM… changing back from the builder into the loader module I got this error message:
This is a ‘special moment’ for me, as this is the first time that the available RAM of one of my i860 cards was actually filled with meaningful data.
But rest assure: As soon the couple works as supposed the hardware tweaking will begin 😉
The usual source provides the full manual/documentation… down to the GAL equations.
All these enhancements enabled the B008 to create simple, yet powerful Transputer networks on a single expansion card and still makes it the perfect platform for todays Transputer retro experiments/fiddlings.
Here’s a late “Rev.F” version of the IMSB008:
The previous revision E had a ceramic version of the T2xx and used GALs instead of the CPLD you can stop in aboves picture.
Clones
Obviously the Inmos B008 had clones as the B004 did.
Transtech TMB08
Well, I guess there’s nothing which Transtech did not clone and/or improve…
In this case they used a AMD MACH CPLD from the beginning, a PLCC version of the T225 and everything else was SMD.
Alta SuperLink/XL Transputer PC Card
Alta Technology was a spin-off of Computer System Architects (CSA).
The SuperLink/XL board used TRAM modules like the Inmos B008, but featured a 20 MHz IMST225 Transputer to handle external interfacing and a beefed-up host interface design. Like the B008 it supported 10 TRAM’s
ARADEX
One of my first TRAMs was an ARADEX one, so this is a first for me, too. Actually I wasn’t aware that ARADEX also made TRAM carriers… but they seem to do quite some:
TransAT Plus
Their interpretation of the B008 theme features just 8 TRAM slots (vs. the 10 “standard”) which are strangely enough sorted in ascending order (0-7) and not like the B008 order of 1, 5, 6, 2, 0, 4, 7, 3, 8, 9. Also the TransAT provides two 9pin D-subminiature connectors in contrast to the B008s 37pin connector – most likely its layout is the so called Aalener Link-Interface. That includes the RS-422 differential drivers and receivers next to the connector (AM26LS23’s and AM26LS33’s).
Concerning other parts, besides an C012 they used some sort of CPLD – presumably to control the 16 bit bus – in the photos I have, I can clearly see the traces coming form the ISA Bus’ D[8-15].
It also uses the IRQs 10-12.
Last fun bit: They named the two GALs with their JED filenames. Very handy 😉
TransAT-8
The “8” in its name makes it a valid member of this collection – but it misses an C004 and also has just 8 TRAM slots… so maybe it should be considered somewhere between an IMSB004 and B008?
This time TIs 74ALS192/193 differential drivers are used, the PLCC chip is yet unknown… and in this case, a TTL chip (next to the ISA slot) is missing… all in all, it looks like a refresh of the TransAT Plus to me.
I even have a piccy of the back-side. Why the heck is somebody putting a GAL there?
Well, because I’ve been asked every now and then… I’ll briefly touch the “Post-Transputer era” of Parsytec and thier PPC products in this Post.
No, I don’t own any of those, and they only run/ran Parsytecs very own PARIX OS, so I’m not of much help when it comes to revive your system. As often said, I don’t like to see Transputers being degraded to communication processors. So this is just for completeness and might help to identify your brand new dumpster-dive finding:
The missing link: PowerTRAM 601
These are the only Parsytec products which truly and directly bridge ‘old-world tech’ (i.e. INMOS) with ‘new-world tech’.
The PowerTRAM – available from 1994 to ca. 1996 – was a size-4 TRAM featuring an 80MHz 601 PowerPC which is memory-mapped into a 25Mhz T425 memory.
The Front has all the glamour. In the lower left corner you can spot the T425 in a QFP package, above it is a MACH FPGA most likely containing the glue logic.
The remaining space is used by the mighty PPC601 hidden under a huge heat-sink and a fan (the 80MHz version was the fastest 601 fabricated using a 0.6 µm CMOS process and ran quite hot) as well as two PS/2 SIMM slots for its RAM.
[Pictures courtesy by J. Snowdon]
The rightmost third of backside is populated with 1MB of RAM for the Transputer and the classic logic to connect it (mainly latches).
The left two thirds are used up by quite some transceivers. Namely six ABT1852 18-bit bus transceivers (the square ones) which most likely connect the Transputer and PPC busses as well as covert the latter 3.6V level to the the T425 5 volts.
The “other x’plorer”
Well, yes, there was another x’plorer in existence. As with the GC-system, Parsytec later offered the “PowerXplorer”- you may guessed it already: It used the cluster from the PPC601 powered GC systems.
Interestingly enough there seem to be 2 versions in existence. At least the German computer magazine c’t reported in May 1994 that there’s a 2 CPU and a 4 CPU PowerXplorer… and featured the two below images as a proof.
Maybe the 2-CPU model was a beta-model or even using early PPC604’s? At least it features SIMM sockets vs. the soldered RAM used in the 4 CPU version.
If you’re really-really interested in that model, here’s a big (Click to zoom) picture of the PPC cluster board. I’ve marked the important parts for easier finding.
TPM-MPC
The TPM-MPC (Transputer Processing Module – Multi Processing Card) is basically a single CPU version of the PowerXplorer. So one T425 is handling the link communications and, depending on the revision, a 100, 133 or 200MHz 604e PPC is doing the number-crunching.
This is a Revision 1 TMP, far left in red frame you can spot a T800 Transputer with its RAM – in the green frame is the PPC604 and soldered 16MB of EDO RAM:
A somewhat different version (can’t spot a Rev making) providing 32MB RAM to a 100MHz PPC604 and having the glue-logic between the 2 CPUs shuffled around a bit compared to the previous version:
The Rev.2 model features SIMM sockets for the EDO RAM and has a slightly different layout.
The Transputer part on this one is a T425 (who needs a FPU for just doing data-shifting?!) with 1MB RAM, framed in red between the 2 SIMM sockets, marked with blue arrows:
The PPC side (heatsink removed) including some drivers and the 3.3V supply.
Independent of the revision, TPMs went into a TPM-Box. A simple, steel box with a power-supply, two fans and a backplane for 4 TPMs. This is it from the front (grille removed):
…and the even less impressive back.
As some ePay auctions mention “taken from RVSI 5700 SYSTEM” I assume the main usage for TPMs were optical analysis/inspection systems which Parsytec built when turning their backs to super-computing.
[The T2shield is currently a work-in-progress project – the first alpha hardware is operating but lots of coding lies ahead!!]
The idea for the T2shield was born when I thought about getting recent peripherals like SD-cards, Ethernet, displays etc. into a Transputer network.
Sure, there are the old, original TRAMs like the STM228 SCSI controller, the B431 Ethernet TRAM or quite some choice of graphics controllers. But they’re all rare like chicken teeth these days which means unaffordable when they rarely pop up on ePay.
Rebuilding them is also a no-no given the obsolete parts they’ve used… and to be honest: A noisy, vintage SCSI-1 drive isn’t what I thought of.
So after some time I came to the conclusion it will be the easiest and cheapest way to re-use what you can buy for a few bucks from China these days: Arduino shields.
As a lucky incident such a shield perfectly fits onto a size-2 TRAM – Yay!
Without much further ado, here is the T2shield (v0.1) with a shield loosely put on top to get an idea…
Arduino shields mainly use the SPI bus for data transfer. With its 10+Mbps SPI is much faster than e.g. I²C (which I used for my T2I2C TRAM) and can cope with fast(er) peripherals.
But this also ruled out a slow IMSC011/12 link-adapter design like the one used on the T2I2C. Also there’s no of-the-shelve SPI master controller to simply glue a bus to it.
So the design turned out much more advanced this time:
A 16bit Transputer (with 64KB SRAM) handles the high OS-link speeds as well as the ‘glue’ like File/Ethernet handling.
A comparably big CPLD (100pins, 128 marcocells) implements the SPI master controller as well as handles the T2xx memory- and interrupt-handling.
All Arduino digital-pins and nearly all analog-pins are connected to the CPLD to adjust to any available shield.
Also this new TRAM design is a “first” for me in many aspects:
1st usage of a 16-bit T2xx Transputer (vs. 32bit)
1st serious utilization of a CPLD (besides the baby-steps taken with the T2A2)
1st Size-2 TRAM
Initial status
Transputer
[wppb progress =100 option=green] 100% done
A T222 Transputer is -after fixing some stupid errors- happily running and has control over his external RAM.
Here’s the first sign of life by RSPY (a brilliant ispy‘ish tool of Michael I really need to write a post about soon):
That means: A T2xx @ 20mbps linkspeed is connected to the host (PC) and has 4K internal and 56K external RAM… wait a second! just 56K? Yes, that’s because the internal 4K overlaps and RSPY leaves the up-most 4K untouched as most peripherals are mapped there and poking there could create unwanted effects…
CPLD
[wppb progress =10 option=yellow] 10% done
All basic Transputer controls are in place, LEDs are controlled by the CPLD
TODO: Implement the SPI master in VHDL. That’s THE biggest challenge for me being a total VHDL noob. Again, I wouldn’t got this far already without the tremendous help from Michael Brüstle, my VHDL Jedi-Master.
Drivers
[wppb progress =100 option=red] 0% done
Write the (Helios) driver to handle file and/or network access. This should be (optimistically) be compatible to existing file- or Ethernet ‘servers’. This will probably be the most time consuming task.
Progress?
This is (also) the first time I’m posting about a project which is not finished. So I will keep you posted about the progress with new posts in this “T2shield” chapter of this wonderful little page.
If you do own
a Transputer network
a free size-2 TRAM slot
a T2xx Transputer
some VHDL/Occam/Helios driver skills & knowledge
shoot me a mail and I might provide you a T2shield to join the development.
That said, here’s a first little sign of life:
The Transputer writes numbers to a mem-mapped address (0xFC00) while the CPLD reads the lowest 2 bits and displays them by 2 of the 3 LEDs on the T2shield
While the guys over at OpenApple were speculating in their latest podcastwhat a Transputer actually is… well, there are about a 100 links and ways on this page to find out – but hey… just click here – and of course that box saying search would do great wonders, too.
But seriously, my bad: I should have mentioned that this page your looking at is really just one post of many… so make sure you start at a Chapter (Menu. At the Top. ↑…yes up there) and read them in the order you’d read a book 😉
After quite some years (and a handful Apple II users requests) I felt the urge to finally put the T2A2 prototype (read that post to get a more general understanding) into a real expansion card… and here it is: Say “Hello!” to the T2A2 version 1.1!
It came a long way…
…in more detail:
As you can see, the final T2A2 is much smaller than the prototype (which used an 8bit Baby one-for-all PCB) and offers many additional features
2 size-1 TRAM slots (or one size-2) – double the processing power!
Low-power, low-profile parts used where possible (3.3V CPLD, HCT logic)
External Transputer-link available as edge connector – extend your network to “near infinitum“
Jumpers for LinkSpeed and optional power to the Transputer-link connector
Fully buffered to be a good Apple II bus citizen
Works in any slot set to “your card”
Beyond this, everything said about the prototype is still true.
Most important:
a) It’s not tested in the ][ or ][+. I simply don’t own one of those. Update: One owner reported it’s perfectly working in his IIe!
b) The T2A2 won’t instantly speed up any of your Apple II[e/gs] applications.
It’s more like a co-processor attached to it. And even then, you’ll need something really calculation-intensive to justify the time you’ll loose due to communication between the Apple and the Transputer. A single square-root for example wouldn’t make much sense – but having a complex algorithm (like the Mandelbrot fractal in my demo) does absolutely make sense, as you just pass the parameters to the Transputer and let him do the sweating.
But on the other hand, FPU cards like the Innovative Systems FPE (using an M68881) or my even faster clone “NumberCruncher Reloaded” did just send instruction by instruction. So I somehow fancy the idea writing a SANE driver for GS/OS to integrate the T2A2 more transparently.
Want your own T2A2?
So now you’re keen to get one yourself? Please check this list first:
Do you have a TRAM already? (*)
You are aware that there’s no real software (yet) besides my little Mandelbrot demo?
You are keen to program something yourself – or are fine to wait until somebody else did?
While the Apple II side of coding is pretty easy, you have to get a grip about the Transputer development, too. That includes a DOS/Windows (<=XP) setup and some knowledge of C and/or OCCAM. I’ve created a little Transputer “SDK”, namely a VirtualBox image running DOS.
Ok, so you’re still with me… so I have the first batch of 20 T2A2 PCBs ready which I will populate on-demand, and for 40€ (plus shipping) one of them can be yours. (*) I might be able to offer you a TRAM, too. The price depends on available model, RAM size and CPU used.
⇒ drop me a mail to (Sorry, you have to type that into your mail-client – nobody likes SPAM, so do I)
Also check the T2A2 forum for current availability, shipping procedure and built status.
Some more technical details
Here’s a T2A2 with a size-1 TRAM installed in Slot-0:
The T2A2’s CPLD programming can be updated any time through a JTAG port (the lower 2×5 pin-row at the edge).
The jumper above it can be used to set the linkspeed for the TRAMs (10 or 20mbps). If you look very close, there’s a tiny LED next to that jumper. It’s the error LED controlled by the CPLD.
The next single jumper enables the VCC pins on the external Link connector, meant for (small!) external extensions. This connector is the same used on the Gerlach card and is very convenient because of its ubiquitous standard 2×5 shrouded pcb header connector. Here’s the pinout:
As said, the V1.1 T2A2 offers two size-1 TRAM slots. Before plugging in 40MIPS of raw processing power consider the amount of juice being pulled there. Depending on the amount of RAM and load a single TRAM can use up to 800mA of power! 😯
Given the max. of 4A on a standard IIgs power-supply, two TRAMs could bring your souped-up GS into trouble… it’s better to use the external connector with just one smaller TRAM or even simply bridge the Link0In/Out pins with Link3In/Out so that the T2A2 works as a TRAM-less adapter.
That said, there are size-2 TRAMs in existence which will snugly fit and won’t hurt that much.
This is a Q’n’D but handy design which I was planning for a long time, but you know how things go… A differential adapter is a simple device which translates a single signal/data line in one positive and one negative line, i.e. one is carrying the inverted signal of the other. This is also known as RS422… But why do we need such thing?
Well, differential signals are/were quite common in the world of Transputing to deliver OS-link signals over longer distances (<10m/30ft) or noisy environments and good examples are systems from Parsytec, the AVM-T1, ISA interfaces like the HEMA TA2 or even some custom measure/data-logging solutions.
So to connect to such systems using a non-RS422 (i.e TTL) interface card, e.g. the INMOS B004/008 or the Gerlach-Card you’ll need such an differential adapter.
Technical data
A very simple design on a 5x5cm PCB. All done in trough-hole technology (THT) to keep this a simple DIY project.
It all based around two AM26LS32 receivers and one AM26LS31 transceiver, some resistors and an unavoidable LED 😉
Usage is very simple, too. Just connect the TTL signals to the standard 2×5 shrouded PCB header connector and RS422 signals are provided on the 2×7 header connector on the opposite side of the PCB.
The TTL connector is the same as the one used on the Gerlach card or my T2A2 Apple II interface:
As you can see, pins 9 & 10 can provide 5V to the PCB so that no external power-supply is needed.
If you connect a system not able to provide power to the differential adapter there’s also a 2pin connector provided on the PCB itself.
The RS422-side of the adapter has this pin-layout:
Nice-to-know: You could also use this adapter to simply invert signals. For example if you need a positive ERR signal instead of the not’ed, you simply take the positive pin (i.e. even pin-number 6 in this case) of the 2×7 connector (ignoring the negative).
Mind there’s no power supply pin on that side and pins 11/12 are not connected.
home of real men's hardware
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
