Category Archives: DIY Projects

DIY Projekts Hardware

DIY Projects, My own TRAMs, T2I2C

The T2i2c

Leave a comment

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 (Sure Electronics DP14211 – it seems in 2022 that company was either sold or folded), which is quite easily controllable through one small ATMEGA controller.

LEDPanel

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.

Blinkenlights

It’s quite straightforward 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:

  1. The good ol’ C012/11 Link Adapter – turning Transputer links into an 8-bit parallel bus
  2. 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 (0x150++, 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.

DIY Projects, My own TRAMs, T2I2C

T2I2C – The nitty-gritty details

Leave a comment

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:

Oneway

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.

Handshaking

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.

Achtung! Kommando!

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

Hardware

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

board

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:

T2i2c_naked

…a bit more dressed (all parts place)…

T2i2c_dressed

…and finally fully dressed (Nano plugged in):

T2i2c_fullyDressed

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:

T2i2c

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!

Outlook

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.

AM-B404, DIY Projects, My own TRAMs

The AM-B404

Leave a comment

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

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

AMB404-Front-small

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

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

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

AMB404-Back-small

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

UPDATE:

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

AM-B404stack

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

First4

Video

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

Want one?

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

Can I have the schematics?

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

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

DIY Projects, DIY Transputer interfacing, QFP Adapter

QFP Adapter

Leave a comment

Again, a man had to do, what a man has to do…
My good friend Udo gave me some Transputers in QFP package, most of them previously used and unsoldered from some PCB. Nobody knows, if they are still OK or already braindead – so I needed a QFP Adapter.

As fate goes, some fine day I stumbled across a nice 100pin QFP burn-in socket from Yamaichi on ePay. Yamaichi is “the other company” producing burn-in sockets besides 3M with their Textool brand range.
Normally those sockets are insanely expensive (100US$++) but this was a lucky buy – well for the “price” that it was an EOL model… for many years. This means no documentation available. But the very kind sales team of Yamaichi Germany (Vielen Dank Frau Howe!) was able to dig out a hand drawn blueprint of this very socket, model #IC51-1004-139.
This valuable Information at hand I was able to create my own Eagle CAD device for this Socket – not an easy task as most measures were not directly given but had to be calculated using other documented distances. After some hours I ended up with two PCBs, one for the burn-in socket which again will be mounted onto a PGA-Pin adapter PCB.
When done it was time for another “first”: Try the DirtCheapPCBs service. 2 Layers, 10x10cm PCB, 10 pieces for just US$25 (incl. shipping) – almost cheaper than doing it yourself.
After two and a half weeks I had two stacks of 10 PCBs each. Anxiously I tried if the socket with its tiiiiiiny pins will fit…. and… it… did! Hooray!! I didn’t expected that but everything fit perfectly, even the silkscreen. Soldering the 0.025″ pitch was another story…

But see for your self. Upper left corner you see the burn-in socket already soldered. At the right edge, the lower PCB it waiting to get 84 Pins soldered for the PGA socket… and another 100 to connect to the upper PCB.

QFPAdaptor

Feel free to contact me, if it happen to be that you also found an IC51-1004-139 socket and need the Eagle lib or even the PCB for it… I have 9 of them left 😉

DIY Projects, T2shield

T2shield – Arduino to Transputers

Leave a comment

[The T2shield is currently a work-in-progress project – the first alpha hardware is operating but lots of coding lies ahead!!]

The idea for the T2shield was born when I thought about getting recent peripherals like SD-cards, Ethernet, displays etc. into a Transputer network.
Sure, there are the old, original TRAMs like the STM228 SCSI controller, the B431 Ethernet TRAM or quite some choice of graphics controllers. But they’re all rare like chicken teeth these days which means unaffordable when they rarely pop up on ePay.
Rebuilding them is also a no-no given the obsolete parts they’ve used… and to be honest: A noisy, vintage SCSI-1 drive isn’t what I thought of.
So after some time I came to the conclusion it will be the easiest and cheapest way to re-use what you can buy for a few bucks from China these days: Arduino shields.
As a lucky incident such a shield perfectly fits onto a size-2 TRAM – Yay!

Without much further ado, here is the T2shield (v0.1) with a shield loosely put on top to get an idea…

t2shield

Arduino shields mainly use the SPI bus for data transfer. With its 10+Mbps SPI is much faster than e.g. I²C (which I used for my T2I2C TRAM) and can cope with fast(er) peripherals.
But this also ruled out a slow IMSC011/12 link-adapter design like the one used on the T2I2C. Also there’s no of-the-shelve SPI master controller to simply glue a bus to it.
So the design turned out much more advanced this time:

  • A 16bit Transputer (with 64KB SRAM) handles the high OS-link speeds as well as the ‘glue’ like File/Ethernet handling.
  • A comparably big CPLD (100pins, 128 marcocells) implements the SPI master controller as well as handles the T2xx memory- and interrupt-handling.
  • All Arduino digital-pins and nearly all analog-pins are connected to the CPLD to adjust to any available shield.

Also this new TRAM design is a “first” for me in many aspects:

  • 1st usage of a 16-bit T2xx Transputer (vs. 32bit)
  • 1st serious utilization of a CPLD (besides the baby-steps taken with the T2A2)
  • 1st Size-2 TRAM

Initial status

Transputer

[wppb progress =100 option=green] 100% done

A T222 Transputer is -after fixing some stupid errors- happily running and has control over his external RAM.
Here’s the first sign of life by RSPY (a brilliant ispy‘ish tool of Michael I really need to write a post about soon):

# Part rt Link0 Link1 Link2 Link3 RAM@cycle
0 T2   20 HOST  ...   ...   ...   4K@1,56K@2|

That means: A T2xx @ 20mbps linkspeed is connected to the host (PC) and has 4K internal and 56K external RAM… wait a second! just 56K? Yes, that’s because the internal 4K overlaps and RSPY leaves the up-most 4K untouched as most peripherals are mapped there and poking there could create unwanted effects…

CPLD

[wppb progress =10 option=yellow] 10% done

All basic Transputer controls are in place, LEDs are controlled by the CPLD

TODO: Implement the SPI master in VHDL. That’s THE biggest challenge for me being a total VHDL noob. Again, I wouldn’t got this far already without the tremendous help from Michael Brüstle, my VHDL Jedi-Master.

Drivers

[wppb progress =100 option=red] 0% done

Write the (Helios) driver to handle file and/or network access. This should be (optimistically) be compatible to existing file- or Ethernet ‘servers’. This will probably be the most time consuming task.

Progress?

This is (also) the first time I’m posting about a project which is not finished. So I will keep you posted about the progress with new posts in this “T2shield” chapter of this wonderful little page.
If you do own

  • a Transputer network
  • a free size-2 TRAM slot
  • a T2xx Transputer
  • some VHDL/Occam/Helios driver skills & knowledge

shoot me a mail and I might provide you a T2shield to join the development.

That said, here’s a first little sign of life:
The Transputer writes numbers to a mem-mapped address (0xFC00) while the CPLD reads the lowest 2 bits and displays them by 2 of the 3 LEDs on the T2shield

Apple II, DIY Projects, T2A2

T2A2 for everyone

5 Comments
While the guys over at OpenApple were speculating in their latest podcast what a Transputer actually is… well, there are about a 100 links and ways on this page to find out – but hey… just click here – and of course that box saying search would do great wonders, too.

But seriously, my bad: I should have mentioned that this page your looking at is really just one post of many… so make sure you start at a Chapter (Menu. At the Top. ↑…yes up there) and read them in the order you’d read a book 😉

After quite some years (and a handful Apple II users requests) I felt the urge to finally put the T2A2 prototype (read that post to get a more general understanding) into a real expansion card… and here it is: Say “Hello!” to the T2A2 version 1.1!

It came a long way…

t2a2_evolution

…in more detail:

t2a2_front

As you can see, the final T2A2 is much smaller than the prototype (which used an 8bit Baby one-for-all PCB) and offers many additional features

  • 2 size-1 TRAM slots (or one size-2) – double the processing power!
  • Low-power, low-profile parts used where possible (3.3V CPLD, HCT logic)
  • External Transputer-link available as edge connector – extend your network to “near infinitum“
  • Jumpers for LinkSpeed and optional power to the Transputer-link connector
  • Fully buffered to be a good Apple II bus citizen
  • Works in any slot set to “your card”

Beyond this, everything said about the prototype is still true.

Most important:

a) It’s not tested in the ][ or ][+. I simply don’t own one of those.
Update: One owner reported it’s perfectly working in his IIe!
b) The T2A2 won’t instantly speed up any of your Apple II[e/gs] applications.

It’s more like a co-processor attached to it. And even then, you’ll need something really calculation-intensive to justify the time you’ll loose due to communication between the Apple and the Transputer. A single square-root for example wouldn’t make much sense – but having a complex algorithm (like the Mandelbrot fractal in my demo)  does absolutely make sense, as you just pass the parameters to the Transputer and let him do the sweating.

But on the other hand, FPU cards like the Innovative Systems FPE (using an M68881) or my even faster clone “NumberCruncher Reloaded” did just send instruction by instruction. So I somehow fancy the idea writing a SANE driver for GS/OS to integrate the T2A2 more transparently.

Want your own T2A2?

So now you’re keen to get one yourself? Please check this list first:

  • Do you have a TRAM already? (*)
  • You are aware that there’s no real software (yet) besides my little Mandelbrot demo?
  • You are keen to program something yourself – or are fine to wait until somebody else did?

While the Apple II side of coding is pretty easy, you have to get a grip about the Transputer development, too. That includes a DOS/Windows (<=XP) setup and some knowledge of C and/or OCCAM. I’ve created a little Transputer “SDK”, namely a VirtualBox image running DOS.

Plenty of Dev-Docs are available here.  
I suggest using the INMOS cross-compilers for C or OCCAM. An alternative C compiler came from LSC, which might suit you more if you don’t like the INMOS stuff.

Ok, so you’re still with me… so I have the first batch of 20 T2A2 PCBs ready which I will populate on-demand, and for 40€ (plus shipping) one of them can be yours.
(*) I might be able to offer you a TRAM, too. The price depends on available model, RAM size and CPU used.

⇒ drop me a mail tonobody likes SPAM
(Sorry, you have to type that into your mail-client – nobody likes SPAM, so do I)

Also check the T2A2 forum for current availability, shipping procedure and built status.

Some more technical details

Here’s a T2A2 with a size-1 TRAM installed in Slot-0:

t2a2_with_tram

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.

DIY Transputer interfacing, Hardware

RS422 Differential Adapter

Leave a comment

This is a Q’n’D but handy design which I was planning for a long time, but you know how things go… A differential adapter is a simple device which translates a single signal/data line in one positive and one negative line, i.e. one is carrying the inverted signal of the other. This is also known as RS422… But why do we need such thing?

Well, differential signals are/were quite common in the world of Transputing to deliver OS-link signals over longer distances (<10m/30ft) or noisy environments and good examples are systems from Parsytec, the AVM-T1, ISA interfaces like the HEMA TA2 or even some custom measure/data-logging solutions.

So to connect to such systems using a non-RS422 (i.e TTL) interface card, e.g. the INMOS B004/008 or the Gerlach-Card you’ll need such an differential adapter.

Technical data

A very simple design on a 5x5cm PCB. All done in trough-hole technology (THT) to keep this a simple DIY project.
It all based around two AM26LS32 receivers and one AM26LS31 transceiver, some resistors and an unavoidable LED  😉

Usage is very simple, too. Just connect the TTL signals to the standard 2×5 shrouded PCB header connector and RS422 signals are provided on the 2×7 header connector on the opposite side of the PCB.
The TTL connector is the same as the one used on the Gerlach card or my T2A2 Apple II interface:

As you can see, pins 9 & 10 can provide 5V to the PCB so that no external power-supply is needed.
If you connect a system not able to provide power to the differential adapter there’s also a 2pin connector provided on the PCB itself.

The RS422-side of the adapter has this pin-layout:

Nice-to-know: You could also use this adapter to simply invert signals. For example if you need a positive ERR signal instead of the not’ed, you simply take the positive pin (i.e. even pin-number 6 in this case) of the 2×7 connector (ignoring the negative).
Mind there’s no power supply pin on that side and pins 11/12 are not connected.

Apple 68k, DIY Projects

Fixing the Quadra 950 power-supply

4 Comments

One day the power-supply of my beloved Quadra went “bzzzzzt-poof” (sparks flying, smoke rising).
First I was desperate… try to find a Quadra 950 power-supply these days. And if you find one, it’ll cost you the same you’d pay for a complete system… and then you’re still not sure, if it won’t go poof very soon, too.

Then I thought: Hey, why don’t replace the whole thing by something more modern, much cheaper and smaller?!
It’s already been proven with other Mac systems that using a standard PC power-supply (PSU for short) is feasible, so why should a Quadra 950 power-supply be much different?
As there are some descriptions out there – mainly for those “10-pin connectors” (Mac IIcx, vx or PMac family) I thought it might be helpful to have a step-by-step how-to with lots of photos…

We’re interuppting this transmission for a stern word of warning:

Working on/in power supplies is dangerous. I take no responsibility for any damages, injuries or fatal strokes! If you’re unsure if you can do this hack, just don’t do it!

First (obviously), unplug the unit. Leave it unplugged for 15 minutes or so. In most PSUs there are bleeder resistors that will bleed down the stored voltages inside over time BUT THERE ARE NO GUARANTEES!!

When you open the unit, understand that there are two hazards:

  1. Stored high voltage (200V or so) on the “input” side of the unit.
  2. Stored high currents (tens of amps) on the “output” side of the unit.

Either 1 or 2 can be deadly. If you die, it’s social darwinism. You have been warned. 

Dismantle

So for the initial try I pulled a cheap ATX power-supply out of my junk-pile (wife-speak for “basement”) and put it next to the original, humongous Supplyzilla created by Apple. Ok, that should fit in 😉

Opening Supplyzilla is another thing. About 10 screws, a cut in my finger and 30 mins of cursing later I found the reason why I wasn’t able to get the two case-parts apart: Don’t forget to unplug the fan cable :-/
After this you can fold-open the case and have a good view onto huge capacitors, lots of dirt and 1990s tech…

There are two PCBs each mounted to a side of the case. Unscrew and separate them – because mine was dead anyhow (and I wasn’t planning to repair it) separation was easy. Snip!
I wasn’t able to get the external cable-harness leading out of the case. So this was a 2nd snip-snap… I planned to use the original PC cables anyhow. You can reuse the original plug or use the one from the ATX PSU (if it’s a 24pin one).

Here they are… rest in pieces 😛

Fitting room

Next up: The first fitting… even still in its enclosure it would nearly fit two times.
BTW: I like the sticker saying in German “VORSICHT! GEFAHRENZONE!” (Caution, danger-zone!) That’s soooo 80’s Top-Gun 😀

Because we have to modify the ATX PSU, it had to be stripped down, too. Compared to Supplyzilla it’s pretty deserted in there…
Yes, it’s a cheapo one looking at the passive PFC and could have be designed much better, but for the 1st try it’s OK.

2nd fitting making sure all heatsinks are well placed into the airflow, cables close to outlets (the fan will be replaced by a big one, of course).

You will be assimilated…

Next step was a meditational one. Loosening all 24 pins clamped into the ATX plug. I used the “cut staple method”. One to the left, one to the right, push them in, pull the cable… repeat.
Configuration of the Q950 plug will be described further down. I suggest to do this as one of the last steps. For now just tape all loosened pins together to save them from bending.

Having the preparations done, it was on to the workshop drilling some holes and cutting screw threads (optional but nicer than holes and nuts)…

…to have a proper seating for the stand-offs. We don’t want the PCB touch the case, don’t we?

All fits nicely. The PFC screwed to the case like in its original habitat – ugly, but will do for now.

The noise filter was directly soldered to the power-out plug. Again ugly, unprofessional but OK for a try.

So the filter went into the case and unneeded cables like 3V, were shortended and kept inside the power-supply.

Connecting the dots

Now for the plug-configuration. All documentation I’ve found on the web were wrong – dead-wrong, even leading to drama…
So this is the correct pinout for Quadra 900/950’s:

Having this, the mapping from the “Mac-plug” to your ATX-PSUs cables is pretty straightforward:

  • Red (5 volts) stays red
  • Black (Ground) stays black
  • Yellow (+12V) also stays that way, too
  • Orange (-12) is blue in your ATX-PSU
  • Blue (5V standby) is the violet cable in ATX-PSUs
  • White is mostly unused on ATX-PSUs – we will recycle that cable for PFW…

As for 5V/GND wires don’t worry if your ATX PSU doesn’t offer enough of them (10 each). Mine just had five 5V wires, so I populated every 2nd slot in the plug.

Killing me softly

Finally the ‘circuit’ for using the Quadras soft-power feature had to be implemented – a simple rocker-switch connecting the green (Pwr_on) wire to GND would do, but this is just so below the mighty Quadras grandeur.
I opted for the very simple, more reasonable solution using a NPN-resistor… even a 74LS04 is an overkill in this case. Just my 2ct, though.

This is the schematic, nothing spectacular:

Yeah, the symbols for the resistors are European, that’s because… well, I am European 😉 As for the transistor use any NPN you can get easily. E.g. BC547 or BC549 (again, European numbering scheme, you’ll have to figure out JEDEC names if needed).

And here’s the PSU before its going to be closed and put back into my Q950.
Pink box: The soft-power ‘circuit’ (yeah, I was too lazy to create a PCB for a transistor and two resistors).
Green box: Unneeded cables been cut (3V, extra 12V, pwr_good).

Everything else was routed outside (All 5V/GND, +12V, -12V, 5V_tickle and the white cable was cut and reused for PFW.

Hints: DON’T use the GND from fan-connectors! They might be modulated to control the fan speed and other wired things. Better use one of the e.g. unused 12V cable-pairs.
Check everything before closing the case – Again CAUTION!!! High voltage. You touch, you die!!

Woo-hoo! Lady Quadra works again!

Outlook

That was a cheap fix… about $5 in parts if you have to buy a used ATX PSU. To make things easier and look more professional I plan to design a small PCB which fits right where one of the original PSU PCBs sat, providing the 4 drive connectors (4-pin) so that you can keep using the original drive power-cables. Also I plan to add:

  • the soft-power circuit
  • a temperature fan speed controller
  • (optional) internal 5¼” power-connectors for solder-free connection to the external 4pin connectors.
Atari, DIY Projects, DIY Transputer interfacing

ATW800 Farmcard

4 Comments

Sometimes a man has to do what a man has to do 😉 And this time it got to be an ATW800 Farmcard.
A what? ATW800 stands for ATARI Transputer Workstation – basically an Atari ST and a Transputer subsystem in a tower case (just about 250 were build and sold) and looks like this:

Atw front.jpg

Background

Even I still do not own an ATARI Transputer Workstation (yet), I “know” it from the very first presentation when working at the 1988 CeBIT Atari booth back then. The initial demo version used a standard Atari Mega-ST connected to a blunt Atari-PC3 case which housed the Transputer stuff… and the whole thing ran the Helios Operation System about which you can read quite a lot in this GeekDot chapter. Well, actually that was no wonder given that Perihelion Ltd. was not only the creator of Helios but also the birthplace of the ATW800 (Called ABAQ in the early stages).

The final version (the one in the tower case) used so-called Farmcards to expand the number of Transputers available to the system. A Farmcard featured 4 fixed Transputers (T425 or T800) with 1MB of RAM each. Here’s a piccy (click to zoom):

That might be plenty back then, but even in those days progress was made quickly and INMOS presented their TRAM Modules at nearly the same time… and these give you so much more flexibility and also save space. Actually, if you closely read the marketing material from Perihelion you will spot the announcement of a TRAM Farmcard. It just never made it…

I did it my way…

So it was just a question of time until I start to design a TRAM-Farmcard. After many years of unsuccessfully hunting an ATW which is for sale, I at least met shock__ (atari-home.de forum) a lucky ATW800 owner who was happy to help. So using the available documentation and the data provided by shock__ I created this:

Features

So what gives? Well, first of all, there aren’t any original Farmcards available anymore. Even if there were, they’re pretty limited. One Megabyte is enough for a computing slave using pure OCCAM but if you’re using Helios, 300k will already ate up by its core demons. Then there’s space for just 4 Transputers, not many given the size of the card.
That said here’s what this new Farmcard provides:

  • 8 TRAM slots. Can be used for anything. Computing, SCSI, Ethernet or graphics TRAMs. Be it size-1 to 8. There were many, many cool modules available. Today you can at least use my AM-B404 TRAM, a super-fast 2MB size-1 compute TRAM.
    This would mean twice the CPU oomp, and double the RAM.
  • Freely programmable Altera EPM7032/64 CPLD. It will implement Perihelions diagnostic-bus, meant for controlling each Transputer separately. Updates can be done in-field.
  • An external RS422-link. Using differential transceivers (26LS31/32) one can connect external Transputer networks over a distance up to 20-30 meters (vs. 30cm in pure TTL).
  • 4 layer PCB design giving stable power distribution throughout the board. Still, simple layout, easy to patch and only through-hole parts being used to make building as easy as possible.
  • 2 LEDs. Just say’in…

Because of the added Transputer-Slots the network topology looks a bit different than is used to be on the original Farmcard.
This is the “old one”, a simple square, each Transputer has two free links being available at the edge connectors J1-J8:

And this is how the 8 slots are connected:

Now each Transputer has just one link connected to the edge-connectors. Slot 7 uses link-3 to connect to the optional external RS422 connector.

Free as free beer!

Because there are probably only two handful of ATW800 owners out there, I made the schematics freely available here under the GPL license. But to make things clear:
This is untested stuff! The card is huge. It is not cheap to have it manufactured. The best price for 10 PCBs I was able to find was about $250.

The hard part

While the cards design was pretty straightforward the “firmware” of the CPLD will be a different beast. As said, Perihelion used a proprietary bus called “diagnostic bus” (DBus) – a two wire bus used to address all or just a single Transputer in a network to either reset or put him into the so-called analyze-state to do some post-mortem debugging. Pretty advanced stuff given that standard Transputer networks simply used a global reset.

Luckily the DBus is documented in the (short) Farmcard Manual (p.8-10). So we have a rough idea what’s going to be expected:

The DBus is daisy-chained through all Farmcards on the slots as well as on the edge-connectors J9 & J10 (in/out). Because I hadn’t had an original Farmcard at hand I wasn’t sure which of these signals are needed to be controlled by the CPLD. So I connected them all using all available I/O ports.  This is the pinout:

pin function
04 5_ANA
05 1_RES
06 1_ANA
08 LED1 (Error)
09 L_IN
11 L_OUT
12 FAST_IN
14 FAST_OUT
16 SLOW_IN
17 SLOW_OUT
18 GLOBAL_RESET_IN
19 GLOBAL_RESET_OUT
20 T_ERR_IN
21 T_ERR_OUT
24 LED2 (Opt)
25 4_ANA
26 4_RES
27 2_ANA
28 2_RES
29 3_ANA
31 3_RES
33 7_ANA
34 7_RES
36 6_ANA
37 6_RES
39 0_ANA
40 0_RES
41 5_RES

So, this is it for now… it’s an ongoing project and it depends on you how fast progress will be made.

  • Do you own an ATW800? We’re looking for brave testers!
  • Are you a VHDL hero? Grab the manual and do your thing!
  • Transputer nut? Feel free to check the schematic… I’m not swearing it’s 100% bug-free.

To be continued…

DIY Projects, Systems

The final Cube – Snow white coffin

5 Comments

This is it. Hooray! The final Cube as I always wanted it to be.
It just took me about 2 years of planning, blood, sweat & tears, huffing and puffing. Many tries to find the right parts, plenty materials evaluated always trying to keep the budget low.

The sleeping beauty – yeah, it’s a bit snow white coffin’ish

Meet the ancestors

You might have followed the route I took for quite some time now:
It began with the ‘Tower of Power‘, basically a component carrier with a power-supply.
After some years it was replaced by the first Cube.  Well, yes, while it had a somewhat cubic’ish case, is still was just a dull standard industrial case. Not really what I imagined how my computer should look.

Form follows function

If you’ve read some posts here on GeekDot, you might already got the impression that I’m a sucker for design. Well, not that kind of a surprise, given I studied design some decades ago 🙄
I’m also heavily influenced by the works and philosophy of Dieter Rams (mainly for BRAUN) and Hartmut Esslinger (of frog design), of which you might not have heard about, but you know their designs for sure…
So I fell in love with the Parsytec x’plorer and other iconic computer designs like these ‘cubistic’ examples:

Yes, I am a strong believer that a computer, while basically being a rather boring calculation tool, should look good, timeless and might give you an idea of its innards are actually doing something.
We could probably go on forever, defining how a well designed computer should look like. But like the Romans used to say: “non potest argui per gustum” (You can’t argue about taste)…
Let’s say, I’m probably not totally off, given that most designs I like are also on display at the Museum Of Modern Art 😉

So mentioning the Final Cubes design, it’s  case we’re talking about: If you’re really picky, then yes, the Final Cube is actually two cubes:

The carrier-cage on the top which I tried to keep simplistic and invisible to give the PCBs as much stage as possible. The user should be able to see the many, shining CPUs. So 10x10mm aluminum square tubes are connected by 3D-printed frame-corners to provide maximum view onto the technology.
For protection but also as a design statement and tribute to Rams’/Gugelots famous ‘snow white’s coffin‘ everything is surrounded by a 30x30x30cm translucent acrylic cube.

The white base actually isn’t cubical at all being much wider than tall. Nevertheless, its design should be even more simplistic and cautious to serve three purposes:

  • Give the computing-parts above it a proper podium
  • House the LED array which provides the fitting aura
  • …and finally house all the tech the user should not care about

With quite a big fan between the base and the top both work like a chimney (following the convection) sucking the air from the bottom and blowing it through 169 holes in the top plate of the cube.
Here’s an idea out how it looks “working”:

When one thing comes to another

The parts of which the Final Cube is build from aren’t all created this year. Actually only the case and the cage-frame are from 2019 – all other parts were designed by me some years before.

The core of everything are TRAMs – these are Transputer computing modules defined by Inmos back in 1990. The specific TRAMs used are my own AM-B404, each containing a 25MHz T800 and 2MB of  fast SRAM.

Finest home-made TRAMs

16 of these TRAMs are placed onto an Inmos B012 (or compatible) carrier board. And up to 10 of these carriers can be put into the Cubes carrier-frame creating the cluster.

Under the hood

Below the carrier-frame, in the base, you can spot a 32×16 LED panel. This one is actually from 2012 when I designed the T2i2c, an i2c-bus to Transputer TRAM.

Yes, that’s an Arduino Micro on top of a TRAM

So it was a natural move to make the T2i2c into a system-controller. It does not only controls the LEDs displaying the current load of all Transputers, but also using a photo-diode to set the display brightness as well as measuring the internal temperature and overall power consumption.

Here’s an overview of the base internals:

I know, the venting holes are not pretty – but they do their job and prevent you from accidentally touching the power-supply.

The red arrow points to the T2i2c being connected to the LED panel to the left as well as to a hall-sensor (blue arrow) measuring the power consumption, a temperature sensor (orange) and a photo-diode (green).
You cannot overlook the 22cm fan in the back sucking air from the bottom along the power-supply and pushing it up to the Transputers above to keep them cool.

And their power consumption is not to be trivialized. In average a single Transputer TRAM requires is about 1 ampere… so the math is easy. This means the quest for a powerful power-supply was on.
After some months I found what used to be the power-supply meant for a 3Com Corebuilder 7000: The mighty 3C37010A. A whopping 90A@5V should be OK for starters… here’s the fitting procedure:

Mooooore powerrrrrrr, Igor! You touch, you die!

The back of the medal…

The backside did not change compared to the previous Cube back  – well besides the supply-cabling which now goes down into the base instead to the side of the cage.


In consequence you’ll spot the power-connector there. No switch though  – still thinking about that… as well as a nicer cable-management for the link-cable which is normally connected to the host.

Next up would be a host matching the look. Mhhhh….