One of the T414 single-width TRAMs has a broken pin: it looks like it's Pin 9, "error analysis"
In addition to this, is anyone aware of a way to find an image of the "IMS B008 Examples/Test" disk
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.
I don't have it and never missed it...
But you can also use ispy/mtest/ftest from various sources. Please note: ftest doesn't run with every microcode revision.
http://bin.transputer.net/bin2 (but requires additional drivers/setup)
how many TRAMs would you stack on a B008?
You weren't kidding! I couldn't find any documentation, so here's how I got this working :-)
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).
I spent yesterday evening debugging a power supply issue.
rspy /T
run-time error R6003
- integer dive by 0
rspy /E
fails for all subsequent modules
advantages/disadvantages for link004.com vs link008.com+s708driv.sys?
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 /EUse /ES (test error propagation via root subsystem)
fails for all subsequent modules
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.
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)
The error problem with the link004.com is a simple bug. I've added the correction
few years ago at the wrong place.
I will release a new version soon.
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 wormbuilt 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 :-)
Is the bug in link004.com or in rspy?link004.com
Since the T212 sits on link 1 from TRAM slot 0I think you can "cut" the T2 off by simple removing the 2 middle jumper at J1.
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.
Hi Tom!in iserver. So, this binary has also changed.
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
-Mike
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.
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.
I'm continuing to study the source code in CSA Mandelzoom, and I feel I've been learning a lot about Transputer assembly.
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.
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 burndown your transputer system!
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.
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.
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.
If I run rspy /i /zmi 12 (or any higher number), then the test always fails with "Fatal-rspy-memory allocation failed"
Could this be an rspy bug?
Perhaps it's not freeing memory that it should, and since I only have 640K in this AT
I will change the boundary in the upcoming full build.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 335 |
Nodes: | 16 (2 / 14) |
Uptime: | 148:49:03 |
Calls: | 7,411 |
Calls today: | 1 |
Files: | 12,670 |
Messages: | 5,613,179 |