PDP Recovery 11/04
Translation of an article on the restoration of an old interesting machine. Many heavy pictures. Italic my comments.
This PDP 11/04 originally belonged to Ericsson. We got it at the end of the eighties from EDKX, the Ericsson computer club. The computer was transferred in parts, but everything was in place except for a pair of screws. Together with the PDP-11 itself, there was a tape station TU60.
Operator console panel
The PDP-11/04 appeared in the mid-seventies as a cheaper successor to the PDP-11/05. In this new version, DEC was able to fit all the processor logic on one six-contact board ( PDP used several types of boards with different form factors - six-contact, four-contact, two-contact. The photo shows 6 groups of pins slightly below. In addition, the boards were divided according to , what tire they are designed for. ) instead of two in the predecessor. The modules were connected to a common cross-board ( backplate ) with nine slots made by wrap. Typically, the PDP 11 was a programming console (a separate panel. The PDP was assembled from several blocks, something like a rack with a set of equipment ) through which the operator could enter simple boot programs and carry out system maintenance. However, this particular instance had only the usual limited operator console.
Cross board
In the Computer Engineering: A DEC view of hardware design, the PDP-11 family of machines is described in great detail. The book is scanned and is publicly available. Very exciting reading!
CPU board
')
The processor module consists of 138 chips. A slight simplification of the operating machine ( datapath, a part of the processor that performs operations on any data. For example, these are ALU, multiplexers, register files, decoders. In general, this is practically the most important part of the processor. ) And the use of programmable memory has reduced the number of chips used . There are five 256x8 bipolar programmable microchips of ROM on the board, allocated for microcode storage, which is packaged in 40-bit structures. The first eight bits are reserved for the address of the following micro-instruction. An interesting feature is that the line through which these addresses are transmitted is implemented according to the open collector scheme, which allows conditional microcode branching to be made simply using wired OR-connections directly on the bus. As the main ALU, DEC took the well-known 74181, and Intel 3101 16x4 RAM chips were used as scratchpad memory for the main registers. There is no separate crystal for clocking, but instead there is a delay line in the feedback circuit.
Memory board
We got the PDP-11/04 with a 16 kilobyte memory module. It contains 32 MK4096, MOS-dynamic memory chips, produced by MOSTEK. An interesting remark - this was the first memory with multiples addressing by column / row, a similar scheme is used in modern DDR. Thanks to this innovation, MOSTEK's engineers were able to fit 4 kilobits of memory into a 16-pin package.
This is the M7800 card, the asynchronous communication module DL11. ( The PDP-11 used its own classification of modules. For example, the scheme indicates MS11-JP, which means a memory module, but the specific boards could be different - M7867-XJ, M7847-DJ or which card complies with the module standard. In this case DL11 is a classifier, and the M7800 is a specific board. )
The latter board, M9312, is used to boot the system, and, moreover, acts as a bus terminator. In general, there should be two terminators in the system, since the processor module itself does not perform this function. Therefore, another terminator should be installed on the opposite edge of the bus, in this case as close as possible to the processor module. On the M9312, there are four bipolar programmable ROM slots that allow support for booting from different devices. In addition, the board has an EPROM, which contains the console emulator code for communication with the operator via the serial port.
The computer is disassembled by screws in this document .
The first thing to start with is to check that the power supply is OK. In particular, it is important to ensure that the capacitors are in good condition. H777 is a pulse power supply with a key element in the secondary circuit, which means that it contains a huge transformer ( compared to the key circuit in the primary circuit, it is really large ), which reduces the amplitude of the input AC voltage to much more pleasant in operation 38 Vac. It's not very nice to mess around with power supplies, in which almost all parts of the circuit have voltage in the region of 400 VDC. H777 consists of two regulators: 5 volt, generating 25 amperes, and MOS-regulator, giving + 15V, -15V, + 5V ( in other versions of H777 there is also a third regulator on + 20V, -5V ).
Some kind soul scanned the necessary manual , which describes in detail the entire internal kitchen of this BP.
Large 50V x 22000mF capacitors, filtering unregulated direct current, were able to fully charge through 10kΩ resistance, and the leakage current was extremely low. The 5V output capacitor was in much worse shape. The Sprague 6V x 3900mF capacitor, on impressive legs, never reached its rated voltage, even with long use with a 560 ohm resistor.
On the left is a time-torn element, on the right is its replacement
At present, such 6V x 3900mF capacitors with bolts cannot be found, so I replaced it with 40V x 6800mF from RIFA.
With a new capacitor, the power supply unit was able to issue 3 amps to my test board, from which the pleasant aroma of heated getinax reached quickly ( mock-ups are often made from this material ).
BP checkout process. By the way, a healthy primary circuit transformer is visible.
But will it all work if you connect the BP to the cross-board? Unfortunately, it did not work. It turned out that the two signal contacts of the power supply unit are in a permanently low state: BUS DC LO L and BUS AC LO L. These signals are active low and suppress the main clock generator in an active state.
The circuit above describes the 5 volt regulator. The highlighted blue area is a current source circuit that receives an unregulated direct current at the input, charging a 50mF capacitor, which then produces a beautiful sawtooth signal. A resistor array and a set of comparators ( operational amplifiers, which act here as voltage comparators ) generate a BUS DC LO L, BUS AC LO L and an internal signal on which the clocking of the main PWM key is based. The capacitor voltage did not exceed 20.4 volts, which is not enough to change the polarity of the two comparators. It looked as if too much current was being absorbed from this source. Replacing a capacitor did not change anything. But, besides the current source, a red region of the circuit is connected to the capacitor - overload protection circuit. If any of the transistor switches fail, then an unregulated direct current of 38 volts will be output. Which, by itself, is not very good. Therefore, it uses a Zener diode and a pair of thyristors, which are triggered at an output voltage of more than 5.4 VDC, which leads to a short circuit in the current source, and, in turn, extremely effectively stops any activity in the power supply. The problem, apparently, was that even under normal conditions, the protective circuit absorbed 1.5 mA due to the leakage of the thyristor, moreover, in the closed state. Of course, any thyristor flows, but not as much as this.
broken thyristor maybe C32AX135
After replacing the thyristor with a modern BT145, the power supply unit was working as it should.
We connect all the cables and turn on the power. Smoke is not visible, which is a good sign. But the “RUN” light often flickers, and, after switching the corresponding toggle switch on the console to the “INIT” value, it only blinked once at all. The situation is not encouraging.
The oscilloscope connected to the main clock signal of the processor module shows that at the beginning there are 8 clock cycles, then a pause for a couple of microseconds, 3 bars, another pause and again 3 bars, but nothing follows them.
In this photo you can see that the period of the sync signal is closer to 250 ns than to 260 ns, about which it is written in Computer Engineering. However, the use of the delay line in the feedback circuit will not be able to give such accuracy. However, 4 MHz is a very impressive result for the mid-seventies.
Most likely, the oscilloscope could not help in further clarifying the causes of the malfunction. For this kind of task, I am keeping this little USB analyzer.
But in order to cover the entire computer with its address and data buses, I need four of these. Fortunately, at that moment I was offered to buy an HP1664A logic analyzer at an affordable price.
After some problems at the beginning, when I mixed up some signals and forgot about the fact that the board uses active-low levels, I received several interesting trace logs:
Here the bus value is displayed, on which the addresses of micro instructions are transmitted for execution. In fact, here is the address of the next micro-instruction, during the execution of the current one. However, judging by the manual , this is a completely correct sequence of micro-operations ( if really interesting, then chapter 6.3.3 Restarts from power failure ).
It is interesting in the top of the log that, when the address is set to 0 on the bus, we get 0165020, which is the value of the command counter containing the address from which we must start execution after a power failure. This address belongs to M9312 and indicates the diagnostic program. But the next address of the instruction on the bus is 0167020. For some reason, the 10th bit turned out to be one! Exploring the DS8641 bus receiver chip in more detail, I noticed that even with an input current of 3.31V, we get 3.78V output! Looks weird.
Here, this little evil thing:
Unfortunately, the DS8641 is not a very common chip. In addition, it was specially adapted to open collector tires for DEC. I ordered a few on Ebay from a seller from China, but since the package was sent for quite a long time, I decided to drop the same chip from another board, and replace it with a failed chip in the processor module.
This time the result was better:
However, it all ends in a looped wait for the TX console serial port readiness bit. Strange. Maybe it's a M7800 error?
Another M7800 module was connected to the cross-board. Serial port connected to a laptop.
Fine. Now the system goes through all diagnostic steps from first to fourth. But entering “DL” in the console in order to try to boot from a non-existent RL device ( RL01 / RL02 is something like hard disks, but with removable data cartridges. ), Causes the machine to stop.
It seems that when you try to test the RAM, it fails, and then, immediately, we get a double error during the processing of the first. This behavior is typical for exception handling ( more precisely traps, trap ) by the processor.
While examining the memory module and checking jumpers and switch positions, I found that when I clicked back and forth with the DIP switch, the position of the 6th key out of 8 is ignored, and the circuit remains closed. Problem.
On the left - the new switch, on the right - the old one.
Finally, the computer has started!
To understand that it works, it is possible by the fact that the author enters console commands in the terminal: @L - load the address, @E - check the data at the address, @D - write the data on the loaded address .
PDP11GUI is a great Windows utility for managing your PDP-11. It can load files into PDP-11 memory, view the memory snapshot and start the processor.
Punched tapes with BASIC can be found on the Internet. But, unfortunately, they are in Absolute Binary Loader format, which PDP11GUI does not understand. However, you can write a simple C program to convert. The resulting file can already be fed minicomputers, but this is all very slow on the 9600bps line.
UPDATE: In version 1.38, the PDP11GUI no longer needs an external program, since the conversion code was included in the PDP11GUI . ( Yes, in the original 5 identical links to PDP11GUI ).
Having started the PDP with the starting address 016104, we will receive the BASIC'a invitation ( it is obvious that the launch went through that tool in which there is a corresponding “initial PC” setting ).
It is noticeable that I have not written anything for a long time on BASIC'e.
For the real test that the processor works as it should, there are two diagnostic programs - GKAA and GKAB. There are two ways to run them: load a punched tape image into the PDP11GUI or use the XXDP. I tried both methods.
It is known that these programs were stored on punched tape, but, alas, I could not find the images of these punched tapes. But I found an image for the XXDP that contained GKAAA0.BIC and GKABC0.BIC. It turns out that binaries have the same format as punched tapes. I used PUTR to extract them from the image. Do not forget that the files need to be copied as binary, and not, like me, you will be puzzling for several hours ( PUTR provides a kind of DOS-like interface, and you need to do “copy / b” instead of just “copy” ).
After extraction, I simply downloaded the images into the PDP11GUI and ran it from the address 0200.
The XXDP should run from some storage device. I only have one option that would be quite simple to use on my PDP-11 at that moment, the TU58 ( tape system ), since it uses the serial port to connect and therefore can be emulated on a PC. I downloaded tu58em and compiled it on my Mac. It was necessary to make only a few changes in the code to work with the serial port in order for the program to be successfully compiled.
After that, I started working on creating a boot image with the XXDP. This kind of work can be done much faster using the PDP-11 emulator. I used E11 . First I tried XXDP 2.6, found as an image on bitsavers:
But it required more memory than it was on my machine, so using this version would not work. In addition, GKAB did not want to run on an emulated PDP-11/04 for an unknown reason.
After that, I spent the time trying to make a TU58 image for XXDP +, an earlier version of the XXDP package. This is how I did it in E11:
GKAAA0.BIC under XXDP + on this machine started successfully. Most of the system is in excellent condition! Here is a link to the image that I made.
But the launch of GKABC0 ended up stopping the system. It is impossible to find the source code for a specific version of the utility, but the version under the PDP-11/34 should work. Looking through the code , you can see that the section where the system stops is a test of the stack overflow processing logic. The stack pointer is set to 0400, and then the console TX interrupt twitches ( apparently IOT refers to the IOT instruction, which causes the 020 interrupt, to which the OS usually hangs the I / O handler ). In this case, the stack pointer becomes less than 0400, which leads to the generation of an exception, the processing vector number of which is 4 or 6. On my machine, the behavior was different - more and more new console interrupts were generated until the stack reached 0177774 (physical memory no address), and then stopped with a double bus error.
Changing the boards, I noticed that using another DL11-W eliminates the problem. It seems that in DL11-W, the interrupt handling logic is broken. The interrupt must be cleared as soon as the processor responds with SSYN ( a Unibus bus signal, a kind of handshake ). This did not happen on a broken map. Only the processor began to process the interrupt, as received it again and again. The process of working with interrupts on the Unibus bus is not very complicated. The device sets the signal BRn, and the processor responds with a BGn setting when it is ready for interrupt service. After that, the device, in turn, responds with SACK, sets the interrupt vector number, and pulls the INTR. The trace below is taken from a working card:
Do not forget that in PDP-11 the active signal level is low
The diagram shows the interrupt trigger and the valve that should clear the interrupt signal when it is already serviced.
This fuzzy photo clearly shows the failing 7408 AND-valve on the broken board.
7408 here is designated as E4, 12 and 13 are input signals, 11 is output, which should, in theory, clear an interrupt when it is in a low state. This does not happen, and interrupts all go and go.
At this, the repair of the main board unit is over, in the second part of the article we are repairing the TU60 tape station, and in the third - the LA30 Decwriter terminal.
This PDP 11/04 originally belonged to Ericsson. We got it at the end of the eighties from EDKX, the Ericsson computer club. The computer was transferred in parts, but everything was in place except for a pair of screws. Together with the PDP-11 itself, there was a tape station TU60.
Operator console panel
The PDP-11/04 appeared in the mid-seventies as a cheaper successor to the PDP-11/05. In this new version, DEC was able to fit all the processor logic on one six-contact board ( PDP used several types of boards with different form factors - six-contact, four-contact, two-contact. The photo shows 6 groups of pins slightly below. In addition, the boards were divided according to , what tire they are designed for. ) instead of two in the predecessor. The modules were connected to a common cross-board ( backplate ) with nine slots made by wrap. Typically, the PDP 11 was a programming console (a separate panel. The PDP was assembled from several blocks, something like a rack with a set of equipment ) through which the operator could enter simple boot programs and carry out system maintenance. However, this particular instance had only the usual limited operator console.
Cross board
In the Computer Engineering: A DEC view of hardware design, the PDP-11 family of machines is described in great detail. The book is scanned and is publicly available. Very exciting reading!
CPU board
')
The processor module consists of 138 chips. A slight simplification of the operating machine ( datapath, a part of the processor that performs operations on any data. For example, these are ALU, multiplexers, register files, decoders. In general, this is practically the most important part of the processor. ) And the use of programmable memory has reduced the number of chips used . There are five 256x8 bipolar programmable microchips of ROM on the board, allocated for microcode storage, which is packaged in 40-bit structures. The first eight bits are reserved for the address of the following micro-instruction. An interesting feature is that the line through which these addresses are transmitted is implemented according to the open collector scheme, which allows conditional microcode branching to be made simply using wired OR-connections directly on the bus. As the main ALU, DEC took the well-known 74181, and Intel 3101 16x4 RAM chips were used as scratchpad memory for the main registers. There is no separate crystal for clocking, but instead there is a delay line in the feedback circuit.
Memory board
We got the PDP-11/04 with a 16 kilobyte memory module. It contains 32 MK4096, MOS-dynamic memory chips, produced by MOSTEK. An interesting remark - this was the first memory with multiples addressing by column / row, a similar scheme is used in modern DDR. Thanks to this innovation, MOSTEK's engineers were able to fit 4 kilobits of memory into a 16-pin package.
This is the M7800 card, the asynchronous communication module DL11. ( The PDP-11 used its own classification of modules. For example, the scheme indicates MS11-JP, which means a memory module, but the specific boards could be different - M7867-XJ, M7847-DJ or which card complies with the module standard. In this case DL11 is a classifier, and the M7800 is a specific board. )
The latter board, M9312, is used to boot the system, and, moreover, acts as a bus terminator. In general, there should be two terminators in the system, since the processor module itself does not perform this function. Therefore, another terminator should be installed on the opposite edge of the bus, in this case as close as possible to the processor module. On the M9312, there are four bipolar programmable ROM slots that allow support for booting from different devices. In addition, the board has an EPROM, which contains the console emulator code for communication with the operator via the serial port.
The computer is disassembled by screws in this document .
Check the power supply H777
The first thing to start with is to check that the power supply is OK. In particular, it is important to ensure that the capacitors are in good condition. H777 is a pulse power supply with a key element in the secondary circuit, which means that it contains a huge transformer ( compared to the key circuit in the primary circuit, it is really large ), which reduces the amplitude of the input AC voltage to much more pleasant in operation 38 Vac. It's not very nice to mess around with power supplies, in which almost all parts of the circuit have voltage in the region of 400 VDC. H777 consists of two regulators: 5 volt, generating 25 amperes, and MOS-regulator, giving + 15V, -15V, + 5V ( in other versions of H777 there is also a third regulator on + 20V, -5V ).
Some kind soul scanned the necessary manual , which describes in detail the entire internal kitchen of this BP.
Large 50V x 22000mF capacitors, filtering unregulated direct current, were able to fully charge through 10kΩ resistance, and the leakage current was extremely low. The 5V output capacitor was in much worse shape. The Sprague 6V x 3900mF capacitor, on impressive legs, never reached its rated voltage, even with long use with a 560 ohm resistor.
On the left is a time-torn element, on the right is its replacement
At present, such 6V x 3900mF capacitors with bolts cannot be found, so I replaced it with 40V x 6800mF from RIFA.
With a new capacitor, the power supply unit was able to issue 3 amps to my test board, from which the pleasant aroma of heated getinax reached quickly ( mock-ups are often made from this material ).
BP checkout process. By the way, a healthy primary circuit transformer is visible.
But will it all work if you connect the BP to the cross-board? Unfortunately, it did not work. It turned out that the two signal contacts of the power supply unit are in a permanently low state: BUS DC LO L and BUS AC LO L. These signals are active low and suppress the main clock generator in an active state.
The circuit above describes the 5 volt regulator. The highlighted blue area is a current source circuit that receives an unregulated direct current at the input, charging a 50mF capacitor, which then produces a beautiful sawtooth signal. A resistor array and a set of comparators ( operational amplifiers, which act here as voltage comparators ) generate a BUS DC LO L, BUS AC LO L and an internal signal on which the clocking of the main PWM key is based. The capacitor voltage did not exceed 20.4 volts, which is not enough to change the polarity of the two comparators. It looked as if too much current was being absorbed from this source. Replacing a capacitor did not change anything. But, besides the current source, a red region of the circuit is connected to the capacitor - overload protection circuit. If any of the transistor switches fail, then an unregulated direct current of 38 volts will be output. Which, by itself, is not very good. Therefore, it uses a Zener diode and a pair of thyristors, which are triggered at an output voltage of more than 5.4 VDC, which leads to a short circuit in the current source, and, in turn, extremely effectively stops any activity in the power supply. The problem, apparently, was that even under normal conditions, the protective circuit absorbed 1.5 mA due to the leakage of the thyristor, moreover, in the closed state. Of course, any thyristor flows, but not as much as this.
broken thyristor maybe C32AX135
After replacing the thyristor with a modern BT145, the power supply unit was working as it should.
Processor check
We connect all the cables and turn on the power. Smoke is not visible, which is a good sign. But the “RUN” light often flickers, and, after switching the corresponding toggle switch on the console to the “INIT” value, it only blinked once at all. The situation is not encouraging.
The oscilloscope connected to the main clock signal of the processor module shows that at the beginning there are 8 clock cycles, then a pause for a couple of microseconds, 3 bars, another pause and again 3 bars, but nothing follows them.
In this photo you can see that the period of the sync signal is closer to 250 ns than to 260 ns, about which it is written in Computer Engineering. However, the use of the delay line in the feedback circuit will not be able to give such accuracy. However, 4 MHz is a very impressive result for the mid-seventies.
Most likely, the oscilloscope could not help in further clarifying the causes of the malfunction. For this kind of task, I am keeping this little USB analyzer.
But in order to cover the entire computer with its address and data buses, I need four of these. Fortunately, at that moment I was offered to buy an HP1664A logic analyzer at an affordable price.
Search for errors using a logic analyzer
After some problems at the beginning, when I mixed up some signals and forgot about the fact that the board uses active-low levels, I received several interesting trace logs:
Here the bus value is displayed, on which the addresses of micro instructions are transmitted for execution. In fact, here is the address of the next micro-instruction, during the execution of the current one. However, judging by the manual , this is a completely correct sequence of micro-operations ( if really interesting, then chapter 6.3.3 Restarts from power failure ).
It is interesting in the top of the log that, when the address is set to 0 on the bus, we get 0165020, which is the value of the command counter containing the address from which we must start execution after a power failure. This address belongs to M9312 and indicates the diagnostic program. But the next address of the instruction on the bus is 0167020. For some reason, the 10th bit turned out to be one! Exploring the DS8641 bus receiver chip in more detail, I noticed that even with an input current of 3.31V, we get 3.78V output! Looks weird.
It's alive!
Here, this little evil thing:
Unfortunately, the DS8641 is not a very common chip. In addition, it was specially adapted to open collector tires for DEC. I ordered a few on Ebay from a seller from China, but since the package was sent for quite a long time, I decided to drop the same chip from another board, and replace it with a failed chip in the processor module.
This time the result was better:
However, it all ends in a looped wait for the TX console serial port readiness bit. Strange. Maybe it's a M7800 error?
Another M7800 board
Another M7800 module was connected to the cross-board. Serial port connected to a laptop.
Fine. Now the system goes through all diagnostic steps from first to fourth. But entering “DL” in the console in order to try to boot from a non-existent RL device ( RL01 / RL02 is something like hard disks, but with removable data cartridges. ), Causes the machine to stop.
It seems that when you try to test the RAM, it fails, and then, immediately, we get a double error during the processing of the first. This behavior is typical for exception handling ( more precisely traps, trap ) by the processor.
Grumpy dip switch!
While examining the memory module and checking jumpers and switch positions, I found that when I clicked back and forth with the DIP switch, the position of the 6th key out of 8 is ignored, and the circuit remains closed. Problem.
On the left - the new switch, on the right - the old one.
Finally, the computer has started!
To understand that it works, it is possible by the fact that the author enters console commands in the terminal: @L - load the address, @E - check the data at the address, @D - write the data on the loaded address .
PDP11GUI
PDP11GUI is a great Windows utility for managing your PDP-11. It can load files into PDP-11 memory, view the memory snapshot and start the processor.
Punched tapes with BASIC can be found on the Internet. But, unfortunately, they are in Absolute Binary Loader format, which PDP11GUI does not understand. However, you can write a simple C program to convert. The resulting file can already be fed minicomputers, but this is all very slow on the 9600bps line.
Hidden text
#include <stdio.h> #include <stdlib.h> int main (int argc, char ** argv) { FILE * input, * output; int ch, state = 0, count, size, sum = 0, address, data=0, start=0; if (argc==3) { input = fopen (argv[1], "rb"); if (input == NULL) { fprintf(stderr, "cannot open file %s for reading\n", argv[1]); exit(1); } output = fopen (argv[2], "w+"); if (output == NULL) { fprintf(stderr, "cannot open file %s for reading\n", argv[2]); exit(1); } } else { fprintf(stderr, "Usage conver <input> <output>"); exit(1); } while(!feof(input)) { ch = fgetc (input); //fprintf (stderr, "state=%d ch=%02x sum=%02x count=%d start=%d\n", state, ch, sum, count, start); switch (state) { case 0: if (ch != 1) state = 0; else { state = 1; count = 1; sum += ch; sum &= 0xff; } break; case 1: if (ch != 0) state = 0; else { state = 2; count ++; sum += ch; sum &= 0xff; } break; case 2: // read low count byte size = ch; state = 3; sum += ch; sum &= 0xff; count ++; break; case 3: // read count size = size | (ch << 8); state = 4; sum += ch; sum &= 0xff; if (size==6) { start = 1; } count ++; break; case 4: // read address low address = ch; sum += ch; sum &= 0xff; state = 5; count ++; break; case 5: address = address | (ch << 8); state = 6; sum += ch; sum &= 0xff; count ++; if (count == size) { state =0; } if (start==1) { fprintf (stderr, "Start at %06o\n", address); fclose (input); fclose (output); exit(0); } break; case 6: data = ch; sum += ch; sum &= 0xff; count ++; if (count == size) { state = 7; } else { state = 8; } break; case 8: sum += ch; sum &= 0xff; data = data | (ch <<8); fprintf (output, "%06o %06o\n",address, data); address +=2; count++; if (count == size) { state = 7; } else { state = 6; } break; case 7: // checksum sum += ch; sum &= 0xff; if (sum!=0) { fprintf (stderr, "Checksum error chsum = %02X\n", sum); exit(1); } sum = 0; state = 0; } } } UPDATE: In version 1.38, the PDP11GUI no longer needs an external program, since the conversion code was included in the PDP11GUI . ( Yes, in the original 5 identical links to PDP11GUI ).
Having started the PDP with the starting address 016104, we will receive the BASIC'a invitation ( it is obvious that the launch went through that tool in which there is a corresponding “initial PC” setting ).
It is noticeable that I have not written anything for a long time on BASIC'e.
Running diagnostics
For the real test that the processor works as it should, there are two diagnostic programs - GKAA and GKAB. There are two ways to run them: load a punched tape image into the PDP11GUI or use the XXDP. I tried both methods.
It is known that these programs were stored on punched tape, but, alas, I could not find the images of these punched tapes. But I found an image for the XXDP that contained GKAAA0.BIC and GKABC0.BIC. It turns out that binaries have the same format as punched tapes. I used PUTR to extract them from the image. Do not forget that the files need to be copied as binary, and not, like me, you will be puzzling for several hours ( PUTR provides a kind of DOS-like interface, and you need to do “copy / b” instead of just “copy” ).
After extraction, I simply downloaded the images into the PDP11GUI and ran it from the address 0200.
XXDP download
The XXDP should run from some storage device. I only have one option that would be quite simple to use on my PDP-11 at that moment, the TU58 ( tape system ), since it uses the serial port to connect and therefore can be emulated on a PC. I downloaded tu58em and compiled it on my Mac. It was necessary to make only a few changes in the code to work with the serial port in order for the program to be successfully compiled.
After that, I started working on creating a boot image with the XXDP. This kind of work can be done much faster using the PDP-11 emulator. I used E11 . First I tried XXDP 2.6, found as an image on bitsavers:
Hidden text
Ersatz-11 V7.0 Demo version, COMMERCIAL USE LIMITED TO 30-DAY EVALUATION Copyright (C) 1993-2013 by Digby's Bitpile, Inc. All rights reserved. See www.dbit.com for more information. E11>assign tt1: dda: E11>mount dda0: dddp.dsk E11>set cpu 04 E11>set mem 16 E11>boot tt1: %HALT ?Bad kernel stack R0/000000 R1/176506 R2/000000 R3/000066 CM=K PM=K PRIO=0 R4/100020 R5/000000 SP/057774 PC/000006 N=0 Z=0 V=0 C=0 000006 halt E11>set mem 24 E11>boot tt1: CPU NOT SUPPORTED BY XXDP-XM BOOTING UP XXDP-SM SMALL MONITOR XXDP-SM SMALL MONITOR - XXDP V2.6 REVISION: E0 BOOTED FROM DD0 12KW OF MEMORY UNIBUS SYSTEM RESTART ADDRESS: 052010 TYPE "H" FOR HELP .R GKABC0 GKABC0.BIC %HALT R0/000357 R1/000000 R2/000300 R3/054426 CM=K PM=K PRIO=0 R4/000001 R5/000776 SP/000500 PC/012006 N=0 Z=0 V=0 C=0 012006 cmp 177776,#000000 E11> But it required more memory than it was on my machine, so using this version would not work. In addition, GKAB did not want to run on an emulated PDP-11/04 for an unknown reason.
After that, I spent the time trying to make a TU58 image for XXDP +, an earlier version of the XXDP package. This is how I did it in E11:
Hidden text
.R UPD2 CHUP2A2 XXDP+ UPD2 UTILITY RESTART: 002432 *ZERO DD0: *DRIVER DD0: *LOAD DY0:HMDDA1.SYS XFR:005034 CORE:000000,017774 *SAVM DD0: *PIP DD0:HMDDA1.SYS=DY0:HMDDA1.SYS *PIP DD0:HDDDA1.SYS=DY0:HDDDA1.SYS *PIP DD0:GKA???.BIC=DY0:GKA???.BIC GKAAA0.BIC GKABC0.BIC *PIP DD0:HELP.TXT=DY0:HELP.TXT *PIP DD0:HUDIA0.SYS=DY0:HUDIA0.SYS *PIP DD0:HSAAA0.SYS=DY0:HSAAA0.SYS *PIP DD0:UPD?.BIN=DY0:UPD?.BIN UPD1 .BIN UPD2 .BIN *PIP DD0:SETUP.BIN=DY0:SETUP.BIN E11>set cpu 04 E11>set mem 16 E11>boot tt1: CLEARING MEMORY CHMDDA0 XXDP+ DD MONITOR 8K BOOTED VIA UNIT 0 ENTER DATE (DD-MMM-YY): RESTART ADDR:033726 50 HZ? NY LSI? N THIS IS XXDP+. TYPE "H" OR "H/L" FOR DETAILS .DIR ENTRY# FILNAM.EXT DATE LENGTH START 000001 HMDDA1.SYS 22-MAR-80 17 000050 000002 HDDDA1.SYS 22-MAR-80 3 000071 000003 GKAAA0.BIC 11-AUG-76 15 000074 000004 GKABC0.BIC 29-JAN-77 16 000113 000005 HELP .TXT 22-MAR-80 26 000133 000006 HUDIA0.SYS 22-MAR-80 6 000165 000007 HSAAA0.SYS 22-MAR-80 24 000173 000010 UPD1 .BIN 22-MAR-80 12 000223 000011 UPD2 .BIN 22-MAR-80 16 000237 000012 SETUP .BIN 22-MAR-80 26 000257 .R GKABC0 %HALT R0/000357 R1/000000 R2/000300 R3/032240 CM=K PM=K PRIO=0 R4/000001 R5/000776 SP/000500 PC/012006 N=0 Z=0 V=0 C=0 012006 cmp 177776,#000000 GKAAA0.BIC under XXDP + on this machine started successfully. Most of the system is in excellent condition! Here is a link to the image that I made.
But the launch of GKABC0 ended up stopping the system. It is impossible to find the source code for a specific version of the utility, but the version under the PDP-11/34 should work. Looking through the code , you can see that the section where the system stops is a test of the stack overflow processing logic. The stack pointer is set to 0400, and then the console TX interrupt twitches ( apparently IOT refers to the IOT instruction, which causes the 020 interrupt, to which the OS usually hangs the I / O handler ). In this case, the stack pointer becomes less than 0400, which leads to the generation of an exception, the processing vector number of which is 4 or 6. On my machine, the behavior was different - more and more new console interrupts were generated until the stack reached 0177774 (physical memory no address), and then stopped with a double bus error.
Glitch DL11-W!
Changing the boards, I noticed that using another DL11-W eliminates the problem. It seems that in DL11-W, the interrupt handling logic is broken. The interrupt must be cleared as soon as the processor responds with SSYN ( a Unibus bus signal, a kind of handshake ). This did not happen on a broken map. Only the processor began to process the interrupt, as received it again and again. The process of working with interrupts on the Unibus bus is not very complicated. The device sets the signal BRn, and the processor responds with a BGn setting when it is ready for interrupt service. After that, the device, in turn, responds with SACK, sets the interrupt vector number, and pulls the INTR. The trace below is taken from a working card:
Do not forget that in PDP-11 the active signal level is low
The diagram shows the interrupt trigger and the valve that should clear the interrupt signal when it is already serviced.
This fuzzy photo clearly shows the failing 7408 AND-valve on the broken board.
7408 here is designated as E4, 12 and 13 are input signals, 11 is output, which should, in theory, clear an interrupt when it is in a low state. This does not happen, and interrupts all go and go.
At this, the repair of the main board unit is over, in the second part of the article we are repairing the TU60 tape station, and in the third - the LA30 Decwriter terminal.
Source: https://habr.com/ru/post/243551/
All Articles