Greetings,

I'm new to Transputers, having come across a B008 (rev. E) and a handful of T414, T222, and T800 TRAMs of various sizes, as well as a good number of mouldy manuals and disks that I'll have to try and clean up sometime.

One of the T414 single-width TRAMs has a broken pin: it looks like it's Pin 9, "error analysis". I think this may be responsible for the "Link Err 9" that you see in the mms2 network mapper function:

Photo of network mapper display:
https://photos.app.goo.gl/hqejoDajpfxjU65i9

Photo of broken pin:
https://photos.app.goo.gl/svQuZe9xk6zhpL5S7
(not sure why the TRAM looks twisted in this photo: it isn't.)

Has anyone out there attempted pin repair or replacement for TRAMs?

In addition to this, is anyone aware of a way to find an image of the "IMS B008 Examples/Test" disk that is mentioned in the B008 User Manual? I'd like to use the included test program to check my installation.

http://transputer.net/mg/b008ug/b008ug.html#x1-410005

Thanks,
--Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Tom!

One of the T414 single-width TRAMs has a broken pin: it looks like it's Pin 9, "error analysis"

Do you have some spare 8 pin spacer/stripe? If yes - cut one out. If not - I can send you such an 8 pin stripe.

In addition to this, is anyone aware of a way to find an image of the "IMS B008 Examples/Test" disk

I don't have it and never missed it. Maybe http://transputer.classiccmp.org/software/drivers/imsb008/d798b.zip contains something for you.

I'm using exclusive rspy since almost 5 years. http://transputer.net/sw/sw.asp#Rspy
http://bin.transputer.net/bin2 (but requires additional drivers/setup)

But you can also use ispy/mtest/ftest from various sources. Please note: ftest doesn't run with every microcode revision.

-Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Mike, thanks for the reply!

On Mon, Sep 12, 2022 at 7:36 PM 'Mike B.' via comp.sys.transputer <[email protected]> wrote:

One of the T414 single-width TRAMs has a broken pin: it looks like it's Pin 9, "error analysis"

Do you have some spare 8 pin spacer/stripe? If yes - cut one out. If not - I can send you such an 8 pin stripe.

Good idea --- I do! In fact, I have the spacer that the old pin broke off into, which isn't so useful for spacing anymore. Thanks for the offer; it looks like I'll be fine!

Unfortunately, I now think this TRAM has more problems than just the pin. I tried a quick and dirty workaround for the broken pin (this is with a different spacer):

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

but I still get Link Error 9. I haven't tried to diagnose further --- I suppose that swapping the T414 onto another TRAM could help isolate the problem to the Transputer or the TRAM.

I don't have it and never missed it...

Thank you for the links you shared! I will start to try them out.

But you can also use ispy/mtest/ftest from various sources. Please note: ftest doesn't run with every microcode revision.

Part of my Transputer experience so far has been discovering what will run and won't run :-)

What I have is a pair of 2-wide 2 MB boards with T800s on them, three 4-wide 1 MB boards with T414s on them, and two (plus one broken) 1-wide 32 KB boards with T414s on them. (Plus the 1-wide 64K T212 board which is not part of the stack right now.) All
are arranged on the B008 in the default way: one host Transputer with system services plus any others I care to add in a subsystem. The setup is sitting inside an original IBM PC AT running MS-DOS 6.22, where we can really get a feel of the Transputers
outperforming an 8 MHz 286. (My only other ISA-slot choice here is a Pentium III machine, and that just feels wrong!)

I've learned that for the Occam compiler to work reliably, you need to have a 2 MB TRAM as the host. I've also found that ispy2331.exe is the latest version that will work; versions 3 onward "fail to send an ID to Transputer 1" or something like that. I'
m also discouraged to find that the Mandelbrot demo that you can find out there won't run on my Transputers at all (it seems to freeze mid-setup). I don't really know why this is the case --- clearly I have a lot to learn!

I'm hoping to show off this system at a computer history museum event that's coming up in November, and so anything that shows off the Transputer's parallelism and speed advantage is nice --- naturally the Mandelbrot calculator would be ideal. I'm
pleased that the Alta demo at http://wotug.org/parallel/vendors/inmos/archive-server/demos/alta/ works fine on my setup (either completely with only the T800s or with just the primes test for the whole T800/T414 crew), but progress bars going fast or
slow is not the most amazing thing in the world!

If anyone out there has ideas for interesting demos that can run on my mixed bunch of Transputers inside a 286 DOS PC, I'd love to hear all about them :-)
Otherwise, well, I'm trying to read the introductory material for Occam. Neat language. We'll see...

Thanks again,
--Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, September 12, 2022 at 7:36:32 PM UTC+1, Mike B. wrote:

http://bin.transputer.net/bin2 (but requires additional drivers/setup)

You weren't kidding! I couldn't find any documentation, so here's how I got this working :-)

With the S708 driver already installed, within the dos/x86 directory:

- Try to run rspy.exe, linktest.exe, etc. Notice complaints of a link module error with number -1.
- Try running link008.com, nothing happens. Try a few more things that don't work.
- Notice the string "linkio.com" in all of the .exe files. Copy link008.com to linkio.com
- (Another discovery: the /Z flag to rspy.exe. Cool.)
- Notice that the .exe files now say a -2 error. Progress?
- Notice the "LINK1" string in link008.com
- Try rspy.exe /sl LINK1. Success!
- Want to run programs that don't have an /sl flag. SET TRANSPUTER=LINK1 works - (Why didn't the #150 default work? That's the correct address for me...)
- Notice link error -1 if I run rspy from outside the directory with linkio.com - PATH including the directory holding linkio.com doesn't seem to work?
- APPEND C:\PATH\TO\LINKIOCOM\DIR /X seems to solve that problem.

Is this how the setup should work, or is there a better way?

Anyway, now that I'm equipped with rspy, I find that rspy /mc /fc shows the F. test failing on the two 32K T414 TRAMs in my stack. I wonder if the chip revision could be to blame, as you suggested --- these are T414B-G20S chips, while the passing 414s
are T414B-G15S?


Lastly --- how many TRAMs would you stack on a B008? Is there such a thing as too many boards on top of one another?

Cheers,
--Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi again.

/Z flag is common in the inmos world. oc /Z, icc /Z ... very usefull.
rspy /I /FT 1 tells you many details about the function tests running on transputer 1

how many TRAMs would you stack on a B008?

Depends on the cooling efficiency. Normal if the computer is not running very warm inside non stacked trams needs no forced cooling. Placing TRAMs over TRAMs makes the connections sometimes wobbly because you must use also spacer. Also the orientation of
the card inside the box can make cooling even more difficult.
In general I try to avoid it.

-Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Tom.

To check an suspect TRAM its the best to put only this TRAM into slot 0. No other.
For the Link1-3 check you can simply put an Loopback wire into the TRAM Pins. Link1In-Link1Out (if no T2 on B008), Link2In-Link2Out, Link3In-Link3Out
If there are still problems, I would also remove the T2 & C004.

You weren't kidding! I couldn't find any documentation, so here's how I got this working :-)

It's not so complicated, but you found the default settings if nothing has been specified as expected :-)

link008 interface module (will be loaded dynamically even under DOS) is using the driver interface from inmos
link004 interface module is using the port io interface from inmos. So works also fine for an ims b008 board any I would use it as an starting point.

comment out the 008 driver
set TRANSPUTER=C:\TRANSP~1\bin\dos\x86\link004.com@#150
set ISERVER=C:\TRANSP~1\bin\dos\x86\iserver.exe
set ISEARCH=C:\TRANSP~1\d72uni\LIBS\
set ITERM=C:\TRANSP~1\d72uni\iterms\ANSI.ITM
set PATH=C:\TRANSP~1\bin\dos\x86;C:\TRANSP~1\d72uni\itools;%PATH%

correct the directories to your structure. d72uni is my unified d7214+d7205 inmos toolset.

Now the stuff should work without specify the link. You can delete all *.vdd. Used for dos under windows only.
For playing with reset/analyse I use iserver.exe /SR or iserver /SA.
With peek/poke you can test internal and external memory. Finally send down a file and read back and compare the content is also possible.

rspy without any options is always useful.
rspy /L
rspy /E
rspy /M
rspy /ZMX
rspy /T
rspy /F

Please note: Testing memory on the B008 T2 will reset the C004!

Finally you can program and readout the C004 via rspy. But lets check/fix the other stuff first.

-Mike

PS: I've not using DOS since many years. So be aware of some typos. If you decide to switch to XP you will end up in a much more comfortable environment. But not so archaisch ...

PSPS: If everything is fine you might try link008.com and the inmos driver (with/without interrupt and/or dma).
set TRANSPUTER=C:\TRANSP~1\bin\dos\x86\link008.com@LINK1

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Tom.

Regarding the " F. test failing on the two 32K T414 TRAMs in my stack"

Can you send me a picture of the transputer and the rspy /I /FT n output (where n is the number of a failing module).

-Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Mike!

On Thursday, September 15, 2022 at 7:15:18 AM UTC+1, Mike B. wrote:

Regarding the " F. test failing on the two 32K T414 TRAMs in my stack"
Can you send me a picture of the transputer and the rspy /I /FT n output (where n is the number of a failing module).

Apologies for not being able to investigate this recently. The PC/AT setup I'm using is not entirely stable, and I spent yesterday evening debugging a power supply issue.

I did get a chance to run rspy /F shortly after power-up using a temporary PSU replacement, and I think the issue may be at least partly thermal in nature, as all modules passed the test while they were still cool. I will try some forced-air cooling
experiments when I am able.

The tests that have never succeeded for me have been "rspy /T", which yields

run-time error R6003
- integer dive by 0

and meanwhile "rspy /E" passes for the host module but fails for all subsequent modules --- perhaps because of my use of the "A Single Board For Developing Software" configuration found on PDF page 11 of the B008 User Guide (first edition, http://
transputer.net/mg/b008ug/b008ug.pdf). I have a log of the test and information about the topology of the Transputer network itself, but these are not handy right now as I'm away from the machine. I'll try to supply this soon.

I have still been using the INMOS driver (s708driv.sys) with link008.com. Thanks for the information on how to configure the environment variables. Do you have any advice on the differences and the advantages/disadvantages for link004.com vs link008.com+
s708driv.sys?

Thanks for all the help, I really appreciate it!
--Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Tom

I spent yesterday evening debugging a power supply issue.

Maybe the electrolyte power supply support capacitors are not working properly anymore (on TRAM/B008)

rspy /T
run-time error R6003
- integer dive by 0

Ok. I will check it. Never tested under DOS. Sorry.

rspy /E
fails for all subsequent modules

Use /ES (test error propagation via root subsystem)

advantages/disadvantages for link004.com vs link008.com+s708driv.sys?

Simply try it out and check the link speed over the link interface.
Check also the ISA timing settings in the bios if available . Some systems have very conservative settings as default.
In my cases link004.com was faster IIRC

-Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Mike,

On Monday, September 19, 2022 at 9:01:42 AM UTC+1, Mike B. wrote:

I spent yesterday evening debugging a power supply issue.

Maybe the electrolyte power supply support capacitors are not working properly anymore (on TRAM/B008)

This problem is nothing so subtle. The 35-year-old power supply in my AT has a fault of some kind and won't work at all. I am pretty certain that it's unrelated to the transputer. I will have to figure out the problem separately: for now, with a suitable
adaptor cable, I can just use an ATX power supply in its place. The biggest shame of it is that it can't use the original AT PSU's "big red switch".

But as far as the `rspy /f` failures are concerned, it does look like the problem was just a thermal one. I've added fans at the front and the back of my B008, and I haven't encountered any of those problems anymore, even after running the computer for a
long time. I'm content now that this issue is fixed.

It's sensible that some forced-air cooling might be required: here's how loaded up my B008 is right now :-)
https://photos.app.goo.gl/dJQdsadNGWMsDYM38
If I fix the T414 single-width TRAM with the broken pin and whatever other problem it has, then I can add on one more...

rspy /E
fails for all subsequent modules

Use /ES (test error propagation via root subsystem)

This works! All transputers pass.

You can now find all of your recommended rspy outputs (except for rspy /T) here:
With link004.com I/O: https://drive.google.com/file/d/1JLrj5r-dtPpto8DxtVdjMRfeCTTFTM7o/view?usp=sharing
With link008.com I/O: https://drive.google.com/file/d/1B4KJoeE4gXonVCciyIlBoT9LrfdJj0z6/view?usp=sharing

advantages/disadvantages for link004.com vs link008.com+s708driv.sys?

Simply try it out and check the link speed over the link interface.

The results of `rspy /L` seem to be nearly identical. However, if I use link004.com, either with or without s708driv.sys loaded, then oc and the other d7205 itools fail in this way:

Fatal-iserver-transputer error flag set

Nothing I tried seemed to be capable of clearing this flag, so it looks like I'll need to stick with the B008 method?

Check also the ISA timing settings in the bios if available . Some systems have very conservative settings as default.

These settings are not available in this BIOS. The computer is an IBM AT with an 8 MHz 286 CPU: it seems likely that its only timings will be slow :-)


If you're familiar with the program, I would love to find a reason why the CSA Mandelbrot demo won't work on this setup. What I observe is this:

C:\MYDIR>man -c
CSA Mandelzoom Version 2.1 for PC
(C) Copyright 1988 Computer System Architects Provo, Utah
Enhanced by Axel Muhr, 2009, 2015
This is a free software and you are welcome to redistribute it

h)ercules c)ga e)ga v)ga: c
Resetting Transputers...Booting...Loading...ID'ing...
Done. Getting data for "only_2k",

The older version found with source code on wotug.org lacks an -x option, but also freezes after asking you what kind of graphics adaptor you are using . My B008 and s708driv.sys are indeed configured to use DMA channel 1, the man.exe default. Naturally,
the -t flag (do compute on the host) works, slowly. I'll see if I can find a clue in the source code.

Thanks again for all your help!
--Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Apologies, the `rspy /i /t` link should have been this one: https://drive.google.com/file/d/1w9Wbjwzf3FHI6trthH-vSFvc0Xoxi6mc/view?usp=sharing

--Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Interesting follow-up: I only just noticed that `rspy /es` fails on the host under the link004.com approach but not under the link008.com approach. I captured the error output for `rspy /i /es` under link004.com here:

https://drive.google.com/file/d/1JRrkJA3DMmhDYyq-wxVGub4fO9fOtA0Y/view?usp=sharing

While I was at it, I also captured the error output for `rspy /i /t` here:

https://drive.google.com/file/d/1JRrkJA3DMmhDYyq-wxVGub4fO9fOtA0Y/view?usp=sharing

This log was collected under link004.com, but the output looks identical under link008.com.

--Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Tom!

The error problem with the link004.com is a simple bug. I've added the correction few years ago at the wrong place. What has not been tested is not working.
The divide by zero has also fixed. This problem is related to the not so easy accurate time measurement under dos and older hardware. I'm currently testing some code to also get micro-second granularity time measurement under dos. But it's tricky.

I will release a new version soon.

Your link speed comparison between link004.com and link008.com interface method is interesting. The link008.com is the clear winner with 228K vs 78K.
This behavior changes when a more powerful CPU is used. My PentiumPRO200 EISA Box is configured with the link004.com:

:: B004
set TRANSPUTER=A:\T\LINK004.COM@#110

# Part rt Link0 Link1 Link2 Link3 RAM@cycle
0 T800D 20 301K ... ... ... 4K@1,2048K@3;

:: B008
set TRANSPUTER=A:\T\LINK004.COM@#150

# Part rt Link0 Link1 Link2 Link3 RAM@cycle
0 T800D 20 307K 1677K 1712K ... 4K@1,1024K@3;
1 T225C 20 ... 1712K ... ... 4K@1.
2 T800D 20 ... 1712K 1712K ... 4K@1,1024K@3;
3 T800D 20 ... 1712K 1677K ... 4K@1,1024K@3;
4 T800D 20 ... 1712K 1712K ... 4K@1,1024K@3;
5 T800D 20 ... 1677K 1712K ... 4K@1,1024K@3;
6 T800D 20 ... 1712K 1712K ... 4K@1,1024K@3;
7 T800D 20 ... 1712K ... ... 4K@1,1024K@3;

:: BOZO
set TRANSPUTER=A:\T\LINK004.COM@#300

# Part rt Link0 Link1 Link2 Link3 RAM@cycle
0 T425A 25 300K ... 1712K ... 4K@1,8188K@4;
1 T805D 30 ... 1712K ... ... 4K@1,8192K@3;

About the CSA Mandelzoom Version 2.1 for PC issue.

I know it's annoying to remove the TRAMs but if you encounter problems with many transputers, first try it with one and see if it's working.
Maybe I find the time to reproduce it on my system.

Kind regards, Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Please note (from https://www.geekdot.com/basic-transputer-tools/ Section Mandelbrot)
Caveat: It breaks if there’s a T2xx in the network (e.g. B008/B012)

-Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, September 22, 2022 at 7:23:17 AM UTC+1, Mike B. wrote:

Please note (from https://www.geekdot.com/basic-transputer-tools/ Section Mandelbrot)
Caveat: It breaks if there’s a T2xx in the network (e.g. B008/B012)

I can't believe I missed that! Oh well. Either I will have to hack the code to work for me or I will need to find another way to make an interesting demo.

Since the T212 sits on link 1 from TRAM slot 0, and since all of my other TRAMs are accessible "downstream" of TRAM slot 0 via link 2 (see Figure 1 at http://transputer.net/mg/b008ug/b008ug.html#x1-20001), I wonder if I could simply constrain the worm
built into CSA Mandelzoom to search only along links 2 and 3. I'm not used to Transputer assembly, but it looks like you might be able to change 0 to 2 on these two lines:

https://github.com/axelmuhr/T-Mandel/blob/Mandel_3/IDENT.TAL#L80 https://github.com/axelmuhr/T-Mandel/blob/Mandel_3/IDENT.TAL#L171

That modification could quite likely be accomplished by changing a $00 byte to a $02 byte in two places in the MAN.EXE binary, if I could figure out where to find them :-)
It's also possible that only the first line needs to be changed.

The error problem with the link004.com is a simple bug. I've added the correction
few years ago at the wrong place.

Is the bug in link004.com or in rspy? I hope it's in link004.com (or in iserver), because if it's in rspy, that may mean most of the itools have a similar problem too (as I mentioned earlier, they complain about "Fatal-iserver-transputer error flag set"
and fail to run).

I will release a new version soon.

Hooray, thank you!

--Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, September 22, 2022 at 9:30:51 PM UTC+1, Tom Stepleton wrote:

Since the T212 sits on link 1 from TRAM slot 0, and since all of my other TRAMs are accessible "downstream" of TRAM slot 0 via link 2 (see Figure 1 at http://transputer.net/mg/b008ug/b008ug.html#x1-20001), I wonder if I could simply constrain the worm

built into CSA Mandelzoom to search only along links 2 and 3. I'm not used to Transputer assembly, but it looks like you might be able to change 0 to 2 on these two lines:

https://github.com/axelmuhr/T-Mandel/blob/Mandel_3/IDENT.TAL#L80 https://github.com/axelmuhr/T-Mandel/blob/Mandel_3/IDENT.TAL#L171

That modification could quite likely be accomplished by changing a $00 byte to a $02 byte in two places in the MAN.EXE binary, if I could figure out where to find them :-)

Correction: changing $40 bytes to $42 bytes. Unfortunately: no such luck with changing only line 80 or with changing lines 80 and 171 both. I think I modified MAN.EXE correctly: I hand-assembled the neighbourhoods of code around those lines (what a
compact ISA!) and found the unique corresponding locations in the binary, but the program still hangs.

Guess I'll have to learn Occam :-)

--Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Tom!

Is the bug in link004.com or in rspy?

link004.com

Since the T212 sits on link 1 from TRAM slot 0

I think you can "cut" the T2 off by simple removing the 2 middle jumper at J1.

As you have an mixed T4/T8 network, I think there is no other fractal program.

I hope you have an AT and not an XT, because the new rspy DOS timer solution requires an 8254 timer.

-Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi again,

On Friday, September 23, 2022 at 1:30:15 PM UTC+1, Mike B. wrote:

I think you can "cut" the T2 off by simple removing the 2 middle jumper at J1.

I wasn't sure about that, but I think you're right.

Unfortunately, I've just discovered that a previous owner of my B008 has soldered every one of those J1 jumpers in place! They must have found them to be unreliable. I could desolder the jumpers, but this feels like too much of a hassle for right now.

As you have an mixed T4/T8 network, I think there is no other fractal program.

Well, there's always whatever I could write myself...

But before I try that, I've now successfully compiled man.exe at https://github.com/axelmuhr/T-Mandel from source code. Let's see if I can figure out the worm assembly well enough to keep TRAM 0 from talking to the 212.

I hope you have an AT and not an XT, because the new rspy DOS timer solution requires an 8254 timer.

Yes, I have an AT!

--Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Tom!

The dos files at http://bin.transputer.net has been updated. The time measurement has been enhanced and also rspy /t under dos is now working fine but requires an PC-AT or higher. link004.com bug has been fixed too. The new time functions are also used
in iserver. So, this binary has also changed.

-Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Mike, thanks for these updates!

They're working pretty well on my AT. rspy /ES passes under both link004.com and link008.com, and the itools work too in both situations.

The only issue I've found is that two of my T414B TRAMs, #3 and #6, report failures under rspy /T. It seems there's about a 50% chance that they'll fail.

With link004.com: https://drive.google.com/file/d/1WiudWm-qR5th7PdVIVqBJShob_CxAFYl/view?usp=sharing
With link008.com: https://drive.google.com/file/d/1mQWEg_Z7exJCgEMe-1S1oqLBgUiYT5R3/view?usp=sharing

You can see a failure in the link004.com test, but both configurations provoke this failure off and on. It's hard for me to say whether this problem is a true problem with those TRAMs or something to do with my AT likely being at the low end of the
hardware configurations that your program supports. I suppose there's also the chance that this AT could have a clock problem of its own :-)

One last oddity I've noticed is that rspy /ZMX fails with a single bit error for TRAM #3 during the first minutes that the computer is running. This suggests a thermal issue somewhere, which is perhaps to be expected with a stack of TRAMs as silly as
mine. There could be a cold solder joint somewhere, or perhaps the T414B needs to be reseated in its socket. In any case, it's not causing me many problems right now, so I won't worry about it yet.

I'm continuing to study the source code in CSA Mandelzoom, and I feel I've been learning a lot about Transputer assembly. I'm especially grateful that transputer.net has John Roberts's "Transputer Assembly Language Programming" --- like him, I've found
some of the INMOS documentation to be "nonstandard and sometimes cryptic". One thing that even Roberts couldn't help me with was determining what state Wptr and the other registers would be in after a network boot --- for that I had to refer to Mitchell
et al. "Inside the Transputer", PDF page 31. I couldn't even find this information in the Transputer datasheets, though perhaps I didn't look in the right places.

--Tom

On Saturday, September 24, 2022 at 2:05:17 PM UTC+1, Mike B. wrote:

Hi Tom!

The dos files at http://bin.transputer.net has been updated. The time measurement has been enhanced and also rspy /t under dos is now working fine but requires an PC-AT or higher. link004.com bug has been fixed too. The new time functions are also used

in iserver. So, this binary has also changed.

-Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Tom!

The only issue I've found is that two of my T414B TRAMs, #3 and #6, report failures under rspy /T. It seems there's about a 50% chance that they'll fail.

Can you please provide the rspy /i /tt 6 output of a failing run.

The failing ttest should not be overrated. Time measurement over a few hops may be delayed in some situations. I've skipping the biggest and the smallest value of 5 measurement rounds and take the average of the remaining 3 from every node. You see all 5
values in the /i output. ttest print out "failed" if the value is +-5% from the nominal value 12800. There are many possible approaches to make it more reliable, but I prefer to keep the things simple (but not simpler). ttest is more or less the clock
matching test. The timer functionality is tested in the ftest programs.

One last oddity I've noticed is that rspy /ZMX fails with a single bit error for TRAM #3 during the first minutes that the computer is running.

Interesting, because at the beginning the system should have a lower temperature. I observed non persistent ram failure only after a longer time.

Please note: /M runs in parallel. If you specify /ZM your transputer system is using the external memory extensive (especially if the mtest on all modules takes approx. the same time). To do mtest more than once you can use /ZMI 100. But don't burn down
your transputer system!

I'm continuing to study the source code in CSA Mandelzoom, and I feel I've been learning a lot about Transputer assembly.

I had a quick look also but find the code quite difficult to read.

I don't know if the TIS-ACWG (Transputer Instruction Set: A compiler writer's guide http://transputer.net/iset/pdf/tis-acwg.pdf) is really a good start but meanwhile it's my main reference book for assembler topics.
The best way to get started with transputers I believe is "The Transputer Handbook" from Ian Graham + Tim King.

To analyze a self-exploring and distributing parallel program may not be the easiest start. The 3L compiler has flood-fill support or even better use the icc/oc toolset and create such a program with a static processor mapping.

Kind regards
Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, September 25, 2022 at 11:15:40 AM UTC+1, Mike B. wrote:

Hi Tom!

The only issue I've found is that two of my T414B TRAMs, #3 and #6, report failures under rspy /T. It seems there's about a 50% chance that they'll fail.

Can you please provide the rspy /i /tt 6 output of a failing run.

Here it is: https://drive.google.com/file/d/1eOeTgTpCfy7RsuaY-FR9wrTTDLJ8OH_w/view?usp=sharing
This text is just the output to standard error: the summary printed to standard output is missing. There's nothing surprising there: it just says that TRAM 6 has failed.

One last oddity I've noticed is that rspy /ZMX fails with a single bit error for TRAM #3 during the first minutes that the computer is running.

Interesting, because at the beginning the system should have a lower temperature. I observed non persistent ram failure only after a longer time.

To me, this behaviour is consistent with bad contact between a pin and a socket somewhere. Let's say the T414B is not well-seated in the B403 TRAM. While the Transputer is cold, one of the pins lacks a good connection between the pin and the socket, but
after a while the IC gets warm and the pin moves just slightly to where it makes good contact.

I think the thing to do to explore this hypothesis would be to remove the TRAM and reseat all of the chips in sockets (potentially also using contact cleaner), but I will wait until the problem gets worse before I do that.

Please note: /M runs in parallel. If you specify /ZM your transputer system is using the external memory extensive (especially if the mtest on all modules takes approx. the same time). To do mtest more than once you can use /ZMI 100. But don't burn

down your transputer system!

No worries, we never get that far. If I run rspy /i /zmi 12 (or any higher number), then the test always fails with "Fatal-rspy-memory allocation failed" when running mtest on node 8. Running rspy /i /zmi 11 always succeeds. Could this be an rspy bug?
Perhaps it's not freeing memory that it should, and since I only have 640K in this AT, it can't fit that many tests.

Here is the standard error output from rspy /i /zmi 12: https://drive.google.com/file/d/1v3Schw5avk8ewe-XqHz7xiwjXz-sZclO/view?usp=sharing

I don't know if the TIS-ACWG (Transputer Instruction Set: A compiler writer's guide http://transputer.net/iset/pdf/tis-acwg.pdf) is really a good start but meanwhile it's my main reference book for assembler topics.

ACWG would be an easier reference for me to use if it were searchable in my PDF viewer (which is just Firefox). The Roberts book supports ctrl-F and also lets me look up instructions alphabetically. But I'm really very happy to have all of these
references thanks to your website --- each of them has had a valuable piece of information that I couldn't easily find elsewhere. There is no need to choose only one!

To analyze a self-exploring and distributing parallel program may not be the easiest start. The 3L compiler has flood-fill support or even better use the icc/oc toolset and create such a program with a static processor mapping.

That is true, but hopefully if I can crack this mystery and tweak the Mandelzoom source in just a few spots, I won't have to write the rest of the program!

I'm enjoying the reverse engineering a lot too. It's not very fast progress, but I've completely understood about half of SRESET.TAL, FLBOOT.TAL, and FLLOAD.TAL so far, and the places where I've been confused are ones where some study has helped me learn
more about how Transputers work. My current mystery at the halfway point is this: FLBOOT.TAL is a worm where each instance sends a copy of itself to its downstream neighbours --- that's fine, I can see how it does that. But what happens if there's more
than one route to a node, and a Transputer has two other Transputers trying to give it a copy of FLBOOT? I hope the answer to this mystery will teach me something new.

--Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Tom!

The only issue I've found is that two of my T414B TRAMs, #3 and #6, report failures under rspy /T. It seems there's about a 50% chance that they'll fail.

Thx for the output. It looks that my high timer/low timer ratio test is too restrictive. I will change the boundary in the upcoming full build.

If I run rspy /i /zmi 12 (or any higher number), then the test always fails with "Fatal-rspy-memory allocation failed"

Fixed und uploaded. Please test it in your environment.

Could this be an rspy bug?

Yes, almost one bug left ;-)

Perhaps it's not freeing memory that it should, and since I only have 640K in this AT

640K is so much memory. rspy is compiled in the small memory model. So only max 128KB needed.

Kind regards
Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I will change the boundary in the upcoming full build.

All binaries have been recompiled and uploaded today.

-Mike

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks Mike! I've given the new binaries a go. rspy /T now always passes, and rspy /I /ZMI 100 also works fine. Patience is required, but happily the Transputers do not catch fire.

Back to the code. Thanks again!
--Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)