PDP-8/E Restoration Log
Dan and Mike picked up the system, made an inventory of the components, and took lots of pictures.
This is Mike's first PDP-8 in his personal collection.
We removed all of the boards, the front panel, and the Omnibus backplane.
We picked the acorn shell parts from the Omnibus connectors, and blew off the dust with compressed air.
There is a manufacturing date on the Omnibus backplane of 5/14/74.
We vacuumed the mouse turds from inside of the chassis and cleaned the dust and grime from the sheet metal chassis.
We powered up just the power supply. All of the output voltages were within a few mV of the desired voltages.
We installed the Omnibus backplane. All of the voltages on the backplane were within specification.
We installed the front panel and powered on the power supply.
Some of the lamps glowed dimly. It may be designed this way to get the bulbs to turn on faster.
We replaced the defective bulbs with real Oshino OL-2 bulbs.
We need to get some Oshino OL-367BP (no longer made) or Chicago Miniature CM2309 spare bulbs because the Oshino OL-2 bulb is no longer available.
We installed all of the processor boards, but no memory boards.
The two processor boards were installed backwards when we picked it up.
There are some signs of life in the system.
If you push the EXAMINE or DEPOSIT switch the MEMORY ADDRESS increments.
This is the expected behavior, so something is working.
We installed both 8k x 12 core memory stacks and powered the system on.
Now when you push the EXAMINE or DEPOSIT switch the RUN light goes on.
You can see in the above image that the FETCH and EXECUTE indicators are both on.
Remove both core stacks to see if the EXAMINE and DEPOSIT switches are operational again.
Install one core stack and test the EXAMINE and DEPOSIT switches.
Install the other core stack and test the EXAMINE and DEPOSIT switches.
This should show if one of the core stack boards is holding a signal on the Omnibus.
We removed both core stacks and found that pushing the the EXAMINE or DEPOSIT switch causes the MEMORY ADDRESS to increment.
So we have life back in the processor and know that one or both of the core stacks causes the processor problem
We put the lower 8k core stack back in and EXAMINE or DEPOSIT still works.
We can actually store and retrieve data from the core.
Installing the second core stack caused the failure again.
We pulled the upper core stack, but left the the Sense/Inhibit and the XY boards installed.
The processor still worked.
This is where Warren would say that I still need adult supervision.
I never noticed that the core stack was installed up-side down and shorted lots of Omnibus lines.
Dan noticed it right away and suggested that I turn the board over.
The processor now works with 16k installed.
We entered a simple ISZ loop and were rewarded with an incrementing AC.
So lots of the processor is working correctly.
The system is sensitive to vibration, especially the core stacks.
We pulled all of the core stack boards, and cleaned and treated the gold edge fingers and backplane connectors with DeoxIT.
The vibration sensitivity is now gone.
I tried a small program to transfer the AC to the MQ and back.
It looks like bit-3 of the MQ is stuck on.
I ordered some Signetics 8271 chips because they are used to make up all of the registers.
The ISZ loop seems to run much faster in the upper 8k of core than in the lower 4k.
This needs investigation because both core stacks are the same speed.
We swapped the current loop cable that was connected to the M8650 KL8-E console teletype control with a BC01V cable.
The BC01V cable enables the RS-232 capability of the KL8-E interface.
We connected the BC01V cable through a null-modem cable, to a 25-pin to 9-pin adapter, and to the 36" flat screen system running a terminal emulator.
We entered a program that sends all possible characters to the console, but never saw them on the screen.
A character echo program didn't see any characters entered from the console either.
In between lots of visitors today we did some more debugging on Mike's PDP-8E.
Last week we toggled in a small program that read characters from the serial console through the M8650 Asynchronous Data Control board and wrote back to the serial console.
It would not echo characters typed on the serial console.
This week we found that the receiver in the M8650 worked OK, but the data sent back to the serial console was not correct.
Any characters typed into the serial console would show up in the AC (Accumulator) correctly.
The program sends the received data back out to the serial console.
The data to send to the console is correct when it is latched from the Omnibus signals and sent to the 8271 chips that make up the UART.
The data is not correct when it leaves the serial port.
We have very good documentation on the M8650 board so we should be able to repair it.
Last week we could get data from a terminal into the PDP-8/E, but not back out.
After some debugging we found that there was a start-bit, 8 data-bits, and no stop-bits going out the serial port.
That really confused the terminal.
The 7474 flip-flop E20 on the M8650 KL8-E board was defective.
We replaced it with a NOS spare IC.
Now it talks both directions to a terminal.
The defective IC had slightly rusty leads, just like we found in the PDP-8/I and PDP-8/L.
We replaced lots of rusty IC in the 8/I and 8/L before they behaved well.
Hopefully this 8/E won't require as much surgery.
We toggled in the RIM loader, then sent the BIN loader and the Instruction Test #1 through the serial port from a terminal emulator.
The instruction test failed very quickly.
It looks like the CLA instruction didn't work.
So we have some debugging to do in the processor.
I found that bits 2 & 3 in memory fields 2 & 3 (the upper 8k) are always on.
It also looks like there might be a problem with memory location 7764 in field 0 (the bottom 4k).
The instruction 7510 gets changed to 3510 so the RIM loader doesn't work correctly.
I should be able to load the RIM loader in to memory field 1 for now to get around the problem.
I plan to install a 32k RAM memory board in this system, so fixing the core memory may not be necessary.
I tried all of the toggle-in tests for the PDP-8.
So far it looks like the processor is working OK.
Even the stuck bit in the MQ register seems to be OK now.
I picked up an RX08 8" Floppy Disk Controller and a KL8E Asynchronous Interface while on a business trip to Germany.
There are lots of RX01 and RX02 drive systems in the RICM collection so getting one to work should not be too difficult.
Kyle Owen wrote a program that emulates a disk drive connected to a serial port.
I can jumper the KL8E to be the second serial port and for a faster baud rate.
The 8E should be able to boot OS8 from the emulated disk.
Once that is working, it should be easy to make some bootable OS8 floppies.
I removed the SYKESdisk 8" floppy subsystem because it is very unlikely that I will ever find an Omnibus controller for it.
I installed a DEC RX01 8" floppy subsystem in the cabinet where the SYKESDisk was. Fortunately they were the same size.
I swapped the 30A plug on the cabinet power cord for a 20A because we have 20A receptacles available.
I powered up the whole cabinet and found that the fan at the top of the cabinet works.
The 716-B power supply that powers the DC side of the TU56 makes +5V, but does not make -15V.
I received a first article version of a 32k RAM board kit this week.
It only took about an hour to assemble it and give it a try.
The 8/e had just the basic processor, the memory extension, and a serial interface installed in a 20 slot backplane.
I removed the 6x core boards and installed the RAM board at the back of the chassis next to the bus loads card.
The processor was so far mostly untested because of problems with the original core memory boards.
I could deposit and examine locations in all 8x fields from the front panel.
It is very cool having 32k of memory in a PDP-8!
I tried a little ISZ loop and that worked OK.
The RIM loader worked OK and loaded the BIN loader.
The BIN loader worked OK and loaded MAINDEC-8E-D0AB, Instruction Test 1.
The instruction test worked OK, so I ran it for 30 minutes.
This is good news, so I guess that some of the processor is probably OK.
I loaded MAINDEC-8E-D0BB, Instruction Test 2.
This failed right away at 4327 in IOT test #9.
Investigation showed that the mask at 0064 that should have been 5200 was 0.
I fixed the mask and the diag failed again at the same location with the same problem.
I moved the RAM board to the front of the backplane in the slot just behind the serial interface and ran Instruction Test 2 again.
This time it ran OK, so I let it run for 30 minutes.
More good news, lots of the processor is working OK.
I loaded MAINDEC-8E-D0CC-D, 8E Adder Tests.
That ran OK, but I didn't have the patience to run it for 4 hours to see if all 8x fields worked.
I loaded MAINDEC-08-D1EC-D, Extended Memory Checkerboard.
I set it for 8x fields of 4k.
It failed several times in field 3 at location 0777.
In all cases the location should have been 0000 or 7777 and was some other value.
Warren suggested that the issue might be from rolling over from the address 30777 to 31000.
In this case 9x address lines would transition from the ground to high state.
Warren also suggested looking at the WRITE EN\ signal to see if there were any glitches, and to look at the power/ground on the RAM chips.
I was thinking maybe the memory Address and Data bus loading is probably very light because of the modern interface chips in the RAM board.
After many discussions last week the consensus was that the 74ABT540 IC that generates the Write Enable signal for the RAM chips was too fast.
It was decoding glitches on the MD DIR\ signal which cause the RAMs to store random data.
I replaced the 74ABT540 with a slower 74LS540, and everything works OK now.
I ran MAINDEC-08-D1EC-D, Extended Memory Checkerboard for 90 minutes without seeing a single error.
I also installed the board in the back of the backplane where memory normally goes, and that worked OK too.
I installed a second 8650 serial interface, this one is the -YA variant that supports speeds above 110 baud.
I had to change the default device code from 03/04 to 40/41 for the second port, and set it for 2400 baud.
I ran some simple diagnostics, and it seems to work OK.
I couldn't find another BC01 serial cable to connect this board my my laptop so I will need to make one.
I loaded and ran the MAINDEC-08-DIRXA-C RX8-RX01 Diagnostic Program.
I am not sure that I configured it correctly and it showed some errors.
I need to study the source code and see what it was trying to do.
Configured to test only the RX8E Omnibus interface with the SW set to 7000.
ERR FAT FAST EAC GOOD PASS
607 600 600 177 0 0
425 404 404 0 0 0
Now that the RAM board in the PDP-8/e is working OK, we did some more experimenting.
Kyle Owen wrote a disk server program that emulates a DEC RK05 disk drive.
We configured the second serial port in the 8/e to 38,400 baud and made a special cable to connect the KL8E serial controller to the PC's 9-pin serial port.
You run the disk server on a PC, connect the PC to a second serial controller in the 8/e, toggle in a serial bootstrap program, and the 8/e boots the OS/8 operating system from the emulated disk.
The RK05 disk image on the disk server PC is in the same format as used with the SIMH PDP-8 simulator, so there are several images available to try.
The disk image needs to be modified to replace the RK05 disk handler (device driver) with the serial disk handler, but Kyle wrote a program to do that.
After running the serial boot strap it took just a few seconds to boot OS/8.
The disk image that I used contained lots of diag programs, so it was much more convenient than loading the paper tape images through the serial port.
Unfortunately the disk image did not contain a copy of the MAINDEC-08-DIRXA-C RX8-RX01 diagnostic program.
The RX01 manual says that the default Device Code for the RX8E is 70, so that is what we used last week.
After some digging through OS/8 source code we found that it needs to be set to 75.
If you tell the diag program to use 70 it will actually use 75.
That diag explains the failures last week.
We loaded the MAINDEC-08-DIRXA-C through the serial port and tried it again.
It looks like the basic controller tests take just a second to run.
The tests for the connection to the RX01 controller failed, and behaved strangely so I don't believe the results.
Next time we will dig deeper into the RX8E and RX01.
I tried to boot OS/8 from the serial disk server again. It did very little.
I toggled in the RIM loader, but it would not load the BIN loader.
I single-stepped the processor and was surprised to see it jump to location 0.
I toggled in some simple instruction tests and found that BSW, RTL, RTR, and JMP were broken.
I bought an M8300 Major Registers board in eBay a few weeks ago, so I swapped it.
I was a little amazed that it actually fixed the problem.
I booted OS/8 and tried to run the DHKAFA.DG 8E/M/F INSTRUCTION TEST 1.
It halted the processor, and the contents of core did not look the same as the MAINDEC-8E-D0AB Instruction Test 1.
I need to research OS/8 diagnostics.
The plan for today was to test the 32k RAM memory board behavior after substituting slower 74ALS245 bus drivers for the faster 74ABT245 drivers.
Modern fast ICs react to Omnibus glitches that the original slower parts ignore, and the fast rise/fall time of the modern parts causes more crosstalk.
Unfortunately the 8/e decided that it would not write to memory.
If the 8/e still had core memory this fault would have wiped memory because core destroys data when it reads.
The RAM memory does not do a destructive read, so it read fine, just would not write.
Both the EXAM and DEP switches did an EXAM.
I disassembled the front panel so I could get a DIP-Clip on the ICs and see the signals.
I looked the signals from the EXAM and DEP switches and what signals they affected.
I found that the MD DIR IN signal from pin 10 of E4 normally had a few mV of noise on the signal, but went to ground when the EXAM switch was pressed.
It looks like the MD DIR IN signal should float high and get pulled low by the EXAM switch.
That would put the memory bus always in the read direction and never allow a write.
I pulled the Omnibus boards one at a time and looked at the MD DIR IN signal.
When I pulled the M8330 Timing Generator board the MD DIR IN signal went to 4V.
The 8/e doesn't have the EAE option so I could put the M8330 on an extender board.
I traced the MD DIR IN signal on from AK2 on the PCB to pin 10 of the 7417 IC E35.
That IC is in section E7 on the schematic.
Pin 11 of E35 was always low, so the open collector output was always active.
The signal for the driver comes from the 1 output from the 74H74 IC E30.
The clock signal on pin 3 was active when the processor was running and pulsed when EXAM or DEP was pressed.
The FAST(0) signal on pin 2 was always low, so that explained the driver chip always active.
The 74H74 IC E31 in section B1 of the schematic creates the FAST(0) signal.
When DEP was pressed there was a pulse on clock pin 3 of E31 and the the data on pin 2 was high.
The output on pin 5 went high on the rising edge of the clock signal, but went low again on the falling edge of the clock signal.
So, it looks like the SN74H74 IC E31 has failed.
We have replaced lots of 7474 parts on other restorations, so finding a faulty one in the 8/e was not a surprise.
The SN74H74 parts have been obsolete for a very long time, so eBay to the rescue.
I will repair the board this week and try again next Saturday.
Our debugging of the M8330 KK8-E Timing Generator last week was correct.
I bought some NOS TI 74H74 ICs on ebay and replaced the defective IC E31 on the Timing Generator.
The system is operational again and booted OS/8 from the serial disk emulator.
I tried to run the DIRXA-D RX01 diagnostic from OS/8, but it complained about an unknown interrupt and died.
I need to research the procedure for running diags from OS/8 more.
I modified the BIN loader so it would use the second serial port, the one that runs at 38,400 baud instead of 110 baud.
Loading the MAINDEC-08-DIRXA-D from the tape image resulted in a loop where it kept asking for the Switch Register settings.
I installed the M8357 RX8-E diskette controller and tried loading MAINDEC-08-DIRXA-C.
This time the BIN loader would not load the diag.
After much fiddling I found that removing the RX8-E controller let the BIN loader work correctly.
Either there is an IOT decoding problem on the RX8-E, or the board is holding an Omnibus signal that it should not.
That will be the project for next week.
Lots of visitors again today with some nice donations so not so much time to debug the RX8E diskette controller.
We ran the MAINDEC-08-D1EC-D Extended Memory Checkerboard for 60 minutes without errors.
We replaced the 74ABT245 bus drivers on the 32k RAM board with slower 74AALS245 parts.
We again ran the MAINDEC-08-D1EC-D Extended Memory Checkerboard for 30 minutes without errors.
The slower bus drivers will make less noise on the Omnibus and seem to work fine.
During some debugging the processor broke again.
Anytime you pressed the EXAM key the processor would go into the RUN state.
We replaced the M8330 KK8-E Timing Generator with a spare M8330-YA board and now the processor works OK.
We wrote some simple diagnostics for the RX8E diskette controller.
We looked at the MD03..MD08 L and BUS I/O PAUSE L signals from the backplane when executing IOT instructions to device 75.
All of the signals look OK.
We verified the inputs to the Signetics 314 7-input NOR gate E34 and all go low when the BUS I/O PAUSE L signal is active.
Unfortunately the pin 3 output of E34 is always high so the RX8E will be selected for any IOT address.
This explains what we observed last week where the RIM and BIN loaders would not work with the RX8E installed.
We will try to get a replacement Signetics 314 chip this week so we can continue debugging next week.
We did more debugging on the RX8E 8" diskette controller in the PDP-8/e.
Last week we found a bad Signetics SP314A 7-input NOR gate E35.
Vincent kindly donated a replacement part.
That fixed the problem of the RX8E being selected by any IOT address and lets the serial ports work with the RX8E is installed.
Just to be sure the IOT logic was working correctly we toggled in a program that executed all 8 possible IOTs for the RX8E.
We looked at the output pins on the SN7442 BCD-to-Decimal IC E41 and triggered the 'scope on the RX8 SEL signal from pin 3 of E35.
For each output pulse from each pin of E41 we saw 8 pulses on the RX8 SEL signal.
That meant that all of the IOT decoding was working correctly.
The next issue we found was the address bit 10 was always on when we pushed the LOAD ADDRESS front panel key.
Removing the RX8E fixed the problem, so we knew the problem was on the RX8E.
We didn't know if the problem was the output of the 8881 E29 or the input of the 8837 E25.
We cut pin 10 of E29 and it fixed the address problem.
Even though this is not a fix, it let us continue debugging.
We will beg for some replacement DEC 8881or SN7439 ICs this week.
The Signetics N8881N might be a suitable replacement, but we need to do some more checking.
We could use a SN7401, but the sink current is much lower than that of the real parts.
A toggled in test program that did an INIT function showed that all of the flags were off.
Then we turned Maintenance Mode to force the flags to turn on and checked the flags.
That didn't work.
We found that the SN7474 E2 would not stay set so we will replace it.
Click on the image for a larger view.
The upper trace is E32 pin 13 and the lower trace is E32 pin 12.
Pin 12 is stuck at 0.8V instead of having the inverse of the signal on pin 13.
We looked at the other signals going to E2 and happened to find that the BTP3 H signal was missing.
The SN7404 E32 has no output from pin 12 even though the signal is present on the input pin 13.
We will replace that IC too.
Another busy Saturday. We fixed an iMac G5 for a visitor. Not sure what was broken, but it worked after we disassembled it, wiggled things, and put it back together.
We replaced the defective SN7474 flip-flop for the MAINT signal, the SN7404 inverter for the BTP3 signal, and the DEC 8881 bus driver for the BUS DATA[8..10] signals.
The serial ports now work correctly with the RX8E installed.
I used the RIM loader to load the simple diag that I am writing.
Some quick testing showed that bit 5 in the diag that I just loaded was always off
Trying to store 7777 to any memory location resulted in 7677.
The 'scope showed good data on the bus, and bit 5 changed with the setting of the bit 5 switch on the front panel.
I am so conditioned to looking for IC failures that it didn't occur to me to check the bulbs in the front panel.
Replacing the bulb for bit 5 fixed everything.
Another case for Warren's adult supervision.
I wrote some simple diagnostic tests to check the state of the DONE, TRANSFER REQUEST, and ERROR flags.
They all work now and control the processor's skip functions correctly.This is good progress.
I ran three different versions of the MAINDEC-08-DIRXA-C-D RX8-RX01 Diagnostic Program to test just the RX8E controller board.
They all ran and didn't report errors, but they looked like they were stuck in a loop.
They responded to a ^C character from the keyboard so they were still alive, but they never reported completing a test loop.
We have the source listing for the diagnostics, but they are very complicated and difficult to understand.
I need to find someone who has a functional RX8E and can run the diags to prove the the diags actually work OK.
I went back to writing my own tests that exercise the circuitry on the RX8E, but I need to use a 'scope to see if everything is working OK.
I will write more diags this week and test more circuitry next week.
Tested and working:
INIT flip-flop and related signals, INTR instruction.
XFER flip-flop and related signals, STR instruction.
ERR flip-flop and related signals, SER instruction.
DONE flip-flop and related signals, SDN instruction.
MAINT flip-flop and some of the related signals, some parts of the LCD instruction.
8/12 flip-flop and some of the related signals, some parts of the LCD instruction.
I need to highlight the parts of the circuitry that have been tested on a schematic to make sure that everything gets tested.
RX08 To Do:
Test the Transfer Register. It looks like I can read/write the TR in MAINT mode.
Use the PDP-11/44 to test the RX01 and borrow the RX02 from the 11/44.
The RX8E controller looks like it is working well now, so we connected it to an RX01 single-density diskette drive to see what it would do.
The diskette drives should make a clunk when the clear button on the 8/e control panel is presses, but no luck.
We traced the INIT signal from the RX8E, to the M7726 Floppy Disk Control Board, to the M7727 Read/Write Control board, to the solenoids for the diskette heads.
R82 on the M7727 was quite warm, so the head solenoid for drive-0 was activated.
Even though the INIT signal looked OK there was no clunk.
Since we have lots or RX01 and RX02 drives in the warehouse we did a survey of the other RX01 drives instead of debugging this one.
We were a little surprised that all but one RX01 had RX02 control boards inside.
We tried several RX02 drives with varying levels of success.
A this point we are not sure if the diagnostics are working correctly, if there is a still problem in the RX8E controller, or there is a problem in the RX01 or RX02 drives that we tried.
It would be really helpful if someone had a working diskette system on a PDP-8/e/f/m system and can verify that the diagnostics actually work.
With DIRXA-C and one of the RX02 drives the MAINDEC said:
ERR FAT FAST EAC GOOD PASS
423 404 404 0 0 0 0
443 404 404 0 0 204 0
With DIRXA-D and a different RX02 drive the MAINDEC said:
FAT CMND XDR CODE RSTA START TARGET TEST PASS
2200 26 0 170 200 23 25 30 0 0
The code=170 means DATA AM NOT FOUND IN TIME
With DIRXA-C and yet another of the RX02 drives the MAINDEC said:
ERR FAT FAST EAC GOOD PASS
423 404 404 14 14 4 0
1440 1260 1401 14 14 4 0
With DIRXA-C and no drives the MAINDEC said:
ERR FAT FAST EAC GOOD PASS
1416 1260 1401 14 14 4 0
I wrote a little program to get the RX8ES and ERCOD registers from the RX8E.
RX8ES = 0014, bit-8 = RX01, bit-9 = Init Done
ERCOD = 7220, I don't know what this means so it is probably wrong.
Next week we will use one of the PDP-11 systems to test the diskette drives, and try another RX01 drive that we found today on the 8/e.
Because we don't know if any of the RX01 or RX02 drives are working correctly, or if the RX8E is completely fixed I went back to a more structured approach to testing
I used the small diags that I wrote to exercise parts of the RX8E circuitry, looked at the signals with a 'scope to make sure that everything was OK.
I used a highlighter to mark the signals and gates on the RX8E schematic that have been tested and have about 85% test coverage now.
I need to figure out how to get data into and out of the Transfer Register in Maintenance Mode to get the test coverage to about 95%.
I will need partially working RX01 or RX02 diskette subsystem to be able to test the remaining 5% of the RX08 circuitry.
Once I get to 100% test coverage I will go back to debugging an RX01.
Many people said that the RX02 diskettes will not pass all of the diags and will not boot OS/8 in double density with a 32 instruction or less bootloader that will fit in a MI8E board, so I will stick with and RX01 drive.
The system was powered on for most of the day while we were reassembling the CRAY J916.
After I got back to testing it looks like something is broken in the processor.
It will read/write memory and will execute a JMP instruction, so there are no major failures.
Next week I will run the toggle-in tests to see if most of the instructions are OK, and then run the MAINDEC instruction tests.
I spent a few hours on the RX8E today. The 8/e processor died yesterday and I didn't want to leave it broken.
It would run all the instructions except Operate instructions which would cause the PC to get loaded with an address that was not even close to the next address.
I tried the spare M8310 Major Register Control that I had and it actually fixed it.
Click on the image for a larger view.
The upper trace is RX DATA between the RX8E and the RX02.
The lower trace is D# CLK BUFF L
The first set of data is the Status Register being transferred to the RX8E after an INIT. It contains 0004.
The next set of data is the 0007 Read Error Register commend being sent to the RX02.
The last set of data is the 7220 response from the RX02.
I wrote a little program to initialize the RX8E/RX02 and then to read the Status and Error registers.
I can actually see the AC data get converted serial bits and sent to the RX02 and the serial results get loaded into the shift register and sent to the AC.
The status register contains 0004. That means that the drive is not ready, it is not an RX02, and it completed the initialization.
I just read that the Error Code is modified by reading the Status Register, so I need to modify the instruction sequence in my diag.
It looks like the RX8E is working OK and now it is time to test the RX01 and RX02 drives on a PDP-11 and see if any are working.
I debugged the Transfer Register test that I wrote.
That exercised and validated more logic on the RX8E diskette controller board.
I tried the RX01 diskette drive again.
Pressing the CLEAR key on the front panel did not reset the RX01.
I replaced the digital board with one from a desktop RX01 and now it almost always resets when you press the CLEAR key.
It is nice to see the heads move and the head load solenoid activate.
It looks like the processor is not always activating the INIT signal on the Omnibus when you press the CLEAR key or execute a CAF instruction.
Power cycling the whole system fixes that issue.
I will debug that issue later.
Reading the RX01 Status and Error Registers exercised the remaining RX8E logic, so I think that the RX8E is ready to go.
I see the Drive Ready and INIT Done bits in the Status Register, and a error code of 0170 Data AM not found in allotted time, or 0200 CRC error on reading the sector from the disk after an INIT.
I started looking at the signals on the analog board in the RX01.
The disk Index pulse for DK0 is every 170 ms, for DK1 it varies a lot.
The drive door latch is not working well so the hub is slipping.
I will write a sector buffer test this week to test the interaction between the RX01 and the RX8E.
Next Saturday I will replace the right diskette drive with a NOS spare.
I will also look at the signal from the diskette head and trace it back through the digital board.
I should check the diskettes on a PDP-11 because they might have been damaged by all of the debugging and experimenting.
I replaced the door on the right diskette drive so the problem with the slipping hub is fixed.
Today, pressing the CLEAR switch always reset the RX01.
It will be interesting to see if that stays reliable.
I booted OS/8 through the serial port and ran the RXREAD program.
This program verifies that all sectors on a diskette can be read.
It failed with the same 0170 Data AM not found in allotted time and added a 0120 a preamble could not be found.
I also ran DHKAFA Instruction Test 1 from OS/8 and it worked fine.
Next Saturday I will look at the signal from the diskette head and trace it back through the digital board to see if it is all OK.
The intermittent with the CLEAR key turned out to be in socket E7 for one of the microcode ROMs on the M7726 logic board in the RX01.
Wiggling the ROM fixed it for now.
I need to take all of the ROMs out and treat the sockets with DeoxIt for a permanent fix.
After fixing the microcode problem the DIRXA controller and the controller-interface diags passed and printed a "C" after every pass.
I tried the complete diskette diagnostics and saw the same 0170 Data AM not found in allotted time, or 0200 CRC error on reading the sector errors.
Earlier this week Warren and I came up with a plan to look at the differential signals from the diskette head, and work through the Op-Amps to the One-Shots.
I really couldn't see any more than a few millivolts from the diskette head, so I verified that the head select logic was all OK.
I swapped the diskette in case it was damaged by earlier experiments, and noticed that there was a radial wear line on the diskette where the head touched.
I poked a flashlight inside the diskette drive and was not really surprised to see that the diskette spindle was not turning.
Last week, I had disassembled the right drive to remove a big red piece of plastic and a cardboard puzzle piece.
At the same time I cleaned the head, the index and track 0 sensors, and put the drive belt back on the pulleys.
It is not unusual to have the belt stick to the pulleys and fall off if the drive hasn't been used for a very long time.
I stopped debugging after cleaning the right drive, and forgot to do the same procedure this week for the left drive.
I put the belt for the left drive back on the pulleys and now I could see the head stepping out the tracks when the diag was running.
The diag still failed, but with mostly with a 0200 CRC error on reading the sector errors, so I though that it might be some of the 40 year old diskettes that I was using.
I tried several different diskettes and got different results.
I ran a cleaning diskette in the drives, and didn't see any improvement.
I dug through the warehouse looking for NOS single-density 8" diskettes.
I found lots of double-density and some hard-sectored diskettes and just a few single-density.
One of the NOS diskettes works perfectly, the left drive passes all diagnostics, and it prints a "D" at the end of every diag pass.
I need to find more good single-density 8" diskettes or get one of the S-100 systems that will format diskettes working.
Next week I will try David Gesswein's restrx01 program to see if I can copy an image of a diagnostics diskette to a real diskette.
If that works, the diskette should boot to OS/8.
I will also take a look at the MI8E board.
I am not sure what custom bootloader is programmed, so need to rearrange the diodes for the RX01 bootloader.
After the MI8E works it will be time to tackle the TD8E and TU56.
The power supply for the TU56 had a broken -15VDC output and the ribbon cable to the TU56 is damaged.
We used DeoxIt to clean and treat the microcode sockets in the RX01.
Hopefully that intermittent is gone for good.
We booted OS/8 through the serial port and used the RXREAD program to test some 8" floppies.
Out of the stack of diskettes from a variety of vendors we found three that work OK.
We used David Gesswein's dump/restore programs to copy an image of an OS/8 diskette to a real diskette.
After trying three different RX8E bootloaders we found that the one in the OS/8 manual would boot OS/8 from the diskette that we just made.
We even ran BASIC from the diskette, so that means that the processor is working well.
The right diskette drive is not working well, so we still need to fix that.
We fixed the 854 power controller.
Now the AC power for all of the peripherals is controlled by the key on the processor cabinet.
We removed the ribbon cable that connects the TU56 DECtape to the TD8E controller.
It looks like it got caught under a cabinet wheel and damaged some of the wires.
The H-716-b power supply for the TU56 should make +5VDC and -15VDC, but the -15VDC is broken.
Both of these should get fixed during the week.
The 8/e would not boot OS/8 from the RX01 floppy today.
It worked OK after we reseated the microcode ROMs in the RX01 diskette drive.
To make it more reliable we removed the microcode ROMs, cleaned the tim plated leads, treated them with DeoxIt, and reinstalled them.
The RX01 works OK now, and hopefully it stay that way.
The right diskette drive doesn't work correctly.
While running diagnostics we compared the INDEX, TRACK 0, and RAW DATA signals from the two drives.
As far as I can see they both look the same.
Next week we can swap the two drives to see if the problem is in the analog board or the diskette drive.
Click on the image for a larger view.
You can see Q7 at the top middle of the PCB in the image is missing.
I replaced transistor Q7 in the H-716b power supply with a 2N3956 that I bought on eBay.
Both +5VDC and -15VDC now work.
Tomorrow I can see if the TU56 transport will work with the local controls on the front of the drives.
I fixed the two broken wires in the ribbon cable that connects the TU56 DECtape to the TD8E controller.
There are some spots on the ribbon cable where the insulation was worn down to the bare wires.
I will tape it for now, and look for a better solution later.
Tomorrow I will swap the left and right diskette drives.
That will let me determine if the problem is with the analog board in the RX01, or in the right diskette drive.
The Forward motor for the left DECtape drive has very little holding torque, and runs very slowly when activated.
Both motors on the right drive work fine.
Next week I will swap boards between the right and left drives to localize the problem.
The motor control boards don't look complicated so it should be an easy fix.
The TD8E diagnostics said that there is something wrong with the drive select logic.
DECtapes have an interesting analog feedback circuit so you can tell if none, one, or more than one drive had been selected.
If the Select Echo signal from the drive is between -6VDC and -9VDC a single drive was selected.
A voltage of -9VDC to -15VDC indicates that more than one drive was selected.
A voltage of 0VDC indicates that no drive was selected.
The diags also said that there was problem when it write to the Command Register and then read the data back.
The only bit that worked with the diag was was for Forward/Reverse.
This error was the same on two different TD8E boards, so I don't trust the diag results.
I toggled in a little program that reads the switches on the front panel and writes the switch settings to the Command Register.
This let me select each drive, set the Forward/Reverse direction, and turn on the Go bit to put the drive in motion.
All of this worked nicely on the right drive, so at least three of the Command Register bits are working OK.
Two of the tape drive indicator bulbs are out.
The same indicator is used on lots of NAVY ships, but I think it will be a lot less expensive to take the indicator apart and replace just the bulb.
A CM2182 bulb is supposed to work. I ordered some from Digikey, so maybe I can repair these next week.
I put two NOS vintage 1979 DECtapes on the drives to see what would work.
The left drive always unwinds the tape because of the motor problem.
I wrote a simple program to tell the DECtape drive to move and found that I can command the right drive to go forward and reverse from the Processor.
I can see Timing, Mark, and Data Track signals when the tape is moving, so lots of the electronics for the right drive are working.
Next week, I will write some simple diagnostics so I can debug the drive select problem.
The simple diags allow me to test small parts of the controller and drive circuitry without trying to understand the DEC diagnostics.
Click on the image for a larger view.
I replaced the bulbs inside of the left WRITE and right SELECT indicators on the drives with CM2182 bulbs from Digikey.
DEC field service always replaced the complete indicator assembly, but they are no longer available.
The surgery involved prying off the metal frame that held on the plastic cover, cutting out the original bulb, and soldering the leads of the new CM2182 bulb to the original contacts.
The color and brightness of the new bulb match the originals very well.
Last week we found that the left drive always unwound the tape because the FWD motor torque was too low.
Replacing the defective G848 Motor Control Flip-Chip in the left DECtape fixed the problem.
The G848 was tagged for future repair.
The first part of the DECtape that needs to work is the Timing and Mark track data.
To help with debugging I wrote a little program that waits for a Single-Line Flag, reads the Mark Track from the DECtape, looks for the Forward Block Mark code (26), reads the block number data, puts the block number in the MQ register, and reverses the tape direction when it sees Forward End Zone (22).
I have two of the TD8E Omnibus TD8E boards that interface the TU56 DECtape drive to the PDP-8/e.
With TD8E #2 the tape just rocks back and forth when the program is run, and the block number is either 0707 to 7070.
I tried both a DEC factory formatted tape, and one that we formatted on the TC01/TU55 on the PDP-8/I.
The behavior with both tapes was the same.
With TD8E #1 the left drive works correctly and shows increasing and decreasing block numbers as it scans the tape.
This means that the Timing, Mark, and Data tracks are all working. With TD8E #1 the right drive rocks back and forth and the block number changes from 0707 to 7070.
I will debug TD8E #2 later because TD8E #1 is mostly working so it will be easier to diagnose and repair.
I looked at the Timing and Mark Track data from the two DECtape drives
The Timing and Mark Tracks from the left drive show a pair of 8us pulses at a 13ms interval when the drive is stopped, and pulses at a 18us interval when running.
The rising edge of the Timing Track signal is centered on the Mark Track signal.
This is how it should be.
The right drive shows constant 20us signals on the Timing Track, and 4us signals on the Mark Track when the drive is stopped or moving.
Something is really wrong with the Mark Track signal.
I swapped the G851 Relay Flip-Chips between slots A09 and A12, but there was no change.
I swapped the M113 NAND Gate Flip-Chips between slots B05 and B16, but there was no change.
I swapped the M040 Solenoid Driver Flip-Chips between slots A08 and A15, but there was no change.
I swapped the G888 Manchester Flip-Chips between slots A14 and B14, and A13 and B13, but there was no change.
The left drive still worked correctly with the swapped Flip-Chips.
The diags reported a select failure when the right drive was selected.
DECtapes wire-OR a Select Echo signal from all of the DECtapes.
If the signal is between 0VDC and -6VDC no drive has been selected. It was -0.2VDC.
If the signal is between -6VDC and -9VDC one drive has been selected. It was -6VDC.
If the signal is between -9VDC and -15VDC more than one drive has been selected. It was -14VDC.
I looked at this signal, and the resulting DF SEL ER L and DF SEL ER H signals.
Everything looked OK under normal and error conditions.
I need to see if this error bit shows up in the Status Register, and if it affects the Skip on Error logic.
After talking to some experts, I did some more debugging on the TU56 tape drive.
It looks like the right tape head is bad.
On Dectapes there are redundant tracks for everything.
One part of the tape head for Mark Track data has an open connection where it should be about 35 Ohms.
I doubt that the tape head is repairable, and is quite a project to replace.
We did some more work on the TD8E tape controller using the left tape drive.
The controller & drive will read a tape, but will not write a tape.
There is a problem reading the Command Register in the tape controller.
These will be the debug projects for next Saturday.
Since the right DECtape drive has a defective tape head we went back to working on the TD8E DECtape controller.
This board has a repair tag on it from 1980 that says that it can't write, and the TD8E diagnostic said that it could not write and then read the Command Register.
We used Kyle Owen's os8diskserver to emulate an RK05 disk drive and booted OS/8.
We were a little surprised to find that we could list directories and read files from the left DECtape drive.
That means that most of the TD8E controller and the left TU56 drive are now working.
Some of the DECtapes that we tried were dated 34 years ago and still read without errors.
That is pretty amazing.
DEC diagnostics will do a good job of making sure that everything is working as expected, but they are sometimes not very useful for debugging a specific hardware problem.
We wrote a little program to read the front panel switches, write them to the TD8E Command Register, then read the Command Register and put the result in the MQ register.
The contents of the MQ register can be seen on the front panel.
All of the Command Register bits worked except for the Write bit. No surprise there.
We disconnected the TD8E DECtape drive, so it would not interfere with debugging.
We found that the SN7474 Flip-Flop E30 that holds the Read/Write bit did not Set when the Write bit was written.
The CLEAR signal to the SN7474 was active when it was trying to Set, so that would explain the behavior.
There a six inputs going to SN7430 E40 that are gated by the SDLC command decoding and make the CLEAR signals to E30.
The DF WLO L and DF SEL ERR L signals were active.
I also found that input pins 4 & 6 on the SN7430 are floating at 2V, not such a good design.
After a long while I found that just about any error in the TD8E or DECtape will clear the Write Flip-Flop.
Connecting the TU56 DECtape drive made the Write Lock Out and Select Errors errors go away, but the Flip-Flop still would not Set.
We have found lots of failed SN7474 Flip-Flop ICs in other DEC projects, so we replaced it.
Unfortunately that didn't change anything.
Prior debugging projects also showed that if one of the input pins on the ICs that are driven by the Flip-Flop is shorted to ground the Flip-Flop will not change it's state.
DEC actually uses this Flip-Flop behavior on some boards and drives the Flip-Flop output pins, hopefully not on this board.
We went looking for all of the ICs driven by the Write Flip-Flop.
The only copy of the TD8E schematic that we have is difficult to read, so that was a challenge.
For the ICs that were common 74 series TTL we just cut the input pin connected to the Flip-Flip and looked at the Flip-Flop output again.
We cut pins 1 & 10 on E35, and E38 pins 1 & 9, but there was no change in the behavior.
We ran out of time before we found the failed IC.
We looked at the Write Flip-Flop behavior on the second TD8E board, and it did Set, and could be read back.
At least we know it should behave as we expected.
Vincent Slyngstad reverse engineered the TD8E and made an Eagle schematic and board layout for it.
We can use the Eagle schematic to text search the signal names and trace the connections on our TD8E, and then annotate the DEC schematic.
Next time we will have a better idea of what ICs are driven by the Flip-Flop and could cause this failure.
One of the possible failed chips is a Signetics N8235N 2-Input 4-Bit Digital Multiplexer with an open-collector output, and we don't have any spares for that.
I think that I found the problem with the Read/Write Flip-Flop on the TD8E.
DEC installed an 0.01 uF capacitor between +5V and the CC R/W (1) H signal from the Flip-Flop.
The other broken TD8E has a working R/W flip-flop and on that board the cap is between +5V and Ground.
The same is true on another TD8E that I have a picture of.
The left leg of the cap is in the correct via, the right leg should go in empty the via to the left of the cap.
This error will take just a minute to fix.
Maybe this TD8E never worked?
The TD8E and TU56 DECtape on the PDP-8/E is now working, mostly.
This morning the DEC diagnostics failed when it tried to write and then read back the Data Register.
The good/bad values were 0020/0206, 0022/0227, 0027/0272.
You can see that the good data was being shifted to the left by three bits, and other data was added at the right.
I wrote a little program to read the switch registers, write the value to the Data Register, read the Data Register, and put the value in the MQ register.
By probing the in and out pins of the 8271 ICs that make up the Data Register I could see that the data was being shifted in the 8271.
I could see extra CLK signals to the 8271 ICs where there should have been just one.
This would load the data from the Omnibus, and then shift it right by three bits.
I traced the source of the CLK signal back to the Timing Track SYNC circuit.
It took me a few hours to find a 7474 flip-flop IC, E03 for the UTS signal, that had both the 0 and the 1 outputs high.
This flip-flop should only go active when the DECtape is Up-To-Speed.
We have found lots of bad 7474 ICs in DEC equipment, so I just replaced the chip.
That didn't change anything.
I then found that both the CLEAR and PRESET signals to the 7474 were low making both the 0 and the 1 outputs high.
This is actually a valid state for a 7474 IC.
I chased the source of the PRESET signal and found that it was controlled by the WTM switch.
This switch is set on to enable writing to the Timing and Mark tracks so you can format a tape.
I had left the WTM switch in the ON position, and should be OFF for normal use.
That was a dumb mistake and wasted a lot of time.
Even after setting the WTM switch to the correct position, the TD8E still failed diags when it is waiting for a quad-line flag.
I need to investigate that further.
Since I had previously been able to read DECtapes from OS/8, I decided to try writing to a tape.
I was able to Zero the directory and copy files to the tape from the virtual disk drive.
I used David Gesswein's resttd8e program to make a bootable OS/8 DECtape from an image on my laptop.
The I told the program to use 4 fields of memory, so it moved lots of blocks from the laptop, and then wrote a lot of tape.
The OS/8 DECtape booted OK, but OS/8 halted when I tried to do a directory listing.
Listing, reading, and writing the OS/8 DECtape from OS/8 booted from Kyle Owen's serial disk emulator works fine.
Maybe the OS/8 image on the DECtape doesn't match the hardware configuration that I have?
I have several TU56 DECtape images, so I will try the others.
I still need to look for, and possibly fix, the potential AC clearing glitch when executing the SDLD instruction.
I have a device that is used to test cables for broken wires near the connectors.
The audio tone that it makes changes when it is touched to a wire, but does not change when touched to just a connector contact.
I will use this device to see if the wire to the Mark Track coil is broken at the connect or at the tape head.
In either case I may be able to do some surgery and fix the broken wire.
The TD8E has a simple 74123 Retriggerable Monostable Multivibrator to create the clock signal to write the timing track on a new DECtape.
It was running at a 4.5 μs interval and should be 8.2 μs.
There is a trimpot on the board to adjust the timing.
Setting it to the correc