Supercomputing adventures with a MegaST/4

[dml]

This afternoon I decided to see if I can get light out of the thing - get the Atari to see it. So far it has just been a lot of DMM checks, making notes and diagrams and stuff but I'm a bit more confident now that I can wire it up. I also wanted to get a bit more done today instead of waiting for more parts to show up.

I installed a header on the Transputer link connector on the ATW800/2 and started looking for an IDC plug/ribbon to carry the signals to the carrier board. As usual, could not find what I was looking for - and to avoid spending the rest of the weekend digging in boxes I fell back to some of those sketchy dupont connectors.

Unfortunately the dupont jumpers are far too short and this makes wiring it up really annoying. That's what happens when you can't wait a few extra days :p

To work around this I tried feeding the signals into the 2nd slot on the row, relying on the internal connections carrying that to the 1st slot in that row, where the Transputer/TRAM is actually installed. I used link 2 since its on the same row as the control signals and helps with the short wires.

I then started MUPFEL and ran rspy. I did not have success with this - it only detected the 3 Transputers usually present. However I noticed that power cycling the carrier caused the green LED on the ATW TRAM (the one it is linked through) to flicker for a few seconds.

I switched things around and moved the Transputer to the slot on the side near the ATW, fed the signals directly into the TRAM pins (these ones have small sockets on top) and tried again.

hotwire.jpg (709.31 KiB) Viewed 105 times

Powering the carrier again caused flickering on the ATW TRAM LED.

This time running rspy though...

detected.jpg (381.4 KiB) Viewed 105 times

So it has been seen by the Atari, across the external link.


It is not working reliably though in this config - rspy only detects it once. A second try shows it missing. Power cycling the carrier brings it back. I'm pretty sure the RESET net is floating on the board since my previous RE work showed it sitting at 1.6v and I kept that in mind while trying this so it's not completely unexpected that the unit would not be detected or would be flaky.

The fact it showed up at all in rspy though is a big step forward.

[dml]

Have been a bit unwell and things are moving slower... but I did make a bit of progress since the last post.

While I did get the TRAM to show up in the rspy query last time, I was cheating a bit by tying it directly on its pins. It works as a hack but I wanted to know if a Transputer can be addressed from the bus - and so, could potentially pass messages across slots. This is a bit more complicated and relies on information I had figured out about the board being accurate...

I moved the TRAM to slot 4, which is where the preferred entrypoint (slot 4, link 0) should be for an inter-board connection.

restored.jpg (514.3 KiB) Viewed 79 times

I then started putting together a small buffer interface board which should allow the ATW800/2 to work with signals exposed on the backplane. This should make the ATW800/2 host appear as just another VME card.

bufferboard.jpg (468.3 KiB) Viewed 79 times

As described in an earlier post, those TRAM signals are not exposed directly but are translated for compatibility with the other cards sitting on the same bus, including the original host which would have been in VME slot 1.

It seems the device (when complete with all cards) was something intended for video processing - the host card had analog video in+out - but it's actual purpose I don't know.

[dml]

(still catching up with current situation)

I completed the buffer board and the IDC ribbon connecting it to the EXT_LINK connector on the external interface of the ATW800/2.

idc-link.jpg (134.46 KiB) Viewed 59 times

I ran some very brief tests with the new arrangement - no hacks in place.

MegaST -> ATW800/2 : TRAM slot 1 -> EXT_LINK -> bufferboard -> VME backplane -> carrier : TRAM slot 4.

The link itself appeared to work and the TRAM on the carrier could be detected as before - but again it would only show on the first query after a carrier power cycle, disappeared on a second query.

I suspected the RESET line. While I did trace out its path, I didn't properly live-test the signal as I did with the ERROR signal so probably I missed something or maybe the PAL is blocking it.

The rspy query sends a worm through the network, resetting and bootloading each Transputer it finds, until the worm runs out of links to explore. If the RESET line is not working, the worm is relying on the Transputer already in the reset/listening state - which is true after a power-cycle. After being discovered once, it will not be in the same state and relies on RESET being asserted on a new query. Without that RESET, the Transputer won't answer and won't show in the enumeration table.

So I set about investigating that - and found a bit more than I bargained for One of those 'enough inversion-flips in key places and everything seems almost correct' situations....

[dml]

Tracking down the RESET issue led me to FOUR new problems.

1. The RESET input from the ATW800/2 was tied to the VME pin for the relevant PAL signal. However the termination resistor arrays on the CN1 connector carrying that signal are much lower value than on the CN2 connector where most of the data is. So trying to drive that signal directly was having almost no effect, It was only moving by 0.1v on the carrier board. That was just an oversight.

2. The RESET signal was also inverted. It is active-high on the Transputer side but active-low on the bus side, inverted by the PAL. I fixed this problem by adding a transistor to invert the ATW's reset and pull down the VME pin. This was also fairly easy to realise/figure out.

3. The RESET sent from the ATW side was apparently being ignored unless the MOTHER setting on JP9 of the carrier board was open. This appears to tell the PAL if to carry control signals through the bus or only within the board itself. So the jumper needs to be open to talk to host (I confirmed this by triggering RESET manually with the jumper open/closed, after a session of being quite confused...)

jp9.jpg (473 KiB) Viewed 43 times

4. ...but the TRAM is only getting detected when the MOTHER setting on JP9 is closed.

So I can have a working external reset, or I can have a detected TRAM - but not both at once. Great!

[dml]

The problem with the JP9 setting and the TRAM's weird detect behaviour had a simple explanation.

At some point I realised that of the 3 control signals going through the PAL logic on the carrier, ERROR is the only one that was NOT inverted.

Both RESET and ANALYSE are being inverted. ANALYSE I mostly ignored because it is only supposed to be useful in relation to debugging, after an error is raised and is not expected to happen in normal operation.

When JP9 is closed, RESET doesn't work - but ANALYSE does not get in the way because the PAL disables it. With JP9 open, RESET and ANALYSE are imported from the ATW800/2 - but ANALYSE is low on that side, being flipped -> high to the TRAM, causing it to halt.

Inverting both signals with Transistors fixed this.

adapter2.jpg (238.72 KiB) Viewed 30 times

After the fix, the TRAM is detected on every query with rspy.

detect-works.jpg (78.84 KiB) Viewed 30 times

[dml]

Now things get interesting - the Atari is now talking to the carrier properly through the bussed links.

At this point it is possible to start adding TRAMs - starting off with slots which have already been figured out as linked downstream from the first TRAM (slot #4, link #0 was picked as the entry point) in the topology shown earlier.

Slot 4 is linked to slot 0 (hardwired) and slot 5 (jumpered) so either/both should be seen from slot 4.

[Badwolf]

When JP9 is closed, RESET doesn't work - but ANALYSE does not get in the way because the PAL disables it. With JP9 open, RESET and ANALYSE are imported from the ATW800/2 - but ANALYSE is low on that side, being flipped -> high to the TRAM, causing it to halt.

Loving your progress, Doug & especially the narration of all the little pitfalls.

Brilliant bit of research and adaptation!

Keep going! When you're done you'll have to render some Babylon 5 with your new video board. I think I heard the Atari was great at that...

BW

[dml]

...adding one more TRAM...

detect-2trams.jpg (28.19 KiB) Viewed 11 times

...and one more...

3-trams.jpg (672.64 KiB) Viewed 11 times

detect-3trams.jpg (32.53 KiB) Viewed 11 times

...and now I need to stop, take a step back and look at the power situation. This is already starting to pull some amps and there is voltage drop at the board. My lab supply - especially the temporary cable clips I am using - will not keep up if I keep adding more.

[dml]

Loving your progress, Doug & especially the narration of all the little pitfalls.

Thanks! It's a bit long-winded but maybe more interesting than 'hey, that worked'. :p

Keep going! When you're done you'll have to render some Babylon 5 with your new video board. I think I heard the Atari was great at that...

hehe. we can name it the 'Video Breville' and retcon the B5 origin story!