Re: PDP-11/70 progress (and a cry for help)
On 02/21/2021 03:33 AM, Josh Dersch via cctalk wrote: "0" here selects DR (Destination Register) input to the mux and is incorrect; it should be 1 (PCB). During a single-instruction-step run, this value reads out OK on the analyzer. I noted a few other discrepancies in the capture (all of which match the ucode listing during a single-instruction step) which makes me think that the high outputs of the PROM are right on the bleeding-edge of acceptable TTL. I checked out the signal on the scope while running a BR .-1 instruction (which also doesn't execute correctly but at least doesn't halt... I don't have a storage scope to capture this during a single instruction execution) and it looks like the voltage swing is from about 0.15V to 1.7V or so. 1.6 to 1.7 V is the normal internal pull-up of a TTL gate input. It sounds like that is what you are seeing. The PROM can pull low when needed, but has no pull-up working anymore. On the off chance it was the 74S174 at E97 pulling the signals down, I socketed it and substituted a spare '174 in; no change. I also noted that the +5V at this chip was about 4.95V, I goosed it up to 5.10V to see if it made a difference (it did not.) So it seems likely it's the PROM. Looks like I may have some typing to do, though given that the ROM works well enough at slow speeds I might be able to dump it with my Data I/O Model 29 and compare it against the listings in the engineering drawings, to save some time... I'll try to dump the PROM tomorrow and see what I get. - Josh A status update here: I've dumped the bad PROM at U101 (and it read out fine on my Data I/O 29, comparing it with the listing in the engineering drawings). A local friend had a spare 11/70 boardset, so while I wait for some (hopefully) NOS bipolar PROMs to arrive, I've installed a spare RAC board. With this installed, instructions execute much better, and after tracing down a faulty Unibus terminator, I got it to run the bootstrap PROM on the M9301! I used my Unibone to boot XXDP+ from an emulated RL02 pack and over the past week I've been running diagnostics and debugging the hardware. Thus far: - Unibus Map registers non-functional: addresses decode but writes have no effect and all reads come back as "0". Replaced bad 8640 bus receiver on the Unibus Map board. - EMKA memory diagnostic hangs the processor in t5 of uAddr 343 (IRD.00), in PAUSE. Traced it down to the HC42 (replaces the original Cache Control Board) board of the Hypercache boardset, lacking any engineering info I swapped this for a spare that I'm fortunate enough to have. The system is now passing all but two diagnostics: - EMKA reports strange errors in banks 50-57 of memory and only with pattern 17; all other banks test fine: MEMORY DATA ERROR PCBANK VADD PADD GOOD BAD XOR MAR BOX MTYPE INT PAT ARRAY 032334 50 157564 05077564 000377 000377 00 0 ? MJ11 ? 17 ?? 032334 50 156450 05076450 000377 000377 00 0 ? MJ11 ? 17 ?? 032334 50 155330 05075330 000377 000377 00 0 ? MJ11 ? 17 ?? When a memory test reports an error, but the good and bad values are equal, I might suspect bad memory where the program is running from or a CPU error. 032334 50 154210 05074210 000377 000377 00 0 ? MJ11 ? 17 ?? 032342 50 154020 05074020 000377 17 177400 0 ? MJ11 ? 17 ?? 032342 50 153740 05073740 000377 17 177400 0 ? MJ11 ? 17 ?? 032342 50 153734 05073734 000377 17 177400 0 ? MJ11 ? 17 ?? 032342 50 153732 05073732 000377 177400 17 0 ? MJ11 ? 17 ?? 032342 50 153730 05073730 000377 177400 17 0 ? MJ11 ? 17 ?? 032342 50 153726 05073726 000377 177400 17 0 ? MJ11 ? 17 ?? 032342 50 153724 05073724 000377 177400 17 0 ? MJ11 ? 17 ?? 032342 50 153722 05073722 000377 177400 17 0 ? MJ11 ? 17 ?? 032342 50 153720 05073720 000377 177400 17 0 ? MJ11 ? 17 ?? 032342 50 153716 05073716 000377 177400 17 0 ? MJ11 ? 17 ?? And, these look like a byte enable bit might not be getting through and data from the previous test pattern remains in one byte. Jon
Re: PDP-11/70 progress (and a cry for help)
On Wed, Feb 17, 2021 at 12:45 AM Josh Dersch wrote: > > > I hooked the LA up to the two PROM bits that select the AMX input (RACC > UAMX00 H and RACC UAMX01 H), on the ROM & Address Control board. These > come from the PROM at U101 and go through a 74S174 at E97 before heading > over to the DAP board. And during FET.00 we have: > > Addr PCB PCA AMX > 260 44 44 0 > > "0" here selects DR (Destination Register) input to the mux and is > incorrect; it should be 1 (PCB). During a single-instruction-step run, > this value reads out OK on the analyzer. I noted a few other discrepancies > in the capture (all of which match the ucode listing during a > single-instruction step) which makes me think that the high outputs of the > PROM are right on the bleeding-edge of acceptable TTL. I checked out the > signal on the scope while running a BR .-1 instruction (which also doesn't > execute correctly but at least doesn't halt... I don't have a storage scope > to capture this during a single instruction execution) and it looks like > the voltage swing is from about 0.15V to 1.7V or so. > > On the off chance it was the 74S174 at E97 pulling the signals down, I > socketed it and substituted a spare '174 in; no change. I also noted that > the +5V at this chip was about 4.95V, I goosed it up to 5.10V to see if it > made a difference (it did not.) > > So it seems likely it's the PROM. Looks like I may have some typing to > do, though given that the ROM works well enough at slow speeds I might be > able to dump it with my Data I/O Model 29 and compare it against the > listings in the engineering drawings, to save some time... > > I'll try to dump the PROM tomorrow and see what I get. > > - Josh > A status update here: I've dumped the bad PROM at U101 (and it read out fine on my Data I/O 29, comparing it with the listing in the engineering drawings). A local friend had a spare 11/70 boardset, so while I wait for some (hopefully) NOS bipolar PROMs to arrive, I've installed a spare RAC board. With this installed, instructions execute much better, and after tracing down a faulty Unibus terminator, I got it to run the bootstrap PROM on the M9301! I used my Unibone to boot XXDP+ from an emulated RL02 pack and over the past week I've been running diagnostics and debugging the hardware. Thus far: - Unibus Map registers non-functional: addresses decode but writes have no effect and all reads come back as "0". Replaced bad 8640 bus receiver on the Unibus Map board. - EMKA memory diagnostic hangs the processor in t5 of uAddr 343 (IRD.00), in PAUSE. Traced it down to the HC42 (replaces the original Cache Control Board) board of the Hypercache boardset, lacking any engineering info I swapped this for a spare that I'm fortunate enough to have. The system is now passing all but two diagnostics: - EMKA reports strange errors in banks 50-57 of memory and only with pattern 17; all other banks test fine: MEMORY DATA ERROR PCBANK VADD PADD GOOD BAD XOR MAR BOX MTYPE INT PAT ARRAY 032334 50 157564 05077564 000377 000377 00 0 ? MJ11 ? 17 ?? 032334 50 156450 05076450 000377 000377 00 0 ? MJ11 ? 17 ?? 032334 50 155330 05075330 000377 000377 00 0 ? MJ11 ? 17 ?? 032334 50 154210 05074210 000377 000377 00 0 ? MJ11 ? 17 ?? 032342 50 154020 05074020 000377 17 177400 0 ? MJ11 ? 17 ?? 032342 50 153740 05073740 000377 17 177400 0 ? MJ11 ? 17 ?? 032342 50 153734 05073734 000377 17 177400 0 ? MJ11 ? 17 ?? 032342 50 153732 05073732 000377 177400 17 0 ? MJ11 ? 17 ?? 032342 50 153730 05073730 000377 177400 17 0 ? MJ11 ? 17 ?? 032342 50 153726 05073726 000377 177400 17 0 ? MJ11 ? 17 ?? 032342 50 153724 05073724 000377 177400 17 0 ? MJ11 ? 17 ?? 032342 50 153722 05073722 000377 177400 17 0 ? MJ11 ? 17 ?? 032342 50 153720 05073720 000377 177400 17 0 ? MJ11 ? 17 ?? 032342 50 153716 05073716 000377 177400 17 0 ? MJ11 ? 17 ?? Occasionally testing banks 50-57 will die with a trap to 4 instead. Pattern 17 tests using alternating patterns of "0" and "1" bytes, using byte accesses to memory, I'm curious why only this pattern would fail. Accesses to this area of memory from the console work fine - EKBD fails with: ADDRESS MULTIPLEXER, AMX, CPU INPUTS TEST FAILED. ERROR ADDRESS REGISTER NOT SET CORRECTLY. TEST. CALL AT PC. EXPECTED ADRS. GOT ADRS. ERROR REG. 5 752406000576144406 (Note the similar address range to the EMKA failures). I've verified that AMX, etc. are not to blame here. I suspect this issue is related to the memory issue above. I've looked at the MMU hardware to see if address generation is breaking for some reason at these addresses and it seems to be OK. I'm going to keep
Re: PDP-11/70 progress (and a cry for help)
On 02/17/2021 02:45 AM, Josh Dersch via cctalk wrote: "0" here selects DR (Destination Register) input to the mux and is incorrect; it should be 1 (PCB). During a single-instruction-step run, this value reads out OK on the analyzer. I noted a few other discrepancies in the capture (all of which match the ucode listing during a single-instruction step) which makes me think that the high outputs of the PROM are right on the bleeding-edge of acceptable TTL. I checked out the signal on the scope while running a BR .-1 instruction (which also doesn't execute correctly but at least doesn't halt... I don't have a storage scope to capture this during a single instruction execution) and it looks like the voltage swing is from about 0.15V to 1.7V or so. Well, that sounds like the pull-up transistor on the PROM has gone open or extremely weak. You might try a resistor to +5V and see if that makes it work. It would explain the error only happening at full speed. Jon
Re: PDP-11/70 progress (and a cry for help)
On Tue, Feb 16, 2021 at 5:08 PM Fritz Mueller via cctalk < cctalk@classiccmp.org> wrote: > > On Tue, Feb 16, 2021 at 2:36 AM Fritz Mueller via cctalk < > cctalk@classiccmp.org> wrote: > > So you could set up on t4 or t5 of that microinstruction with the KM11... > > > On Feb 16, 2021, at 11:08 AM, Josh Dersch wrote: > > I can't, though -- all of this stuff works fine when running slowly :) > > Oh right -- I keep forgetting that part! So that really does leave you > with just the LA to catch things in the act I guess. > > > Right now I'm thinking it is most likely the AMX selecting the wrong > input (I'm guessing that BMX is correctly selecting KOMX, to get the > constant "2" for the add operation). > > I agree; seems a good place to look next. > I hooked the LA up to the two PROM bits that select the AMX input (RACC UAMX00 H and RACC UAMX01 H), on the ROM & Address Control board. These come from the PROM at U101 and go through a 74S174 at E97 before heading over to the DAP board. And during FET.00 we have: Addr PCB PCA AMX 260 44 44 0 "0" here selects DR (Destination Register) input to the mux and is incorrect; it should be 1 (PCB). During a single-instruction-step run, this value reads out OK on the analyzer. I noted a few other discrepancies in the capture (all of which match the ucode listing during a single-instruction step) which makes me think that the high outputs of the PROM are right on the bleeding-edge of acceptable TTL. I checked out the signal on the scope while running a BR .-1 instruction (which also doesn't execute correctly but at least doesn't halt... I don't have a storage scope to capture this during a single instruction execution) and it looks like the voltage swing is from about 0.15V to 1.7V or so. On the off chance it was the 74S174 at E97 pulling the signals down, I socketed it and substituted a spare '174 in; no change. I also noted that the +5V at this chip was about 4.95V, I goosed it up to 5.10V to see if it made a difference (it did not.) So it seems likely it's the PROM. Looks like I may have some typing to do, though given that the ROM works well enough at slow speeds I might be able to dump it with my Data I/O Model 29 and compare it against the listings in the engineering drawings, to save some time... I'll try to dump the PROM tomorrow and see what I get. - Josh
Re: PDP-11/70 progress (and a cry for help)
> On Tue, Feb 16, 2021 at 2:36 AM Fritz Mueller via cctalk > wrote: > So you could set up on t4 or t5 of that microinstruction with the KM11... > On Feb 16, 2021, at 11:08 AM, Josh Dersch wrote: > I can't, though -- all of this stuff works fine when running slowly :) Oh right -- I keep forgetting that part! So that really does leave you with just the LA to catch things in the act I guess. > Right now I'm thinking it is most likely the AMX selecting the wrong input > (I'm guessing that BMX is correctly selecting KOMX, to get the constant "2" > for the add operation). I agree; seems a good place to look next. > Have the 11/70 microcode PROMs been dumped? I had to recreate the 11/05 PROM > from the listings in the engineering drawings... I am not sure? For the 11/45, I also keyed it in by hand from the engineering drawings, but since it is only a 32x8 bit ROM this was pretty easy. --FritzM.
Re: PDP-11/70 progress (and a cry for help)
On Tue, Feb 16, 2021 at 2:36 AM Fritz Mueller via cctalk < cctalk@classiccmp.org> wrote: > > > > On Feb 16, 2021, at 1:13 AM, Josh Dersch wrote: > > My money's on t5 going wrong -- an ALU input mux or operation being > selected incorrectly, possibly. This also somewhat explains why execution > doesn't trap due to executing a HALT from an odd address -- it isn't > actually executing from the wrong address, because the bus address is > loaded from a still-good PCB in t1. > > Yes -- that seems to match the observations. So you could set up on t4 or > t5 of that microinstruction with the KM11 in single-clock-phase mode, and > then have at the ALU with a logic probe to check... > I can't, though -- all of this stuff works fine when running slowly :). It's possible that while running in single-clock mode I might be able to see a waveform that's slightly off on the 'scope, if I can pinpoint the failure. Right now I'm thinking it is most likely the AMX selecting the wrong input (I'm guessing that BMX is correctly selecting KOMX, to get the constant "2" for the add operation). > > There is a small ALU control ROM on the GRA (E74 in the upper left of > sheet GRAA), which selects the ALU mode and operation based on lines coming > over from the IRC. I had a failure of this part on my 11/45, and ended up > with incorrect ALU setup in some circumstances. That part is a 256-bit > DM8598 tri-state bipolar mask ROM, and the truth table is on sheet GRAK. > > Looking back at my notes, I think it was Glen who informed me (on this > list, in 2016!) that the Signetics 82S123 PROM could be substituted here. > Programmed one up, and it worked, in case you run into the same thing and > it is useful info. > I think I may have ended up doing a similar substitution with a microcode ROM on my 11/05. Have the 11/70 microcode PROMs been dumped? I had to recreate the 11/05 PROM from the listings in the engineering drawings... - Josh > > cheers, > --FritzM. > >
Re: PDP-11/70 progress (and a cry for help)
> On Feb 16, 2021, at 1:13 AM, Josh Dersch wrote: > My money's on t5 going wrong -- an ALU input mux or operation being selected > incorrectly, possibly. This also somewhat explains why execution doesn't > trap due to executing a HALT from an odd address -- it isn't actually > executing from the wrong address, because the bus address is loaded from a > still-good PCB in t1. Yes -- that seems to match the observations. So you could set up on t4 or t5 of that microinstruction with the KM11 in single-clock-phase mode, and then have at the ALU with a logic probe to check... There is a small ALU control ROM on the GRA (E74 in the upper left of sheet GRAA), which selects the ALU mode and operation based on lines coming over from the IRC. I had a failure of this part on my 11/45, and ended up with incorrect ALU setup in some circumstances. That part is a 256-bit DM8598 tri-state bipolar mask ROM, and the truth table is on sheet GRAK. Looking back at my notes, I think it was Glen who informed me (on this list, in 2016!) that the Signetics 82S123 PROM could be substituted here. Programmed one up, and it worked, in case you run into the same thing and it is useful info. cheers, --FritzM.
Re: PDP-11/70 progress (and a cry for help)
On Mon, Feb 15, 2021 at 8:01 PM Fritz Mueller via cctalk < cctalk@classiccmp.org> wrote: > Hi Josh, > > In the situation you describe, I guess I would first chip clip '174s for a > slice of both PCA and PBC on the LA, run the troublesome instruction > sequence, and look at the trace. Check that CLKPCA H and CLKPCB H are > happening when and only when expected, and that all the timing there looks > okay. > > You would also be able to see good-data-clocked-in-but-bad-data-presented > on that trace, indicating more failed '174, or see any bad data arriving > from the ALU upstream. > > I'll take a look through the flows after dinner. The "0002" might be one > operand used to increment the PC, but the other operand shows up as all > zeros because of a bad ALU setup? I guess I'd trace to definitively rule > out PCA and PCB first, and then move backward around the chain from there > verifying the ALU, ALU muxs, mux sources, etc.? > > --FritzM. > Thanks, Fritz, that's a good idea. I'm a bit short on dip clips at the moment so I had to read PCA and PCB on separate passes (and just the low 6 bits); and right now the clock's still hooked up to RACA CLKA RAR H (which clocks when the ucode ROM address changes) so it's not quite as fine grained as I'd like (I have to move everything around to get the logic analyzer's clock signal hooked up to the main clock and it's just too late tonight...). But still, this is fairly revealing. This is an execution of a MOV #1, R0 instruction poked in at address 40: Addr PCB PCA 334 40 40 260 40 40 343 42 42 022 42 44 027 44 44 205 44 44 260 44 44 343 03 03 010 03 05 316 03 05 164 03 05 240 03 05 352 03 05 170 03 05 (Note that the sample is taken at the beginning of the microinstruction). Based on this, it's clear that things get messed up during 260 (FET.10). The operations performed during this instruction are: t1: BA <- PCB; BC <- DATI t2: t3: BRQ STROBE t4: BUS PAUSE t5: PCA <- PCB + 2 t6 IR <- BUS; BR <- BUS PCB <- PCA t3 FPA <- BA My money's on t5 going wrong -- an ALU input mux or operation being selected incorrectly, possibly. This also somewhat explains why execution doesn't trap due to executing a HALT from an odd address -- it isn't actually executing from the wrong address, because the bus address is loaded from a still-good PCB in t1. More investigation later this week... - Josh
Re: PDP-11/70 progress (and a cry for help)
Hi Josh, In the situation you describe, I guess I would first chip clip '174s for a slice of both PCA and PBC on the LA, run the troublesome instruction sequence, and look at the trace. Check that CLKPCA H and CLKPCB H are happening when and only when expected, and that all the timing there looks okay. You would also be able to see good-data-clocked-in-but-bad-data-presented on that trace, indicating more failed '174, or see any bad data arriving from the ALU upstream. I'll take a look through the flows after dinner. The "0002" might be one operand used to increment the PC, but the other operand shows up as all zeros because of a bad ALU setup? I guess I'd trace to definitively rule out PCA and PCB first, and then move backward around the chain from there verifying the ALU, ALU muxs, mux sources, etc.? --FritzM.
PDP-11/70 progress (and a cry for help)
Hi all -- Thought you all might be interested in an update, and I'm also looking for advice in debugging the current issue I'm hitting. After replacing the clock crystal on the TIG, the system started showing signs of life, but the Load Address switch would stop working after being powered on for 10-30 seconds, but would work fine single-stepping via the KM11. Brought the DAP board out onto the extender for debugging and the problem went away. Reinstalled the board after cleaning the slot (again) and the problem hasn't recurred since. First bad backplane connection, I'm sure it won't be the last. After this, addresses could be loaded, data could be toggled into memory. But instructions wouldn't execute; Tracing through the microcode with the KM11 indicated that the microcode flow was aborting early and returning to the main console loop (via BRK.90) before the instruction fetch at FET.00; this was due to the TMCB BRQ TRUE H signal being stuck high. Probing of the TMC board revealed a bad 74H30 at E70, which had its output stuck at 1.65V or so, just high enough to confuse things. Now instructions would execute but the PC would contain garbage after execution of an instruction, after tracing the microcode and staring at the flow diagrams all signs pointed to the PCB register (twin to the PCA register that is used for storing PC data) having trouble. Garbage in the PC after execution was always in bits 6-11, everything else was fine, which pointed to a 74S174 at H47 on the DAP board. Replaced and now instructions execute! Mostly. They seem to execute properly when single-stepping instructions, or running off the RC clock at a clock rate of about 16-20Mhz, any faster than that and things stop working correctly. This is what I'm currently banging my head against -- if anyone has any experience with the 11/70 or wants to stare at the manuals for a bit (and who doesn't?), I'd appreciate any extra input. There are a number of different issues, I'm currently focusing on two-operand instructions that take an immediate argument (MOV #10, R0, or ADD #42, R5) for example. The behavior here is a bit befuddling and I can't quite figure out how it ends up happening, given the microcode. I'll use ADD as a representative example. An ADD #10, R0 instruction (followed by HALT) poked in at address 1000 executes properly -- R0 gets 10 -- but afterwards the PC is corrupted: it contains 2, rather than 1004. In the general case, "ADD #X, R0" ends with PC containing 2 + . (MOV shows the exact same behavior, except that there's no addition, obviously.) This value of PC is shown in the Address lights, as well as when examining the register from the front panel (at 1707). When single-instruction-stepping the processor this instruction executes perfectly: R0 gets R0+10, PC is 1004 afterwards (both in the Address lights and when examining from the front panel). I have verified with my logic analyzer that when running normally (i.e. not single-stepping) the microcode executes the proper sequence of instructions -- which is the same as executed when single-stepping except at the very end: In FLOWS 4, after the D00.90 instruction executes, a branch is taken to BRK.90, which exits back to the console loop. I don't believe there should be any other differences in execution between the two paths -- other than the branch at the end there are no conditional branches or conditional operations based on whether the CPU is single-stepping or not. There's a signal somewhere in there that has just gone a little bit slow... the trick is finding it. For reference, the microcode sequence (starting at FET.03, see pg. 5 of http://bitsavers.org/pdf/dec/pdp11/1170/MP0KB11-C0_1170engDrw_Nov75.pdf) is: 334 (FET.03) 260 (FET.10) 343 (IRD.00) 022 (S13.01) 027 (S13.10) 205 (D00.90) 260 (FET.10) 343 (IRD.00) 010 (HLT.00) 316 (HLT.10) 164 (FET.04) 240 (BRK.90) 352 (BRK.00) 170 (CON.00) You can see it fetching and executing the ADD instruction, then returning back to FET.10 and executing the next instruction, which is a HALT instruction (because all other memory contains 0 at this point). I believe this is what causes the "+2" portion of the final (incorrect) PC value. (What's extra odd -- literally -- here is that if you start with a "1" in R0, the final PC is 3... seemingly indicating a fetch/execution of an instruction at an odd address, which you'd think would cause a trap instead...) I've been staring at this awhile and I'm puzzled; everything seems to execute properly, the instruction is fetched and decoded, and the immediate value is fetched, the ALU does the right thing and the result is properly stored in R0. And then the PC gets screwed up, and I'm not quite sure how that's possible from looking at the microcode, so I'm not quite sure where to start looking. I sort of suspect the PCB register again, as this is related to the difference in behavior between single-stepping and normal execution: the branch back to the
