Perfect, we have a running Helios system now. But with just one CPU it’s not that exciting as it should be. With just one MB there’s not much you can do with the system, 2MB allows to run some programs and 4MB is what you need for e.g. running the C-Compiler.
So: “More power, Igor!”
Some more background
Helios has no idea about how many Transputers are available. That’s not a shortcoming but a feature as you may not want to use all Transputers or you might like to dedicate certain tasks to a specific Transputer or you have a mixed system made of Inmos, Parsytec and Meiko parts which all behave a bit different.
This is why Helios needs a ressource map, which is a text file describing your Transputer network. As a first step, you should use ispy(a network worm tool) to identify the available CPUs in your system. Calling it together with mtest give you a list like this:
c:\> ispy | mtest [return]
Using 150 ispy 3.23 | mtest 3.22
# Part rate Link# [ Link0 Link1 Link2 Link3 ] RAM,cycle
0 T800d-25 280k 0 [ HOST … … 1:0 ] 4K,1 1024K,3;
1 T805b-24 1.6M 0 [ 0:3 2:0 3:0 4:0 ] 4K,1 4096K,3;
2 T800d-20 1.8M 0 [ 1:1 5:0 6:0 … ] 4K,1 1024K,3;
3 T800d-20 1.8M 0 [ 1:2 7:0 … … ] 4K,1 1024K,3;
4 T800d-20 1.8M 0 [ 1:3 8:0 … … ] 4K,1 1024K,3;
5 T800d-20 1.6M 0 [ 2:1 9:0 10:0 11:0 ] 4K,1 1024K,3;
6 T800d-20 1.6M 0 [ 2:2 12:0 13:0 14:0 ] 4K,1 1024K,3;
7 T800d-20 1.8M 0 [ 3:1 15:0 16:0 17:0 ] 4K,1 1024K,3;
8 T800d-20 1.6M 0 [ 4:1 18:0 19:0 20:0 ] 4K,1 1024K,3;
9 T805d-20 1.7M 0 [ 5:1 … … … ] 4K,1 1024K,3;
10 T800c-17 1.7M 0 [ 5:2 … … … ] 4K,1 28K,3 2016K,4 4K,3;
11 T800c-20 1.7M 0 [ 5:3 … … … ] 4K,1 1024K,3;
12 T800d-20 1.7M 0 [ 6:1 … … … ] 4K,1 1024K,3;
13 T800d-20 1.7M 0 [ 6:2 … … … ] 4K,1 128K,4;
14 T800d-20 1.7M 0 [ 6:3 … … … ] 4K,1 128K,4;
15 T800d-20 1.8M 0 [ 7:1 … … … ] 4K,1 1024K,3;
16 T800c-17 1.8M 0 [ 7:2 … … … ] 4K,1 28K,3 2016K,4 4K,3;
17 T800c-20 1.8M 0 [ 7:3 … … … ] 4K,1 1024K,3;
18 T805d-20 1.8M 0 [ 8:1 … … … ] 4K,1 1024K,3;
19 T800d-25 1.8M 0 [ 8:2 … … … ] 4K,1 28K,3 2016K,5 4K,3;
20 T800d-20 1.8M 0 [ 8:3 … … … ] 4K,1 1024K,3;
Wow, 21 Transputers, looks my Tower of Power 😉 Ok, so you see how the CPUs are connected to eachother and how much RAM they have, for example this line
1 T805b-24 1.6M 0 [ 0:3 2:0 3:0 4:0 ] 4K,1 4096K,3;
says: Transputer 1 is a T805/25MHz has 4K internal and 4MB external RAM. It is connected with Link-0 to Transputer 0 on its Link-3 and with Link-1, 2 and 3 to Transputers 2, 3 and 4 on their Link-0. Phew, lots of colors, but it should help you reading this much easier.
Sadly, Helios cannot read this format… it uses a different one which goes like this:
network /FullTower {
Reset { driver; ~00; tram_ra.d}
processor 00 { ~IO, , , ~01; System; }
processor 01 { ~00, ~02, ~03, ~04; }
processor 02 { ~01, ~05, ~06, ; }
processor 03 { ~01, ~07, , ; }
processor 04 { ~01, ~08, , ; }
processor 05 { ~02, ~09, ~10, ~11; }
processor 06 { ~02, ~12, , ; }
#~13, ~14; # these only have 128kb – too small for Helios!
processor 07 { ~03, ~15, ~16, ~17; }
processor 08 { ~04, ~18, ~19, ~20;
# ~21;
}
processor 09 { ~05, , , ;
# ~22, ~23, ~24;
}
processor 10 { ~05, , , ; }
processor 11 { ~05, , , ; }
processor 12 { ~06, , , ; }
# processor 13 { ~06, , , ; }
# processor 14 { ~06, , , ; }
processor 15 { ~07, , , ; }
processor 16 { ~07, , , ; }
processor 17 { ~07, , , ; }
processor 18 { ~08, , , ; }
processor 19 { ~08, , , ;
run -e /helios/lib/tcpip tcpip henkelmann 192.168.50.33 -e pc-ether;
run -e /helios/lib/inetd inetd
}
processor 20 { ~08, , , ; }
# processor 21 { ~08, , , ; }
# processor 22 { ~09, , , ; }
# processor 23 { ~09, , , ; }
# processor 24 { ~09, , , ; }
processor IO { ~00; IO }
}
At the first sight this looks a bit complicated, but it’s actually much easier to read than ispy’s output. If we take the last example again (without mtests addition)
1 T805b-24 1.6M 0 [ 0:3 2:0 3:0 4:0 ]
the Helios version looks pretty simple:
processor 01 { ~00, ~02, ~03, ~04; }
As you can see in my above ressource map example, there’s a bit more to it. For all details refer to chapter 2.6.5 of the Helios Manual I’ve mentioned earlier in this article.
In this case, I’ve commented out all Transputers with less than 1MB RAM because the 128K of some of them aren’t enough to even load the Helios mini-kernel (“nucleus”).
Also, you can see one of Helios’ cool features: You can bind a service/program to a Transputer at boot-time. Here are some example:
processor 00 { ~IO, , , ~01; System; }
This is my Gelach-card… with just 1MB it’s just enough for a decent basic system. The processor is reserved for use by the system. It cannot be allocated to users, and hence it is usually impossible to run applications here.
processor 19 { ~08, , , ;
run -e /helios/lib/tcpip tcpip henkelmann 192.168.50.33 -e pc-ether;
run -e /helios/lib/inetd inetd
}
This is a 2MB T800. It is dedicated to do the TCP/IP stuff (more on IP networking later) as this requires quite an amount of RAM and CPU cycles… nicely offloaded to this Transputer.
Tool Time!
If your transputer network changes as often as mine does, it might become a drag to constantly rewrite your resource map file. This is why I wrote this little parser script in perl. It takes an “ispy | mtest” output and converts it into a Helios resource map (*.rm) file.
Yes I know, perl is not optimal in a DOS environment but I was in a hurry… maybe I’ll rewrite it in C-for-DOS one fine day.
Two more steps…
Now that you edited your resource map (e.g. network.rm) to your needs, you need to generate a binary version of it. This needs to be done running Helios. So make sure the .rm file is inside the /etc folder (below helios root) and boot your single-CPU Helios and create a map file like this:
# cd etc
# rmgen network.rm
This will create a network.map in /etc for you. Now shutdown Helios again.
Now you need to tell Helios to actually use that map file. This can be done inside your initrc file which you edit like this:
# Helios System Configuration File
# This file is interpreted by init to configure the system
# it is NOT a shell script.
# Start up the X server if required
ifabsent /window run -e /helios/lib/window window
# Option 1
# Run the network software if necessary, and wait for the Session Manager
# to start up. Then create a console window and register it with the
# Session Manager, which will run login automatically
run -e /helios/bin/startns startns -r /helios/etc/network.map
waitfor /sm
console /window console
run -e /helios/bin/newuser newuser
# Option 2
# Run login by itself without any of the networking software. This gives
# a single-processor single-user system
#console /window console
#run -e /helios/bin/login login
This way you can now change between a single- and multi-processor system by (un)commenting either the Option 1 or Option 2block.
Now boot Helios again and you should see its initializing each Transputer while booting. When you (hopefully) get to the shell enter ‘network monitor‘ – that’s like ‘top‘ on UNIX – to indulge yourself by watching your Transputers doing… nothing/something.
Caveat: If you have more than 20 Transputers in your system (lucky you!), you might need another version of startns (copied into /helios/bin) which allows an unlimited number of Transputers to be used.