Category Archives: Hardware

The DSM-860 Series

June 4, 2009 Axel 2 Comments

Based on a public project from Rolf-Dieter Klein and Tobias Thiel (“PC-Karte mit i860”) in the German computer magazine “mc” (2/90 to 7/90), the Munich based company DSM built several i860 boards for the PC/AT which they called the DSM-860 series.
All DSM-860 have one thing in common: They offer a high level of hardware features – no costs were feared. So naturally, those cards were not cheap. But you really got something for your money. All versions featured

4 Transputerlinks for networking multiple cards
Connection to the hosts system-bus (ISA/EISA) via dual-ported RAM
A 16-bit bus is also available via dual-ported RAM on special connectors giving a throughput speed of 8MByte/s for high-speed connections between several SPC boards.
RAM was put on an extra RAM board making the complete SPC-860 a double-card sandwich

DSM-860

The 1st incarnation was the SPC-860, very quickly renamed to DSM-860, an 8-bit ISA card with 4MB RAM (DIL) and 4 10mbps Transputerlinks via four C012’s (polled by the i860 resulting in 740kbps linkspeed).

Here’s a picture from a 1992 ad, with separate RAM card attached:

It did cost 16450 DM including the (GNU) C compiler and assembler.

DSM-860/16

Next, they released the DSM-860/16 (renaming the DSM-860 into DSM-860/8) being a full fledged 16-bit ISA card. It has a real Transputer (16bit T222, having its own 32K SRAM) for handling the “multiprocessor communication” and is able to support up to 256MB on a sandwiched daughter-board, now using SIMM modules instead of DIL parts.
The Hitachi HD63310 dual-ported RAM, used in the 8-bit version to communicate with the host was replaced by faster Cypress IDT7130 types (“because of the high speed of the 16-bit ISA interface” ;-)), resulting in a peak-rate of 14MByte/s.

Here’s the schematic of the card and its components

This is how it looks in reality… my DSM-860/16:

As you can see, the card is not exceptionally high integrated – even built 1992 there is not a single SMD part used, everything is socketed, only some PALs could be called “custom parts”. But this does not necessarily mean it’s badly designed or build.
If you have a close look (click the picture for a bigger version), you’ll see that every part/socket/jumper on the board is nicely specified in the silk-screen printing. All GALs and the EPROM contents are available in the documentation… which has 426 pages by the way.

Here’s the left side in more detail:

This end of the card is the “external comms” side. Beside the all-mighty i860 you can easily spot the golden Transputer being the communication controller.
To its left, there’s the first dual-ported RAM (1k x 8) connected to the socket for the external bus (Ring-A, located on the edge above). Below that are the two 16k SRAMs -marked MHS- for the Transputer. Then to the right are the two dual-ported RAMs (a 7C131 and a so-called slave 7C141) making the 16-bit connection to the i860’s bus. The rest of the parts are quartz oscillators (5MHz & 40MHz) and drivers/buffers for the buses. On the top edge next to the Ring-connectors you can spot the 4 Transputer links (JP9-12).

The right side is comparably boring:

The boot EPROM, 6 GALs, again two dual-ported RAMs (this time for the ISA-bus connection) and some buffers… well, and 5 LEDs. LEDs are good. 😉
Also, you can see the pin-row connectors at the lower edge and on the left of the photo. That’s the expansion-bus. The lower connector is more or less 1:1 the ISA bus, the left one is a 16-bit bus to the i860. AFAIK, they never offered an expansion for sale.
The last (but not least) interesting thing on this picture is the copyright. Yes, it’s a DSM860/16 from 1992, RDK made it (Rolf-Dieter Klein), DSM in Munich distributed it – but it’s obviously also a rev. 1.6, which means there could be others before or after that one. If you have more informations I would be happy to learn more.

DSM860-OEM/16

I’m pretty sure there was one more version after this rev.1.6, this b/w picture from a DSM press release about shipping the 250.000th slot-CPU card shows a very changed design. The silkscreen print says “DSM860-OEM/16”, so it’s obviously nothing for the normal market.
Mind the onboard-RAM, the missing comms-section and the high integration (SMD parts all-over) and even an early form of an FPGA from Lattice – my assumption is that this version could be the answer to the Kontron SBC860 showing nearly the same layout:

At least this ‘riddle’ is finally solved. I was able to buy an DSM860-OEM/16..Yay! As assumed, it is a modern (for 1990 standards) version of the DSM860-16 now consisting of just one board, so no more RAM card as described below- and without the Transputer and Ring-A/B stuff.

Here are my pictures of it. First of all, the card in full view:

The right half shows a very high degree of integration compared to its predecessor. All DIL ICs were replaced by SMD parts and lot of logic went into PALs and even an FPGA (The contents of the EPROM is the same as with the other card, minus Transputer handling):

The left half contains the CPU and the RAM. This time only 8 SIMM slots:

The RAM card

This is the 2nd part of every DSM-860 – the RAM card (except the OEM-16). Same dimensions as the SPC itself… i.e. full length. The biggest part of it is consumed by the 16 angled SIMM sockets, obviously interleaved, thus named altering slot-a & b. Only the 8 a-slots are populated on mine.
The rest of the board is used for lots of buffers and drivers, some GALs (doing the mem-mapping) and there’s quite a big copyright… again.

One typical detail of those days is the fact that manufacturers were not very keen on having users doing upgrades themselves. Even this RAM board has standard SIMM sockets and one could simply plug in more SIMMs to expand the RAM you had to change a GAL (the one in the lower left corner with a while label saying “UXM24Wxx” on it). Obviously these GALs are the only ones notdocumented. All I know is that there were 3 GALs available differing in the last two letters of the label:

8B = only a-slots can be used by either 1M or 4M SIMMs giving 8 or 32MB total
16 = both a- and b-slots used with 1M SIMMs = 16MB total
64 = a- and b-slots filled with 1M and/or 4M SIMMs giving 16, 40 or 64MB total.

Because the card as well as the documentation says the maximum supported amount of RAM is 256MB there might be the chance of supporting 16MB SIMMs – I did not try this yet.

Both cards attached together give quite a big and heavy sandwich

It’s obvious that you not only need 2 full-size slots but also guide-rails inside the case to hold the weight of this beast.

DSM-860/32

This seems to be the king of the SPC hill. Technically it’s pretty much the same as the DSM-860/16 but this time featuring a 32-bit system bus – namely EISA. The EISA bus was a dead-end like IBMs Microchannel but comparably easy to implement and free of license fees.

So the main difference to the DSM-860/16 is the 32-bit wide connection to the hosts bus, visible by the 4 dual-ported RAMs used for a 32-bit wide connection to the EISA slot.

Again, here’s a 1992 magazine ad showing a probably early version of the card as the marking says “DSMß860-32” (mind the beta) and the year “1991”:

Compared to that, my version (1.2) does not look that much cluttered – also the Transputer comms part were moved to the left side of the i860 and two more LEDs were added:

So the left side of the card looks pretty identical to the DSM860-16, while the right side has a bit more logic to satisfy the EISA standard, the already mentioned 2 more DP-RAMs, a bigger expansion-bus due to the EISA slot and most important: 2 more LEDs! Did I mention that LEDs are good? 😉

This more detailed picture shows that the DSM860/32 was released the same year as the ISA version. This card is a rev.1.2 – again, if you know more about revisions, I’d be happy to hear from you.
You might have spotted that this card looks a bit shabby. That’s because it was pulled from some universities dumpster. It was missing some components and had some “scars”. The good thing was that none of the GALs were missing and due to the fact that every piece is documented on the card it was easy to replace the missing parts.
On the above picture you can clearly see e.g. the 100nF capacitor C40 below the i860 or the 40MHz OSC. I wish everything would be that well documented.

The Infinity card

This is a rare and mysterious beast. The documentation only touches it very briefly. It’s definitely nothing been built for the average DSM860 user – if something like that existed. For sure it was extremely expensive… and it has LEDs 😀

So at the first look you see 2×3 connectors for 40pin cables – the same used on the DSM860 cards (Ring-A and -B). Then there are a lot of drivers and buffers and a big Lattice pLSI 1032-50 which is a 6000 gates PLD (Programmable Logic Device). A closer look to the board gives more hints – thanks to the DSM (or RDK) habit to print as much info as possible onto the board:

Ok, first information we get is that this is a EINF860M or INFINITY 32Bit Extender. It’s like all other boards (c)1992 by DSM Munich and -as one would expect- designed by Rolf-Dieter Klein (RDK).
The three connectors are labeled ADDR(ess), DATA MSB (Most Significant Byte) and DATA LSB (Least Significant Byte).
The the right of the connectors is an Intel 85C098-20. I think that’s a One-Time-PLD, not 100% sure.

My educated guess is that this card is what the print on it says: A bus extender. Using the 16-Bit bus on the DSM860 cards one can build quite a big parallel computer. But the max. length of the flat-cable to connect each card with the next one is limited. So this card would be connected to other DSM860 cards in the same case (i.e. a 19″ case in a rack) and the extender would then “amplify” the bus-signals to be send over into the next rack full of DSM860 cards.
That said, my fear is, you’ll need two of those cards as the seperation of Adresses and Data (MSB and LSB) is nothing being used on the DSM860 cards. So my next guess is, that the INFINITY communicates over the EISA bus with the other cards and has its own external bus. Again – I’m happy if you contact me if you know more/better!

Nostalgia

And here’s a full page ad I found in my old (German) computer magazines – it shows all 3 versions:

AVM T1

Hacking the AVM T1

June 21, 2009 Axel Leave a comment

It was inevitable… the biggest system AVM built was the “T1”, a 30 channel ISDN controller in a sleek 1U 19 inch case of which nothing more than the above marketing picture seems to exist.
One fine day I had to had one – and today is the day!

I was able to find a AVM T1 on ePay which was not very well advertised so I had no “professional competition”. Even I didn’t spent a fortune it was a bit of gambling because I didn’t knew what to expect.
Besides AVMs own T1 PDF manual there’s next to nothing available in the Web – So this section is yet another WWW-exclusive brought to you by geekdot.com 😉 (Ok since 2009 others discovered this page and also this cheap entry into the wonderful world of multi Transputing)
Still, the docs said “a Transputer network with 9MB RAM” so I couldn’t go completely wrong. That said, I was expecting SMD T400s at AVMs usual sluggish speed…

First look

When the box arrived first thing was getting out good ol’ screwdriver and open the case…

…and I was very surprised:

A socketed T425 – so that’s another easy upgrade then.
An external power supply (48V)! That’s strange but also neat – no noise and next to no heat in the case itself
Also, the board is very small… lot’s of room left in the case.

That’s done by intention as you could buy the T1-B, where “B” stands for the “Booster Board”, yet another board with 4 more Transputers and another 8MB of RAM giving a total of 7 Transputers and 17 Megs of memory. Quite a setup for just an ISDN controller.

Sniffing around

Ok, this beast has to do something better than handling 30 boring B-Channels… Mandelbrot for example 😉 So let’s see how this thing is/was supposed to speak to the outside world.

The manual is talking about an ISA or PCI controller-card which will be connected to a 9-pin Sub-D connector. Having a closer look to the mainboard where that connector is seated I discovered some other old friends: AM26C31 and AM26C32.
Aaaaalrighty, RS422 time… that’s the same way my Tower of Power is transmitting its data. So I can use my TTL-to-RS422-converter I’ve built for the Gerlach card.

Out goes the multimeter and after a while I figured out the the traces on the board. For a better understanding, here’s the “map”:

Marked by the red arrows are the three Transputers: T1, a T425-25, is the “application processor” while T2 and T3 are more simple T400-20 handling the ISDN subsystem.

The yellow arrows mark the four links of the T425 – which is probably the reason why AVM used a 425 vs. their usual T400: this time they really needed 4 links.
Link0 is connected to the 9-pin sub-D connector (via the RS-422 transmitters/receiver) for interfacing to the PC.
Link1 and Link2 are directly connected to the T400s.
Link3 goes to the connector on the lower edge of the board. I bet this is where the “booster board” would be connected… not a hard bet, I admit.

The pinout for the 9-pin sub-D connector (female) is:

 1 Link0-IN -
 2 N/C
 3 Reset-IN +
 4 N/C
 5 Link0-OUT +
 6 Link0-IN +
 7 Reset-IN -
 8 GND
 9 Link0-OUT -

As Link0-IN and Reset-IN are routed through two separate 26c32 I assume there might be more differential signals available. If time allows I’ll dig deeper on this matter.

Do something Gromit!

Well then… a cable was built in a couple of minutes – some cursing and swearing about the differential polarity and then the exciting moment came: Let’s see if it’s really so easy again!

It is! And here’s the ispy output for the T1 (connected to the “Gerlach card”):

Using 150 ispy 3.23 | mtest 3.22
# Part rate Link# [ Link0 Link1 Link2 Link3 ] RAM,cycle
0 T800d-25 288k 0 [   HOST    …    …    1:0 ] 4K,1 1024K,3;
1 T425c-20 1.6M 0 [    0:3    2:0    3:0    … ] 4K,1 4092K,3.
2 T400c-20 1.7M 0 [    1:1    …    …    … ] 2K,1 1022K,3.
3 T400c-20 1.8M 0 [    1:2    …    …    … ] 2K,1 4094K,3.

Some remarks about this:

9 MB is true. The “application processor” (T1) got 4MB while the two T400s got 1 (T2) and 4 MB (T3, obviously connected to the SIEMENS Munich32 Über-ISDN controller).
While the built-in T425 is spec’ed for 25Mhz it’s just running at 20MHz… what a waste of bang… and what an opportunity for improvement :->
The linkspeed is at maximum… which one would expect with directly connected links. But with AVM you’ll never know 😉
The RAM-speed is pretty good (compared to what they did to the B1) – even they just used 70ns RAM.

Next up: Having fun with Mandelbrot! Having just T4xx Transputers it can only use the integer algorithms (i.e. no floating point) but who cares for a quick start?!

It’s working and showed another nice gadget: LEDs! Each Transputer has a tiny SMD-LED connected to it’s Link-Out.
So having the T1 underneath the table I have quite a nice light-show while the three are working their a** off 😉

If you happen to have no access to a RS422 converter: Never say die!
Like said above, there’s still Link3 available – normally meant for the booster-board – and it’s pure TTL. All you need is a somewhat non-standard plug to this connector. Be creative but don’t forget that unbuffered link connections only allow a distance of a couple of inches/centimeters!

The pin-out (so far) is, counting from left to right:

 1 - 5V VCC
 2 - T1 Link3 OUT
 3 - T1 Link3 IN
 4 - RESET
 5 - T3 Link1 OUT
 6 - T3 Link1 IN
 7 - GND

[UPDATE 11/14/10] Again, with some ePay-Luck I got another T1… and it again was some kind of lottery… and I had luck! This time it’s a T1-B!! This means, the “booster board” is installed. So opening the case, it looks like this. On the right the normal T1-board, to the left, “da mighty booster board” 😉 I’ll call it “BB” from here…

As expected, it’s connected via Link-3 of the T1 Board. On the lower edge of the picture you can spot the power-supply “module”. It’s longer than in the T1 configuration and provides 3.3V/GND to the BB, i.e. the BB is 3.3v only!!

Here’s the BB alone:

All in all the BB is more modern than the T1-board. Very suspicious are the JTAG connector on the lower left having its lines connected to a EEPROM (AT28V256, right edge of the BB board, above the row of RAMs). Further up, left to the CPU nearby is a pad with the lable “Boot from ROM/Link”. I wonder what the default is and what’s inside that EEPROM – will investigate later.

Most importantly the BB board features 4 ST20450 processors, which aren’t INMOS products anymore. They were designed by ST after they bought INMOS. For short, the ST20450 is a T425 on steroids. More on-chip RAM (16K), higher clocking (40MHz) and some more instructions.
Each ST20450 has its own 2MB of RAM and a GAL handling the memory etc.. Here’s a close-up of a single ST20450 “module”:

Mind the careful markings/labels on the board. The CPUs are numbered (“Processor 3”) and there are pads for Links etc.

Finally, I currently have no tools to check/use ST20450 processors. ispy finds the Transputers on the T1 board but freaks-out when it pings the ST20s.

Here’s another new addition: A picture of the official T1-PCI interface. It contains a PCI-controller (the big IC) and a XILINX FPGA… probably containing a synthesized C011.

UPDATE:

Jonathan Schilling also ~~plays~~ played around with an AVM T1 on his page including the original ISA controller card… and he~~‘s making~~ made very good progress!
[2015, Jonathan quit ‘the scene’ and handed over all his equipment… further on, it seems in 2020 he closed his pages]

Another UPDATE [2017]:

Just got another T1 off ePay… surprisingly it contained yet another board-design. I’ll call it the “non-booster layout“. This board has no connectors for the booster-board and missing the regulator below the DC/DC converter – no need for 3.3V.

TODO:

Change the T425
~~Make the 30 front-panel LEDs blink~~
Figure out for what the female 15pin sub-d connector is good for (not mentioned in the manual)

Here’s how to access the LEDs at the front – thanks to Michael Brüstles research:

typedef unsigned long int u32;

/*
 *  addr XXXX-XXXX-X111-XXXX-XXXX-XXXX-XXXA-AA00
 *    
 *  wr                               0-01    __ EN __ __-__ __ __ SY
 *  wr                               0-10    08 07 06 05-04 03 02 01
 *  wr                               0-11    16 15 14 13-12 11 10 09
 *  wr                               1-00    24 23 22 21-20 19 18 17
 *  wr                               1-01    SC ST 30 29-28 27 26 25
 *
 *  rd                               0-01    readable ... content unknown
 */

int main( void ) {

    u32 *p = (u32*)0x80700000UL;

    p[ 1 ] = 0x40;  /* enable all leds 0x40 & Sync 0x01 */
    p[ 2 ] = 0x05;  /* Led01-Led08 */
    p[ 3 ] = 0x00;  /* Led09-Led16 */
    p[ 4 ] = 0x3F;  /* Led17-Led24 */
    p[ 5 ] = 0x92;  /* Led25-Led30, System, S-channel */

    return 0;
}

Caplin Cybernetics

Caplin Cybernetics i860/Transputer cards

August 26, 2009 Axel Leave a comment

Caplin Cybernetics (just Caplin for short) was one of those many UK based (London to be exact) companies building Transputer based high-performance systems. Caplin seemed to be specifically concentrating on providing Transputer technology for DEC systems, namely VAXen.

As of now, I do not know much more about Caplin, but I know there are still some former employees around and I’d be happy to learn more about the company as well as the systems I’m going to describe further down.

By a lucky indecent I got my little greedy hands onto 2 different Caplin systems. Both connecting Transputer (networks) to a mighty Intel 80860XP.
While these boards have i860’s on them I’ve put them into this Transputer category, as they were meant as math accelerator for Transputer networks, not the other way round like the DSM860 boards, which used Transputers mainly for networking.

I don’t have any documentation for those boards but I hope to get them working as soon I figured out how to connect to the Transputers, find out more about the memory-mapping and found a way how to read those damn Bipolar-PROMs.

That said, from here everything is just wild speculation, assumption and finger-in-the-air-guessing – If you know more/better: Let me know please!

I’m specifically looking for the document called “Caplin XPR Series Technical Overview”. If you still have a copy or you do know somebody who might: I’d be very happy to hear from you!

HXI860

The HXI860 seems to be the earlier implementation of a Transputer-to-i860 board. It is a quite late i860 implementation though, featuring the first incarnation of the i860, the 860XR, predecessor of the 860XP.

A picture says more than a 1000 words: The HXI860 in full view

Let’s start with the left side of the board. The picture is a bit blurry (sorry) but it’s enough to identify what I’m going to talk about:

Starting on the left there are many blue 2-row pin connectors. This seems like a job for long winter evenings to find out which pin is connecting to what.
Then there are the 3 “golden boys” next to the connectors: From top down those are 1 T800-25 and two C004 linkswitches. Above the T800 there’s 4MB for his own use.
Then there are two FPGAs, one with the AT&T logo (ATT3020) and one more familiar XILINX XC2064, both getting their programming from an Xilinx 1736A PROM.
In the top-right corner the heavy-wight-champion i860XR (40MHz) surrounded by lots of buffers and GALs. The long DIP ICs on the right edge are IDT73210 octal transceivers with parity checking.
Rightmost are the connectors to the DEC Q-Bus… luckily only power & GND are taken from there, so you don’t necessarily need a VAX to use the board.

The right side of the board looks like this:

Ignoring the lurking C004 and Xilinx CPLD the leftmost black square IC is an T222C-17 which most likely controls the initial C004 configuration. He gets his code from two ICT 27CX642 which are quite strange devices: Made like CMOS EPROMS they use differential memory cell techniques to provide bipolar-prom speed. No idea how I will be able to read them out with my standard EPROM programmer.
Also, there’s a “6bit” dip-switch next to the T222 which I was told will be used to configure the link routing… let’s see what I will figure out by try’n’error.
The other four square ICs are 2Kx16 dual-ported RAMs (IDT7133). Four of them makes 64bit… well, that the i860 memory bus interface.
Last but not least there’s a long DIP IC above the DP-RAM… it’s an C012 Transputer link-adapter. So one Transputer link must be connected here, converted into 8-bit parallel. Could it be that they connected the 64-Bit RAM of the i860 via a transputer-link? (shudder)
Ok, and obviously there are 8 SIMM slots for i860 RAM… parity RAM required.

XPR201

This much bigger board seems to be the successor to the HXI860 and I was told it was the fastest i860 board Intel ever tested. Also this seems to be a prototype and was never officially sold.
It now features a 50MHz i860XP (fastest i860 available), two instead of one T800 but no C004 at all. Also the communication between the Transputer(s) and the i860 seems to be fully memory-mapped and no C012 is involved.

Here’s the full-view:

Let’s go into detail… the “Transputer side” for a start:

The connector at the top-right edge is yet of unknown type.
Below this, there are 2 T805-25, each having 4MB of RAM. Two AM27S33 4Kx4 bipolar PROMs (flanking the RAM to each side) seem to offer the 4K boot-code.
This board, too, has a 6bit dip-switch. Again, no idea yet what it does.

The most space in this picture is used by the much more sophisticated i860-to-Transputer interface, which is so complicated that it needs a diagram for itself (Thanks to Mike B. for beautifying this!):

Eight(!) 4Kx16 IDT7024 dual-ported SRAMs are used to convert the i860’s 64bit bus to the Transputer 32bit bus – most likely they’re part of the “DMA engine”, too.

For doing this you normally only need 4 of them, but as you can see on the above diagram, Caplin chose to use the two T800 independently, so each Transputer has his own 16k SRAM directly connected to the i860.
Then, each Transputer is also connected to a 1MB VRAM bank (consisting of eight HM538123 having 128K word x8 DRAM and 256-word x8 Serial RAM). I was told the serial-side is connected to the Transputer, the parallel-side to the i860. Behind the VRAM is the “DMA engine” most likely the array of XILINX FPGAs you can see on the upper edge of the picture below.

The reason for this “over engineered” design most likely was, that you could use the SRAM for small but very fast read/write operations, while you would use the VRAM for bigger chunks of data.

The lower-edge (“i860 side”) overlaps a bit with the above picture of the “Transputer side”:

Again, like on the HXI860, lots of IDT73210 octal transceivers, the 4 XILINX FPGAs (the “DMA-engine”, also fed by 1736As) and a huge array of GAL/PALs doing the bus-handling.
Then there’s the i860XP (50MHz) hidden under a heatsink.
A bit below is a 16-positions dial – no idea what it does. First thing coming to my mind: RAM timing.
Finally even more buffers connected to 8 SIMM slots (the i860 private RAM, Parity-only again).
The blue connector on the bottom edge is meant to connect to a 2 digit, 7 segment display which I have on a second board I own.

Paradico

Paradico – “The cube”

September 22, 2009 Axel Leave a comment

This is yet another pretty unknown Transputer module. The silkscreen print says “PARADICO – beheer submodule – BOP 1990”. Well, beheer is Dutch for management, so it was the management submodule for… something.

I got myself 4 of those from my Transputer-Bro’ Mike and after a good year of lying in my cupboard it was overdue to do something with them.
Mike was kind enough to do the basic deciphering of all the traces, links and stuff, so it was basically just building & wireing a front- and back-plane to get them working.

This is how one PARADICO looks like:

Not everthing is readable here but it does the job because the PARADICO is a pretty standard Transputer design. More or less a huge TRAM. So nothing fancy about it:

One T800-25 Transputer
4MB DRAM (4×256)
Some PALs for the memory decoding
Buffers for the links
A 5MHz oscillator
A fuse… just to be safe 😉
Handy jumpers for LinkSpeed and CPUSpeed

IMHO this is actually quite a waste of space but in these days you have to take what you get, right? 😉

Ok, so I ordered 8 DIN41612 sockets and after a day worth of soldering “The Cube” was finished:

“The Cube? It’s not square at all!” you might say. Yes, true, but the specs are all nicely squared so here’s the proof. The Cube has: 2² Transputers running at 5² Mhz, each has its own 2²MB RAM. Voilà, a cube 😉
For the convenience of connecting the cube to more or less any other system, I’ve added a hex-inverter so notAnalyse, notReset & notError can be converted into their “positive” counterparts (in the upper left corner of the picture, next to 3 red jumpers).

This is the ispy output connected to the “Gerlach Card“:

Using 150 ispy 3.23 | mtest 3.22
# Part rate Link# [ Link0 Link1 Link2 Link3 ] RAM,cycle
0 T800d-24 240k 0 [   HOST    1:0    …    … ] 4K,1 1024K,3;
1 T800d-25 1.8M 0 [    0:1    2:0    3:0    4:0 ] 4K,1 4096K,4;
2 T800d-25 1.8M 0 [    1:1    …    …    … ] 4K,1 4096K,4;
3 T800d-24 1.8M 0 [    1:2    …    …    … ] 4K,1 4096K,4;
4 T800d-24 1.8M 0 [    1:3    …    …    … ] 4K,1 4096K,4;

And if you happen to stumble over a Pradico yourself, here’s the pinout of the front DIN41612 connectors:

          X  A32 C32   X
        GND  A31 C31  GND
 UpNotError  A30 C30  DownNotError
 UpNotAnaly  A29 C29  DownNotAnaly
 UpNotReset  A28 C28  DownNotError
        GND  A27 C27  GND
         X   A26 C26   X
   LinkOut0  A25 C25  LinkOut1
    LinkIn0  A24 C24  LinkIn1
        GND  A23 C23  GND
        GND  A22 C22  GND
         X   A21 C21   X
   LinkOut2  A20 C20  LinkOut3
    LinkIn2  A19 C19  LinkIn3
        GND  A18 C18  GND
         X   A17 C17   X
        GND  A16 C16  VCC
        GND  A15 C15  VCC
         X   A14 C14   X
         X   A13 C13   X
         X   A12 C12   X

JP1:
1 LinkSpecial
2 Link0Special
3 Link123Special

JP2:
1 ProcSpeedSel0
2 ProcSpeedSel1
3 ProcSpeedSel2

Next up: The Cube moves into the Tower of Power… when other more important things are done.

DIY Projects, DIY Transputer interfacing, T2C64

T2C64

March 25, 2010 Axel Leave a comment

So here we go, C64 first. Some moons ago I was at least midwife if not the mother of the 8BitBaby manufactured by the fairies and elves over at individual computers.

This little card features 4 slot-connectors to the most used home-computer systems as well as a CPLD… and makes a perfect basis for my first C64 “cartridge” ever 😉

The schematic was taken from “Das Transputerbuch” by U. Gerlach and being put into the CPLD saving lots of TTL chips. Actually all you need then is an Inmos C012 or C011 link-interface chip, a 5MHz oscillator and some resistors and caps.
I refrained from designing a complete Transputer system but went the easy route by interfacing to a TRAM. A TRAM is a complete “Transputer system on-a-stick”, like those used in my Tower of Power. All you need for a TRAM is an interface to your system. For the C64 you would need the thing I’ve called T2C64 (aka “Transputer to C64”)

The T2C64 prototype in its full glory:

A short overview what’s on the card:

The left edge is the connector to the C64s expansion slot (ignore the other edges).
The square black chip is the Altera CPLD mainly containing the bus-interface and the Transputer Analyze/Reset/Error signal handling. Ah, and it controls the 2 LEDs.
The long black chip above the CPLD is an Inmos C012. This guy interfaces an 8bit parallel bus to the serial Inmos link ‘bus’.
The silver thing is a 5MHz oscillator to clock the C012.
And finally the longish module at the top edge is a TRAM with 128KB RAM and a mucho-macho T800 Transputer.

The CPLD maps the C012 register into the memory area of 0xde00, using just 6 addresses:

Data in 0xde00 (56832)
Data out 0xde01 (56833)
in-status 0xde02 (56834)
out-status 0xde03 (56835)
reset/error 0xde08 (56840)
analyse 0xde0c (56844)

So programming it pretty easy, still, you have to read some Inmos manuals about the protocol etc… that said the next chapters will show you some code examples I’ve slapped together just to test the hardware. All sources and binaries (.D64 image) are available in a zip file over here, obviously most of that does not make sense without having a T2C64…

Read on in the next posts for demo-code and even a video. “uuh, videos!”

DIY Projects, DIY Transputer interfacing, T2C64

1st code example

March 25, 2010 Axel Leave a comment

For the fun of it, here’s my first Commodore BASIC v2 program which does 3 things.

Line 1-50: Initialize the Transputer and set/get its status.
Line 69-110: Write (poke) some data into T’s memory and read (peek) it back.
Line 128-240: Send a little program to the T and read its result.

10 PRINT"INIT TRANSPUTER"
11 POKE 56840,1:POKE 56844,0:POKE 56840,0
20 REM CLEAR I/O ENABLE
21 POKE 56834,0: POKE 56835,0
30 REM READ STATI
31 PRINT "I STATUS: ";(PEEK(56834)AND1)
35 PRINT"O STATUS: ";(PEEK(56835)AND1)
40 PRINT"ERROR: ";(PEEK(56840)AND1)

This is the Transputer POKE command (0) which tells the T that the next 4 bytes are an address followed by 4 bytes of data:

45 PRINT"SENDING POKE COMMAND" 46 POKE 56833,0 50 PRINT"O STATUS: ";(PEEK(56835)AND1) 58 :

Mind that were little endian and BASIC is using decimal numbers. So we’re POKEing 0,0,0,128 which is 0x00, 0x00, 0x00, 0x80 in hex which again is the 32bit address of 0x80000000.

59 PRINT"SENDING DATA TO T." 60 POKE56833,0:POKE56833,0:POKE56833,0:POKE56833,128 61 POKE56833,12:POKE56833,34:POKE56833,56:POKE56833,78 70 PRINT"I STATUS: ";(PEEK(56834)AND1) 79 :

Now reading back (PEEK) from 0x80000000 what we just wrote:

80 PRINT"READING FROM T." 90 POKE56833,1:REM PEEKING 100 POKE56833,0:POKE56833,0:POKE56833,0:POKE56833,128 110 PRINTPEEK(56832);PEEK(56832);PEEK(56832);PEEK(56832)

These 4 sequential PEEKs print 12 34 56 78. Yay! A very simple Ram-disk if you want.

Now something more serious. A very small programm is sent to the T and executed. Instead of peek and poke (1/0) the initial ‘command’ is the length of the program (23 in this case), so the T starts executing after he received the 23rd byte.
The program itself is trivial, after some initialisation it writes 0xAAAA0000 to link0out. The use of it is very simple. If the Transputer is working correctly the first 2 bytes will allways be “0xAA”, if it is just a 16bit Transputer (T2xx) there won’t be more than 0xAAAA. A 32bit Transputer returns the full 0xAAAA0000. Voilá, that’s a simple T-detection.
To handle timeouts end error conditions I had to do some ugly things in BASIC. Sorry, don’t blame me, BASIC v2 is just… very basic.

120: 128 DIM R(4) 129 PRINT"SENDING PROGRAM TO TRANSPUTER..." 130 FOR X=1 TO 24 140 READ T:POKE56833,T 150 WAIT 56835,1 160 NEXT X 170 PRINT:PRINT"READING RESULT:" 175 C=0 180 N=TI+50 181 IF C=10GOTO 220 189 IF TI>N THEN ER=ER+1:IF ER=10 GOTO 220 190 IF (PEEK(56834)AND1)=0 GOTO 189 195 R(C)=PEEK(56832) 200 C=C+1 210 GOTO 180 211 REM ------------------------ 220 IF C=1 THEN PRINT"C004 FOUND" 230 IF C=2 THEN PRINT"16 BIT TRANSPUTER FOUND" 240 IF C=4 THEN PRINT"32 BIT TRANSPUTER FOUND" 1000 DATA 23,177,209,36,242,33,252,36,242,33,248 1001 DATA 240,96,92,42,42,42,74,255,33,47,255,2,0

Next up a bit more useful example, reading the Transputer executable directly from a binary file instead of having it in-line.

DIY Projects, DIY Transputer interfacing, T2C64

2nd code example

March 25, 2010 Axel Leave a comment

This example actually puts the Transputer to some sort of use… well, it’s still way beneath him but it does its job as an example.
Two tasks: a) Read the Transputer executable from disk and b) exchange data with the Transputer.

Here we go:

10 PRINT"INIT TRANSPUTER" 20 POKE 56840,0 30 POKE 56844,0 40 POKE 56840,1:POKE 56840,0 50 FOR W=0 TO 1000:NEXT W 60 POKE 56834,0 70 POKE 56835,0 80 REM READ STATI 90 PRINT "I STATUS: ";(PEEK(56834)AND1) 100 PRINT"O STATUS: ";(PEEK(56835)AND1) 110 PRINT"ERROR: ";(PEEK(56840)AND1) 140 PRINT"O STATUS: ";(PEEK(56835)AND1)

Up to here everything should be clear. Init Transputer, read stati -just to be sure.
Now we’re reading the executable (“GRAB”) from floppy and poke the bytes to the Transputer as they come flying crawling in:

150 DIM R(4) 160 PRINT"SENDING PROGRAM TO TRANSPUTER..." 170 REM READ TRANSPUTER BIN FILE 180 OPEN 1,8,2,"0:GRAB,S,R" 190 FOR I=0 TO 1 STEP 0 200 IF ST=64 GOTO 240 210 GET#1,A$:A=ASC(A$+CHR$(0)) 220 POKE 56833,A 230 NEXT I 240 CLOSE 1

Ok, the Transputer binary expects us to tell it the number of integers we’re about to send to it (AN), the we send these (X) and finally re-read the results… which should all be X+7.

250 INPUT"COUNT:";AN 255 POKE 56833,AN 260 FOR AA=1 TO AN 270 PRINT"ENTER ";AA:INPUT X 280 POKE56833,X 290 NEXT AA 295 PRINT"GETTING";PEEK(56832);" RESULTS" 300 FOR BB=1 TO AN 310 PRINTPEEK(56832); 320 NEXT BB

Some final words about Transputer executables. There are many kinds depending which development system was used. Some need special loaders or bootfiles before the actual binary will be send to the Transputer. A ‘raw’ upload is only possible with binaries mostly having the extension of “.btl” (BooTfromLink). AFAIK only the OCCAM SDK and the Inmos C-compiler ‘icc’ will create those executables.

For those geeks who actually (still) do know their OCCAM, here’s the source of GRAB:

PROC first(CHAN OF BYTE in, out)
  #USE "hostio.lib"

  BYTE data.in, data.out :
  INT count, temp :
  [1000]BYTE array :

-- {{{ start main SEQ

  SEQ
    in ? data.in
    count := (INT data.in)
    SEQ i=0 FOR count
      in ? array[i]                   

        -- {{{ inner loop
        
            SEQ i=0 FOR count
              SEQ
                temp := (INT array[i])
                temp := temp + 7
                array[i] := (BYTE temp)
        
        -- end of inner loop
        -- }}}
                
    out ! (BYTE count)
    SEQ i=0 FOR count
      out ! array[i]          
    in ? data.in       -- debug only
    CAUSEERROR()

-- }}}
        
:

DIY Projects, DIY Transputer interfacing, T2C64

3rd sample and video

March 26, 2010 Axel Leave a comment

And now something which you knew it would come: Mandelbrot time! 😉

I don’t want to bore you with all the details before you had it seen in action… so here we go:

“Man, that was brilliant! And even you had a lot of geek-babble in there, I want to know more!”
Ok Timmy, let’s go into detail…

Like I said in the video, the Transputer is finally doing something for real, he’s actually doing the most of the work, crunching through a 320x200x8 Mandelbrot, 32 iterations in double-precision floating point. The code itself was written 1988 in OCCAM by Neil Franklin and is available on his page.
This shows the general beauty of Transputers: If the code is written flexible enough to fit into any topology, it’ll run on any platform!

That said, I ran into a certain limitation on the C64. The Transputer mandelbrot executable expects the initial data (resolution, coordinates, iterations) to be send in a specific order and format. While the order isn’t the problem, the format is: The coordinates have to be doubles (C-lingo i.e. 64bit IEEE 754 compliant float). The C-Complier I’ve used for this demo (CC65) doesn’t now a flying s*** about floats or even doubles.
So to get that demo done ASAP I tricked myself a bit and used the same technique we’ve seen in my 1st demo when POKEing something the Inmos-way:

To get the coordinates for left (-2.0), right (1.0), top (1.125) and bottom (-1.125) over to the Transputer they had to be converted into 64bit IEEE 754 format, ordered into little-endianess and finally put into an array like these:

static char left[] = {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xc0}; //-2.0 static char right[] = {0x00,0x00,0x00,0x00,0x00,0x00,0xf0,0x3f}; // 1.0 static char top[] = {0x00,0x00,0x00,0x00,0x00,0x00,0xf2,0x3f}; // 1.125 static char bottom[] = {0x00,0x00,0x00,0x00,0x00,0x00,0xf2,0xbf}; //-1.125

Yes, that’s a bit awkward, but it was OK to get a fast start. The ‘problem’ with this quick-hack is that the demo is pretty static, i.e. no zooming into the Mandelbrot. If you know of a quick way to create IEEE 754 compliant doubles from a long (which is the biggest floating point variable CC65 can handle, so StringToDouble() isn’t an option here) I’m happy to hear from you.
Of course I could have the Transputer do the typecasting but in this case, as part of a demo, I wanted to keep the original binary untouched.

In the video you saw (or didn’t because of the blurry picture) that the timer printout was about 70s… and as said, normally it takes about 60s to complete the fractal – and it did in the video, too! Watch the video-timer or check with a stopwatch. What I’ve forgot to take out from the timing was the actual upload of the code into the Transputer.
The Transputer binary is in this case a bigger array in the C-source, so it’s not being loaded from floppy but directly pushed to the Transputer after it was initialised. This takes some extra time which also went into the stopwatch timing… I’ll correct that in a later version.

“Later version” is a good catchword. If this wouldn’t be just a demo for now, there are obviously plenty of ways to optimise things:

First of all one should take off the burden of converting the colors from the C64 and let the Transputer do that.
My second idea would be to reduce the communication overhead (polling) by having the Transputer to render the whole screen into his own RAM and when done have it ‘pumped’ down to the C64
Yes, DMA would be cool but that’s not possible (yet)

Ok, that’s about it for now. The T2C64 is still in its prototype stage and I can image many more cool things to add… but first I will have a ‘proper’ circuit board being made.

Final words: Don’t get too excited about the acceleration of the C64… it’s not accelerated at all. 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 C64 and the Transputer. A single square-root for example wouldn’t make sense at all. 100 sqrts in one go would certainly do.

Of course adding another linkOut/In to the T2C64 to get more Transputers involved into the calculation would be the final step. This is planned for the next version of the hardware but the bigger part of the work would be a complete rewrite of the Mandelbrot code to have it broken down to parts being run in parallel on each Transputer… which closes the loop to today where programmers are trying to wrap their brains around multithreaded programming. 22 years after the first Transputer was released 😉

DIY Projects, DIY Transputer interfacing, T2A2

T2A2

March 27, 2010 Axel Leave a comment

Ok, here it is. The T2A2. What sounds like a robot from StarWars is actually a Transputer to Apple II interface. Its design is pretty much the same than its cousin, the T2C64, with the addition of some buffers to behave like a good citizen of the Apple-II bus. So this is how the little beast looks as of now (v0.5):

To use the Apple-II bus-connector of the 8Bit-Baby (another brainchild of mine), I had to shuffle the parts around a bit. On top you’ll see the same TRAM used on the T2C64… 20MHz T800 Transputer, 128KB SRAM. Right below it is an LS245 octal bus-transciever to handle signals like DevSel, R/W and A0-3. To its right its the IMS012 Linkadapter converting 8bit parallel bus into INMOS’ serial link-protocol. Below that, there’s the silver 5MHz oscillator to clock the IMS012 as well as the Transputer and another 245 to buffer the data-lines (D0-7). Finally on the left bottom there’s the CPLD which handles the Analyze, Reset and Error lines of the Tranputer as well as chipselect and such (Thanks to Mike for helping out on VHDL here!).

The picture above is the first Prototype and it’s finally working… even it’s a nightmare to look at its back side 😀

But because I’m a Commodore guy who wasn’t able to afford an Apple II in its hey-days I had to start from scratch and learn a lot…
That said, when I finally could afford an Apple II system, I went straight for the IIgs. I think IIgs is the perfect platform for an 8-bit Transputer interface given the amount of available/adressable RAM, native access to harddisks and a decent screen resolution.

Because of its simple design, the T2A2 should also work in any Apple-IIe etc. There’s no ‘firmware’, no EPROM. Just plain simple reading and writing to some (slot)specific addresses.
Due to its close relationship to the T2C64, programming is quite similiar. As a matter of fact I just slightly changed the examples I’ve used on the C64… which is the beauty of the idea.

So jump to the next post to see the first little test proggie in AppleSoft BASIC…

DIY Projects, DIY Transputer interfacing, T2A2

1st basic example

August 6, 2010 Axel Leave a comment

Like with the T2C64, the CPLD on the T2A2 maps the C012 registers into the memory area of the used slot, using just 6 addresses starting at 0xc080 + (SLOT# * 0x10). So for e.g. Slot 4 this would be:

BASE (0xc080 + (4 * 0x10)) = 49344
Data in: BASE 49344
Data out: (BASE + 1) 49345
in-status: (BASE + 2) 49346
out-status:(BASE + 3) 49347
reset: (BASE + 8) 49352 (writing)
analyse: (BASE + 12) 49356
errorflag: (BASE + 8) 49352 (reading)

With this ‘knowlege’ we can start talking to the Transputer… and to make our first babysteps we’re using BASIC. It’s pretty much the same code as used on the C64 with the exception that there’s no “elegant” timeout handling due to the missing clock in AppleSoft, so you have to wait a bit longer until you get the printout in the end.
For details about what’s going on here, see the C64 page.

10 PRINT "INIT TRANSPUTER" 11 BASE = 49344:IN = BASE:OUT = BASE + 1:IS = BASE + 2 12 OS = BASE + 3:RESET = BASE + 8:ANA = BASE + 12 13 POKE RESET,0: POKE ANA,1: POKE RESET,1 20 REM CLEAR I/O ENABLE 21 POKE IS,0 22 POKE OS,0 30 REM READ STATI 31 PRINT "I STATUS: ";( PEEK (IS) AND 1) 35 PRINT "O STATUS: ";( PEEK (OS) AND 1) 40 PRINT "ERROR: ";( PEEK (RESET) AND 1) 45 PRINT "SENDING POKE COMMAND" 46 POKE OUT,0 50 PRINT "O STATUS: ";( PEEK (OS) AND 1) 58 : 59 PRINT "SENDING DATA TO T." 60 POKE OUT,0: POKE OUT,0: POKE OUT,0: POKE OUT,128 61 POKE OUT,12: POKE OUT,34: POKE OUT,56: POKE OUT,78 70 PRINT "I STATUS: ";( PEEK (IS) AND 1) 79 : 80 PRINT "READING FROM T." 90 POKE OUT,1: REM PEEKING 100 POKE OUT,0: POKE OUT,0: POKE OUT,0: POKE OUT,128 110 PRINT PEEK (IN); PEEK (IN); PEEK (IN); PEEK (IN) 128 DIM R(4) 129 PRINT "SENDING PROGRAM TO TRANSPUTER..." 130 FOR X = 1 TO 24 140 READ T: POKE OUT,T 150 WAIT OS,1 160 NEXT X 170 PRINT : PRINT "READING RESULT:" 175 C = 0: REM RETRIES 180 IF C = 10 GOTO 220 181 FOR X = 0 TO 5000: NEXT X: REM DELAY 189 ER = ER + 1: IF ER = 10 GOTO 220 190 IF ( PEEK (IS) AND 1) = 0 GOTO 181 195 R(C) = PEEK (IN) 200 C = C + 1:ER = 0 210 GOTO 180 211 REM ------------------------ 220 IF C = 1 THEN PRINT "C004 FOUND" 230 IF C = 2 THEN PRINT "16 BIT TRANSPUTER FOUND" 240 IF C = 4 THEN PRINT "32 BIT TRANSPUTER FOUND" 250 IF C = 0 OR C > 4 THEN PRINT "COULD NOT IDENTIFY"" 1000 DATA 23,177,209,36,242,33,252,36,242,33,248 1001 DATA 240,96,92,42,42,42,74,255,33,47,255,2,0

Ok, if this is running fine, i.e. a Transputer was actually found and your Apple didn’t went up in smoke, we’re set for some serious numbercruncing… and a video! Yay! We love Videos, don’t we?

(I’m skipping the other sample code available on the T2C64 page. It’ll work the same on an Apple, so no need for redundancy)

GeekDot

Category Archives: Hardware

The DSM-860 Series

DSM-860

DSM-860/16

DSM860-OEM/16

The RAM card

DSM-860/32

The Infinity card

Nostalgia

Hacking the AVM T1

First look

Sniffing around

Do something Gromit!

Caplin Cybernetics i860/Transputer cards

HXI860

XPR201

Paradico – “The cube”

T2C64

1st code example

2nd code example

3rd sample and video

T2A2

1st basic example

home of real men's hardware