Those are rare moments but sometime it happens:
My brother-in-law gave me a very simple schematic drawing (a ppt file 🙄 ) asking if i could “turn that into reality”. It should be a Arduino shield to measure vibrations created by passing trains (in German that’s a “Zug Erschütterungs Detektor”).
Well, out went trusty Eagle CAD and some interpretation fun began. Some components were described as “resistor 1-10k” others had unknown dimensions like “pushbutton bought at eBay”.
After sending some photographs back and forth I was pretty clear that everything makes sense… and after some optimizing the shield had plenty of space left. So in went a nice breadboard section with the option of placing a RTC there as well.
Then the DirtyPCB drill started again – and after 2.5 weeks the PCBs arrived and bro’-in-law happily started to assemble the “ZED 1.0”.
What should I say? It just worked. Immediately… wow. That should happen more often, or like Hannibal says “I love it when a plan comes together” 😉
It’s an open secret that the CSA mandelbrot benchmark tool (available in my ‘basic Transputer tools‘ package) is one of my favorite benchmark and test-tool when playing around with my various Transputer toys.
One fine day I thought VGA with more than 16 colo(u)rs would be nice… and the coding began. First step: Put the original source (well, already enhanced by a timer and some debugging) on github.
The original CSA Mandel program uses the official 640×480 16 color VGA mode (aka 0x12) and uses its own calls for that, i.e. no external 3rd party libs. Very manly 😉 but not very colorful…
So I created the first branch (aka Mandel_3) added a more “modern” command-line options handling and dived into hand-coding VBE (VESA BIOS Extensions) matters. That was very instructive and fun… and the first results showed that I didn’t just got 256 colors now but draw speed was increased, too 😯
Look Mom! More colors:
Running in host-mode (/t) on my P200MMX the initial screen took 6.6s vs 7.1s for 16-colors – so a difference of 0.5s or 7% should be much higher on Transputers, so I thought. And should this mean that bigger Transputer farms had been bottleneck’ed by the actual plotting of pixels?
Because 256 colors and higher resolutions (up to 1280×1024 depending on your VGA cards VESA BIOS) are fine, but even more colors are better, I branched the code a 2nd time (MANDEL_BGI) and replaced the VBE code by a BGI SVGA interface.
While originally Borland only supports VGA, there are 2 BGI drivers written by 3rd party developers which do support SVGA and up to 24-bit colors.
It’s commonly known that BGI is not the fastest graphics interface on planet earth… and the benchmark proved this:
P200MMX
Orig
VESA
SVGA
SVGA256
1
7.123
6.623
8.911
6.915
2
38.258
36.635
39.717
37.725
I was hoping the change would have more impact when running the same on my Cube system… well it didn’t:
65x T800 (integer)
Orig
VESA
SVGA
SVGA256
1
2.323
2.288
3.940
2.383
2
8.163
8.173
8.181
8.164
So as final conclusion, I will stay with the VBE SVGA drivers included in the V3.x code – it’s a good compromise between overall code/distribution size, comfort and speed.
The original VGA mode (0x12) will stay in the code forever to get comparable benchmark measurements – if you really need CGA/EGA/Hercules, you can always use the 2.x version.
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 😉
Well, we all know that especially software isn’t created for eternity. Sometimes even not for years. But sometimes dying software also means the end for your not-so-old device…
For me this became truth in 2013 when my trusty Chumby alarm clock became a very simple clock after the company ran out of money – thanks to its open design, the community was able to revive it (a bit).
But sometimes you just end up with a brick – or at least with just 25% of the functionality you had before:
In this recent letter from Revolv, they announce the end of their connected home solutions due to the change of ownership (first Nest, then Google)
Some more key-words your devices might have been built for using them:
last.fm, podcasts, Second Life, MySpace or even Altavista (All things you might have thought they last for 10+ years)
… not mentioning web browsers which are useless because of missing support for CSS, JS, HTML4+ etc.
So even before planned obsolescence of your hardware strikes, you might loose functionality by a decaying piece of software.
Do you own a piece of hardware with software-orphans in it, too?
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.
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.
As soon you’re talking about Transputers with people which weren’t there back in 1985 you’ll be asked this very soon: “How fast are these Transputer thingies”? Then there’s a stakkato of “MIPS? Whetstones? Dhrystones?” etc…
As always with benchmarks, the only valid answer is “it depends”. Concerning Transputers that’s even more true.
First, I suggest you read this Lies, Damn lies and benchmarks document from INMOS itself. It pretty much describes the dilemma and all the smoke and mirrors around that matter.
Benchmarks? It depends.
So you’ve read the above INMOS document? As you might saw, it’s full of OCCAM code. That’s the #1 prerequisite to get fast, competitive code (as long you’re not into Transputer assembler). From there it gets worse if you use a C compiler or even FORTRAN…
My little benchmark
Because it scales so well, works with integer as well as floating point CPUs and also runs on the x86 host while using at least the same graphic output routines, my personal benchmark is CSAs Mandelbrot tool (DOS only).
My slightly modified version is part of my Transputer Toolkit, which is downloadable here. You will need that version because I extended the code of this Mandelzoom with a high precision timer (TCHRT, shareware, can’t remove the splashscreen, sorry) when run with the “-a” parameter. You’ll need my provided default “MAN.DAT” file, which contains 2 coordinates to calculate (1st & 2nd run) to get comparable numbers.
So to bench your Transputer system start it with:
man -v -a
which runs it in VGA mode (640x480x16c), loads the coordinates from “MAN.DAT” and when done presents you with a summary screen like this:
To run it on your hosts x86 CPU, call it with “man -t -v -a”
The Results
Here are my results of the different Mandelzoon runs I made in the past. The blue background marks the host machine results, yellow are the integer timings and green is where the mucho macho things are happening.. well, sort of 😉
There are two columns for the results, the HD timer and the hand-timed runtimes. This is because these are from days before I enhanced the Mandelzoom.
This table will continously updated of course. e.g. the last row is pretty new – what might that system be? 😯
The sources are available in my github repository – so we can collaborate on enhancing and optimizing it.
HD in-programm Timer (s)
Hand-Timed
System
1st
2nd
1st run
2nd run
Comment
i386DX/33 (0kb L2)
1800
0
1:30:00
(canceled)
0
Canceled 1st run after a quarter of Mandelbrot was done…
i386DX/33 (0kb L2) + 387
588
3316
0:09:48
0:55:16
Am386/40 (0kb L2) + 387
490
2980
0:08:10
0:49:40
21% faster clock but only 10.5% better result
i386DX/33 (128k L2) + 387
274
1547
0:04:34
0:25:47
Am386DX/40 (128k L2) + 387
228
1292
0:03:48
0:21:32
i486DX/33 (8k L1, 0k L2)
01:06.24
368.56
Pretty close to a single T800-20
i486DX2/66 (8k L1, 128k L2)
00:33.72
185.51
Very close to 2x T800-20
Pentium 133 (256kb L2)
00:09.09
00:55.01
About 8x T800-20
Pentium 200 MMX
00:07.13
00:38.06
About 9x T800-20
AMD K6-3+/266
00:06.00
00:32.00
Downclocked, 64k L1, 256kb L2, 1M L3
Core i3-2120 3.3GHz
00:01.66
00:02.13
VirtualBox,1 CPU
1x T425-20
0:00:25
0:02:28
There’s something wrong here – needs re-run
2x T425-20
00:51.55
04:56.60
3x T425-20
00:34.42
03:17.81
4x T425-20
00:25.86
02:28.56
5x T425-20
00:20.74
01:58.96
6x T425-20
00:17.37
01:39.19
9x T425-20
11
62
0:00:11
0:01:02
13x T425-20
8
42
0:00:08
0:00:42
21x T425-20
5
27
0:00:05
0:00:27
25x T425-20
4
23
0:00:04
0:00:23
65xT425 (48x25Mhz, 16x20MHz)
00:02.323
00:08.163
Actually it was 64xT800 and one T425 forcing the calculation to integer
1x T800-20
01:09.13
06:27.18
1x T800-25
0:00:55
0:05:09
25% higher clockrate should result in 17.5% speedup. Incl comm-overhead that pretty much fits
1x T800-30
00:00.46
00:04.30
2x T800-20
00:35.65
03:13.79
3x T800-20
00:23.16
02:09.32
4x T800-20
00:17.43
01:37.04
5x T800-20
00:14.04
01:17.74
6x T800-20
00:11.82
01:04.83
5x T800-25
11
62
0:00:11
0:01:02
9x T800-20
8
40
0:00:08
0:00:40
13x T800-20
5
30
0:00:05
0:00:30
17x T800-25
00:03.8
00:18.59
“1st run” shows that the slow ISA interface is really getting a bottleneck
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 😉
The IMSB430 is a rare, yet interesting and important TRAM. It’s been meant for hardware developers to easily build and test prototypes before producing actual PCBs.
Interesting enough, next to no documentation besides a sales brochure has survived. So it’s time for reverse engineering… again. This is also an official call for help – If you by any chance know more about this TRAM, please contact me!
Here’s the left side of this size-4 TRAM. The other half is just the prototyping grid with lots of through holes which we can omit here.
I tried to number all jumpers on the board starting at the top – numbers in brackets are the jumper-numbers actually printed on the boards silk-screen. That numbering is a bit confusing and seems not to follow any logic.
IC connections
Buzzing through all lines from/to the GAL leads to this table so far:
1 ProcClkOut
20 VCC
2 A13
19 Mem0 (IC2B „/CE“ + JP26)
3 A14
18 Mem1 (IC3B „/CE“ + „J20“)
4 A15
17 1Wait (IO 2-above JP8)
5 notMemCE
16 2Wait (IO above JP8)
6 WaitSEL0 (JP8)
15 3Wait (IO below JP8)
7 WaitSEL1 (JP9)
14 SelWait (MemWait+ IO below JP9)
8 Map0 (JP10)
13 BLK0 (IO below JP10)
9 Map1 (JP11)
12 BLK1 („IO1“ below JP11)
10 GND
11 (I/OE) GNDed
Each SRAM socket is actually a “double row”.
If you seat your SRAMs aligned to the right, they will be accessed word-wide (16bit, D0-A15). When aligned to the left, they are accessed byte-wide (8bit, D0-A7). That’s why the silkscreen print says “IC2B/IC2W“…
Jumpers
This is the official press photo. It seems to show the default jumper settings (using the full 64KB SRAM, word-access):
Some jumpers are already identified (“JP” precedes the official jumpers, “J” is my numbering):
Jumper
description
1
MemWait (FIT=GalPin14, else ????)
2
DisIntRam (FIT=use internal RAM)
3
ProcSpeedSel0 (FIT=HoldToGnd T222)
4
MemReq (FIT=no request)
5
EventReq (FIT=no request)
6
MemBacc (FIT=word access)
7 (JP6)
ProcSpeedSel2 (FIT=HoldToGnd T222)
8
BootFromRom (FIT=BootFromLink)
9 (JP7)
ProcSpeedSel1 (FIT=HoldToGnd T222)
JP8
Set MemWaitstate Bit0
JP9
Set MemWaitstate Bit1
JP26
Connects /OE with /CE of IC2 (upper SRAM)
J20
Connects /OE with /CE of IC3 (lower SRAM)
The external RAM access wait-states can be set with JP8/9:
Happy new year, y’all! I hope Santa brought you some geeky stuff 😉
Here’s a quick heads-up of what’s cooking since more than 2 months… Well lots of small and bigger things happened mostly in the background in preparation for something bigger 😉
Made quite some progress with the Helios Server. That’s the ‘terminal’ software which interfaces your PC to the Helios Kernel(s) running on your Transputer(s). For now everything is checked into github. Currently I’m working on the write up of all findings and howtos.
While doing so, I learned a lot about the concepts used programming the Helios kernel. Also needs quite some documentation.
Wasted quite some time in upgrading my workhorse PC due to amnesia and eroding instincts 🙁
But now everything is working again and I can keep on working on the Tower of Powers successor. Here’s a small hint:
I had to close my little shop. It’s way too risky given german laws make it very easy for any idi** to submit a judicial warning in order to make some money just because of e.g. formal errors in your terms and conditions 😕
So if you need something Transputer’ish, drop me a mail, maybe I have some parts left I can share.
Ah, that said, I had a 2nd run of AM-B404s… need to solder pins and sockets to finalize them. And 10 are already reserved 😉
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.
