Hi again,

Having conquered mandelzooming, I'm now giving Helios a try. My TRAMs may be a little small for Helios, but hopefully most of them aren't *too* small.

Well, things are working well when I run on TRAM 0 only, but I'm having bad luck going any further than that. I see this error message when the network server attempts to boot the next eligible TRAM connected to TRAM 0, which is a T414 with 1 MiB of RAM:

https://photos.app.goo.gl/e7e6wySWZMmhrBJbA

The critical error messages seem to be:
ns: failed to boot processor 03 via link 2 of processor 00
ns: reported fault was 0xd105000a

In Helios, decoding the fault code by typing `fault d105000a` reports that ns is experiencing a timeout. Does anyone know what might cause this? I think the TRAM should be healthy enough since it works with CSA Mandelzoom and since it passes `rspy /zmx` and `rspy /f` tests. Some thoughts:

- Is a 15 MHz T414 too slow for Helios?
- Would host.con for an 8 MHz PC/AT need a BOGOMIPS setting? Surely not...
- Some TRAMs on this network don't have enough RAM for Helios, but those aren't the ones that are having this trouble. Could they still be a problem?

For reference, my B008 is configured in the out-of-the-box way described under "A Single Board for Developing Software" in the B008 manual (http://transputer.net/mg/b008ug/b008ug.html#x1-150002.4.1).
You can see all other details of my network and my TRAMs here:
https://drive.google.com/file/d/1mQWEg_Z7exJCgEMe-1S1oqLBgUiYT5R3/view?usp=sharing

Now for some rspy questions:

1. I'd like to use rspy to reconfigure the c004 switch. It can do this, but it needs a file in "iswitch" or "swc" format. Is there a good reference for this format anywhere?

2. Is there any way to have rspy tell TRAM 0 to issue a subsystem reset?

3. Why does rspy /ch produce the line "reset { driver; ; null_ra.d }" instead of "reset { driver; ; tram_ra.d }"?

4. Why does rspy number my TRAMs as 0,1,3,4,5,6,7,8? Where's #2?

Thanks for any help!
--Tom

I'll take the Helios part and leave the RSPY stuff to Mike ;-)

Generally, it's always helpful to provide your Network resource map (the one which you later feed into 'rmgen').
Maybe even your host.con file...

step...@gmail.com schrieb am Sonntag, 2. Oktober 2022 um 16:27:53 UTC+2:
> Well, things are working well when I run on TRAM 0 only, but I'm having bad luck going any further than that. I see this error message when the network server attempts to boot the next eligible TRAM connected to TRAM 0, which is a T414 with 1 MiB of RAM:
[...]
> In Helios, decoding the fault code by typing `fault d105000a` reports that ns is experiencing a timeout. Does anyone know what might cause this? I think the TRAM should be healthy enough since it works with CSA Mandelzoom and since it passes `rspy /zmx` and `rspy /f` tests. Some thoughts:

Have you tried playing with the debugging features of the SERVER which I've documented here: https://www.geekdot.com/troubleshooting/ ?
Try the "T" switch if it tells you more than we already know...

> - Is a 15 MHz T414 too slow for Helios?
> - Would host.con for an 8 MHz PC/AT need a BOGOMIPS setting? Surely not....
> - Some TRAMs on this network don't have enough RAM for Helios, but those aren't the ones that are having this trouble. Could they still be a problem?

I'd say, the CPU clockspeed should not be of importance, the same goes for the BOGOMIPS setting in the host.con (which just 'stretches' the delay in the DOS host). 1MB is just about enough to not dying... but its life will be miserable ;)
My primary suspection is (and Mike surely know more about this) is, that your ROOT Transputer is a T800, which is capable of Overlapped acknowledge, which a T414 is not. I /assume/ Helios thus waits for an ACK too short...

To double check my theory, 'dumb down' your network to just the T800 and that T800D (#7) and see if it boot with just the 2 of them.

Cheers, Axel

Hi!

> 1. I'd like to use rspy to reconfigure the c004 switch. It can do this, but it needs a file in "iswitch" or "swc" format. Is there a good reference for this format anywhere?

No. But here is an example (and rspy /CL should generate an template):

--
-- swc file for a single B012
--

switch
name b012.c004[0]
type c004
path 1 0
connect 23<18 02<03 00<06 17<16
connect 21<09 01<28 07<31 20<15
connect 14<12 29<25 30<26 11<08
connect 27<05 24<04 10<19

switch
name b012.c004[1]
type c004
path 1 3
connect 23>18 02>03 00>06 17>16
connect 21>09 01>28 07>31 20>15
connect 14>12 29>25 30>26 11>08
connect 27>05 24>04 10>19

--=EOF=--

Notes:
two dashes -> ignore the rest of the line e.g. comment
name is freetext
type must be c004
path is the linknumbers to the c004
connect is the c004 config:
> (or <) are unidirectional link connections
- is bidirectional

connect 1>2 1<2
connect 1-2
connect 1>2 2>1
... all 3 are identical

> 2. Is there any way to have rspy tell TRAM 0 to issue a subsystem reset?

No. But simply poke to 0 two times can do it.

> 3. Why does rspy /ch produce the line "reset { driver; ; null_ra.d }" instead of "reset { driver; ; tram_ra.d }"?

Simply because it's hardcoded. It's intention is to have an template and an remainder in the output.

> 4. Why does rspy number my TRAMs as 0,1,3,4,5,6,7,8? Where's #2?

It's the C004. Use rspy /c4 to see the missing number and config.

-Mike

Thanks both! This is a busy week so I may not get much time to experiment, but I will ask a few rspy follow-on questions now:

On Monday, October 3, 2022 at 1:48:34 PM UTC+1, Mike B. wrote:
> > (or <) are unidirectional link connections
> - is bidirectional
>
> connect 1>2 1<2
> connect 1-2
> connect 1>2 2>1
> ... all 3 are identical

Is it correct then that you cannot specify which link is used in this format? The connect line only indicates that different Transputers are connected, and rspy chooses which links to use? (Or perhaps it's constrained somehow by the C004?)

Can you say more about the numbering scheme used for the connections? For the B008, does it refer to slot numbers or some other way of numbering?

I've also noticed that if I use s708's mms2.b4 program to apply the SOFTWIRE file included in s708, then rspy /cl emits a configuration that connects (if I remember correctly) a device identified by the number 11 to a device identified by the number 23. Given that there are only the 7 TRAMs, the built-in T212, and the C004, this numbering is confusing. Could it refer to the B008's D-sub connector somehow?

Thanks again for the help!
--Tom

Hi Tom!

> Is it correct then that you cannot specify which link is used in this format? The connect line only indicates that different Transputers are connected

Sorry, the connect number is the C004 link number 0 to 31. So, you have to consult the hardwire file or the schematics.
http://transputer.net/mg/b008ug2/b008ug2.html#x1-64000G

C4 0,LINK 11 TO SLOT 1,LINK 3
....
C4 0,LINK 6 TO SLOT 6,LINK 0

If you want to connect Slot1-Link3 with Slot6-Link0 write 6-11 (6 from LINK, not SLOT)
The < and > are required for B012 boards.

> Could it refer to the B008's D-sub connector somehow?

The c004 links at the 37 d-sub are called edge. See http://transputer.net/mg/b008ug2/b008ug2.html#x1-6100117

> this numbering is confusing

Yes, I agree. Please also take care of the patch header. The third place to make things worser.
http://transputer.net/mg/b008ug2/b008ug2.html#x1-5900124

You can configure via mms2 and readback via rspy.

-Mike

step...@gmail.com schrieb am Sonntag, 2. Oktober 2022 um 16:27:53 UTC+2:

> 1. I'd like to use rspy to reconfigure the c004 switch.

My 2 Euro-cents to that: C004 sux... even more when your network grows.
https://www.geekdot.com/the-inmos-c004/

Pull that thing (incl. the T2xx), hard-wire your setup, save some power and config hassle ;-)

Cheers, Axel

On Tuesday, October 4, 2022 at 12:20:05 PM UTC+1, ax...@geekdot.com wrote:
> My 2 Euro-cents to that: C004 sux... even more when your network grows.

Seems like a valid opinion.

Right now there's a lot of experimentation I'd like to do with network topology, so it's helpful to have something reconfigurable. When I find a network configuration I like, then it'll probably be a good time to lock things down more permanently.

Of course, if I could get my hands on some more capable TRAMs, there might be less of a need to identify optimal configurations. Please feel free to let me know if you are aware of any spare ones lying around. :-)

In the meantime, I'd love to have advice on how to remove a Transputer (or C004) PGA chip from its socket. The one TRAM where I've experimented with removing a chip is holding onto its T414 very tightly. I'm not sure how to pry it up and out without (at least) damaging the ceramic packaging or the circuit board underneath.

--Tom

Tom Stepleton <stepleton@gmail.com> writes:

> Of course, if I could get my hands on some more capable TRAMs, there
> might be less of a need to identify optimal configurations. Please
> feel free to let me know if you are aware of any spare ones lying
> around. :-)

Don't make the mistake I originally made, and buy an overpriced TRAM on
eBay! Luckily, I discovered the error of my ways, and populated the
rest of my B008 with TRAMs I bought from Axel. He makes them himself.

....and right now, I'm just waiting for winter to get here for real, so I
can defend firing up the old Pentium II machine with PCI and ISA buses
in it, where my B008 is hosted by Minix 3.4, so I can continue playing
with Helios on the network of T800 modules. :)

-tih
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important idea in computer science. --Alan Kay