Re: PDP-11/70 debugging advice
On Fri, Feb 5, 2021 at 12:29 AM Fritz Mueller via cctalk < cctalk@classiccmp.org> wrote: > > > > On Feb 4, 2021, at 9:45 PM, Josh Dersch wrote: > > The 11/70 is now somewhat operable. I can examine and deposit memory, > at least for a short while -- after the system warms up for 30 seconds or > so the Load Address switch stops functioning. > > Nice!! > > One handy test on '45 is to put the data display knob to bus address; if > the microcode is still running in the control panel idle loop (halt switch > down or fault) the data lights will follow along with the toggles. This is > a super quick way to tell if the microcode is still running or if it is > wedged. > > (The '45 and '70 microcode seem quite similar, so your '70 might have the > same feature? I haven't looked at the flow diagrams yet to know for sure.) > Thanks for the tip, I'll check that out. Before I went to bed I did a bit more poking. Upon closer examination, the Load Address switch is still being recognized: the Data lights get reset to 0 after it's toggled. So the microcode is taking a jump to ADR.00 when the switch is toggled. It looks like what isn't happening is the PCA <- BR in T5. So I have a couple of places to look -- it's possible that the T5 clock signal is going wrong after warming up (note that ADR.00 is the only step in the console flow that does anything in T5, except maybe RDP.00 -- I'm not sure if that's a "5" or a 3"). (See flow 14, p. 18 of http://bitsavers.org/pdf/dec/pdp11/1170/MP0KB11-C0_1170engDrw_Nov75.pdf) Or something's going wrong with the PCA <- BR operation. I put the KM11 back in, and while single-stepping or running under the RC clock (which is currently set to a really low clock rate, like 7Mhz, for some reason) Load Address works fine. Seems like some component has slowed down a bit and stops operating correctly at full speed. Something to poke at this weekend... - Josh >--FritzM. > >
Re: PDP-11/70 debugging advice
> On Feb 4, 2021, at 9:45 PM, Josh Dersch wrote: > The 11/70 is now somewhat operable. I can examine and deposit memory, at > least for a short while -- after the system warms up for 30 seconds or so the > Load Address switch stops functioning. Nice!! One handy test on '45 is to put the data display knob to bus address; if the microcode is still running in the control panel idle loop (halt switch down or fault) the data lights will follow along with the toggles. This is a super quick way to tell if the microcode is still running or if it is wedged. (The '45 and '70 microcode seem quite similar, so your '70 might have the same feature? I haven't looked at the flow diagrams yet to know for sure.) --FritzM.
Re: PDP-11/70 debugging advice
On Thu, Feb 4, 2021 at 2:42 PM Fritz Mueller via cctalk < cctalk@classiccmp.org> wrote: > > > On Feb 4, 2021, at 1:51 PM, Josh Dersch wrote: > > [RC maintenance clock] Yeah, you'd think... but it doesn't work :). I > mentioned earlier in this thread that it's stuck in single-step mode. From > the schematics it looks like the crystal clock needs to be running to clock > some of the flip flops used in the "Source Synchronizer" to select the > proper clock source. My guess is that since the clock isn't running, the > flip flops are left in a weird state. > > Oh, interesting! Noted for future reference. The TIG is not exactly > straightforward... So I realized today that, hey, I have a burned-out 11/45 in the garage, and it has a TIG (albeit an M8109), and it also has a 33.33Mhz crystal on it. And because I'm impatient and can't wait for my Digi-Key order to come in, I went out and borrowed the crystal from the 11/45's TIG and installed it in the 11/70's. The 11/70 is now somewhat operable. I can examine and deposit memory, at least for a short while -- after the system warms up for 30 seconds or so the Load Address switch stops functioning. (Happens gradually, too... for 10 seconds or so it works every other time you toggle it, then it stops entirely.) Everything else seems to work properly after this happens, so I'm kind of curious if there's an IC on the front panel that's gone bad, though I suppose it's still completely possible it's something on the CPU end. I'll have to do some debugging, but it'll have to wait until this weekend. As an aside... The M8109 is very similar looking to the M8139... any ideas what the functional differences are? There seems to be an extra IC and some ECO wiring on the M8139. I'll have to take a closer look someday. - Josh
Re: PDP-11/70 debugging advice
> On Feb 4, 2021, at 1:51 PM, Josh Dersch wrote: > [RC maintenance clock] Yeah, you'd think... but it doesn't work :). I > mentioned earlier in this thread that it's stuck in single-step mode. From > the schematics it looks like the crystal clock needs to be running to clock > some of the flip flops used in the "Source Synchronizer" to select the proper > clock source. My guess is that since the clock isn't running, the flip flops > are left in a weird state. Oh, interesting! Noted for future reference. The TIG is not exactly straightforward...
Re: PDP-11/70 debugging advice
On Thu, Feb 4, 2021 at 10:19 AM Fritz Mueller via cctalk < cctalk@classiccmp.org> wrote: > > > > On Feb 3, 2021, at 8:07 PM, Josh Dersch wrote: > > Sure enough, TIGB XTAL H was a flat line. Nothing happening at the > crystal itself either. The crystal's casing was fairly corroded (which is > interesting, since nothing else on the board is) and after a tiny bit of > prodding one of the legs fell off, so I'm hoping that's the culprit. > > Ah. One of the switches on the KM11 should enable the machine to run off > the separate RC maintenance clock on the TIG, if you want to keep going > before your new crystal shows up. Yeah, you'd think... but it doesn't work :). I mentioned earlier in this thread that it's stuck in single-step mode. From the schematics it looks like the crystal clock needs to be running to clock some of the flip flops used in the "Source Synchronizer" to select the proper clock source. My guess is that since the clock isn't running, the flip flops are left in a weird state. Or there's another problem here unrelated to the crystal clock. I guess I'll see in a day or so. - Josh
Re: PDP-11/70 debugging advice
> On Feb 3, 2021, at 8:07 PM, Josh Dersch wrote: > Sure enough, TIGB XTAL H was a flat line. Nothing happening at the crystal > itself either. The crystal's casing was fairly corroded (which is > interesting, since nothing else on the board is) and after a tiny bit of > prodding one of the legs fell off, so I'm hoping that's the culprit. Ah. One of the switches on the KM11 should enable the machine to run off the separate RC maintenance clock on the TIG, if you want to keep going before your new crystal shows up.
Re: PDP-11/70 debugging advice
On Tue, Feb 2, 2021 at 12:30 AM Josh Dersch wrote: > > > On Sun, Jan 31, 2021 at 10:03 PM Fritz Mueller wrote: > >> >> >> > On Jan 31, 2021, at 8:19 PM, Josh Dersch wrote: >> > Well, what's interesting here is that on my system, switch S4 (MAINT >> STPR) steps the processor with switches S1 and S2 set to *any* >> configuration. >> >> Hmm, would expect to see S2:1 S1:0 step by microinstruction, and S2:1 >> S1:1 step by clock phase. The other two settings should free run the >> microcode. So yeah, sounds like something fishy there... The TIG card has >> more than a few analog components, and its not too unusual for these to get >> hung up on the adjacent card and have a leg pulled or sheared from the >> board. >> >> > Ah, and page II-6-20 (p. 178) indicates that when DCLO is asserted, it >> asserts: "UBCE ROM INIT H - forces the ROM to ZAP.00 (200), and stops and >> clears the Timing Generator and the Cache timing." >> >> Yup, that's one of the signals coming in to RAC E106. Probing there >> should indicate which of possible sources for ZAP is actually occurring >> (UBCE ROM INIT H on pins 2 and 3 there). >> >> DCLO is a classic... Make sure to 'scope it, because it sometimes has >> troublesome spikes that don't show on a multimeter. If you have H742s, >> there are some wet tantalums on the control board that sometimes leak and >> cause trouble with this. >> >> I'm sure you are raring to go -- hope those fans show up for you >> tomorrow, and will be interested to hear what you find! >> > > > Small update; fans arrived today and they are now installed. Voltages > tested on the backplane at the points called out in the service docs, and > all voltages dialed in to 5.05V. Ripple is within tolerances -- about > 200mV with some very short spikes that barely show up on my 'scope that go > to 300mV or so. Not sure if this is abnormal, I also saw these while > burning the supplies in on the bench. > > Checked the AC LO and DC LO signals at all the points called out in figure > 6-12 (p. II-6-22 of > http://bitsavers.org/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf) > and appear to be correct. Looked at most of them under the scope and no > spikes (other than those in the ripple from the power supply.) > > Tomorrow I'll get some boards out on extenders and take a look at what's > going on at the logic level. > Another quick update: Had some time last night to poke at things. I started with the TIG, since I wanted to see if the crystal clock was running at all and if the right clock source was being selected. Sure enough, TIGB XTAL H was a flat line. Nothing happening at the crystal itself either. The crystal's casing was fairly corroded (which is interesting, since nothing else on the board is) and after a tiny bit of prodding one of the legs fell off, so I'm hoping that's the culprit. New crystal ordered and when it arrives we'll see... - Josh
Re: PDP-11/70 debugging advice
On Sun, Jan 31, 2021 at 10:03 PM Fritz Mueller wrote: > > > > On Jan 31, 2021, at 8:19 PM, Josh Dersch wrote: > > Well, what's interesting here is that on my system, switch S4 (MAINT > STPR) steps the processor with switches S1 and S2 set to *any* > configuration. > > Hmm, would expect to see S2:1 S1:0 step by microinstruction, and S2:1 S1:1 > step by clock phase. The other two settings should free run the > microcode. So yeah, sounds like something fishy there... The TIG card has > more than a few analog components, and its not too unusual for these to get > hung up on the adjacent card and have a leg pulled or sheared from the > board. > > > Ah, and page II-6-20 (p. 178) indicates that when DCLO is asserted, it > asserts: "UBCE ROM INIT H - forces the ROM to ZAP.00 (200), and stops and > clears the Timing Generator and the Cache timing." > > Yup, that's one of the signals coming in to RAC E106. Probing there > should indicate which of possible sources for ZAP is actually occurring > (UBCE ROM INIT H on pins 2 and 3 there). > > DCLO is a classic... Make sure to 'scope it, because it sometimes has > troublesome spikes that don't show on a multimeter. If you have H742s, > there are some wet tantalums on the control board that sometimes leak and > cause trouble with this. > > I'm sure you are raring to go -- hope those fans show up for you tomorrow, > and will be interested to hear what you find! > Small update; fans arrived today and they are now installed. Voltages tested on the backplane at the points called out in the service docs, and all voltages dialed in to 5.05V. Ripple is within tolerances -- about 200mV with some very short spikes that barely show up on my 'scope that go to 300mV or so. Not sure if this is abnormal, I also saw these while burning the supplies in on the bench. Checked the AC LO and DC LO signals at all the points called out in figure 6-12 (p. II-6-22 of http://bitsavers.org/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf) and appear to be correct. Looked at most of them under the scope and no spikes (other than those in the ripple from the power supply.) Tomorrow I'll get some boards out on extenders and take a look at what's going on at the logic level. - Josh > > --FritzM. > >
Re: PDP-11/70 debugging advice
> On Jan 31, 2021, at 8:19 PM, Josh Dersch wrote: > Well, what's interesting here is that on my system, switch S4 (MAINT STPR) > steps the processor with switches S1 and S2 set to *any* configuration. Hmm, would expect to see S2:1 S1:0 step by microinstruction, and S2:1 S1:1 step by clock phase. The other two settings should free run the microcode. So yeah, sounds like something fishy there... The TIG card has more than a few analog components, and its not too unusual for these to get hung up on the adjacent card and have a leg pulled or sheared from the board. > Ah, and page II-6-20 (p. 178) indicates that when DCLO is asserted, it > asserts: "UBCE ROM INIT H - forces the ROM to ZAP.00 (200), and stops and > clears the Timing Generator and the Cache timing." Yup, that's one of the signals coming in to RAC E106. Probing there should indicate which of possible sources for ZAP is actually occurring (UBCE ROM INIT H on pins 2 and 3 there). DCLO is a classic... Make sure to 'scope it, because it sometimes has troublesome spikes that don't show on a multimeter. If you have H742s, there are some wet tantalums on the control board that sometimes leak and cause trouble with this. I'm sure you are raring to go -- hope those fans show up for you tomorrow, and will be interested to hear what you find! --FritzM.
Re: PDP-11/70 debugging advice
On Sun, Jan 31, 2021 at 7:55 PM Josh Dersch wrote: > On Sun, Jan 31, 2021 at 7:04 PM Fritz Mueller via cctalk < > cctalk@classiccmp.org> wrote: > >> > Yeah. I want to get the fans installed and then go triple-check all >> the power signals and get the voltages dialed in nicely. But then things >> come out on extenders :). >> >> Yup -- I'm surprised how picky my '45 is about +5 undervolt; it really >> seems happiest with trimmed up to about 5.1 at the backplane. >> >> Looks like E106 on the RAC (M8123) might be a good place to start >> (drawing RACA, lower left.) >> > > I was just looking in chapter 4 of the processor manual to learn more > about how the processor clocks are generated on the M8139 (TIG) board; on > page II-4-2 (p. 136 in the PDF on Bitsavers) section 4.1.3 it says: > > "The third source of timing [the other two being the crystal clock and a > diagnostic R/C network] is the manually-operated, single-step MAINT STPR > switch S4, located on the maintenance card. This switch is only enabled > when maintenance card switches S2 and S3 are both set to 1." > > Section 4.2.3 confirms this: > > "The maintenance card S2 and S1 switches are both set to 1 to allow single > timing pulses to be generated by MAINT STPR switch S4 Removing the S2 > or S1 input conditions the MS EN flip-flop to be cleared." > > Well, what's interesting here is that on my system, switch S4 (MAINT STPR) > steps the processor with switches S1 and S2 set to *any* configuration. > Tried it with the other KM11 I have, same behavior. This being the case, I > wonder if the logic that selects the clock source is faulty, and is always > selecting the MAINT STPR input. This would definitely explain the behavior > I'm seeing. I hope the fans arrive tomorrow so I can start debugging this > :). > Ah, and page II-6-20 (p. 178) indicates that when DCLO is asserted, it asserts: "UBCE ROM INIT H - forces the ROM to ZAP.00 (200), and stops and clears the Timing Generator and the Cache timing." I suppose that this is the more likely explanation for the behavior here and that the maintenance card behavior is a side-effect of this. Time to actually probe things, rather than speculating... - Josh > > - Josh > > >> >> cheers, >> --FritzM. >> >> >> >>
Re: PDP-11/70 debugging advice
On Sun, Jan 31, 2021 at 7:04 PM Fritz Mueller via cctalk < cctalk@classiccmp.org> wrote: > > Yeah. I want to get the fans installed and then go triple-check all the > power signals and get the voltages dialed in nicely. But then things come > out on extenders :). > > Yup -- I'm surprised how picky my '45 is about +5 undervolt; it really > seems happiest with trimmed up to about 5.1 at the backplane. > > Looks like E106 on the RAC (M8123) might be a good place to start (drawing > RACA, lower left.) > I was just looking in chapter 4 of the processor manual to learn more about how the processor clocks are generated on the M8139 (TIG) board; on page II-4-2 (p. 136 in the PDF on Bitsavers) section 4.1.3 it says: "The third source of timing [the other two being the crystal clock and a diagnostic R/C network] is the manually-operated, single-step MAINT STPR switch S4, located on the maintenance card. This switch is only enabled when maintenance card switches S2 and S3 are both set to 1." Section 4.2.3 confirms this: "The maintenance card S2 and S1 switches are both set to 1 to allow single timing pulses to be generated by MAINT STPR switch S4 Removing the S2 or S1 input conditions the MS EN flip-flop to be cleared." Well, what's interesting here is that on my system, switch S4 (MAINT STPR) steps the processor with switches S1 and S2 set to *any* configuration. Tried it with the other KM11 I have, same behavior. This being the case, I wonder if the logic that selects the clock source is faulty, and is always selecting the MAINT STPR input. This would definitely explain the behavior I'm seeing. I hope the fans arrive tomorrow so I can start debugging this :). - Josh > > cheers, > --FritzM. > > > >
Re: PDP-11/70 debugging advice
> Yeah. I want to get the fans installed and then go triple-check all the > power signals and get the voltages dialed in nicely. But then things come > out on extenders :). Yup -- I'm surprised how picky my '45 is about +5 undervolt; it really seems happiest with trimmed up to about 5.1 at the backplane. Looks like E106 on the RAC (M8123) might be a good place to start (drawing RACA, lower left.) cheers, --FritzM.
Re: PDP-11/70 debugging advice
On Sun, Jan 31, 2021 at 5:05 PM Fritz Mueller via cctalk < cctalk@classiccmp.org> wrote: > Hi Josh, > > ZAP is effectively reset for the micro-architecture, forcing the ucode > address to known/initial value. It has multiple sources throughout the > processor, including tendrils into some of trap handling hardware. (Caveat: > my experience is based off extensive work with the '11/45, but the > micro-architecture as I understand it for the '11/70 is quite similar.) > Yeah, ZAP seems to be the entry point at power-up as well as for trap handling. > For the '45, there was a very handy "KB11-A,D Maintenance Manual", which > explained the logic of such internal signals and the board by board > internal operation of the CPU to a very useful level of detail; I'm sure > similar is available for the KB11-B,C? It's worth a read through if you > haven't already, though its quite a bit to take in. > Yes, there's a similar doc. The engineering drawings include the flow diagrams for the microcode, and the Processor Manual ( http://bitsavers.org/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf) goes into details on the rest. I started digesting all of this last night, it's going to take awhile :). > > I would imagine the next step would be to throw the RAC board out on > extenders, verify that ZAP is asserted, and if so pursue the driving source. > Yeah. I want to get the fans installed and then go triple-check all the power signals and get the voltages dialed in nicely. But then things come out on extenders :). > > Do you know if you have a KB11-B or C? > It's a KB11-C. > Happy hunting! > Thanks, it'll be interesting for sure. - Josh >--FritzM. > > >
Re: PDP-11/70 debugging advice
Hi Josh, ZAP is effectively reset for the micro-architecture, forcing the ucode address to known/initial value. It has multiple sources throughout the processor, including tendrils into some of trap handling hardware. (Caveat: my experience is based off extensive work with the '11/45, but the micro-architecture as I understand it for the '11/70 is quite similar.) For the '45, there was a very handy "KB11-A,D Maintenance Manual", which explained the logic of such internal signals and the board by board internal operation of the CPU to a very useful level of detail; I'm sure similar is available for the KB11-B,C? It's worth a read through if you haven't already, though its quite a bit to take in. I would imagine the next step would be to throw the RAC board out on extenders, verify that ZAP is asserted, and if so pursue the driving source. Do you know if you have a KB11-B or C? Happy hunting! --FritzM.
Re: PDP-11/70 debugging advice
On Sun, Jan 31, 2021 at 2:39 PM Guy Sotomayor via cctalk < cctalk@classiccmp.org> wrote: > Did you check to make sure that power is wired correctly to the > PEP-70/Hypercache? They are typically installed in "empty" slots and > don't have power (or anything else) routed to them. They require some > additional jumpers to be installed on the backplane so that they get power. > Yes, it's wired up (Don't know who did the installation, but I'm assuming it was operational at some point). There are four large black jumper wires leading from slot 18 to slot 19, matching the instructions in the PEP70 installation manual. Thanks, Josh
Re: PDP-11/70 debugging advice
Did you check to make sure that power is wired correctly to the PEP-70/Hypercache? They are typically installed in "empty" slots and don't have power (or anything else) routed to them. They require some additional jumpers to be installed on the backplane so that they get power. On 1/31/21 2:31 PM, Josh Dersch via cctalk wrote: Hi all -- Making some progress with the "fire sale" PDP-11/70. Over the past month I've rebuilt the power supplies and burned them in on the bench, and I've gotten things cleaned up and reassembled. I'm still waiting on some new chassis fans but my curiosity overwhelmed my caution and I decided to power it up for a short time (like 30 seconds) just to see what happens. Good news: no smoke or fire. Voltages look good (need a tiny bit of adjustment yet) and AC LO and DC LO looked good everywhere I tested them. Bad news: processor is almost entirely unresponsive; comes up with the RUN and MASTER lights on, toggling Halt, and hitting Start causes the RUN light to go out, but that's the only response I get from the console. I got out the KM11 boardset and with that installed I can step through microinstructions and it's definitely executing them, and seems to be following the flow diagrams in the engineering drawings. Left to its own devices, however, the processor doesn't seem to be executing microinstructions at all, it's stuck at uAddress 200. In the troubleshooting section of the 11/70 service docs (diagram on p. 5-16) it states: IF LOAD ADRS DOES NOT WORK AND: - RUN, MASTER & ALL DATA INDICATORS ARE ON - uADRS = 200 (ZAP) THEN MEMORY HAS LOST POWER Which seems to adequately describe the symptoms I'm seeing, but as far as I can tell the AC and DC LO signals are all fine. (This system has a Setasi PEP70/Hypercache installed, so there's no separate memory chassis to worry about.) I'm going to go back and re-check everything, but I was curious if anyone knows whether loss of AC or DC would prevent the processor from executing microcode -- from everything I understand it should cause a trap, and I don't see anything in the docs about inhibiting microcode execution. But perhaps if this happens at power-up things behave differently? And the fact that the troubleshooting flowchart calls out these exact symptoms would seem to indicate that this is expected. But I'm curious why the KM11 can step the processor, in this case. I'm going to wait until the new fans arrive (hopefully tomorrow or tuesday) before I poke at this again, just looking for advice here on the off chance anyone's seen this behavior before. Thanks as always! - Josh -- TTFN - Guy
PDP-11/70 debugging advice
Hi all -- Making some progress with the "fire sale" PDP-11/70. Over the past month I've rebuilt the power supplies and burned them in on the bench, and I've gotten things cleaned up and reassembled. I'm still waiting on some new chassis fans but my curiosity overwhelmed my caution and I decided to power it up for a short time (like 30 seconds) just to see what happens. Good news: no smoke or fire. Voltages look good (need a tiny bit of adjustment yet) and AC LO and DC LO looked good everywhere I tested them. Bad news: processor is almost entirely unresponsive; comes up with the RUN and MASTER lights on, toggling Halt, and hitting Start causes the RUN light to go out, but that's the only response I get from the console. I got out the KM11 boardset and with that installed I can step through microinstructions and it's definitely executing them, and seems to be following the flow diagrams in the engineering drawings. Left to its own devices, however, the processor doesn't seem to be executing microinstructions at all, it's stuck at uAddress 200. In the troubleshooting section of the 11/70 service docs (diagram on p. 5-16) it states: IF LOAD ADRS DOES NOT WORK AND: - RUN, MASTER & ALL DATA INDICATORS ARE ON - uADRS = 200 (ZAP) THEN MEMORY HAS LOST POWER Which seems to adequately describe the symptoms I'm seeing, but as far as I can tell the AC and DC LO signals are all fine. (This system has a Setasi PEP70/Hypercache installed, so there's no separate memory chassis to worry about.) I'm going to go back and re-check everything, but I was curious if anyone knows whether loss of AC or DC would prevent the processor from executing microcode -- from everything I understand it should cause a trap, and I don't see anything in the docs about inhibiting microcode execution. But perhaps if this happens at power-up things behave differently? And the fact that the troubleshooting flowchart calls out these exact symptoms would seem to indicate that this is expected. But I'm curious why the KM11 can step the processor, in this case. I'm going to wait until the new fans arrive (hopefully tomorrow or tuesday) before I poke at this again, just looking for advice here on the off chance anyone's seen this behavior before. Thanks as always! - Josh
