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.
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.
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.
a) It’s not tested in the ][ or ][+. I simply don’t own one of those.
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) 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?
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 50€/55USD (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)
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.
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:
Raspberry Pi Model B+ (700 MHz)
Raspberry Pi 2 Model B (1000 MHz – one core)
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 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.
If you google this, you most certainly end up with “your mileage my vary”. Indeed it does… and here are my 2 cents:
Because the grass might be greener on the other side of the river, I’ve tested and will keep on testing several PCB houses over the time. So I’ll update this Blog post every now and then… until now, I wrote about
For my AM-B404 TRAM I hadn’t had any other option than have them manufactured in china. 6 Layers and sub-20$ weren’t possible anywhere else. So I tried ShenZhen2U…
After sending in the Eagle-CAD files their support was great. Manufacturing and shipping was OKish (20 days in total). At first sight, everything looked great. Nice, professionally framed SMD stencil, PCBs carefully bubble wrapped.
When holding the whole stack of PCB it felt a bit ‘bouncy’ – looking at it from the side, it became clear why:
Some PCBs were bent. You can see the gaps between some of them.
Well, when the PCBs were separated (I had 3 panels in PCB) it wasn’t that obvious anymore. So I started populating them.
This brought me to the next issue. The silkscreen was quite a bit off on some of the PCBs. Luckily, all of them had enough solder pad left to be usable:
In the end, 3 of the 60 boards were completely unusable. They had shorts within the internal layers which couldn’t be fixed even by cutting traces and re-wireing.
I guess all those glitches are the price you have to pay when going “cheapo”.
Update: I ran a 2nd batch of the same boards from the same gerber files and mentioned the non-working boards in the 1st order.
This time the quality was very good and they silently added 2 extra boards to my order. Thumbs up, ShenZen2U!
Dirt Cheap PCBs
For my QFP-to-BGA adapter – which just uses 2 layers – I tried Dirt Cheap PCBs. I really like the attitude of their site and for just 25 bucks for 10 PCBs it was worth a shot.
It’s a no-brainer. Upload your eagleCAD/Gerber file and wait – after some minutes you can even look at a rendering of the top- and bottom layer of your boards. They explicitly state, that this function is beta and yes, 1 of the ~5 times I used their service, that rendering wasn’t totally correct – so don’t wet your pants if this happens. Use a real gerber viewer instead. That said, you normally have 1-2 days to update your files if I might have found a mistake later.
About 20 days later I got my little brown envelope. Everything’s fine, I’m totally OK with it.
Before using their service, be sure to check their FAQ. You’ll find jewels like this:
“The board house will add three tiny numbers to your board: batch ID, a customer number, and our PCB ID. This is so everyone knows which crappy PCBs to send you. Don’t like it? Tough. Buy an entire panel somewhere else.”
Update: I also tried their 4 layer service (for which they use an external board house) and while the price is good, the results were OK’ish.
They did not place the solder-mask on the most fine-pitch part (QFP 100pin) which is a pain in the a** to reflow without getting shorts 🙁
A more posh version of manufacturing PCBs in China is Seeedstudio who asked me to check out their “Fusion” service. They even offered me a $30 coupon (thanks!), so why not give it a try?!
Before sending my gerber files I had a couple of questions and their email service is very good an responsive.
As they offer hard-gold finishing, I thought it might be a good time to create an expansion card with its connectors being plated with hard-gold to make it more robust to plugging the card in and out a couple of 100 times… some mails flew back and forth but in the end they asked for the same price for having the connector-fingers done in hard-gold as having done the whole PCB done in this process (the rest was planned in HASL). That’s 30 vs 230 bucks! Erm, no thanks… not this time.
So I ordered some standard 2-layer, HASL finished PCBs, no bells and whistles on Fri. Nov. 25th. Their order form is well designed and shouldn’t leave you with any questions – they even offer a gerber viewer of your uploaded files, which I think is very cool! (One hint: When entering your address, the form insists that you enter an EORI tax-number which private persons normally don’t have. A simple dash “-” does the trick, though). They offer 3 ways of shipping, ~10€ for normal post (10+ days), DHL and FedEx (both 3+ days). I went for DHL – I’m pretty sure “normal post” wasn’t an option for my order when I had the choice. Maybe because of the weight…
Next day the boards went into production. You’ll be updated about the proceedings by mail – pretty standard today – as well as in you accounts order history on their page.
On Nov. 29th I got an email confirmation, that my PCBs are finished and shipped… and on Dec. 3rd I got the boards in my mailbox. That was blazing fast indeed! 9 days from ordering to receiving
The cool thing is, that I’ve ordered the predecessor of this design at “Dirt Cheap PCB”, so I have a direct comparison.
Given the simplicity of the design, I haven’t found any glitches or mistakes… the two boards are nearly identical.
If you’re super picky about your design: like Dirt Cheap PCB, Seeed does print some internal ID on your silkscreen – and that’s not in their FAQ.
For a simple design (2-4 layers, no extras) Seeedstudio is comparable to other PCB houses – even a tiny bit more expensive.
Where they shine is when it comes down to support and all those extra features like penalization, V-grooves etc. which the other houses just can’t offer or leave you in the cold when it comes down to getting help.
Do you have/had any good/bad experiences with Chinese PCB manufacturers? I’m happy to hear about it in the comments below!
Here it is, my latest baby, the goal I was aiming for since years (4 to be exact) – not only to get more TRAMs for my systems but also to break the insane price spiral developing in the last years on ePay and other places. >300$ for a TRAM is crazy. Do not pay that amount! Even $100 is too much.
Update: Final version finished! Click here or scroll down for more.
My first CPU TRAM called AM-B404 in reminiscence to the IMS-B404 which comes closest to its specs:
2MB low-power SRAM
2 LEDs showing the Transputers status (running and error)
Well, the original Inmos B404 had 2MB DRAM, too (and additional 32k SRAM) but was a Size-2 TRAM and LEDs weren’t available on any Inmos TRAM… and we all know how important LEDs are! 😉 Contrary to the IMS-B404, the AM-B404 is low-profile, SRAM-only, so the whole RAM is accessed at 3-cycles vs. the IMS-B404 4-cycle DRAM.
Using a 6-layer PCB and all-modern SMD parts (well, as modern as 5V parts can get) the power consumption is a bit lower, too. I’d say about 100mA for the whole Board (no Transputer of course). Finally, there’s an easy access solder-bridge on the backside to set the CPU clock (20/25MHz).
This is just the 1st prototype. After thorough testing, I will optimize its layout a tiny bit and give it the proper shape of a TRAM. When that’s done, we’ll see how I can make you a realistic price offer.
From Shenzen with love. The final PCB designes arrived and the first test went perfectly fine.
And here are the first 4 PCBs waiting to be finished with the Trough-Hole parts (i.e. Transputer Socket and TRAM Pins)… 100 solder-points in total… per TRAM. That’s quite a bit to solder :-/
Finally, here’s a short video showing the prototype AM-B404 in action (running Helios on my Inmos B020). The “exciting” thing is the blinking green LED which shows the CPUs activity. There’s even some brief red LED access (error) during boot-up which is triggered by Helios scanning the Transputer network.
The bright blue LED to the left is the T2i2c TRAM, so all TRAMs on the B020 are built by me now 😉
Ok, so you saw the thing in action and now you want to know more – maybe even build an interface yourself because you’re one of the other ~15 guys on this planet still fooling around with Transputers 😉
Good news! This time I created circuit diagram so you can actually make you own T2I2C – and that’s not enough: I’ve already laid out a TRAM-1 size circuit board using SMD parts of the C011 and 8574 making space for piggy-backing an Arduino Uno on top of that board.
But let’s start with the other details I mentioned the chapter before. I’m totally aware that there are many, many things to improve and optimize – and then there are probably even more I’m not aware of.
Here’s the how and why I did things they way I did:
For this first version of T2I2C I’m using an C011 in ‘mode 1’ – that means it is offering actually two 8-bit buses, one for receiving (input, I0-7)) and one for transmitting (output, Q0-7). Because it’s quick and easy I don’t use the I-bus and therefor grounded it.
This means there’s no way for the Arduino to talk to the Transputer side of things. But using an extra bus for input would mean using a second 8574 and obviously using another 4 wires on the ATMega.
The elegant solution to this is using the C011 in ‘mode-2’ – it then behaves like a C012 which means it provides a single butbidirectional 8-bit bus. So why didn’t I used mode-2 in the first-place?
Well, while mode-1 just requires 2 lines for data-control, mode-2 needs 4 lines and some more coding in the ATMega ‘firmware’ e.g. handling the 2 registers provided by a C012 – So yes, I was just lazy and wanted results quick. The next release will certainly use mode-2.
So what is that data-control you’ve mentioned? Using 2 converters (C011/8574) in a row there’s obviously a need for all parties to know when data has arrived and needs to be processed.
The C011 as well as the 8574 provide a pin which flags a “hey, we have something here!” signal (QValid in the C011, /INT in the 8574) . But in contrast to the 8574 the C011 also needs an “Ok, got the data, feel free to fetch the next one” – which is called “QAck”. So the ATMega controls the data-flow talking to the C011 and completely ignores the 8574 which makes it somewhat transparent.
The comms protocol of the C011 can be found in its data-sheet here. It’s all about reading, holding and releasing QValid/QAck in the right timing.
First I was using an external interrupt line on the ATMega connected to QValid because it’s so obvious. But somehow the results were flaky – sometimes the ATMega seemed do choke on some bytes which simply didn’t make it through(*). After some cursing and hair-ripping I decided to switch back to polling – again because I was lazy and wanted to get results 😉
Up to now polling QValid just works great, probably because the ATMega is pretty fast and I2C is pretty slow.
(*) Yes, of course I’ve read all the docs about interrupt-programing and its caveats (short routines, volatile vars etc…) didn’t help.
So what is actually going on in the ATMega running “Se Fiiiirmwarrre”? As mentioned in the previous chapter, I decided not to send a complete ‘bitmap’ of 128bytes each time an update occurs. Instead I created a simple command protocol, (currently) consisting of 3 bytes:
1st byte: If < 255 it’s the number of the Transputer data. If 255 (0xFF) command flag set.
2nd byte: If 1st-byte < 255, it’s the CPU-load in percent, else it’s acommand.
3rd byte: If 1st-byte < 255, it’s the Memory-load in percent.
This means a single Transputer information update only takes 3 bytes. A command like “clear the display” is just a single byte.
Of course there are downsides. Updating a complete display of 128 Transputer-loads means sending 384 bytes instead of 128 bytes needed for a bitmap (512 pixels, 2 bits each = 1024bits = 128bytes) – But OTOH you could enhance the firmware for just that case: One command initiates a bitmap-transfer and then you send the 128bytes of data. Mind the could, i.e. this command doesn’t exist yet.
What comes on top of the handling/processing is the calculations needed to be done by the ATMega. There’s a command telling the ATMega how to setup the panel according to columns. If there are less than 33 Transputers to be displayed, each Transputers gets its own line of 16 LEDs. To display 64 Transputers, it will be divided into 2 columns with 8 LED each. 96 Transputers have to get along with 5 LEDs and 128 can only use 4.
No matter how many Transputers have to be displayed, poor ATMega first has to calculate the percentage value into 16, 8, 5 or 4 LEDs, then decide into which column this value goes and finally handle the displaying itself – worst case a 128 times. All this could be circumvent with a bitmap-transfer, offloading all those calculations to the sender (a Transputer in this case). But I’m not sure if this is much cleverer…
The Arduino source (.ino file) is available here. I suggest you have the Arduino Software installed.
There’s still debugging code in the source, putting out info on Arduinos USB/Serial port.
These are the commands currently implemented (in decimal):
001 – 015 : Set display brightness (0..15)
031 – 034 : Set the columns to be displayed (1..4)
099 : Clear the panel display
100 : Toggle CPU-load-only vs. CPU & RAM load mode
Like you’ve seen in the video, there’s no real circuit board existing yet there wasn’t a real circuit board around back then. But I’ve created a board layout for a TRAM-1 containing an SMD C011 and 8574 which provides the space needed for a socket to plug in anArduino Nano (the small version of an Arduino Duemilanove) – Version 3.x to be precise. You have to use a V3.0 or higher if you want to use my ‘firmware’ out of the box! This is because the analogue pins (A0-A7) have been rotated in V3.x and up – if you plan to use an earlier version of the Nano, you have to adjust the i2c-pin definition in the firmware source.
Anyhow – Using an Arduino Nano is much more flexible -and cost saving- than putting everything incl. the ATMega on the board itself.
The socket is laid out to be “double-row”, so you can still plug wires right next the Arduinos pins – well, actually this is mandatory at least for connecting to the LED panel.
Currently (v1.0) these pins are used/defined by the firmware on Arduino:
Portd: 7, 6, 5 and 4 for connecting the LED panel
Analogue input pins 4 & 5 (SDA/SCL) for the I2C bus
Portd: Pin 2 connects to QVAL, Pin 3 to QACK on the C011
I tried to layout the board in such way that it could also be used as stand-alone, i.e. without being seated into a TRAM slot. Then you would have to provide the Links, 5V, GND, a 5MHz clock and Reset yourself via the alternative connector in the middle of the board, called “ALT_C” . There is still room left which I’ve used for a little breadboard section.
This design is to be considered v1.0 – still things to improve, especially a way to choose the link to be used if the board is actually plugged into a TRAM socket. v1.0 routes LinkIn/Out to the ALT_C socket which needs to be air-wired to the TRAM-pins… not nice but does its job.
If interested, you can download the Eagle CAD files here.
After nearly a year I was able to get a hand full of boards created and populated one using my brand new reflow oven (Reworked pizza oven) and voilá, here’s the T2i2c in flesh, naked:
…a bit more dressed (all parts place)…
…and finally fully dressed (Nano plugged in):
So the final question was: Will it actually work? Yes it did! I plugged it into slot 2 of my beloved BOZO, connected the LED panel and adjusted my Helios test-sources a bit, and tadaa:
The cool side-effect of this project is, that you can keep the USB cable connected to your host, while the T2i2c is actually running in a system, giving a perfect OS-link-sniffer for what’s going on in a Transputer setup.
Also, I reworked my Helios tools for checking the T2I2C functionality. Everthing is now in one single tool, i.e. test-pattern, clearing the panel or manually sending a command. Here’s the source as well as the executable… read the source header before using! You can crash your Helios system – you’ve been warned!
I won’t say the sky is the limit, but if the T2I2C-TRAM will be full-duplex in the next release (ie. C011 in Mode-2) driving an LED panel would be just one of many other uses this TRAM could fulfill.
Think of all the million things people did with their ATMega/Arduinos: LCD-Displays, SD-Card Interface, Ethernet and then some more. Ok, the speed of I2C will limit that somewhat (I already have made prerequisites in my ‘firmware’ to put I2C into 400kHz/kbps “fast mode”) but still a nice interface for connecting today-tech to your yester-tech.
Boy, my acronyms are really getting Star Wars’ish now… After the T2C64 and the T2A2, T2I2C sounds like a new protocol-robot but stands for “Transputer to I2C (Bus)”.
The I2C bus is a comparably slow serial bus – even to the Transputers 1990 standards – but in contrast to the Transputer OS-link interface I2C is still alive and kicking… even more since those simple-to-tinker-with controllers like ATMEGA or PIC made there way beneath your soldering gun.
As you might have guessed by now, the I2C bus wasn’t my primary intention to do this interface.
Since I started fooling around with Transputers I was thinking of an LED “CPU load display” like the one the lovely BeBox had… just bigger, a real manly Blinkenlights 😀 It should be at least capable of showing the load of up to 32 Transputers…
So I stumbled across a very nice bi-color 32×16 LED panel, which is quite easily controllable through one small ATMEGA controller.
By incident, a friend of mine gave me an surplus Arduino as a present and the decision was made. I’ve build & programmed ATMEL devices before, but Arduino plus breadboard can’t be beaten if you need to get something done quick.
It’s quite ststraightforward to connect the panel (can one say “display”? Nahh.) to the Arduino. To make things even more ‘bus-y’ the ATMEGA talks over just 4 wires to the panel over SPI bus – yet another serial bus, but luckily we don’t have to care about that fact as there’s a library handling this.
So after some days of coding, the “panel firmware” was done. The Arduino is happily talking to the panel over the SPI bus and listening on his I2C bus (another 4 wires) for commands and sends the calculated output to the panel.
Commands? Well, I was thinking about how to handle the data in an efficient manner. The most simple way would have been to have the Transputer sending the complete 32×16 ‘bitmap’. For a bi-color panel (2 bits per pixel) that would have been 1024bits/128bytes each time/interval.
To be more flexible I came up with a 3-byte command structure – for details see the next post.
Old guy speaking new language
So how to connect a Transputer to an IC2 ‘device’? We need two things for that:
The good ol’ C012/11 Link Adapter – turning Transputer links into an 8-bit parallel bus
An 8bit bus-to-I2C converter
We saw the C012/11 in some of my projects already, so piece of cake here. The 2nd converter needed some research and was easily found: A Philips/NXP PCF8574(A). So without control-lines the setup is quite simple:
Transputer → C012 → PCF8574 → Arduino → LED panel
After some hassle with handshaking (see next post “nitty gritty details”) I was able to send bytes to the display using MS-DOS’debug.exe to write bytes to the standard Transputer link IO ports (0x15x, you should know that by now ;-)) using a nice tool called ‘iskip.btl‘ from the INMOS ANSI-C Toolset (also available in my Transputer Toolkit). It simply shortcuts one Transputer link to another, e.g. Link 0 to Link 2. This relieves you from removing your Transputer and put jumper-wires into its socket… very nice and clean solution.
Doing it the right way
Well, while talking to devices through debug is definitely geeky, it’s not what I wanted as a result.
Having more than one Transputer running, watching its CPU and probably RAM load leads to the inevitable target of Helios. At least that’s the No.1 reason I created this interface… but with the command structure of the ‘firmware’ you’re obviously not bound to that OS, e.g. OCCAM programs could control the panel, too.
So the biggest development part was creating a clean way of taking to the panel while running Helios. For debugging and testing I wrote a simple command-line tool which opens a link on the Transputer you have the shell running on, then it sends what ever byte you added as parameter. Fine.
Next was version 2 of that tool, sending 32 fictional CPU-load values (0-100%), version 3 did the same adding RAM-load values.
Then it was time to do it the right way – so I dived into the sources of ‘network‘. network is the Helios tool for examining the Transputer (not IP!) network(s), so it shows the actual load in nice bar charts etc. – pretty much like top does on todays Unices.
While the sources of Helios are available, they seemed to be accumulated from different sources, dumped into an ISO image without caring for symbolic links etc. – in a sentence: They’re a mess.
After some days of try’n’error I was able to compile the sources of network. This made network2 (working name) possible which includes the new parameter ‘led’ followed by the number of the Transputer link to be used, eg. ‘network2 led 2‘ results in displaying the current CPU/RAM load of all Transputers in the network on the panels.
CPU-load is displayed by red LEDs, RAM-load uses green LEDs, overlapping is shown orange. As long as there are up to 32 Transputers each line represents one Transputer (using 16 LEDs). If there are >32 and <65 each line will be split into 2 columns (8 LEDs for each Transputer). This goes on for >64 and <97 (3 columns) and finally 4 columns for up to 128 Transputers – this isn’t very ‘readable’ anymore given there are only 4 LEDs left for one Transputer, but hey! It’s Blinkenlights, who cares!?
So without much further ado, here’s the prototype-beast in action:
For more details, thoughts, outlook and code see the next post.
This is a hack which is very similar to the DesperRAM. It was borne out of pure despair, so it’s neither elegant nor very clever – but it works and that’s what counts.
During the “BOZO resurrection“, I had one specific PAL under suspicion to not working correctly any more. That PAL was soldered (i.e. not socketed) onto the board in a very tight spot, so I wasn’t able to cut the pins as close as possible down on the board.
I know, there are special pliers which can somewhat around corners, but my trustworthy Knipex (The pliers maker in the world, full stop.) can’t. So I had to cut the pins right at the PALs package – easy and quick.
The downside is that this method leaves you with a leg-less IC… and if you then decide it might be useful to read-out that IC (like I did) it’s time to slap your forehead :-/
But not so fast, young Padawan. Despair has the advantage that it normally can’t get worse, so nothing to lose. Even you cut the legs off you still can spot the tiny remains leading into the package. So why not trying to replace the amputated legs with artificial limbs!?
My initial thought was soldering new pins to the package, but the remaining connection is way too small to allow anything to be soldered to it but a human hair.
So I used a socket, turned upside-down, slightly bent the legs inward, squeezed the PAL between the sockets legs and carefully soldered the pins to the case-connectors. Finally I put small bits of wire into the sockets empty holes to create new pins to connect the whole thing to my GAL-programmer. Voilá: FrankenPAL
Yes, it looks horrible and I was quite sure that this doesn’t work but it just costed me 10 minutes, so what the heck, let’s try read-out that beast.
What should I say? It worked right on the first try… So never despair as long as you have a working solder iron 😉
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 price you have to pay if you’re into real men’s hardware:
Being (falsely) identified as “old crap”, some cool things end up in the dumpsters… or worse. Being tossed around in some storage for years, probably stacked with other cards and boards, it might happen that some traces on the outer layers got badly scratched, thus making the board/card non-working. Here’s how I try to fix scartched traces… and most of the times it works:
First make sure that the circuit path (trace) is really broken – I just may look like, but isn’t.
To do this you need a volt-meter. Follow the suspected trace in both directions until you find a pin or through-hole it is connected to. Use these two points to test if the trace is still connected.
Ok, damn, it’s broken 🙁 You need three things:
A sharp knife or scalpel
Adhesive tape (Scotch, Tesa or whatever it’s called in your corner of the world)
Conductive (silver) lacquer
Conductive-what? Conductive lacquer is actually a cool thing to play with… but be prepared: It’s not cheap (about 9-10 Euros). It comes in tiny bottles or as a pen, which is even more expensive (20+ Euros). The bottles look like this (lacquer and diluter):
Ok, the process is quite simple:
Use the knife to scratch-off some of the coating lacquer on both ends where the trace was “cut” until you see some copper shining through.
Check with your volt-meter that you actually have contact with one end and e.g. a pin on the other end of the trace. Do this for both “halves” of the cut trace.
Mask the place you’re going to ‘heal’ with your adhesive tape – this prevents the conductive lacquer to run all over your board.
Apply the conductive silver lacquer onto the spot you’ve just masked and let it dry (read the manual that came with the lacquer – yeah it’s unmanly but nobody will see you ;-))
Using your volt-meter, check again. This time from both ends of the complete trace.
If you’ve done everything right, the trace should work again – and so does your card/board! Yay!
Here’s how my badly scatched MiroHIGHRISC looks like in certain places – can you spot the little silver dot?
Final hit: Some lacquers are quite thin on silver (blame the manufacturer) so after some days the spot you just fixed might become unreliable. In this case you might repeat the procedure to get more silver to that spot.