- Details
- Written by Scott G Taylor
Wisdom from Wayne Durkee
https://mailman.qth.net/pipermail/greenkeys/2023-April/058111.html
Adjusting the Selector Clutch Stop and Release Lever.
Make sure the semi captive plastic nut is in the rangefinder slide, cocked or crooked.
See the below image for Selector Clutch Stop and Drum gap checkpoints.
Is the gap between the drum brake lever (right of the blue gap) and the lever-stop (left of the blue gap) very large? [Ed: Need to inquire with Wayne on the measured gap expectation.] If so, the brake shoes are worn out. Compare to the other main shaft clutches gap.
- Details
- Written by Scott G Taylor
During the Fall of 2021, my Nissho PDP-11 (11/94 equivalent CPU in a PDP-11/34a BA11-K and DD11-PK chassis set-up) was humming along unmolested when it suddenly stopped communicating over Ethernet.
Installed in that machine was a Digital DELUA M7521 Network Interface board. And it decided to quit working.
Ethernet networking is important to me to be able to transfer large amounts of data from my simh PDP-11 2.12BSD (My versioning of a completely refactored 2.11BSD with many extensions) to the real PDP-11 machine for boot testing and performance. I also use that machine for imaging RL02 drive packs and utilizing SMD disks (CDC Sabre SMD, Mitsubishi SMD drives and a CDC RSD 80 megabyte cartridge drive).
There's really no finding DELUA boards easily, or affordably, any more.
My diagnosis, and resulting easy repair, follows.
The first thing that I noticed was that the power light was not illuminated on the transceiver bulkhead panel for the cable connection to the DELUA board.
The DELUA User Guide, EK-DELUA-UG-002, section 6.2.1 "Selftest" under "Troubleshooting" on page 6-1, states the following about indicator light at the bulkhead:
"If the DELUA fails its external loopback test, check the LED on the UNA bulkhead assembly that monitors the -15 V supply to the transceiver. There is also a circuit break on the UNA bulkhead assembly for the -15 V power to the transceiver."
The fuse at the bulkhead assembly was OK. But a VOM meter shows no voltage at the fuse.
Time to check the -15 V path coming from the backplane. According to the chart provided on page 2-2,
the -15 V feed is at "finger" F (bottom left-most edge connector #6 when facing component side), side B (aka Side 2), Pin 2 from the right.
Here's the pin on the connector:
I followed that thick trace from pin 2, along the edge of the board, going up to the top corner where the chassis lever is, to its termination at a through-hole junction to the component side. The component side is a through-hold fuse component which returns back to this side at the "Post-fuse connection" point identified. This circuit continues to the pin on the berg header to the left to which the bulkhead cable attaches:
I tested the voltage at the top - 15 V connection, and the voltage was there. The bottom connection was dead. I had found the failure.
On the component side, this is the -15 V circuit through-hole fuse component (after replacement):
I did not know the rating of the fuse that failed, not having found a schematic for the DELUA M7521 board. I did have, however, a failed DEQNA (Qbus Ethernet) board that had the same on-board fuse. I removed it from the scrap DEQNA, soldered it onto the DELUA, and it is now repaired and working. The full CZUAD diagnostics have passed.
I wish all board repairs were so easy, particularly because I do not have board extenders to diagnose faulty boards in-situ. Logic analyzers are not usable in the tight confines of a UNIBUS chassis with its board spacing.
- Details
- Written by Scott G Taylor
Today, while porting the MRY Print Spooler banner-page language processor to TOPS-20, I discovered that the KCC C Compiler does not support binary constants.
I really didn't want to re-code 4,600 lines of big-letter font C-headers.
So I added binary constants to KCC-6. It was trivial.
$diff -C 7 tops20:<kcc-6.kcc>cclex.c cclex.c
*** dist:<kcc-6.kcc>cclex.c Sun Mar 6 23:58:24 2022
--- work:<kccdist.kcc-6.kcc>cclex.c Mon Mar 7 20:27:17 2022
***************
*** 288,301 ****
--- 288,306 ----
if ((c = *cp) == '0') { /* Octal/Hex prefix? */
c = *++cp;
if (c == 'x' || c == 'X') { /* Hex (base 16) */
while (isxdigit(c = *++cp)) {
if (v & (017 << (TGSIZ_LONG-4))) ovfl++;
v = ((unsigned long)v << 4) + toint(c);
}
+ } else if (c == 'b' || c == 'B') { /* Binary (base 2) */
+ while (((c = *++cp) == '0' || c == '1')) {
+ if (v & (01 << (TGSIZ_LONG-1))) ovfl++;
+ v = ((unsigned long)v << 1) + toint(c);
+ }
} else { /* Octal (base 8) */
while (isodigit(c)) {
if (v & (07 << (TGSIZ_LONG-3))) ovfl++;
v = ((unsigned long)v << 3) + c - '0';
c = *++cp;
}
if (isdigit(c)) { /* Helpful msg for common error */
- Details
- Written by Scott G Taylor
The SIMH PDP-10 simulator from Richard Cornwell was updated to his Version 3 recently. See his posting to the SIMH message board on groups.io: https://groups.io/g/simh/message/1111
Having learned that it was supporting the DBD9 disk images for RP07, I decided to set up his version to boot my KLH10 images of TOPS-20 7.1 (my PANDA and SRI hybrid).
Things did not go particularly well, however.
I copied my system disk images (A dual-RP07 pair), and booted to standalone. I disabled most all services (networking, etc) in TOPS-20 and then shut down. I then disabled networking (the NI20 device) in SIMH, and then booted again.
Once booted, I ran a Dhrystone test on the Cornwell's SIMH PDP-10 (KL10B) and under KLH10.
SIMH reported 12936 dhrystones/second.
KLH10 reported 28355 dhrystones/second.
This was all fine and well, as I didn't expect SIMH to perform as fast as KLH10.
The problems encountered were due to the crashes that occur when booted under SIMH when any code compiled with the KCC C compiler is run. Many programs seem to just hang, but can be stopped with ^C. Some sort-of work, but TTY output is problematic. A simplified UNIX cat(1) program doesn't output to the TTY correctly. And many programs will crash TOPS-20. While I'm aware that there is code in KLH10 to accommodate the "Panda Lights" console-light hardware, I do not know of any changes to the underlying machine simulation particular to the Panda or SRI TOPS-20 kernel changes, nor any changes made to accommodate KCC C-generated machine code.
There is also something amiss with the SIMH PDP-10 timer support. Calls to the DISMS monitor JSYS result in waits (dismissals) that are 4 to 5 times longer than the milliseconds requested. That is, a one-second wait/dismissal request doesn't return for 4-5 seconds. Timer-based macro programming through DISMS is failing under SIMH.
I may investigate the SIMH PDP-10 issues/limitations at a later date. For now, I have satisfied my curiosity about the SIMH-based PDP-10 simulation functionality.
Page 1 of 5
