PDP-9 Restoration Blog Starting 2020
We tried the ASR-33 Teletype from the Altair 8800 as the system console
We blew one of the 3A fuses because the wires for the paper tape reader control inside the TTY were reversed
This looked like a short to the PDP-9, and the fuse protected everything
After we fixed the paper tape reader control wiring the TTP keyboard and printer worked OK
The paper tape reader would not turn on
We checked the transistors and diodes on the W040 that drives the printer and controls the reader
Diodes D2 and D7 were shorted
We replace them with NOS D-662 1N645 parts
The paper tape reader in the TTY is enabled when ADSS first boots, but is disabled after the first character is entered
Looks like we have some debugging to do in TTY input circuitry
We tried to demonstrate ADSS booting to a visitor, but ADSS would not restart from the core image or load from DECtape
Time for some debugging
We ran MAINDEC-9A-D01A-D Instruction Test Part 1 and MAINDEC-9A-D02A-D Instruction Test Part 2
Both ran successfully so we know the processor is mostly working OK
We ran MAINDEC-9A-D1AA-D PDP-9 Basic Memory Checkerboard Test
It failed and showed that bit-11 in the upper 4k of core was on when it should have been off
Rerunning the test resulted in the same error at the same address
We swapped the G009 Sense Amplifiers in slots C24 & C25 and the fault moved to bit 10
We put the good G009 from slot C25 back in slot C24 and replaced the G009 in slot C25 with spare
The diagnostic ran a little longer and then showed the same failure on bit-7
We swapped the G009 sense amplifiers in slots D24 & D25
There was no change, so we swapped them back to the original locations
We ran the MAINDEC-9A-D0CA Memory Address Test to check the G219 modules
It ran OK, but 20 minutes to complete
We ran the MAINDEC-9A-D1FA Extended Memory Address Test to do a more thorough test of the G219 modules
This also ran OK
Click on the image for a larger view.
We ran the MAINDEC-9A-D1BA Extended Memory Checkerboard Test
This showed errors at address 013223 where the contents should be 000000 and were 000040, so it is picking up bit-12
This showed errors at address 017274 where the contents should be 000000 and were 000400, so it is picking up bit-9
The problem could be in one of the 36 G219 Memory Selector flipchips for the Digit drive
We should check the G219s in slots AB06 & EF06 for bit-9, and in slots AB03 & EF03 for bit-12
It could be in one of the 8 G219s in slots HJ23 through HJ30 that are used for Word Selection
Since the failing addresses all have MA6= 0 or 1 & MA7=1 that points to the G219s in slots HJ24 or HJ26
The failing addresses all have MA10=1 & MA11=0 that points to the G219 in slot HJ29
It could also be in the G009 Sense Amplifier flipchips for bit-9 and bit-12 in slots C23 & D22 or the W612 Pulse Amplifiers in slots C26 & D26
Of course now that we are prepared to to fix the memory the diag reported four new errors and is now working OK
We should take a look at the memory timing and voltages to make sure that they have not drifted out of specification
ADSS booted on the first try, so now we are back to trying to determine why versions prior to V5 get a .SYSLD 4 error when loading any application
We also need to make some V5A bootable DECtapes, and get all three TU55 DECtape drives working
When we try to run any application on an ADSS that is earlier than V5, the system reports a .SYSLD 4 error
This means that one of the DATs that map physical to logical devices is bad
We have the source code for the System Loader for ADSS V5, but not for earlier versions
Our current project is to reconstruct the System Loader source code for ADSS V4E
Then we can debug what .SYSLD is doing, and which DAT it doesn't like
The real PDP-9 and SIMH show the same behavior when running early versions of ADSS
If we can figure this all our, then we can probably get earlier, and smaller, versions of ADSS running on the PDP-9
The current debugging method is to run ADSS V4E on SIMH
This lets us put in breakpoints to stop the processor when it runs .SYSLD
Then we can single-step the code and watch what it does
At the same time we can modify the V5 source code to match what we see with V4E
SIMH decodes and displays instructions when you single-step, and lets you see register contents
So far, the V5 and V4E source are about 90% the same, but the V5 .SYSLD takes more memory
Eventually we should be able to reconstruct the V4E .SYSLD source which will make debugging it a lot easier
We have been chasing an intermittent problem where the DECtape drive at address 1 cannot be addressed
We traced the signals in the TC02 DECtape controller, and everything up to the control cable going to the drives looked OK
The drive select 1 signal in the drives should have been at a ground level and was at -3V
We got sidetracked, and by the time we got back to debugging the drive select 1 was working
We tried all of the ADSS DECtapes that we made during the week
The STARTREK FORTRAN source could be read, and the ALGOL tape booted OK
ALGOL ran out of memory on the 8k system, so it would not load
The other two ADSS V5A DECtapes we made had parity errors when we tried to boot
One of the TU55 DECtape drives showed intermittent problems, so we swapped it for a drive from the PDP-8/I
It looks like all three DECtape drives are working OK now
The intermittent drive select 1 problem came back
We traced the problem to the control cable that connects the TC02 DECtape controller to the first TU55 DECtape drive
We resoldered all of the connections on the flipchip on the TC02 end, and it looks like it is fixed
We tried editing a file using the ADSS V5A ALGOL DECtape
It first created a temporary file on drive 2, then displayed the editor prompt
We entered a one line file and closed it
It saved the file on drive 2, copied it to drive1, deleted the file on drive 2, and then reloaded the non-resident part of the ADSS monitor
While it is way faster than using just paper tape, having a disk would be even better
The ADSS ALGOL DECtape doesn't include the small versions of MACRO and F4, so it is not so useful
We will remake the ADSS V5A DECtapes, and try booting again
It would be nice to get an ADSS software development environment working
We have found that the PDP-9 format is really picky about DECtapes
You can format DECtapes in PDP-9/PDP-10 format on a PDP-8, but only about 10% of the ones that I have tried will successfully format and go through all of the checking steps
Some DECtapes are too short and go off the end of the tape
Maybe it is just that having been a PDP-8 DECtape for 50 years makes them reluctant to be changed to a PDP-9 format?
In any case, the DECtapes that format and check OK on my PDP-8/e & TD8E seem to work OK on the PDP-9
I can use a modified dumprest program to write tapes that work OK on the PDP-9
Today we booted ADSS V5A that I sysgenned on SIMH to be configured for 8K of core
The other two TU55 drives held scratch tapes
I used the "N 1" and N 2" commands to write empty directories to the scratch tapes
I used EDIT to create a "HELLO WORLD" program in FORTRAN
That was a learning experience, and too quite a few tries, and really spins DT1 and DT2 alot
We have to use the "abbreviated" F4 compiler because our PDP-9 only has 8K of core
We got the program to compile, and even got a listing of the resulting MACRO instructions
We got stuck getting the LINKER to work. You need to enter the ALTMODE character after the program name, and it wasn't obvious how to get a VT220 to sent that character
Even then it didn't link the file and run it
That is the project for this week.
It looks like this project is finally going into the software phase. Time to get some demonstration programs running.
During the week I experimented with Bob Supnick's SIMH PDP-9 emulator and the same ADSS V5A DECtape image that is running on the PDP-9
I found that the example commands in the manuals for inking/loading a FORTRAN IV program don't work
After some experimenting, and reading Bob's software notes, I was able to compile and execute a FORTRAN IV program
I tried the same commands on the PDP-9, and it also worked
Now we need to copy the FOCAL binary onto the system DECtape so we can work with that language
We got FOCAL running.
Time to find some interesting programs for demonstrations
Booted ADSS just to make sure everything is working OK.
We borrowed a coil winder from the New England Wireless and Steam Museum. We cut the adhesive holding the coil onto the metal bracket and mounted the coil onto the winder. We set the turns counter to zero and very carefully unwound the coil. After a very long unwinding project we found the break in the wire and counted 4400 turns on the coil. Guessing at a 3/8" average diameter for the coil means that we need about 432 feet of wire. The wire measured about 2.5 thousandths of an inch in diameter, so it is 42.5 AWG. I bought a 6954 foot spool of 42.5 AWG magnet wire from Remington Industries on eBay. That should be enough to repair this coil, and have plenty left over to make a Tesla coil.
I noticed that the PC04 schematics show the coil as having 685 Ohms resistance. The Electrisola WWW page lists the resistance of 42.5 AWG wire as 1793 Ohms per 1000 feet. That calculates to about 384 feet of wire, close to the wild guess of 432 feet.
I will get some Mylar or Kapton tape to hold the first turn of the wire to the spool, and to hold the larger diameter pigtails to the magnet wire. The wire insulation is Polyester, so apparently a soldering iron will burn it off. On the coil winder one turn of the crank makes one turn of the coil. It would take 4400 crank turns to rewind the coil. I will try replacing the crank with a variable speed electric drill to reduce the hours required to rewind the coil.
We tried to boot ADSS from DECtape last Saturday. The bootloader loaded from paper tape, but the DECtapes never moved.
We tried to run the Memory Checkerboard and the Memory Address test, but both failed to run.
We toggled in a program to copy the console switches to the Teletype output. That worked OK for a variety of characters.
We toggled in a program to copy the console switches to the TC02 DECtape controller. That worked OK and we could select all three DECtape drives.
We ran Instruction Test #1, which tests the basic instructions for the CPU. It failed right away at address 000611. That corresponds to error E84, where the accumulator dropped a bit when rotating a single bit. This part of the test starts at 000575 by clearing the AC and Link, and complimenting the Link. Then it executes 9 Rotate Two Left instructions which should leave bit 1 a 1 and the Link cleared. Our machine has the AC cleared, so we dropped a bit during the rotates. We single stepped the CPU through this test. The CLA!CLL!CML instruction worked and left the AC cleared and the Link set. The first RTL left only AC bit 16 set and the Link cleared. The next RTL left only AC bit 14 set and the Link cleared. The next RTL left the AC cleared and the Link cleared. This is wrong, so we dropped the bit rotating it from bit 14 to bit 12.
We tried the sequence of RAL which shifts a single bit left through the AC. This worked OK, so all of ADR bits are getting gated onto the O-Bus correctly.
This points to the L or K input on the B169 Flip-Chip in slot B31 that muxes bit 14 from the ADR onto the O-Bus bit 12 during rotate instruction. We replaced the B169 in slot B31 with a spare and now this test of the RTL instruction works OK.
Now the diag stops at address 002314, error E226A. Here it clears the AC and Link, compliments the Link, loads the AC with the constant 000000, and test to see that the AC contains 000000. The AC contains 400000, so it failed. The constant at 002344 contained 400000 and should have contained 000000. We fixed that location and now the diag stops at 002601 which corresponds to error E245. The constant for this test at 002345 contained a 200000 and should contain a 400000. Now it looks like the constants for this diag got loaded one location too low. We reloaded the diag from paper tape, and now it runs OK.
We measured the voltage drop for all diodes and transistors on the failed B169 flip-chip. Transistor Q4, a Fairchild/DEC -4258 (2N4258) has an open emitter that is activated by inputs L and K. That matches our guess for the failure mode.
We ran the PDP-9 for most of the day rehearsing for the presentation on Wednesday. It mostly ran OK, but exhibited some flakiness. Next Saturday we should run a full set of diagnostics while adjusting the margin voltages. I would not be surprised to find some leaky or low gain transistors.
We ran the PDP-9 to record video for tomorrow's presentation. Other than one glitch reading the DECtape on the lower right drive it behaved very well.
We tried to demonstrate ADSS last week, but it would not boot. After testing with toggled in instructions we found that all of the instructions that we tried worked OK, except for the JMP instruction.
We connected 'scope and the logic analyzer to the microcode address to see if we could see it execute the microcode steps. We were thinking that it was not getting to the microword for the JMP instruction. After lots of fiddling we were never able to get the logic analyzer to decode the negative logic levels and display the correspond logic states. After many hours of fiddling we demonstrated what was wrong to one of our volunteers, and of course it worked. After several tried it booted ADSS. Something is marginal, and we will need to find out what it is to make the machine more reliable. A project for next week.