15 Feb
2021
15 Feb
'21
5:55 p.m.
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 + <original value of R0>. (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 17777707).
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 console loop *doesn't* update PCA from PCB, whereas the
branch back to the fetch / decode loop does.
Anyone have any bright ideas as far as what to poke at?
Thanks as always,
- Josh
15 Feb
15 Feb
8:01 p.m.
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.
16 Feb
16 Feb
1:13 a.m.
On Mon, Feb 15, 2021 at 8:01 PM Fritz Mueller via cctalk <
cctalk at 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: <SHFR <- PCB + 2>
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
2:36 a.m.
On Feb 16, 2021, at 1:13 AM, Josh Dersch <derschjo
at gmail.com> 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.
11:08 a.m.
On Tue, Feb 16, 2021 at 2:36 AM Fritz Mueller via cctalk <
cctalk at classiccmp.org> wrote:
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).
On Feb 16, 2021, at 1:13 AM, Josh Dersch
<derschjo at gmail.com> 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.
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.
5:08 p.m.
On Tue, Feb 16, 2021 at 2:36 AM Fritz Mueller via
cctalk <cctalk at 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 <derschjo
at gmail.com> 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.
17 Feb
17 Feb
12:45 a.m.
On Tue, Feb 16, 2021 at 5:08 PM Fritz Mueller via cctalk <
cctalk at classiccmp.org> 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
On Tue, Feb
16, 2021 at 2:36 AM Fritz Mueller via cctalk <
cctalk at 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
<derschjo at gmail.com> 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.
8:05 a.m.
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
21 Feb
21 Feb
1:33 a.m.
On Wed, Feb 17, 2021 at 12:45 AM Josh Dersch <derschjo at gmail.com> 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
PC BANK VADD PADD GOOD BAD XOR MAR BOX MTYPE INT PAT
ARRAY
032334 50 157564 05077564 000377 000377 000000 0 ? MJ11 ? 17
??
032334 50 156450 05076450 000377 000377 000000 0 ? MJ11 ? 17
??
032334 50 155330 05075330 000377 000377 000000 0 ? MJ11 ? 17
??
032334 50 154210 05074210 000377 000377 000000 0 ? MJ11 ? 17
??
032342 50 154020 05074020 000377 177777 177400 0 ? MJ11 ? 17
??
032342 50 153740 05073740 000377 177777 177400 0 ? MJ11 ? 17
??
032342 50 153734 05073734 000377 177777 177400 0 ? MJ11 ? 17
??
032342 50 153732 05073732 000377 177400 177777 0 ? MJ11 ? 17
??
032342 50 153730 05073730 000377 177400 177777 0 ? MJ11 ? 17
??
032342 50 153726 05073726 000377 177400 177777 0 ? MJ11 ? 17
??
032342 50 153724 05073724 000377 177400 177777 0 ? MJ11 ? 17
??
032342 50 153722 05073722 000377 177400 177777 0 ? MJ11 ? 17
??
032342 50 153720 05073720 000377 177400 177777 0 ? MJ11 ? 17
??
032342 50 153716 05073716 000377 177400 177777 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 00007524 06000000 05777776 144406
(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 poking at this, but the complexity of the PEP70 memory board plus the
lack of hardware docs is going to make this a challenge. If anyone has any
bright ideas, let me know.
I suppose that worst case I still have a megabyte or so of contiguous
working memory; I can modify the memory size jumpers and patch operating
systems to ignore the rest. Better than nothing!
Anyway: I'm pretty happy with the progress here, I wasn't expecting this to
go as smoothly as it has (knock on wood) for a computer in as sad shape as
it was. Total carnage here: 4 bad ICs, one dead clock crystal, a dead
Unibus terminator, and a marginal HC42 board. And a few slightly dirty
backplane fingers... Gives me hope for the 11/45...
- Josh
8:48 a.m.
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
PC BANK VADD PADD GOOD BAD XOR MAR BOX MTYPE INT PAT
ARRAY
032334 50 157564 05077564 000377 000377 000000 0 ? MJ11 ? 17
??
032334 50 156450 05076450 000377 000377 000000 0 ? MJ11 ? 17
??
032334 50 155330 05075330 000377 000377 000000 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 000000
0 ? MJ11 ? 17
??
032342 50 154020 05074020 000377 177777 177400 0 ? MJ11 ? 17
??
032342 50 153740 05073740 000377 177777 177400 0 ? MJ11 ? 17
??
032342 50 153734 05073734 000377 177777 177400 0 ? MJ11 ? 17
??
032342 50 153732 05073732 000377 177400 177777 0 ? MJ11 ? 17
??
032342 50 153730 05073730 000377 177400 177777 0 ? MJ11 ? 17
??
032342 50 153726 05073726 000377 177400 177777 0 ? MJ11 ? 17
??
032342 50 153724 05073724 000377 177400 177777 0 ? MJ11 ? 17
??
032342 50 153722 05073722 000377 177400 177777 0 ? MJ11 ? 17
??
032342 50 153720 05073720 000377 177400 177777 0 ? MJ11 ? 17
??
032342 50 153716 05073716 000377 177400 177777 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
1400
days inactive
1405
days old
9 comments
3 participants
participants (3)
-
derschjo＠gmail.com -
elson＠pico-systems.com -
fritzm＠fritzm.org