PDP-8/E Restoration Log

2/11/14

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.

2/15/14

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.

Next week:

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.

2/23/14

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.

3/2/14

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.

3/8/14

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.

3/22/14

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.

4/10/14

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.

4/26/14

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.

5/10/14

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.

5/17/14

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

5/24/14

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.

5/26/14

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.

6/14/14

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.

6/21/14

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.

6/28/14

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.

7/5/14

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.

7/14/14

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.

7/19/14-7/20/14

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.

7/26/14

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.

7/27/14

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.

8/2/14

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.

8/3/14

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.

8/9/14

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.

8/11/14

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.

8/16/14

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.

8/22/14

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.

8/23/14

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.

8/30/14

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.

9/1/14

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.

9/6/14

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.

9/8/14

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?

9/20/14

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.

Very nice!

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.

9/27/14

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 correct frequency fixed the problem where the it would not format a DECtape.

I was able to format four never used 1979 vintage DECtapes.

It actually takes 6 passes to format and check the tape.

I looked at the SDLD glitch issue that has been discussed a lot in some vintage computer forums.

One input to the 8881 bus driver for the C0 Omnibus signal is delayed by 20 ns as it goes through the 8251.

There is a sizable glitch on the C0 bus line (see below) until the SDLD instruction is decoded by the 8251 and deactivates the bus driver.

I ran a little SDLD test program for 20 minutes without a single error, so maybe my little 20 slot 8/e doesn't see the SDLD glitch where a longer (up to 80 slots) system might have a problem.

We need to look at the processor schematics to see how the C0 signal clears (or not) the AC register.

Maybe it is tolerant of a C0 glitch at the beginning of the IOT instruction cycle.

The upper trace is CC AND 09 H, the lower trace is C0 on the Omnibus backplane.

I started a page dedicated to this issue here: Omnibus TD8E Simple Dectape Controller Glitch discussion

10/3/14

We made a DECtape on the PDP-8/e containing OS/8 using Dave Gesswein's dumprest program.

It actually booted and ran from the tape!

It is painfully slow to run programs because it needs to spin a lot of tape to get to most programs.

So now we have one DECtape, one 8" diskette, two serial ports, and 32k of RAM working on this system.

We need to determine if the diskette problem is in the analog board in the drive subsystem, or in the disk drive.

The easiest way to do that is to swap the two drives and see if the fault follows the drive.

The open connection to one of the timing track coils in the TU56 tape head will be more of a challenge.

I can measure the capacitance at the connector contact and see if I can determine if a wire is attached to the connector contact.

If not, I can use a Dremel tool to dig out the epoxy in the back of the connector and see if I can repair the broken connection.

If the broken connection is in the tape head it will be a lot more challenging to fix.

Once we get both diskette drives and both DECtapes working it will be time to look for an RK8E disk controller and attach an RK05 removable disk drive.

Debugging the RK8E is supposed to be a big challenge because of sensitivity to revision levels of just about everything in the system.

The RK8E also uses Data-Break (DMA) so it will exercise logic in the processor that has not been used yet.

10/13/14

We swapped the left and right diskette drives to see if the problem followed the drive.

It did, so the analog board in the RX01 subsystem is OK and the drive is bad.

We replaced the bad drive with a newer style drive that was silkscreened "RX01 ONLY".

The newer drive has a resistor on the head connector that is usually only used with an RX02 controller.

Oh well, the replacement drive didn't work either.

We need to research the drives in the collection and find one that will work.

10/25/14

We replaced the left diskette drive in PDP-8/e again today, and actually found another one that works!

This one looks like a slightly newer model because it has a resistor in the data head connector.

The resistor is only used in RX01 subsystems, so the diskette must also work in the newer RX02 subsystem.

So now both diskette drives are working.

Time to fix the MI8E bootstrap board so the 8/e will boot from diskette with the push of a button.

10/25/14

We replaced the right diskette drive in PDP-8/e with the newer design that matches the left diskette.

Both diskette drives still work OK.

We removed the tape head from the right DECtape drive.

We have access to some fancy tools that might be helpful for determining the problem without doing lots of investigative surgery.

Hopefully we will find a bad solder joint and will be able to repair the tape head.

10/29/14

We measured the resistance between the MT(1) to the MT(G) signals at the Amphenol connector on the end of the harness.

That measured just a few Ohms and we can see Mark Track data from that track when the tape is moving.

The resistance from MT(0) to the MT(G) is infinite and there is no Mark Track data on from that track.

We used a Cirrus Which Ender to verify that there was a wire connected to the MT(1) contact on the Amphenol connector.

This device emits an audio tone that varies with capacitance, so it was easy to determine that the wire was connected.

The bottom side of the tape head has a cover held on my four tiny screws.

I removed the cover and measured the resistance on the brown wire MT(1) to the corresponding Amphenol connector contact.

The reading was less than 1 Ohm.

Click on the image for a larger view.

So that means that the problem is inside of the epoxy potting in the tape head.

I started digging the epoxy out with a small chisel point soldering iron.

The process seems to work well, but it is time consuming.

The crater that I dug is about 1/2" deep so far.

I broke the solder connection between the orange wire and the MT(1) wire.

You can see a really tiny piece of wire just to the left of where the MT(1) arrow is pointing.

The yellow MT(G) wire looks like it goes deep into the epoxy and then loops back up.

If so, then I probably broke the MT(G) wire off the yellow wire, but maybe I can fix that.

The brown MT(0) wire goes deep into the epoxy, and I have not found the end if it yet.

11/1/14

I bought an MI8E bootstrap board from William Donzelli a few months ago.

This board contains a 12x34 diode array that is really a ROM containing bootstrap code.

The board is manufactured with all diodes installed (0 bits) and diodes are cut out to represent 1 bits.

When you toggle the SW switch on the front panel the MI8E board emulates someone flipping the switches on the front panel to toggle in and run a bootstrap loader.

The one that I bought contains the RX8E diskette bootstrap.

I installed the MI8E, toggled the SW switch, and was really surprised when OS/8 booted from the floppy.

A 40 year old board worked without any repairs!

Now that both floppy disk drives are working it was time to attempt recovering my wife's Masters thesis from 8" floppies.

She did all of the thesis documents on a DEC WT-78 word processing system quite a while ago.

DEC used two recording formats for 8" floppies on the PDP-8.

One was 12-bit based and one was 8-bit based, and both were IBM SSSD format.

The PDP-8/e can use either version.

The OS/8 installation that I am using defaults to 12-bit mode, but the console command "SET HANDLER FLOP=BYTE" will change the floppy disk device handler to 8-bit mode.

Doing a DIR on the WT-78 floppy yielded a "bad directory", which was what I expected with a decades old floppy.

Further investigation showed that DEC made a program "WPFLOP" to read/write Word Processing floppies.

I used the console command "R WFLOP" to run the program, and "RXB1:1" and hit the Escape key to type file #1 on the console.

Word Processing file #1 conveniently was the file directory listing.

Using WPFLOP I have recovered 2/3 of the Masters thesis files and have converted it to an MS Word file.

I will convert the remaining files tomorrow.

11/3/14

We were able to convert almost all of the remaining WPS files from the WPS-78 diskette.

Two files said that there was a header error in the file.

The error was the same for the master and backup diskette.

11/7/14

We borrowed a DECtape head from another TU56 tape drive that is connected to the unused TC11 controller in the collection.

Both DECtapes on the PDP-8/e now work.

We started formatting DECtapes in the collection so we can see which ones are still good.

The success rate is about 50% so far, even for tapes that are probably unused.

Bob Vines volunteered to X-ray the broken DECtape head.

That will show where the tiny wires are embedded in the epoxy so maybe we will have a chance of fixing the broken connection without further damage to the wiring.

We used David Gesswein's dumprest tools to make new diskettes from images.

So far we have bootable OS/8 with diagnostics, OS/8 with Fortran-IV, and COS-310.

COS-310 was targeted towards business use, but we haven't found a copy of the DIBOL language to run in it.

We are also looking for a copy of the WPS word processing software to run under OS/8.

None of the diskettes have support for the DECtape, so we will need to learn how to reconfigure the OS handlers.

The MI8E bootstrap board is very nice.

Just toggle the SW switch and it boots from diskette.

We made a bootable DECtape that configures a new DECtape to boot from a TD8E tape controller.

After it finishes doing some magic it asks for a copy of the OS/8 installation tape.

We haven't found an image of that DECtape yet.

11/15/14

Using David Gesswein's dumprest tools we made a diskette of the WPS word processing software for the PDP-8/e from the ws78_v3.4_wps_system_disk.rx01 image on David Gesswein's http://www.pdp8online.com/ site.

It booted and ran just fine, and I was able to look at the the files on the diskettes that contained my Wife's master's thesis.

I was surprised to see that the contents of the MQ register display on the front panel of the 8/e was cascading lights while WPS was running.

WPS normally ran on a dedicated WT78 that was a PDP-8 microprocessor inside of a VT-52 terminal.

This was very cool stuff 30 years ago.

We have an LQP-02 daisy-wheel printer in the collection, so we should see if it works and get it connected to the 8/e.

That would make a good demonstration of ancient word processing technology.

1/7/15

The 8/e is now the test bed for the Omnibus Peripheral Emulator project.

The OPE can now decode paper tape reader/punch IOT instructions.

During testing the 20A fuse for the +5V blew.

A replacement fuse lasted just a few seconds.

Further testing showed that the "crowbar" circuit that protects electronics if the output voltage gets too high triggered.

The "crowbar" circuit is just an SCR across the +5V output.

I need to see if the crowbar is triggering at too low a voltage, or if the +5V regulation is not working.

1/9/15

I soldered wires to just about all of the pins on the +5V regulator IC VR5 so I could see the signals on a 'scope.

After getting a lot of help from the people on cctech and the Vintage Computer Forums I determined that the +5V regulation is broken.

About 18ms after power on the +5V output goes to 6.4V and the crowbar circuit turns on to protect anything connected to the +5V.

There is a removable A2 regulator board for the +5V in the power supply.

Nothing on it looks damaged.

The project for next week is to diagnose and repair the +5V regulation.

1/10/15

I got a tutorial on how a linear power supply works from Alex and Warren.

I now have a much better idea of how to debug this issue.

Last night I removed the A2 regulator board from the power supply.

This board includes the +5V regulator and the crowbar circuit.

When powered on, the +5V output with no load was about 0.5V, so I don't think that the pass transistors Q201 through Q206 are fried, or Q200 that controls Q201 through Q206 is fried.

That is good news because they look like a lot of work to replace.

I measured Q10 on the A2 board as a diode and it looks OK.

Next Steps:

Connect a ceramic resistor to the +5V output and use a current limited lab power supply to inject a few mA into the Q200.

Hopefully Q201 through Q206 will turn on a little and I will be able to adjust the lab supply to make Q201 through Q206 regulate to +5V output.

I expect that this will work OK and show that all seven of the 2N3055 transistors are OK.

I will measure the resistors on the A2 regulator board to see if one has gone bad.

Another 8/e owner said that this happened on hos power supply.

If one of the precision resistors for the reference voltage is off the power supply won't regulate.

I will remove R56, install the A2 board, and see if the +5V output stays off. That should show that Q10 is still a transistor.

I am not sure that I have enough high value resistors to try injecting a really small amount of current into Q10 to see if I can make the power supply output can be regulated to +5V.

If I can, then I could watch the output of VR5 while adjusting R21 to see if it is really trying to regulate.

Digi-Key has more than 500 LM723 parts in stock so I will order two today.

1/11/15

I removed R56, installed the A2 board, and turned on the power supply.

The +5V output was about 0.5V with no load.

That means that transistor Q10 is not shorted.

1/13/15

We looked at all of the signals going to the LM723 voltage regulator IC for the +5V power supply.

Pin-2, the Inverting Input in the LM723, gets the output voltage from the +5V supply and compares it to the voltage on Pin-3, the Non-Inverting Input.

If Pin-2 is higher than Pin-3 the output voltage on Pin-6 will go lower and cause the +5V power supply to reduce it's voltage.

When it is working correctly this will cause the +5V power supply to remain constant even with changes in temperature and load.

In this case, the voltage on Pin-2 is about 1.6V lower than the +5V power supply output so Pin-6 is always trying to make the output voltage higher.

This goes on for about 18 ms at power on, then the output goes over +6V, the crowbar protection circuit trips, and the +5V output fuse blows.

The 1.6V drop across resistor R59 shows that the LM723 input is consuming about 2 mA instead of the expected micro-Amps.

Something inside of the LM723 is causing the large current draw, so we will replace this IC.

1/15/15

I replaced the LM723 regulator IC on the A2 regulator board.

The system is fully operational now.

Back to working on the Omnibus Peripheral Emulator.

2/1/15

I got an RK8-E disk controller board set, but it will need to be repaired.

I have an offer of an RK05 drive, but I need to get the cables that connect the drive to the controller.

I have two RK05 disk packs that are the version for the PDP-8.

5/9/15

I got an early revision EAE board set.

The interrupts don't work with the M8341 boards installed.

Haven't figured this one out yet.

5/18/15

The STATE display on the front panel stopped working.

Looks like one of the hundreds of diodes is shorted.

5/21/15

It was an operator error problem.

There are aluminum spacers between the front panel PCB and the aluminum bar that holds the front panel in the chassis.

When I reassembled the front panel I put the nylon washers under the heads of the screws instead of between the aluminum spacer and the PCB.

That shorted the -15 trace for the STATE display to Ground and burned a trace on the PCB.

I repaired the burned trace and now the STATE display works again.

Click on the image for a larger view.

7/11/15

I received two RK05 disk drives from Charles Lasner.

They are missing the heads, but otherwise look very good inside.

They will either provide parts, or if I can find heads will get repaired.

9/20/15

Warren and I moved the cabinet containing the TU56 and RX01 to my house, along with the latest RK05 drive that is complete.

I moved the DECtape holder from below the processor to the top of the cabinet, and installed the RK05 drive below the processor.

9/23/15

I replaced the 30A plug on the power cord with a 20A plug so I didn't need to add a 30A receptacle at home.

I reconnected the cabled for the TU56 and the RX01.

It won't boot from either the TU56 or the RX01.

The RX01 had socketed microcode ROMs that have caused trouble before.

I tried wiggling the ROMs, but it will still not boot from the RX01.

I ran some simple diags that I wrote on the TD8E/TU56.

It looks like the direction bit doesn't have any effect, the drive always goes forward.

When running the second test in MAINDEC-08-DHTDA-A-D TD8E DECtape Diagnostic, the tape ran off the end.

I need to look at the SN7474 E34 that holds the Forward/Reverse bit of the command register.

There is an inverter on the paddle card that plugs into the TU56 that could also cause this problem.

9/27/15

Not sure what the problem was with the TD8E, but after fiddling with the board and cables the direction control is working OK.

When I first started debugging the TD8E I wrote some simple programs to test the board and exercise the drive.

One program runs the tape end to end and displays the block number in the MQ register.

With this running bit-6 is always on.

Time to look at the Data Register and the gating logic.

Uh-Oh, the right drive works OK, the left drive has a stuck bit-6.

Maybe the left head has now failed.

10/01/15

I modified my simple TD8E diags to read the switch register, write to the command register, read the command register, and put the contents in the MQ.

With all of the switches off, bit 4 of the MQ is on indicating Write Lock Out.

With switch 0 on to select drive 1, bit 4 of the MQ is off.

The DF WLO L signal on pin 2 of the SN7430 E40 is low for the right drive and high for the left drive.

This will prevent the Write bit in the command register from going on for the right drive.

It turned out to be a dirty Write switch on the right drive.

The WRITE light was going on, but the WRT ECHO signal from the right drive was in the wrong state.

Wiggling the WRITE switch about 50 times fixed the problem.

Time to try the TD8E diags again.

10/06/15

After more fiddling with the RX01 it is working again.

It booted WPS, COS, and OS/8 from the floppies.

I took the cover off the RK05 and powered it up...No smoke!

I deactivated the head coil, pushed cartridge detect switch and pushed the RUN button.

The blower and the spindle motors came on, and still no smoke.

The drive needs to be cleaned and needs all of the foam seals replaced.

I setup my PC at home as an os8diskserver.

OS/8 boots OK through the 38kb serial port.

I need to replace the non-system disk handler with the one for os8diskserver so I can access the rest of the RK05 disk images.

I am having some difficulty loading a text file through the serial console into the edit program.

I need to add more delays to the terminal emulator to give edit time to manage the new text.

3/20/16

For the past few months I have been fiddling with the TD8E DECtape controller with the idea of writing software to read LINCtapes.

I may have to modify the timing track signal so that the phase is the same as with the LINCtape controller.

I bought a replacement front panel from Rod Smallwood.

It looks much better than the original.

Click on the image for a larger view.

I got two more RK05 disk drives, one is complete and now installed in the PDP-8/e rack.

I cleaned off the dried foam seal for the blower and disk pack, and replaced the seals with weatherstripping from Home Depot.

DEC used some foam tape to seal around the cables going into the card cage.

The foam was dried out and sitting in the bottom of the drive, so I replaced it with some of the weatherstrip foam.

Click on the image for a larger view.

Two layers of 3/4" x 7/16" worked for the blower

Click on the image for a larger view.

One layer of 3/16" x 5/16" worked for the disk pack seal.

I tied the pack-present switch closed and spun up the spindle motor.

The bearing sounds really bad.

Hopefully running it for a while will warm it up and spread the lubricant around.

If not, I will check the other three drives and see if one of the other spindle bearings is OK.

It looks like the spindle replacement procedure is not difficult.

3/24/16

I tried to finish up the front panel installation, but noticed that one bulb is out.

I can't find my spares, so I ordered 25 more CM7371 bulbs from Mouser.

3/28/16

I replaced all of the Memory Address bulbs with CM7371 bulbs so they would be exactly the same brightness.

I replaced the RUN bulb because it is on a lot, and two of the other bulbs that looked bright.

The original bulbs were a mix of OL-2 and CM7367 bulbs.

The new front panel looks very nice now.

I booted OS/8 from the RX01 floppy and the processor died.

I can load the Memory Address from the switches, but cannot examine, deposit, or run.

3/30/16

The -15V power supply is only making -4.22V.

The -15V is used for a bias voltage for the front panels, so the switches won't work without the correct voltage.

The DC OK signal is deactivated so the processor won't run.

When the +5V failed, the LM723 regulator had failed.

It is very likely that the same part on the -15V supply has failed.

I have a spare LM723, but it is quite a bit of work to disassemble the system to get to the power supply.

4/3/16

I replaced the LM723 regulator on the A1 card in the H724 power supply, but it did not fix the problem.

The voltage across C300 and C301 is about 30V, so the transformer, CR300 and CR301 are all OK.

The voltage base of Q301-Q304 needs to be about 15.6V and is 0.6V.

The voltage base of Q300 needs to be about 16.2V and is 1.0V.

Q300 is driven from pin 6 of the LM723 that I just replaced.

While I was measuring the voltages on the LM723 it decided to regulate correctly.

I readjusted the supplies to +2.5%: +5 to 5.13V, the -15V to -15.38V and the +15V was +15.46V.

The voltages on the LM723 pins relative to the -15V output when in regulation are:

1, Current Sense: N/C

2, Inverting Input: 5.17V

3, Non-Inverting Input: 5.17V

4, Vref: 7.07V

5, V-: 0.2mV (the -15V output)

6, Vout: 16.55V

7, Vc: 20.51V

8, V+: 20.51V

9, Freq Comp: 18.34V

10, Current Limit: N/C

I put the system back together and ran OS/8 for about 5 minutes and the -15 supply died.

Time to take it apart again.

The power supply is out and back on the workbench.

Of course it is working OK now.

I put a load on the -15 and will run it for a while.

4/5/16

I resoldered the whole A2 regulator board and now the -15V does not work.

Maybe this is a good thing.

The voltages on the LM723 pins relative to the -15V output are:

1, Current Sense: N/C

2, Inverting Input: 7mV

3, Non-Inverting Input: 1.86V

4, Vref: 4.20V

5, V-: 0.2mV (the -15V output)

6, Vout: 3.64V

7, Vc: 5.16V

8, V+: 5.16V

9, Freq Comp: 4.85V

10, Current Limit: N/C

4/6/16

I spice modeled the -15V power supply so I could see exactly how it works. It turns out that the LM723 is a very good regulator. Now that I understand how the -15V supply works, I measured the power supply voltages again. I used the -15V connection as the ground on the DVM to make interpretation of the voltage measurements easier. The voltage on the base of Q300 was 3.64V, and 2.91V on the base of Q301-Q304. Very low, but at least the transistors look OK. The voltage drop emitter to collector on Q301-Q304 looked reasonable considering the low base voltage.

I then measured voltages relative to the common ground in the power supply. The -15V output was about 2.75V, so nothing was shorted. The emitter of Q301-Q304 was also 2.75V. Um, that's not right, it should be at ground. The emitter of Q301-Q304 goes to the -15V fuse F300 and it was OK. The ground side of teh -15V fuse also measured 2.75V, so that wasn't right. I chased the ground connection from F300 to ground, and found that the screw that connects F300 to the ground bus bar was loose. That explains why the power supply was position sensitive. A little over a year ago the +5V regulator died. When testing the repair I used the screws that attach the big filter capacitors to the bus bars to connect lots of ceramic resistors for loads. I forgot to tighten one of the screws when I finished testing, and it happened to be the ground for -15V.

I put everything back together...again.

It is alive again, and just booted OS/8 from diskette.

Now I can go back to working on the RK05 disk and the RK8E controller.

4/11/16

I cleaned the RK05 heads. They were very clean anyway. I looked inside of one of the RK05 packs that I have. It was spotlessly clean. I gave it a swipe with a barely damp Texpad and it didn't pick up any residue. I think that it is safe to give it a try. I put the pack in the drive, and spun it up. No funny noises. I deactivated the positioner amplifier, and manually moved the heads onto the pack. No funny noises. The voice coil tries very hard to pull the heads off the pack. I need to find out if that is normal.

4/12/16

I replaced the HEPA filter. It made a huge improvement in the air flow. This drive is one of the newer styles that has the plenum as part of the filter.

The noise when the spindle is rotating is from the lower bearing on the spindle motor. I have a spare motor, so I will replace it.

I adjusted the power supply voltages. The pot of -15 was a little dirty. After a few turns it worked OK.

4/15/16

The spindle motor spins up when you press the RUN switch. That means that all of the interlock switches are OK.

The heads do not move to track 0, so there is an issue with the Index/Sector transducer, HOME switch, or parts on the M7700 or M7701 boards.

I looked at the SECTOR INDEX RAW signal on terminal 1 of TB2. Putting some paper in the Index/Sector transducer slot caused the signal to change from 0V to 4V.

I installed a disk pack and spun it up. I could see Index/Sector pulses on pin A02E1 on the backplane, so the cables are OK.

I could not see Index/Sector L pulses on pin B02D1, A02R2, or A02S2. I need to look at the Sector Timing Delay circuitry on the M7700 board.

4/18/16

I replaced the M7700 module with a spare. I can now see the INDEX PULSE L signal on A02R2, SECTOR PULSE L on A02S2, and INDEX/SECTOR L on A02D1.

The LOAD HEADS H signal goes high 8 seconds after the strive is spun up, but the heads don't move.

4/20/16

I studied the prints and maintenance manual for the RK05, so now I have a good idea of what should happen when the RUN switch is pressed.

If the HOME switch on the carriage doesn't work, the head won't move out. It checked out OK.

The behavior of the FWD H and REV H signals doesn't look correct.

The INNER LIMIT H and OUTER LIMIT H signals from the G938 are working OK.

COUNT PULSE FWD H from the G938 is working OK, but the COUNT PULSE REV H is not.

I replaced the G938 module with a spare, and now the drive shows ONCYL and RDY!

4/21/16

I added the jumpers listed in section 5.4.2.1 of the Maintenance manual, Dynamic Off-Line Checks and Adjustments.

I dded the jumpers listed in section 5.4.2.1 of the Maintenance manual, Dynamic Off-Line Checks and Adjustments.

I configured it for 2, 4, 64, and then 128 cylinder oscillating seeks. It worked OK, and did not fault.

Tomorrow I will look at the Sine, Cosine, Velocity, and Amplitude adjustments on the G938 module.

4/21/16

I installed the RK8E controller and tried the DHRKA-E Diskless Diagnostic.

It ran for a very long time and then failed with:

STATUS REGISTER ERROR

PC: 2033 GD:2204 ST:6204

4/26/16

Test 49 at location 2033 in memory. It looks for a "DRL" when the buffer is empty.

I skipped to test 50 and it:

STATUS REGISTER ERROR

PC: 2075 GD:2200 ST:6200

I skipped to test 51 and it:

DISK SKIP ERROR

PC: 2115

These tests are all related to "DRL", so I guess that I need to fix that before I can continue testing.

I tried some of the other tests. When started test 78, it tested the data-break capability, ran for a while, and printed RK8E DISKLESS PASS COMPLETE.

At least now I know that data-break in the processor and the RK8E both work.

Time to study the maintenance manual and prints and fix the "DRL" problem.

4/27/16

If you raise SW3 and hit CONT after the diag halts you get more information on the Test 49 failure.

STATUS REGISTER ERROR

PC:2033 GD:2204 ST:6204

CR:000774 ST:6204 DB:7775 CM:0000 DA:7775

PC=Program Counter where the error occurred.

GD=Good Data

ST=Status Register

CR=CRC Register

DB=Lower Data Register

CM=Command Register

DA=Disk Address Register

The bits in the Status Register are BUSY, HEAD IN MOTION, FILE NOT READY, DATA REQUEST LATE.

In this case the BUSY bit was on in the Status Register, and should not have been.

I ran many of the tests in the 49-77 range and most stopped with bit 0 in the Status Register as a 1 when it should have been a 0.

The missing 100ns delay line on the M7104 board is tied to the clock line of the Done flip-flop.

I connected the wires that used to go to the delay line together and ran the diag again.

Unfortunately it didn't make a difference.

I will try executing a DCLR instruction with the AC=0000, and then read the Status Register.

If bit 0 is still on, then I know where on the M7104 board to look for the problem.

4/28/16

Executing:

7301 CLA,CLL,IAC

6742 DCLR

6745 DRST

Should clear the major registers, and put the contents of the Status Register in the AC.

The AC contained 2200, meaning Head In Motion, File Not Ready.

Bit 0 in the Status Register is off, so the DONE FLAG flip-flop E39 and the path to the AC is working.

I ran the DHRKA diag again, and it stopped with the same message about the Status Register containing 6202 when it should contain 2202.

I executed a DRST instruction and the AC contained 6202, so I know the diag is not lying.

I hit the CLEAR key and executed a DRST instruction and the AC contained 2200, so I know the CLR STATUS L signal mostly works.

Still more to investigate.

4/29/16

If I single step through TST49 it works OK.

My guess is that the problem is timing related.

Probably time to put the 100ns delay line back in the M7104 board.

5/6/16

I bought another complete 8/e.

The processor, 8k core, RX8E, and MI8E boards all work.

The M8655 UART based serial console board will transmit, but not receive.

5/17/16

Vincent sent me an M104 flip-chip that became a donor for the missing delay 100ns line on the M7104 board.

I reran the DHRKA-E Diskless Diagnostic, but still have all of the boards from the new 8/e installed.

This time it halted at 3471, so TST49 now works, and it is failing at TST77.

This test puts a 0000 in memory location 0000 and uses a data break write to disk to fetch the data.

These tests worked before, so it might be a problem with the processor boards from the new 8/e.

DATA BREAK ERROR

PC:3471 GD:0000 CM:4000 AD:0000 DT:6244

CR:007740 ST:2200 DB:7122 CM:4000 DA:7122

PC=Program Counter where the error occurred.

GD=Good Data

CM=Command Register

AD=Break Address of Data Break

DT=Data Found During Data Break

5/18/16

I put the original 8/e processor boards back in the chassis.

Now the data break TST49 runs OK, but TST79 failed.

DATA BREAK ERROR

PC:3553 GD:0000 CM:4000 AD:7777 DT:7777

Hitting the CONT key caused the diag to complete the rest of the tests successfully.

It printed RK8E DISKLESS PASS COMPLETE and ran the program again.

After several successful passes it printed:

DATA BREAK ERROR

PC:5655 GD:2525 CM:4010 AD:7777 DT:0022

So it looks like there is an intermittent problem with data break.

5/22/16

I put the 32k RAM board back in the system in case the 8k core board was the cause of the data break errors.

I connected the RK05 drive to the RK8E controller to see how much works.

It will seek to a cylinder and recalibrate.

I tried reading the disk, but it gets lots of errors.

I have no idea how the alignment of this drive matches the disk pack that I bought on eBay.

I gave up on the idea of making an image of the pack and formatted it.

The whole format process took just a few minutes and didn't report any errors.

MAINDEC-08-DHRKB Drive Control Test ran successfully after the drive was formatted.

I used David Gesswein's dumprest program to write an image of an RK05 disk pack onto the real RK05 disk.

It booted OS/8 from the RK05 disk pack.

There is not much activity when it boots from the disk, so it is not as impressive as booting from DECtape.

5/23/16

Several PDP-8 enthusiasts had a discussion today about making a good OS/8 disk pack image that can be used with SIMH and on a real PDP-8.

Charles Lasner will make the OS/8 pack image and several of us will write it to real RK05 disks.

That should give all of us a known good version of OS/8 to work with.

5/25/16

I have the DECUS 8-804 Music program running.

You put an AM radio near the PDP-8/e and you hear music!

It clicks the diskettes for emphasis.

5/30/16

I reinstalled the TD8E DECtape controller for the TU56 tape drive.

I managed to modify the OS/8 configuration to support the RK05 disk, RX01 diskettes, TU56 DECtapes, and the serial disk.

Now I can use SIMH to make RK05 disk images, and then copy the files from the disk image in my PC to the hard drive, diskettes, or DECtape.

6/15/16

I made an image of the RK05 disk pack from the PDP-12 using this 8/e.

Unfortunately there was nothing on the pack other than a 5252-2525 pattern.

This pattern was probably left from running the disk diagnostics.

6/16/16

I borrowed the M8655 serial port board from my second 8/e and put it in this system.

Now the console runs at 9600 baud, much nicer than 110 baud.

6/27/16

I replaced the noisy spindle motor with a spare.

The motor was noisy at first, but quieted down after running for a few minutes.

I noticed that the blower motor was not running.

It is a really bad idea to run a drive without a blower supplying clean air to the heads.

There is 117VAC to the blower motor, so it looks like I need to replace that motor too.

6/28/16

I removed the blower motor and measured the resistance on the coils.

The common connection to the start and run coils is open, but the resistance across the start and run coils is 127 Ohms.

I did some surgery on the motor, but it looks like it would be quite a challenge to repair the connection to the coils.

I will take a blower off of one of my other RK05 drives.

7/1/16

I replaced the RK05 blower and the drive is working again.

I remade the RK05 OS/8 disk pack for the PDP-12 and will try that tomorrow.

7/2/16

The RK05 OS/8 disk pack worked fine on the PDP-12.

To Do:

Load the RIM & BIN loaders into field 7. (done)

Load and rerun Instruction Test #1 to see if all of the instructions are working in the processor. (done)

Need to get:

32k RAM board. (Installed and working well)

M868 TD8-E DECtape Control board so we can connect the TU56 DECtape drives. (Have two, one working. Both DECtape drives are working)

M8650 KL8-YA Terminal Control. This serial console support high speed connections. (Have one, plus a M8650 KL8-E configured for 38,000 baud)

M8357 RX8-E RX01/RX02 diskette interface, because we probably will never find a controller for the SYKESdisk floppy drives. (The RX8-E and both RX01 drives are working)

M7104, M7105, M7106 RK8-E RK05 Disk Interface. Need to get the cable to connect the RX8E to the RK05. (Repaired and working nicely.)

Simple TD8E Diagnostics