Can all registered uses please login, even just for a few minutes..
It helps build a picture where our "good traffic" is coming from..
Thanks :)

Supercomputing adventures with a MegaST/4

General discussions or ideas about hardware.
User avatar
dml
Posts: 876
Joined: Wed Nov 15, 2017 10:11 pm

Re: Supercomputing adventures with a MegaST/4

Post by dml »

Forgot to mention JP1/JP2 - these are close to one of two unpopulated D-SUB15 connectors near the front of the board (the front panel where the handles are).

These are marked I/F : MTH which looks like maybe a way to switch some signals from the VME to the D-SUBs. In any case, those connectors are not on my board so probably can be left alone.
User avatar
dml
Posts: 876
Joined: Wed Nov 15, 2017 10:11 pm

Re: Supercomputing adventures with a MegaST/4

Post by dml »

First stage of the de-confuscation...

I spent a full ice age trying to figure out what the DM1/DM2/DM3 ICs were doing since I first got the board. I could follow them to the VME P2 connector at multiple points but some could also be followed back to *some* of the link-in pins on *some* of the TRAM slots. But the mapping seemed patchy.

My initial searching didn't produce any datasheets and a few produced datasheets which were linked from a description that were not the part in the datasheet :)

One of the possibles I ran across was a multiplexer - which would make sense if some of the links were backplane-configurable by control signals. i.e. the routing is on the board but switchable by the backplane. However there are enough pins on the backplane to just do that on the backplane so it seemed like overcomplicating things. Also my DMM probing results did not match a multiplexer.

The next near-match was a tristate buffer which is where I started to get into the weeds because it actually matched pretty well.

The middle pins 5/6 were tied to GND/VCC and the rest looked like in-out pairs, which would suggest a quad buffer. The in-out pairing was also suggested by both odd and even pins going to the connector while only odd pins go to the TRAMs. Still strange though.

I tried some tests to drive them as buffers from the connector with a pullup resistor but the 'output' did not change, tested in either direction. Probing the pins just yielded weird results (0.16v in both directions on most pins).

At some point I gave up and took one off the board and tested it directly. With this and a bit more searching I got an answer.

These are a variation on a 74S1056 bus-terminating schottky diode array, They have a different internal configuration though which explains why the middle pins were GND/5V and sent me in the wrong direction.

SN74S1057SC.png
SN74S1057SC.png (120.88 KiB) Viewed 53 times

I added diodes to a pinout for the '1056 showing the internal layout of the '1057.

Since these are for protection on the VME they don't matter for 99% of what I'm doing and can ignore them for the topology. Which is nice.
User avatar
dml
Posts: 876
Joined: Wed Nov 15, 2017 10:11 pm

Re: Supercomputing adventures with a MegaST/4

Post by dml »

Next stage of de-obfuscation is the discovery of internally hardwired links between some of the Transputer slots.

ctx002-intra-links.jpg
ctx002-intra-links.jpg (599.67 KiB) Viewed 34 times

The yellow paths show directly-tied slot connections tying two Transputers together on LINK3 on a single 'row', without jumpers or buffers. These are fixed topology, not configurable.

The magenta paths show additional direct-connections between 'rows' - but routed via jumpers JP3-JP8. These jumpers have two positions for each side (RX/TX) of the link. One position connects two rows together, the other 'BUS' position maps the links onto the VME bus.

For the non-bus connection, the actual link being tied is indicated on the jumper.

e.g. the jumper is named 'L50' and the non-bus position is 'L61' which ties TRAM slot 5, link #0 -> TRAM slot 6, link #1.

This reveals an internal topology shaped like a 'comb' or spine. 4 rows of 2, with the rows being fixed and the spine being jumper-configurable, on the right side of the board.
User avatar
dml
Posts: 876
Joined: Wed Nov 15, 2017 10:11 pm

Re: Supercomputing adventures with a MegaST/4

Post by dml »

The full set of probe samples have been added to this diagram. It shows a subset (incomplete) of each type of signal/connection on the board and is what I used to make predictions about how the rest might fill out, especially for all the Transputer links mapped to the connector.

ctx002-probe-samples.jpg
ctx002-probe-samples.jpg (647.1 KiB) Viewed 15 times

The yellow & magenta paths relate to the previous diagram (but are not fully shown in this version).

The cyan paths show Transputer link INPUTS arriving directly from the VME P2 connector onto the TRAM slots without any logic in between.

The red paths are less direct, with a few hops - these are Transputer link OUTPUTS to the VME P2 connector. Each one passes through a 74244 buffer and 33R resistor. It was not obvious initially but as more samples were taken it became clear all of those resistors are carrying link outputs to the VME.

The white paths are the most interesting. These involve the PAL chip and where I spent most of my time live-testing signals to see what it was doing. One of these signals is the only case I found to be mapped onto the backplane-shared VME P1 connector.
User avatar
dml
Posts: 876
Joined: Wed Nov 15, 2017 10:11 pm

Re: Supercomputing adventures with a MegaST/4

Post by dml »

Each Transputer (TRAM module) has a clock input, 4x serial link pairs (RX/TX) and 3 control signals.

The control signals are basically RESET, ERROR (output), ANALYSE (input).

The white paths through the PAL appear to map just three signals onto two connectors - I could find no other paths between these. One of those signals is to the shared connector (for VME P1, the signal gets tied to the same pin on all cards on the backplane) and is the only signal I found routed there.

I suspected this would be the RESET line. The other two are most likely ERROR/ANALYSE.

I then checked connections between the PAL and the TRAM slots and found those signals do reach the PAL. The direction for these signals was also compatible with the PAL pinout (although some pins can be in+out).

The same routing could be found on every TRAM slot - these signals are all tied together, pass through the PAL and out to the connectors.


This diagram shows the completed net for the control signals.

Note that JP9 is also tied to the PAL, which makes sense given this header has a position for board priority. I did not figure out this part of the logic since many of the remaining PAL signals route to unpopulated ICs/resistors which would be for a different revision of the board. In this version, the PAL is mainly managing the board primary/secondary status and the 3 Transputer control signals.

ctx002-control.jpg
ctx002-control.jpg (641.67 KiB) Viewed 11 times
User avatar
stephen_usher
Site sponsor
Site sponsor
Posts: 7515
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Supercomputing adventures with a MegaST/4

Post by stephen_usher »

For the interfacing may I suggest that you read up on the VME bus specification and the protocols used? It may help you understand why you have those buffers/transceivers etc.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
User avatar
dml
Posts: 876
Joined: Wed Nov 15, 2017 10:11 pm

Re: Supercomputing adventures with a MegaST/4

Post by dml »

To make sure the PAL is not getting in the way (blocking the control signals by default), I used a pullup/pulldown resistor on the VME P2 connector position #32 and on a TRAM slot pin while watching the signal on the other side of the IC. The PAL appears to pass the signals ok.

If that had not worked, it would probably have been necessary to further reverse the PAL inputs or the PAL itself - or bypass it completely. So far, it seems like that won't be necessary.

For the jumpers, I confirmed that each of JP3-JP8 would make/break the L0-L1 chain forming the Transputer 'spine'. When the chain is broken, those links are swapped out to the P2 connector.

This diagram shows the direct input links in cyan and the jumper-controlled input links in violet, which form the 'spine' when not configured to the connector.

ctx002-linkin-map.jpg
ctx002-linkin-map.jpg (644.9 KiB) Viewed 7 times
User avatar
dml
Posts: 876
Joined: Wed Nov 15, 2017 10:11 pm

Re: Supercomputing adventures with a MegaST/4

Post by dml »

stephen_usher wrote: Sun Aug 30, 2026 9:25 am For the interfacing may I suggest that you read up on the VME bus specification and the protocols used? It may help you understand why you have those buffers/transceivers etc.
A detail I didn't cover yet is that the '244 buffers/drivers are hardwired-on. They are not being selected by anything - just acting as buffers for all link outputs. This simplifies things a lot.

It should be possible to drive the board without any real host on the VME - just import/export the Transputer signals for a single slot.

Things may get more complicated if more boards were present but it looks as if they set it up to rely on a static backplane configuration - maybe wire-wrapped - to tie the links and control signals across boards rather than selecting the boards with signals.
User avatar
dml
Posts: 876
Joined: Wed Nov 15, 2017 10:11 pm

Re: Supercomputing adventures with a MegaST/4

Post by dml »

I collected a bit of extra path info on JP1/JP2 which mainly relate to the missing components and the missing DSUB connectors (the missing parts also tie to some PAL pins).

Adding this for completeness - doesn't look like it will matter for my experiments so I don't need to go any deeper with it.

ctx002-jp1jp2.jpg
ctx002-jp1jp2.jpg (586.29 KiB) Viewed 1 time
User avatar
dml
Posts: 876
Joined: Wed Nov 15, 2017 10:11 pm

Re: Supercomputing adventures with a MegaST/4

Post by dml »

So from all of the probing/mapping work we get a Transputer network topology that is partly static, partly configurable.

ctx002-link-topology.png
ctx002-link-topology.png (104.41 KiB) Not viewed yet

The 'host' and 'next board' links are implied - not expressed on the board itself. Those links could be picked from any of the exposed paths but for connecting to an ATW800/2, using the L0->L1 spine as an extension of one of the ATW slots seems like a good option.

The JP3-8 jumpers could be opened and the whole thing unrolled into a linear chain - which simplifies programming a bit - but the repeating pairs can be an extension (nearly) of the initial pair on the ATW itself.

One wrinkle is that the EXT link on the ATW board comes from the 2nd slot (i.e. not the 'spine' - which would be the 1st slot) but that's a minor thing which can be fixed in the software or maybe a different link can be taken from slot 1 to keep it consistent....

So this is enough info to start playing with it. The next step is to experiment with a TRAM restored to the board and see if it will respond.
Post Reply

Return to “HARDWARE DISCUSSIONS”