Embedded Files
Go to the earlier restoration blog.
1/4/23
The system booted and ran the "Hello World" program OK.
We replaced the 2N2646 Unijunction transistor Q4, the D-664 diode D14, the 2N4443 SCR D15, and the MDA 942-5 diode bridge on the G850 SCR driver flipchip that goes in slot A12 of the TU55 DECtape drive that is in the Processor cabinet.
The right hub motor works now, but it is always on in the strong torque mode. This could be a problem with the logic that controls the G850, or maybe there are still problems on the G850.
1/7/23
Lots of visitors, so not much debug time.
We had trouble reading the DECtape on the lower-right drive until the system had been powered on for an hour, and then it worked OK. The Hello World program loaded and ran OK.
We swapped the G850 Flipchip for the left and right hubs. The original G850 worked OK in both locations, and the repaired board drive the motor with full torque in both locations. Looks like it isn't repaired yet.
1/11/23
We spent the afternoon experimenting with running the FOCAL interpreter under ADSS. The FOCAL.BIN file needs to be loaded with GLOAD and will link to the RELEAE or RELNON library depending on if the machine is equipped with the EAE option or not. Unfortunately our PDP-9 only has 8k of memory so there is not enough memory to fit the LOADER, FOCAL.BIN, symbol table, and required parts of the library at the same time. For an 8k machine you can use CHAIN (most likely on a larger memory machine) to build FOCAL.XCT and FOCAL.XCU files. These files are prelinked with the required library routines and are loaded and run with the EXECUTE command. We have these files, but it looks like they were prelinked to the math routines from the RELEAE library. Since our machine does not have the EAE option the math in FOCAL doesn't work. We can't find any documentation for the CHAIN command in the PDP-9 or PDP-15 ADSS manuals. The DEC-XV-UCHNA-A-D-CHAIN_XVM_EXECUTE_XVM_UTILITY_MANUAL.pdf PDP-15 manual on Bitsavers has documentation on the CHAIN command for the XVM operating. The CHAIN command under XVM has a lot of options that are specific to the more complicated memory management on the PDP-15 so we will have a lot of trial-and-error work to figure out how CHAIN works on a PDP-9.
11/14/23
Lots of visitors, so nothing accomplished.
11/18/23
We are back to looking at the broken G850 FlipChips for the TU55 DECtape drives. We started by looking at the signal on the base1 of the 2N2646 Unijunction transistor of a working G850. The Unijunction transistor is a little strange, it has two bases and an emitter. You switch it on and off with the emitter. This signal is connected to ground through a 220 Ohm resistor and is used to fire the SCR and control the torque from the hub motor. Complex logic circuitry in the TU55 controls the torque and brakes on both hub motors to allow for smooth starting, direction change, and stopping of tape motion.
We looked at the base1 of the Unijunction transistor so we could see the current going through the transformer T1. On the base1 of the unijunction transistor we can see about 5mV of noise when the REMOTE/LOCAL switch is on the OFF position. In this case there is no motor drive at all and the brakes are off.
Details of the spike when the Unijunction transistor turns on. The positive spike 80us after the Unijunction transistor turns off is probably inductive kickback from the transformer T1. The diode D14 keeps the positive spike to a minimum so that the Unijunction transistor doesn't get destroyed.
In the LOCAL or REMOTE position, and when making low torque, we see 10uS -20mV spike about 6ms after the zero crossing. The SCR will turn on at the time of the spike, and turn off 2ms later at the zero crossing. Since the SCR turns on very late in the AC cycle very little energy is sent to the motor.
When making medium torque we see the same spike, but it occurs earlier, about 5ms after the zero crossing. This will fire the SCR earlier in the AC waveform, The SCR will stay on for 2ms suppling more energy to the motor, and making more torque.
When making high torque we see 9x spikes, the first occurs about 1.2ms after the zero crossing, and occurs every 800us. I think that the SCR will turn on at the first pulse and stay on for 7ms, making maximum torque.
The low and medium torque settings are adjustable with a Trimpot on the G850 Flipchip. The Trimpot adjusts the turn on time of the SCR, and therefore the amount of energy sent to the motor, and the torque that the motor makes. The low and medium torque of both hub motors need to be adjusted to optimize the tape motion.
We looked at one of the G850 FlipChips that does not drive the motor at all. This one has the expected single spike at low and medium torque, but also has another spike 2.5us later. The high torque spikes look OK, but the extra spike is also present. This one may have a bad D14. The second G850 has all of the correct signals on the Unijunction base1, but no motor drive. Both of these Flipchips may have failed SCRs.
We looked at the GATE signal on the SCR relative to the ANODE. On a functional G850 we see spikes that change for low, medium, and high torque. On the broken G850 we see just about 50mv of ripple at 60Hz and no changes when we press buttons on the TU55. Maybe diode D20 that conducts the pulses from the transformer to the SCR is broken?
1/21/23
It looks like the circuit on the G850 is similar to a Relaxation Oscillator used in a typical SCR based motor speed control. In the case of the G850 there are three different values of R that are enabled by the transistors Q1, Q2, and Q3. This yields three different oscillation frequencies. (We actually only see the oscillation in the high torque mode because the Unijunction transistor turns on early in the AC cycle.) The charging of the capacitor C is is also controlled by the voltage from the 54VAC transformer and the diode bridge. The three different resistance values in the G850 actually control how the capacitor gets charged by the AC voltage, and therefore the turn on point of the Unijunction transistor relative to the AC cycle. Because the hub motor in the TU55 runs on 115VAC the Unijunction transistor is connected to a transformer and then to the SCR to electrically isolate the Unijunction transistor from the SCR.
R5 is connected to transistor Q1 which is enabled by pin E, R9 is connected to transistor Q2 which is enabled by pin F, and R12 is connected to transistor Q3 which is enabled by pin H. Enabling pin E yields medium (Stop/Rest) torque, pin F yields low (Drag) torque, and pin H yields high torque. We measured the R5 & R9 Trimpot resistance on three different G850 Flipchips to get average values of 21.7kOhms and 28.6kOhms. R12 has a fixed value of 5.6kOhms. The delay for triggering the SCR from the start of the AC cycle for low torque is about 6us, for medium torque it is 5us, and for high torque it is about 1.2us. The longer the SCR is turned on, the more energy is sent to the motor, and the more torque it will make.
To turn on the SCR on the G850 we need to have a positive voltage on the Gate relative to the Cathode. When one of the transistors Q1, Q2, or Q3 is turned on, the Unijunction transistor Q4 will turn on during each positive or negative excursion of the AC voltage. When Q4 turns on it will send a pulse through transformer T1 which will send a positive pulse through diode D20 and into the SCR gate. When the SCR turns on energy will flow through the hub motor until the AC voltage reaches zero volts and the SCR turns off.
We looked at the voltage on the SCR Gate voltage relative to the SCR Cathode on a working G850.
We looked at the voltage on the SCR Gate voltage relative to the SCR Cathode on a broken G850. When configured for no torque we saw the expected 1/2 sine-wave signal, but the negative excursion was only 100V where it was the expected 175V on the working G850. Maybe a bad SCR?
We looked at the voltage on the SCR Gate voltage relative to the SCR Cathode on the broken G850 that had the extra pulse. This one had the expected 170V negative excursion. There was no change in the waveform when configured for medium or high torque. Maybe a bad diode D20? Nope, the voltage drop across diode D20 looks OK. The transformer T1 primary & secondary winding resistance is only a few Ohms, so that looks OK. That leaves the SCR as the most likely failed component. We will replace that next week, and also check the diode D14.
1/25/23
The diode D14 on the G850 with the extra pulse both had correct forward and backward voltage drops, so it is probably OK. We checked the diodes in both bridges, and they are both OK. We replaced the SCR, D15, a 2N4443. We also checked the big power resistor, R3. It measured a little above the expected 1800 Ohms, so it is OK. There is still no motor drive.
The PDP-9 boots OK, but won't talk to the VT220 or the Teletype.
1/28/23
We toggled in a little console loopback program. If we type characters on the VT220 keyboard about once per second the loopback is OK. If you type faster sometimes the TTI receiver contains a random number of ones, always right justified, instead of the character. This could be caused by many possible problems in the processor. Time to run the instruction diagnostics.
We ran MAINDEC-9A-D01A Instruction Test Part 1, and it ran OK. We also heard a beep from the VT220 console about once per second when the diag completed. That means that the output part of the serial console is working OK.
We ran MAINDEC-9A-D02A Instruction Test Part 2, and it immediately halted at address 01261. This halt equates to E1245 where is tested an ISZ instruction using memory address 2. We restared the diag and it halted at 05327. This equates to E1506 where it checks an auto-index indirect XOR instruction. It does a LAC 6347 to get the constant 777777, and does a DAC 17700. Memory location 10 contains 17700, so the auto-index worked. Memory location 17700 contained a 137777 instead of 177777, so it dropped bit 3. The AC contained 010000 instead of 000000 so it halted.
We hit continue, and the diag ran until it halted at 05327. It had dropped bit 3 again. We can manually deposit and examine all bits at address 17700.
We hit continue, and the diag is running OK now. Maybe something isn't working when it is cold?
ADSS booted from DECtape OK. We will try this again on Wednesday when the machine is cold.
1/28/23
Frank Pascucci, an ex-DEC Connecticut field service engineer, donated a very special Magnetic Tape tester that works with the TU20 magnetic tape drive on the PDP-9. This will be very helpful when we get back to working on the TU20.
2/4/23
Bill Degnan of the Kennett Classic Computer museum donated a BC09A-7 PDP-9 I/O cable. We have been looking for some of these cables for about 10 years because we didn't get any with the PDP-9. You need 2x BC09 cables to connect the processor to a controller like the TC02 and TC59, or to daisy-chain the I/O bus between controllers. We substituted 8x PDP-8 I/O cables for 2x BC09 cables so we could use the TC02 DECtape controller. The PDP-8 I/O cables don't have active Thevenin termination on them like the BC09 cables, so we may have excess noise on the I/O bus. We need 3x more of these cables, and Anders Sandahl also needs some of these cables for his PDP-9. We will make CAD files for the W850 FlipChips that are on the ends of the cable and get some made. The electrical components on the W850 are DEC D662 to make the -3V clamp voltage, DEC D664 diodes for the positive and negative clamps, a few 0.01 uF disc capacitors, and some 2W 270 Ohm resistors. Each cable consumes 400 mA @ -15VDC for the termination. The original Mohawk cable is 0.58" diameter, 24 AWG with 7 strands per conductor, 37 pair, 72 conductor, and has 6 pairs in the center, 12 pairs in the middle layer, and 18 pairs in the outer layer. The characteristic impedance of the cable is 68 Ohms, with a propagational velocity of 1.8 ns/ft, and a capacitance of 25 pf/ft.
The PDP-9 booted ADSS and ran Hello World.
2/8/23
The PDP-9 seems to be behaving and is demonstrable. W still have quite a few things to fix, and possibly a disk emulator to make. We are using KiCAD to make a clone of the W850 FlipChips on the ends of the I/O cables. We will take a break from this machine for a while and fix the PDP-8/I and the PDP-12.
4/1/23
We demonstrated the machine to a visitor. It took several tries to get ADSS to boot because of DECtape errors.
4/15/23
We demonstrated the machine to a visitor. It booted ADSS on the first try, and linked and ran HELLO on the first try.
6/17/23
We moved the PDP-9 to the new RICM Lab space. We have enough power so we can resume work on the TU20 tape drive. We will swap the individual PDP-8 I/O cables for PDP-9 BC09 I/O cables. It will be interesting to see how much work it takes to get the PDP-9 running again.
7/8/23
The PDP-9 processor seems to be alive. The build in maintenance mode circulates data to all of the registers. We can read and write core memory. It will execute JMP instructions. The next project is to wire the power plug on the I/O cabinet, connect the processor to the TC02 DECtape controller with the new BC09 I/O cables that we got recently, and see if it will boot ADSS.
7/12/23
We put a 30A twistlock on the power cord for the I/O rack, and connected the remote control power cord from the I/O rack to the processor rack. When the processor is powered on, the I/O cabinet powers on. The next step is to connect the processor to the TC02 DECtape controller with the new BC09 I/O cables that we got recently, and see if it will boot ADSS. We also need to make a short BC09 cable from the two cut cables so we can connect the TC02 I/O bus to the TC59 I/O bus.
7/15/23
It isn't obvious how to connect the BC09 I/O cables between the PDP-9 processor and the TC02 DECtape controller. Two BC09 cables are used for the I/O bus. Each BC09 cable has two paddle boards, and each paddle board has two single-sided card-edge connectors. The processor and the I/O Controllers each have two sets of I/O bus connectors. On the processor the two sets of connectors can be cabled to two different I/O controllers. The I/O controllers are designed to be daisy-chained, so one set of connectors is for the cables that go towards the processor, and the other set of connectors goes to the next controller on the bus. On our system the TC02 DECtape controller will be wired like Device C and the TC59 Magnetic Tape controller will be wired like Device B in the diagram to the right.
The PDP-9 Users Manual says that the input connector pairs are at the bottom left of the controller when viewed from the front. The output connector pairs are to the right of the input connector pairs. The total length of the I/O cables is 50 feet.
On the processor the first set of I/O Cables plug into slots AB25 & AB26 and the second cable plugs into slots AB27 & AB28. The second set of I/O Cables plug into slots AB29 & AB30 and the second cable plugs into slots AB31 & AB32.
Processor:
Pin AB25AD is IO BUS 00, pin AB26AD is IO SYNC.
Pin AB27AD is IO RUN (1), pin AB28AD is WR RQ.
TC02 Dectape:
Pin EF01ED is IO BUS 00, pin EF02ED is IO SYNC.
Pin EF03ED is IO RUN (1), pin EF04ED is WR RQ.
So, the first cable goes from the processor slots AB25 & AB26 to the TC02 slots EF01 & EF02. The Second cable goes from the processor slots AB27 & AB28 to the TC02 slots EF03 & EF04.
The TC02 is now cabled to the processor with the BC09 cables.
We can't find the ADSS V5A DECtape that we have been using. We tried the ADSS V5A DECtape that also contains FOCAL, but it constantly gets parity errors and will not boot. We tried the ADSS V4E DECtape. That booted, but we know that it always gets .SYSLD 4 errors, it just proves that the processor is running OK. After a few more tried the ADSS V4E tape would no longer boot. The processor is getting stuck in an instruction loop somewhere. Time to run the processor diagnostics.
7/19/23
Somehow during the move the paper tape punch power switch got turned on. The switch is broken, so we could not turn the motor power off. We disconnected and labeled the white power wire at the back of the punch below the data ribbon cable.
We loaded MAINDEC-9A-D01A Instruction Test Part 1 and set the switches to 777700. We started the diag at address 13041. It immediately halted at address 00023 E1. Core address 00022 should contain a SKP instruction, 741000, but it contained 753042. We fixed the contents of address 00022 and restarted the diag at address 13041. It immediately halted at address 00023 E1. Core address 00022 should contain a SKP instruction, 741000, but it again contained 753042. We set Single-Step on and it halted at 00023.
We compared the instructions in memory with the diag listing. We found several errors at the very beginning. We fixed address 00022, address 00023 was OK, and addresses 00024 and 00025 contained zeros. We tried to fix address 00024, and it always returns zeros. We need to fix the core memory before anything will run.
We set the data switches to 777777 and deposited that value in memory locations 00000-00077. When we examined memory we found that locations that ended with 0, 1, 4, and 5 contained zeros. This pattern is the same throughout the whole 8kW of memory.
We toggled in a program in addresses 2, 3, 6, and 7 that jumped to the next address in the sequence and then back to address 2. The program runs OK, and the contents of memory after running is also OK. That means that most of the processor is running OK, the interface to the memory controller is OK, all of the memory bits work, and we just have a memory addressing problem. The problem could be a bad address from the processor, or an address decoding problem in the memory controller.
We swapped the B169 flipchips in locations C28 and C36. These are the address and data input multiplexors for bits 16 & 17. There was no change in the behavior. We swapped the B169 flipchips in locations C29 and C35. These are the address and data input multiplexors for bits 14 & 15 .There was no change in the behavior.
On Saturday we will look at the B213 flipchips that implement the MA to make sure that all of the bits are working. We can also use the Maintenance Panel Examine and Deposit functions to see if the data from the processor is getting to the memory controller.
7/29/23
After studying the defective addresses, it looks like the fault only occurs when MA bit 16 is a zero. In the Digit Drive circuit the signals MA16A(0), MA16A(1), MA16B(0), and MA16B(1) are used to drive all of the G219 flipchips. All of these signals come from the B213 Jam Flip-Flops in slots A16 and C16. We swapped the B213 Flipchips in slots A16 and C16. Oops, that was the wrong pair to swap. In this case any address with MA bit 16 a 1 didn't work. At least we know the problem is one of the B213 boards. We swapped the B213 Flipchips in slots A16 and B16. Now the memory is a mess, and I don't see a specific pattern to the problem. We swapped the B213 Flipchips in slots A16 and B16, and now the memory is back to the original problem. We swapped the B213 in slot A16 with spare, and now the memory is working for all addresses.
We loaded and ran MAINDEC-9A-D01A Instruction Test Part 1. It halted in a weird state, so we are not sure what went wrong. We set the processor for single step, repeat, and set the repeat speed at the slowest setting. The processor runs the diag for quite a while, and then stops with 407540 in the MB and nothing in the AR and AC. Maybe the XCT instruction isn't working? After a reset 001341 was in the PC and still nothing in the AR or AC. There is no XCT instruction near address 001341. We need to reverse-assemble the diag so we can compare the listing to the contents of memory. It looks like it doesn't match.
8/5/23
We loaded and ran MAINDEC-9A-D1AA PDP-9 Basic Memory Checkerboard Test. It ran for about 30 seconds and then halted at address 000222. The AC contained 017515 which is the address of the error. The core memory location should have contained 000000, but contained 002000. The Pattern Control Word was 037700. We restarted the program and observed the same error. We suppressed bit-7 errors and it quickly halted with a bit-6 error. We suppressed bit-6 errors and now it runs continuously. After running for a few minutes we reset the diag to test all bits and it worked OK. Maybe there are some minor voltage or timing adjustments to do so it will run when it is cold.
We loaded and ran MAINDEC-9A-D0BA ISZ Test. It ran OK.
We loaded and ran MAINDEC-9A-D0CA Memory Address Test. It ran OK.
We loaded MAINDEC-9A-D0DB JMP Self Test, but it ran off the end of the paper tape. We have successfully run this in the past. Power cycling the machine didn't help.
We loaded and ran MAINDEC-9A-D0EA JMP-Y Interrupt Test. It ran OK.
We loaded MAINDEC-9A-D1FA PDP-9 Extended Memory Address Test, but it actually ran the previously loaded D0EA diag.
8/8/23
The source code listing for MAINDEC-9A-D01A Instruction Test Part 1 at the end of the documentation is just the source code and a symbol table. That makes it a little more difficult to determine if the instructions in core memory are correct, and to determine what the diagnostic was trying to do when it failed. I wrote a program in C# that reads the binary diagnostic paper tape image and creates a compiled listing, a source code listing, and a symbol table. You can also manually enter symbols in a CSV file to make the listing more accurate. I am now trying to get the D01A source code onto a Simh DECtape image so I can assemble it using the PDP-9 MACRO Assembler. This is proving to be challenging, but I will get it done.
8/12/23
We loaded and ran MAINDEC-9A-D0CA Memory Address Test. After 20 minutes it said that address 17213 was 760565 and should be 067772, and address 17214 was 760564 and was 237765. It also said that locations 17215 and 17217 were bad, but the contents were 760563 and 760561 which matched the good and bad. That is a little strange. It has been running for much longer than 20 minutes and has not reported any more errors.
We tried to load MAINDEC-9A-D0DB JMP Self Test. It didn't stop and the end of the program, so it didn't load correctly and did not run correctly.
The indicators on the TC02 DECtape controller were all off. After some investigating we found a bad crimp on the faston terminal that supplies -15VDC to all of the indicators. Replacing the faston got the indicators back to normal.
We loaded and ran MAINDEC-9A-D1AA PDP-9 Basic Memory Checkerboard Test. It immediately halted a 00223
Error Address Should Be Was Pattern
14015 000000 002000 037700
14016 000000 004000 037700
14116 000000 002000 037700
16054 000000 002000 037700
16474 000000 002000 037700
17074 000000 002000 037700
17114 000000 002000 037700
17406 777777 777767 037700
17415 000000 002000 037700
17515 000000 002000 037700
17515 000000 002000 037700
17515 000000 002000 037700
We swapped the G219 flipchips in slots AB09 and AB10 for bits 7 & 6 and it successfully ran the diagnostic. It even ran OK after swapping the flipchips back to their original locations. After running for about 30 minutes bit-7 failed at 17515. Time to wiggle the Sense Amplifiers in EF09 & EF10. It quickly failed bit-7 at 17515. We swapped the G219 flipchips in slots AB09 and AB10 again, and it ran the diagnostic for an hour without failures.
8/16/23
We ran MAINDEC-9A-D1AA PDP-9 Basic Memory Checkerboard Test. It immediately halted at 00223.
Error Address Should Be Was Pattern Comment
17400 777777 773777 740076 Dropped bit-6
17400 777777 773777 740076 Dropped bit-6
17400 777777 773777 740076 Dropped bit-6
Swapped the G009 Sense Amplifiers for bit-5 (B23) and bit-6 (B24)
17662 000000 040000 037700 Picked up bit-3
17510 777777 577777 037700 Dropped bit-1
17515 000000 002000 037700 Picked up bit-7
17662 777777 737777 740077 Dropped bit-3
16000 777777 737777 740076 Dropped bit-3
Swapped the G009 Sense Amplifiers for bit-2 (A24) and bit-3 (A25)
17412 777777 677777 037700 Dropped bit-2
17452 777777 677777 037700 Dropped bit-2
17510 777777 577777 037700 Dropped bit-1
17511 777777 677777 037700 Dropped bit-2
17571 777777 677777 037700 Dropped bit-2
17720 777777 677777 037700 Dropped bit-2
17412 000000 100000 740076 Picked up bit-2
Replaced the G009 Sense Amplifier for bit-2 in (A24)
17510 000000 200000 740076 Picked up bit-1
17510 777777 577777 037700 Dropped bit-1
17515 000000 002000 037700 Picked up bit-7
17610 000000 200000 340076 Picked Up bit-1
Replaced the G009 Sense Amplifier for bit-1 in (A23)
15250 000000 200000 340077 Picked up bit-1
14310 000000 200000 740077 Picked up bit-1
16330 000000 200000 740077 Picked up bit-1
Replaced the G009 Sense Amplifier for bit-1 in (A23)
17515 000000 002000 067700 Picked up bit-7
17515 000000 002000 067700 Picked up bit-7
17515 000000 002000 067700 Picked up bit-7
Replaced the G009 Sense Amplifier for bit-7 in (B25)
14015 000000 002000 067700 Picked up bit-7
14056 000000 002000 067700 Picked up bit-7
14116 000000 002000 067700 Picked up bit-7
14166 000000 002000 740077 Picked up bit-7
Replaced the G009 Sense Amplifier for bit-7 in (B25)
10015 000000 002000 07700 Picked up bit-7
10176 000000 002000 067700 Picked up bit-7
10416 000000 002000 067700 Picked up bit-7
12436 000000 002000 067700 Picked up bit-7
Swapped the G219 Memory Selector for bit-7 and bit-8 in (AB09 and AB10)
12055 000000 002000 067700 Picked up bit-7
12074 000000 002000 067700 Picked up bit-7
12414 000000 002000 067700 Picked up bit-7
12415 000000 002000 067700 Picked up bit-7
Swapped the B169 Inverter for bit-6/7 and bit-8/9 in (C31 and C32)
10015 000000 002000 067700 Picked up bit-7
10150 000000 002000 740077 Picked up bit-7
11431 777777 775777 037700 Dropped bit-7
11451 777777 775777 037700 Dropped bit-7
We noticed that bit-14 is always on for the faulting address. Maybe a MA register problem? We will check that later.
Swapped the G219 Memory Selector for bit-6 and bit-7 in (EF09 and EF10)
10015 000000 002000 037700 Picked up bit-7
10250 000000 002000 740077 Picked up bit-7
10116 000000 002000 037700 Picked up bit-7
11456 000000 002000 037700 Picked up bit-7
Swapped the G219 Memory Selector for bits-0/1/2/3 and bits-4/5/6/7 in (HJ23 and HJ24)
12415 000000 002000 037700 Picked up bit-7
12436 000000 002000 037700 Picked up bit-7
12455 000000 002000 037700 Picked up bit-7
12474 000000 002000 037700 Picked up bit-7
8/23/23
Swap the flipchips that make up the MA register
We ran MAINDEC-9A-D1AA PDP-9 Basic Memory Checkerboard Test. It immediately halted at 00223.
Error Address Should Be Was Pattern Comment
12054 000000 002000 037700 Picked up bit-7
12055 000000 002000 037700 Picked up bit-7
12074 000000 002000 037700 Picked up bit-7
12414 000000 002000 037700 Picked up bit-7
12444 000000 002000 037700 Picked up bit-7
We disabled checking bit-7, and the diagnostic runs OK
8/26/23
We ran the MAINDEC-9A-D0CA Memory Address Test. It immediately failed:
INDIVIDUAL LOCATION TEST
ADDRESS GOOD BAD
000020 777757 002020 Should contain the compliment of 000020
WRITE ONES IN A FIELD OF ZEROS
ADDRESS GOOD BAD
000014 775777 777777 Bit-7 should have been a 1 but was a 0
000030 775777 777777
000031 775777 777777
000044 775777 777777
000050 775777 777777
000054 775777 777777
After reloading D0CA it reported a single Individual Location Test error, and ran without errors.
We ran MAINDEC-9A-D02A Instruction Test Part 2.
It immediately halted with the PC=1401 which is E1265. The diag loads the contents of address 06347 (all ones), saves it to address 14000, does and ISZ, and it should skip. It did not skip. The AC=777777 so the contents of address 06347 was OK. Address 14000 contains 776000 so the ISZ did not work correctly. Maybe the carry from bit-8 to bit-7 did not happen which left some ones in the memory?
We continued the diag and it immediately halted with the PC=1404. which is E1266. This is just a check of the contents of address 14000 to make sure that it was all zeros. It was 76000 so it halted.
We continued the diag and after a few seconds it halted with the PC=00503 which is E1165. The diag loads the contents of 06370 (777775), saves it in 177775, and will halt of the contents of the AC is different from memory. The AC and memory are both 7777775, so it should not have halted.
We continued the diag and it halted at 00503, 01401, 01404, beeped to indicate that it completed a diag pass, and halted at 00503.
We verified the instructions in locations 00476-00502, and they were OK. We verified that location 06370 contained 777775, and that the AC=777775. We single stepped the instructions starting at 00476. The LAC instruction loaded the AC with 777775. We examined the contents of address 17775 with the intent of changing it to zeros before we executed the DAC instruction. We were surprised to see that it contained 775775 because it had dropped bit-7. Maybe this really is a bit-7 memory problem and the processor is OK. We executed the DAC and the contents of address 17775 were 777775. This time the SAD & SKP instructions worked correctly.
Time to investigate how the SAD (Skip if Accumulator Differs) instruction works. The F-97 Maintenance Manual Volume 1 describes how the PDP-9 works. The SAD instruction is described in section 3.5.6.10 on page 3-42. It looks like when the SAD instruction does a memory fetch it drops bit-7 so the compare fails. Time to go back to fixing the core memory.
We loaded MAINDEC-9A-D1FA PDP-9 Extended Memory Address Test. It didn't autostart and wouldn't run when started from 00100.
We loaded MAINDEC-9A-D0CA Memory Address Test. It ran without errors.
We loaded MAINDEC-9A-D1BA PDP-9 Extended Memory Checkerboard Test. The program loaded and ran, but listed lots of memory addresses where the contents should have been zeros and contained data. I couldn't determine any pattern to the problem data. I am not convinced that the diagnostic got loaded into memory correctly.
We ran MAINDEC-9A-D1AA PDP-9 Basic Memory Checkerboard Test. It immediately halted at 00223.
Error Address Should Be Was Pattern Comment
10015 000000 002000 037700 Picked up bit-7
10055 000000 002000 037700 Picked up bit-7
10055 000000 002000 037700 Picked up bit-7
10176 000000 002000 037700 Picked up bit-7
8/30/23
We looked through the Module Utilization chart to find all of the FlipChips that are used to implement bit-7. We moved the G795 Level Terminators from slots D38 & E38 to slots D39 & E39 to match the Module Utilization chart. That should not make any behavioral difference.
We wiggled all of the FlipChips that that are used to implement bit-7 in the core memory.
We ran MAINDEC-9A-D1AA PDP-9 Basic Memory Checkerboard Test. It immediately halted at 00223.
Error Address Should Be Was Pattern Comment
10415 000000 002000 037700 Picked up bit-7
10416 000000 002000 037700 Picked up bit-7
11075 000000 002000 037700 Picked up bit-7
11076 000000 002000 037700 Picked up bit-7
11156 000000 002000 037700 Picked up bit-7
11265 000000 002000 740077 Picked up bit-7
11437 000000 002000 037700 Picked up bit-7
We swapped the G795 FlipChips between slots D39 & E39. It is still picking up bit-7.
We swapped the W612 FlipChips between slots B26 & B27. It is still picking up or dropping bit-7.
We swapped the G009 FlipChips between slots B24 & B25. It is now picking up bit-6.
We replaced the G009 in slot B24 with a spare, and it ran for a few seconds without errors. Now it is back to picking up or dropping bit-7.
We replaced the G009 in slot B24 with a spare. It is picking up or dropping bit-7.
We replaced the G009 in slot B24 with a spare. It is picking up or dropping bit-7.
We swapped the G009 FlipChips between slots B24 & B25. It is now picking up or dropping bit-6.
We replaced the G009 in slot B24 with a spare. It is now running MAINDEC-9A-D1AA PDP-9 Basic Memory Checkerboard Test OK. We let it run for 30 minutes just to name sure everything in the core memory was OK.
We ran MAINDEC-9A-D01A Instruction Test Part 1 for a few minutes to make sure that the processor is OK.
We ran MAINDEC-9A-D02A Instruction Test Part 2. It halted at 02013, E1311. We restarted the test sequence at 02002 where it did a LAC from 06751 which contained 602007, JMP 2007. It then did a DAC to 06567, and another DAC to 00020. It then did a JMP to 00020 which contained a JMP 02007, and then a JMP to 2007. This instruction sequence looks a little strange. Now it did a DZM to 6567 which worked and overwrote the JMP 2007. Next it did a LAC from 6570 which contains a JMP to 02020. Then it did a SZA where the AC contained 602020 so it did not SKP and halted at 02012. We looked at location 06751 and it contained the expected 602007. We cleared location 06570 and continued running D01A. It halted again at 02013, and location 06570 contained a JMP to 02020. There is a JMP to 02020 stored in location 06752. The test after the failing test loads the JMP 02020 from location 06752 and stores it in location 06750. The next test does a DZM to 06570 so it should contain zeros. Maybe the DZM to 06570 isn't working all the time?
9/2/23
We looked at the test code around the HLT at E1311. We found that location 2020 contained a DZM 6170 instead of a DZM 6570. That caused the previous test to fail and halt at address 2013. We fixed the instruction and now MAINDEC-9A-D02A Instruction Test Part 2 runs OK.
We tried to boot the ADSS operating system from several different DECtapes. Some will boot but not respond to console commands, some get Timing and Parity errors when reading. We decided to run MAINDEC-9A-D3BB TC02 Basic Exerciser to see if the TC02 DECtape controller and the TU55 DECtape drives are working OK.
Some of the tests run OK, but try to use blocks beyond the end of the DECtape. It looks like the END bit in Status Register B is not getting to the CPU. Fixing that will be the project for Wednesday.
9/6/23
We toggled in a little program that lets us send the switches to the TC02 Status-A register and control the motion of the DECtapes. If we move the tape into the End Zone the motion should stop. It turned out to be more complicated than that.
We ran the MOVE SCOPE LOOP function in MAINDEC-9A-D3BB TC02 Basic Exerciser. This test runs the DECtape until it hits the End Zone, reverses direction, runs until it hits the other End Zone. This seems to be working OK, so it must be able to read the END error in bit-2 of Status Register B.
The Search Scope Loop (0), Search Scope Loop (1), Read Scope Loop (2) tests within D3BB all worked OK today. The Search Find All Blocks test is looking for block number 1102 and going into the End Zone. There are only 1101 blocks on the tape, so this error should not happen. The project for Saturday will be to find out why it is searching beyond block 1101.
9/9/23
While running D3BB we noticed that DATA BUFFER indicator 3 is always on. After disassembling the indicator assembly and testing transistors we found a bad solder joint on a cable between the TC02 controller and the indicator panel. It would have been just a few minutes work to fix the cable if we knew that was the problem. We fixed the bad solder joint and all of the indicators are working now.
We continue to run D3BB trying to find what works and what doesn't. Test #5 Read/Write Data Test seems to work OK it it is configured to test 16 blocks at a time. If it is configured to do the whole tape it will try to write or read block 1102 which doesn't exist.
We toggled in a little program to test the LAS, LAC & TAD sequence that is used to configure the number of blocks. That seems to work OK.
The processor ran DECtape diagnostics for several hours today, so it seems to be pretty solid.
The last block number on the tape is 1100 (octal) -1 and is stored in ENDBLK @ 00272 (contained 001077 which is correct). The block in the End Zone is 1101 and that value is stored in EZBLOK @ 00271 (contained 001100 which is correct).
The subtest that searches for all blocks is SRCHTS @ 01167. It looks like the block number is stored in RECORD @ 00641. The subtest looks for all blocks until it gets to the End Zone block #1100.
9/13/23
We had a tornado a few miles from here today. That was exciting.
We need to look at the details for how the DECtape is formatted for a PDP-9. The block numbers should go from 0 to 1077 octal for a total of 1100 octal blocks. I believe that there is another block, # 1100 and maybe also a block #1101 that are actually in the end zone. Maybe the D3BB diag isn't working quite correctly and should stop looking for more blocks when it gets to the end zone. The diag calculates the last block as 1077, so I am not sure why it is looking beyond that block.
The DECtape formatter program says that it defaults to writing 1102 octal blocks numbered from 0000 to 1101, with each block containing 400 octal words.
9/16/23
The TC02 DECtape Controller manual says that a tape has 1100 octal (576 decimal) addressable blocks per tape. So, the blocks between the end zones would be numbered 0000 through 1077 octal. There is more information later in the manual that says the blocks are numbered from 0001 to 1100, and that there is also a block 0000 and 1102. Based on this blocks 0000 and 1102 are in the two end zones.
The PDP-9 User's Manual has more information on DECtapes. It says that blocks 0 and 1101 are next to the end zones. It says to not use these blocks because you will end up in the end zone when doing a turnaround. It also says you can put one block length of zone marks between the end zone and the first/last block so that you can bounce off the end zone and still have time to get the tape up to speed before you find the first block.
I booted ADSS V5 on Simh, and the the directory listing from the ADSS operating system says that the monitor file starts at block 0, so that block can't be in the end zone. I tried several other ADSS tapes and got the same results. The DECtape boot program starts loading ADSS from block 0, so another vote for block 0 not being in the end zone. I wrote a tool in MS C# that will dissect DECtape images. I opened the V5A ADSS DECtape image. It has blocks numbered 0000-1077. The V3C ADSS tapes has blocks from 0000-1100. Block 1077 has a pointer to block 1076, so that is the last block used by ADSS. Maybe there are several different DECtape format versions available? The ADSS manual says that non-file-oriented DECtapes have blocks numbered 0-1077. On the ADSS source code tapes the first file starts at block 1. It seems consistent that the kernel file starts on block 0, but if there is no kernel file and there is a source file it starts on block 1.
I looked at the source code for the DEC-9A-EUFC DECtape Format Generator program. It says that it makes blocks numbered 0000-1101. We have the paper tape image for DEC-9A-EUFA, and the documentation for DEC-9A-EUFC.
9/23/23
The MAINDEC-15-D4AF TC-59 Instruction Test has a good Data-Break test that the TC02 doesn't support. We need to make one short BC-15 I/O cable from two cut cables so we can connect the TC59 magnetic tape controller to the TC02 DECtape controller and have both controllers connected to the processor at the same time. The BC15 cable has connections on both sides of the finger-edge connectors, where the BC09 only uses one side. We have short BC15 cables and no more BC09 cables, so we will use what we have.
We tried running MAINDEC-EUFA to format a DECtape. The standard format is 576 decimal or 1100 octal blocks of 256 decimal or 400 octal blocks. So the blocks should be numbered 0000 through 1077 octal. The tape moved a little, and then it displayed a Timing error motion stopped. During the week we will investigate how the TC02 does tape formatting and find out how the Timing error bit can be set.
9/27/23
We tried running MAINDEC-EUFA again, but this time we waited to set the toggle switch to WRTM after the program asked instead of before. It wrote the Timing and Mark tracks, but ran off the end of the tape. We respooled the tape, set the toggle switch to NORM, and pressed a key on the console terminal to continue formatting the tape. It ran for a few seconds, did a quick reverse and forward, and the light pattern changed on the TC02 display. This means that it found the End Zone, detected the end of the End Zone, and started writing block headers on the tape. That means that the Timing Track and the Mark Track were written onto the DECtape. It did not run off the end of the tape, but it reported a Mark Track Error. This could either be a problem with the DECtape itself, the DECtape transport, the DECtape controller, or the processor.
We tried another DECtape, and it also ran off the end of the tape. We respooled the tape, set the toggle switch to NORM, and pressed a key on the console terminal to continue formatting the tape. It did not run off the end of the tape, but it reported a Mark Track Error.
We tried another DECtape drive with the previous DECtape and it ran off the end of the tape. We respooled the tape, set the toggle switch to NORM, and pressed a key on the console terminal to continue formatting the tape. It did not run off the end of the tape, but it reported a Mark Track Error.
All three attempts yielded the same results, so the problem is not with the DECtapes and the DECtape drives. Since it ran off the end of the DECtape either the DECtape drive speed is too slow, or the clock used to write the Timing Track is to slow. We need to insure that the CLK signal from the R401 flipchip in slot D29is really generating a 120 kHz signal. It is possible that the capacitors in the RC network for the clock are a little off after 55 years so we may need to adjust the clock. Maybe we could adjust the clock a little high so it doesn't run off the end of the DECtape when formatting.
9/30/23
We tried to look at the 120 kHz CLK signal on pin D of the R401 in slot D20. We found that the T/M ENABLE signal on pin S needed to be active to turn the CLK signal on, which meant that the formatter program needed to run. When we enter the DECtape drive number the program prints a "?" and reprints the prompt. We looked at the TTI display on the console and could see that a 370 (octal) was loaded into the console input when it should have loaded 260 (octal). Looks like next Wednesday We need to fix the console serial port before we can work on the DECtape controller again.
10/4/23
We are back to debugging the serial console using the VT220 terminal. We verified that the VT220 was configured for 110 baud, 7 bits, mark parity, and 2 stop bits.
We configured the PDP-9 console to display TTI, which is the serial console input register. We entered a few characters on the VT220 and didn't get what we expected in the TTI. A=340 (should be 301) , B=341 (should be 302), C=341 (should be 303), D=342 (should be 304), 1=330 (should be 261), 2=331 (should be 262), 3=331 (should be 263). It looks like bit-11 is stuck on. It isn't obvious if this is a problem with the PDP-9 or the VT220.
We repeated the same tests with an ASR-33 Teletype connected to the serial console port. A=300 (should be 301) , B=377 (should be 302), C=341 (should be 303), D=377 (should be 304), 1=330 (should be 261), 2=377 (should be 262), 3=377 (should be 263). Well, that didn't prove much. I am pretty sure that the Teletype is working correctly.
We repeated the same tests with PuTTY, a USB Serial Cable, and an RS-232 to 20 mA current loop converter connected to the serial console port. A=377 (should be 301) , B=377 (should be 302), C=377 (should be 303), D=377 (should be 304), 1=377 (should be 261), 2=377 (should be 262), 3=377 (should be 263). I am pretty sure that PuTTY, the cable, and the converter is working are correctly. We tried Warren's modified terminal emulator with the same results. It is possible that the FTDI USB Serial cable will not work at 110 baud, or that the RS-232 to current loop adapter is broken.
We ran the DECtape Formatter program to get some serial console output. At 110 baud each bit was 9 ms long. When transmitting each bit was a little less than 9 ms long. At least we know that the baud rate of the PDP-9 and the USB serial cable match. Note, the high-order bits exit the serial port first.
We connected the oscilloscope to the output of the VT220 and pressed the "U" key. We saw alternating ones and zeros as expected.
We connected the ASR-33 Teletype to the PDP-9 serial console and ran the DECtape formatter. The program displayed the right output, accepted input, and worked OK. It did not run off the end of the tape on any of the four passes. The formatter said that the tape has 1100 (octal) blocks. The blocks should be numbered 0000 through 1077 (octal).
The TTI register contains the right data, A=301 and 0=260 (octal). I connected the VT-220 to the PDP-8/I, and it seems to work OK. After a few minutes the PDP-8/I broke. No register lights are displayed on the console, so maybe a power supply has failed.
The ASR-33 made some horrible noises and now the motor shaft is jambed. Looks the ASR-33 is broken too. I was able to unjamb the ASR-33, and it looks like it is working again. Spoke too soon. After running for 10 minutes it jambed again. This is getting very frustrating.
11/4/23,
We fixed the PDP-8/I so now we can get back to the PDP-9.
We fixed the bad solder joint on the 20mA input cable to the ASR-33 Teletype, so that is working much better now. The bad solder joint was held together with shrink tubing so we could not see the problem. It a lot of wire wiggling to find the problem. We think that the bad solder joint was causing erratic data received by the Teletype, and caused mechanical problems in the printer.
The VT220 terminal seems to be working OK. We need to look at the VT220 manual to see what bit patterns are sent by the keypresses and then look in the PDP-9 TTI register to see what is received.
The V220 that we are using is configured for VT52 mode, 20mA current loop, and the serial port is configured for 110 baud, 7-bit characters, Mark parity, and two stop bits. Pressing the "A" key on a VT52 will transmit a 101 octal. The TTI register in the PDP-9 contains a 301 octal. From the PDP-9 User's Manual the Teletype code for an "A" character is 301 octal, so that looks OK. We tried a few other characters, and they all looked OK.
We loaded MAINDEC-9A-D3BB TC02 Basic Exerciser and continued testing with the DECtape that we formatted a few weeks ago. We made several passes of test #4, Search Find All Blocks. It ran OK, and did not report any errors. Notes: When reading forward all of the Data Buffer, RWB, and LPB lights are all on bright. When reading in reverse Data Buffer and RWB lights are off, the LPB lights are on dim, and the LINK light flashes. After running for about 20 minutes it got stuck rereading blocks near the far end of the tape.
We tried all of the subtests in D3BB
Test #0, Move Scope Loop. This just goes End Zone to End Zone using the MOVE command and works OK.
Test #1, Search Scope Loop. This also goes End Zone to End Zone and works OK using the SEARCH command, but it displays the block number on the console. The highest block displayed was 1077 octal which is what we expected to see.
Test #2, Read Scope Loop. This just goes End Zone to End Zone using the READ command and works OK.
Test #3, Write Scope Loop. This just goes End Zone to End Zone using the WRITE command and works OK.
Test #4, Search Find All Blocks. This works OK until it gets to the end of the tape. It displays a message that says it is looking for block 1100 and can only find block 1077. Hitting CONTINUE displays a message that it is looking for block 1101. This is a problem with the diagnostic, because the tape should only have 1077 blocks on it. Earlier today this subtest worked OK and didn't display any messages.
Test #5, Write/Read Data. This displays a WRITE DATA FWD message with BLOCK 000000, W.C. 002762, and STAT B 410000, IORS 000200, and the TIM light is on.
Test #6, Parity Test. It was looking for block 776261 instead of 000000 so it would not run. This is a problem with the diagnostic.
Test #7, BASIC SEARCH ROUTINE. This read the tape and displayed the block numbers found. Everything looks OK.
Test #10, START STOP TURNAROUND. This rewound the tape and displayed a message saying that it was searching backwards for block 776260 and found block 000000. This is a problem with the diagnostic.
Test #6, Parity Test, starts at address 02101 in the diagnostic. The constant ENDBLK is in address 00272 and contains 776261 and should contain 001077. We replaced the 776261 with 001077 and restarted the diagnostic at 00200. The wrong contents were stored at address 00272 again. We fixed the contents of 00272 again and this time pressed CONTINUE instead of START. The same issue occurred. The code around 00220 looks at the switches to see if PDP-7 or PDP-9 DECtapes are being used and sets EZBLOK @ 00271 to either 001102 @ 06472 or 001100 @ 06473. The location EZBLOK @ 00271 contains 776262. The literals at 06472 and 06473 contain 001102 and 001100, which is OK.
Something is going wrong during the execution of the diagnostic and is putting the wrong data into memory locations 00271 and 00272. Memory location 221 should contain 506471 and actually contained 506671. Memory location 223 should contain 206472 and actually contained 206672. We fixed those memory locations, but it is still misbehaving. We probably have a memory problem with bit-10.
11/7/23
We tried to MAINDEC-9A-D3BB TC02 Basic Exerciser. It read about three feet of paper tape and the CPU halted. There is a BIN loader on the front of the paper tape that runs and loads the rest of the paper tape. It looks like the BIN loader didn't automatically start. A second attempt loaded correctly. We verified that locations 221 & 223 contained the correct address in the instructions. The literals at 06472 & 06473 contained the correct 001102 & 001100 respectively.
We started the diagnostic at 00200 and set it to run subtest #4. We looked at locations 00271 & 00272 and they contain the correct 001100 & 001077 respectively. Subtest #4, Search Find All Blocks ran OK. We ran subtest #6, Parity Test and it ran OK. Subtest #5, Write/Read Data ran OK when set to 16 block writes. It ran for about 20 minutes, and then displayed errors on the console. The error was on block 0576 when writing forward. The error data scrolled off the screen, so we could not see the exact failure.
We reloaded D3BB and retried subtests 0, 1, 2, 3, 4, & 6. Subtest #3 got a Timing error and got stuck in a pattern executing code around 01070. Subtest #6 got a Timing error and the processor started executing the same code over & over again. The code that it was executing was below address 00200 so it is in the data buffers. We looked through the code that was executing around 01315. It looks like it got a CLK interrupt, but there is no return address at 00000. There is a JMP I 00002 and then the address 01317, which is labeled INRETU in the code. Maybe a processor or memory problem after it gets warmed up?
We loaded MAINDEC-9A-D01A Instruction Test Part 1. It ran off the end of the paper tape which is not a good sign. The diagnostic didn't halt which is usually a good sign. We had the switches set to 777700 and should have heard a bell on the serial console periodically. The code in memory did not match the source code listing.
We loaded MAINDEC-9A-D1AA Basic Memory Checkerboard. It halted at 12015 which is not one of the expected halt addresses.
Time to let it cool off and try again on Saturday.
11/15/23
Since the memory problem only shows up after the system has been running for a while, we decided to run MAINDEC-9A-D1AA Basic Memory Checkerboard when the machine is cold, and see if it displays any errors before the diagnostic dies.
It immediately halted at 00223 indicating an error. The error address was 13536, the correct data was 000000, the incorrect data was 002000, and the pattern word was 037700. So we picked up bit 7 at address 13536.
Error Address Correct Data Incorrect Data Pattern Word
13536 000000 002000 037700
12556 000000 002000 037700
13054 000000 002000 037700
13056 000000 002000 037700
13155 000000 004000 037700
13271 000000 001000 740077
13401 000000 004200 037700
13402 000000 002000 037700
13414 000000 007000 037700
13415 000000 001000 037700
13416 000000 104020 037700
13417 000000 010000 037700
13437 000000 100000 037700
13441 000000 000200 037700
13455 000000 007000 037700
We reloaded and ran MAINDEC-9A-D1AA Basic Memory Checkerboard to see if the diagnostic got corrupted and if the results were different.
Error Address Correct Data Incorrect Data Pattern Word
13456 000000 002000 037700
13474 000000 002000 037700
13476 000000 001200 037700
12515 000000 001000 037700
13516 000000 002000 037700
We disabled the error bits as they were found and were left with 0,3,4, & 16 not disabled. In this configuration the diagnostic ran without errors. We started enabling bits to see if the diagnostic would halt. We got to the point where the diagnostic ran OK with only bits 2,6,7,8, & 14 disabled.
We started going through the Tech-Tip #1 for the PDP-9 on Memory Tuning. The static Memory Voltage was 22.4VDC and is supposed to be 23.5VDC. We adjusted the trimpot on the G804 Flipchip in slot HJ08 to correct the voltage. The 2nd Stage Clamp Voltage was 3.71VDC and is supposed to be 6.0V. Adjusting the right hand trimpot on the G008 in slot E25 didn't change the voltage. We swapped the G008 with an unknown spare, and adjusting the right hand trimpot didn't change the voltage. With the changed Memory Voltage the memory is now both dropping and picking up bits when running the Basic Memory Checkerboard.
Looks like debugging the 2nd Stage Clamp Voltage adjustment issue will be Saturday's project.
I studied the memory schematic, the G008 Master Slice Control schematic, the printed System Adjustment manual, and the PDP9-TT-1 Memory Tuning tech note. There is a pin name error on the fiche PDP9-TT-1 Memory Tuning tech note. That explains why the Second Stage Clamp voltage was incorrect and the adjustment didn't work.
11/18/23
The PDP9-TT-1 Memory Tuning tech note says to measure the 2nd Stage Clamp Voltage between pins E25M and E25B. Pin M is actually the 1st Stage Clamp and is not adjustable. The 2nd Stage Clamp Voltage is actually measured between pins E25N and E25B. The System Adjustment manual has the correct pins described.
We adjusted the 2nd Stage Clamp Voltage to 6VDC and the Slice Voltage to 4.2VDC. We ran MAINDEC-9A-D1AA Basic Memory Checkerboard just to see if we improved the memory behavior, and it ran without faults. We decided to leave it running for a while to see if warming up the machine would break it. After an hour it was still running, so we declared victory.
We tried to boot ADSS, but the paper tape bootstrap read off the end of the tape and then halted at address 17532. It didn't get loaded into memory correctly.
We tried MAINDEC-9A-D01A Instruction Test Part 1. It looked like it was stuck in a loop and didn't ring the bell on the console periodically.
We tried MAINDEC-9A-D02A Instruction Test Part 2. It halted at 01060 E1216. We found that the M37 constant in memory location 17777 was 777640 and should have been 777740, so it dropped bit 11. We fixed the memory error and it halted at 02375
Time to go through the whole memory tuning procedure.
11/25/23
We started with the PDP-9 System Adjustment manual. Last week we adjusted the Main Memory Voltage to 23.5VDC, 2nd Stage Clamp Voltage to 6.0V, and the Slice Voltage to 4.2VDC. We followed the procedures in the manual to check the memory timing and delays. We didn't get any further because of lots of visitors.
12/2/23
According to section 2.2.3.1 in the System Adjustment Manual we connected the scope to the DIGIT READ SYNC signal on pin C16D relative to the CLOCK signal on pin F36M, and adjusted the MA Set Up to a delay to 180 ns. We also adjusted the Stagger Delay, Strobe Delay, Pause Delay, and Write Delay. We looked at the Stagger Time Setup signals according to section 2.2.3.6. We noticed that the Strobe SENSE AMPLIFIER RIGHT signal should go from ground to -3V, and was only going to -2V. The Strobe SENSE AMPLIFIER LEFT signal looks the same. We tried a different B360 Pulse Amplifier Flipchip that makes the SENSE AMPLIFIER LEFT signal and the voltage swing was the same as on the original. The original B360 must be OK.
The instructions in section 2.2.3.7 Slice Level Setup are cryptic. The Tech Note has a better explanation for the adjustment. We will start here on Wednesday.
12/6/23
We started with section 2.2.3.7 Slice Level Setup. The PDP-9 Tech Note #1 has a better description of what the signals should look like, and how to perform the adjustment. It is difficult to determine the optimal setting for Slice Level, so we set it to two turns from the CCW limit as suggested in Tech Note #1.
We loaded and ran MAINDEC-9A-D1AA PDP-9 Basic Memory Checkerboard Test. It ran for a short time and halted at address 00213, which is not a valid halt address. The instructions near this address are not even close to what the diagnostic listing says they should be. We cleared the memory, reloaded the diagnostic, and it ran OK this time.
We flipped Margin Switch #7 on the memory chassis, set the margin control switch on the front panel to +10MC, set the voltage offset to 0V, and started the diagnostic. We adjusted the +10V up until the diagnostic failed. At +4V the diagnostic halted. We restarted the diagnostic and adjusted the voltage down. At -9V the diagnostic ran OK. These margins should be symetric on the +/- so we need to adjust the Slice Voltage. We turned the left trimpot on the G008 FlipChip counter clockwise 1/2 of a turn. This time the diagnostic halted at -7V and was running OK at +10V. Tech Note #1 says to adjust the Slice Voltage to favor the low side of the Voltage Swing. We adjusted the Slice Voltage to 4.02V. The trimpot adjustment is very sensitive. This time the Voltage Swing was -8V/+10V. That exceeds the +/-7V specification, so we will leave it as it is. We set switch #7 back to the FIXED position, and the diagnostic still runs OK.
We loaded and ran MAINDEC-9A-D0BA ISZ Test. It runs without halting.
12/9/23
We loaded and ran MAINDEC-9A-D0CA Memory Address Test. It did not execute correctly and ended up in a loop at 00021 where there is no code. We single-stepped the code and found at address 17250 the contents was a JMS 07600 and should have been a JMP 17601, so it dropped bits 5 & 17. After fixing that memory location the diagnostic ran for a few minutes, and then got stuck in a loop at 00021 again. We checked the contents of memory location 17250 and it contained the correct JMS 17601. We configured the machine for SINGLE INSTRUCTION, a repeat speed of 5, and latched the CONTINUE switch. The program is running about 25% of the normal speed and the diagnostic is running OK. It ran for several hours without errors like this.
For Wednesday We will find out what the problem is with running at full speed.
12/13/23
We tried MAINDEC-9A-D0CA Memory Address Test at dull speed and it is running OK. Maybe we shouldn't fiddle with the memory adjustments?
We loaded and ran the MAINDEC-9A-D1AA PDP-9 Basic Memory Checkerboard and it auto-started. The light pattern doesn't look right, it looks like it is stuck in a loop. Location 00154 should be 200154 and is 015450. The instructions starting about 00154 are shifted to the left by two octets so the left two octets were lost and the right two octets are actually the left two octets from location 00155. This could be a problem with the paper tape reader, the paper tape reader controller, or maybe even the processor's microcode. We reloaded the diagnostic and this time it looks like it is running OK.
We tried MAINDEC-9A-D1BA PDP-9 Extended Memory Checkerboard Test. It auto-started, which it is not supposed to do. What was loaded into memory bears little resemblance to what is on the paper tape. Of course it didn't run correctly. On the second try it loaded and halted, but the PC was not 01101. We restarted the diagnostic at 00021 and it halted at 10222, which is incorrect. The diagnostic starts at 00021, executes a few instructions, and then does a JMS to 1103. The memory contents at 1103 are really incorrect.
We tried MAINDEC-9A-D1FA PDP-9 Extended Memory Address Test. It auto-started, but did not print the banner on the console. Memory location 00132 should be a 744200 and was a 740200. Memory locations 00133 through 00146 all contained 000000 instead of instructions.
We tried MAINDEC-9A-D0BA ISZ Test. It ran, but got stuck in a loop at addresses below 00100. Low memory addresses contain 000000. Starting at 17000 we can see the ISZLOW testing code.
We single-stepped the diagnostic starting at 17000. The LAC and DAC instructions look like they are working OK. After pressing CONTINUE without single-step the program got stuck in a loop.
We tried MAINDEC-9A-D01A Instruction Test Part 1. It ran from 000022 to 1331 and halted. The contents of memory past that point were corrupted.
Looks like we need to fix the problem with loading paper tapes.
12/16/23
We decided to look at the paper tape reading problem. We have a paper tape with a binary counting pattern punched. We should be able to read this in ASCII and in Binary mode to see if it gets read correctly. We will create and toggle in a small program to test this. In Alpha mode 8 bits from the paper tape are put in the right-most AC bits. In Binary mode the first 6 bits are the left-most, the second go in the middle, and the third are the right-most bits. Paper tape channel 1 is on the outer edge with three punches. Channel 8 is on the outer edge with 5 punches.
We toggled in a little program to read a paper tape with alternating ones and zeros in ASCII mode. We can see the tape data in the RDR buffer when the RSA instruction is executed, and then in the AC when the RSB instruction is executed. Time to test binary read with the RSB instruction.
W changed the toggled in program to read binary and fed it a tape with just channel 6 & 8 punched. It read three lines from paper tape, and assembled them into a 18 bit word. This also looks like it is working OK. Maybe it is sometimes missing the strobe that comes from the channel 8 punch?
12/23/23
We received the A704 10V Precision Power Supply FlipChip for the 34H graphics option on the PDP-9 from Will on eBay this week. We still need a W681 Scope Intensifier FlipChip. Vincent put the design on OSH Park so we could make a new one if necessary.
From last week's testing we can see that the 3x paper tape reads to 1x 18-bit word logic in the paper tape controller works OK at low speed. I don't think that it is working correctly at full speed, so we have some investigating to do in the I/O controller.
12/30/23
Bit-10 in memory is stuck on. Since the path from the console switches to memory goes through a lot of devices it will take a while to debug this issue. We connected a 'scope to the the ADSO(G) and ADDR SW 10 signals. The ADDR SW 10 signal goes to -12V when the switch is on and ground when off. The ADSO(G) pulses when the DEPOSIT function is active. By the time we got to look at the signal the stuck bit problem went away. So we have something that is temperature sensitive that we will nee to fix later.
Page updated
Report abuse