19 Oct
2006
19 Oct
'06
12:34 p.m.
I just brought up my /34a and apparently it's sick. It has one DD11-PK.
Configuration is as follows:
1 - M8266 (A-F)
2 - M8265 (A-F)
3 - M9312 (A-B), M7859 (C-F)
4 - M7891 (A-F)
5 - Grant (D)
6 - Grant (D)
7 - Grant (D)
8 - Grant (D)
9 - M9302 (A-B), Grant (D)
What works:
Storing & retreiving various patterns from ram via the front panel works
fine in all cases.
Looping on CLR PC loops as expected
Looping on BR . loops as expected
Trap catcher works (first pass halts at 1030 filling ram, then a BR . loops
as expected).
The memory address test program fails though. It halts at 246 indicating a
memory addressing error. R1 points to 422. Examining memory via the front
panel shows the following:
420 420
422 177355
424 177353
426 177351
430 177347
So it looks to me like it is able to store 420 in 420, but nothing after
that. I would normally think there is a problem with the memory board
(M7891). However, I have replaced that board with 2 others, and all 3 boards
fail at the same address AND with the same values. I find that likely to
rule out the memory board as really being bad. In addition, I can deposit
and examine values to locations 420 through 430 via the front panel just
fine. It's my understanding that the KY11-LB puts data in memory via the
unibus, so I would think this makes it somewhat unlikely to be a backplane
issue. Is it a strong likelyhood that the problem is the cpu set itself
then, as that's what would be writing the values to memory during the
address test?
And as I type this, I just noticed something interesting. The numbers stored
in ram at 422 through 430 are the right numbers, just inverted logic. More
specifically if you invert all the bits in 177355 you get 422, if you invert
all the bits in 177353 you get 424, inverting 177351 gives 426 (all the
latter values being what I'd expect). I'm guessing there's a dead inverter
on the cpu set somewhere perhaps? But if that's the case, why does 420 get
set to 420 correctly??
Any advice is most appreciated :)
Jay West
19 Oct
19 Oct
12:45 p.m.
Well, I don't have the listing in front of me, but perhaps there are
multiple passes through the memory test. Maybe it wrote out all the
inverted numbers fine on the first pass, then when it tried to write the
real numbers it failed (or vice versa). That way it will test all the
bits, although not adjacent bit stickiness. So, maybe try to write the
inverted number to 420?
Just my quick thoughts.
Joe Heck
Jay West wrote:
I just brought up my /34a and apparently it's
sick. It has one DD11-PK.
Configuration is as follows:
1 - M8266 (A-F)
2 - M8265 (A-F)
3 - M9312 (A-B), M7859 (C-F)
4 - M7891 (A-F)
5 - Grant (D)
6 - Grant (D)
7 - Grant (D)
8 - Grant (D)
9 - M9302 (A-B), Grant (D)
What works:
Storing & retreiving various patterns from ram via the front panel works
fine in all cases.
Looping on CLR PC loops as expected
Looping on BR . loops as expected
Trap catcher works (first pass halts at 1030 filling ram, then a BR .
loops as expected).
The memory address test program fails though. It halts at 246 indicating
a memory addressing error. R1 points to 422. Examining memory via the
front panel shows the following:
420 420
422 177355
424 177353
426 177351
430 177347
So it looks to me like it is able to store 420 in 420, but nothing after
that. I would normally think there is a problem with the memory board
(M7891). However, I have replaced that board with 2 others, and all 3
boards fail at the same address AND with the same values. I find that
likely to rule out the memory board as really being bad. In addition, I
can deposit and examine values to locations 420 through 430 via the
front panel just fine. It's my understanding that the KY11-LB puts data
in memory via the unibus, so I would think this makes it somewhat
unlikely to be a backplane issue. Is it a strong likelyhood that the
problem is the cpu set itself then, as that's what would be writing the
values to memory during the address test?
And as I type this, I just noticed something interesting. The numbers
stored in ram at 422 through 430 are the right numbers, just inverted
logic. More specifically if you invert all the bits in 177355 you get
422, if you invert all the bits in 177353 you get 424, inverting 177351
gives 426 (all the latter values being what I'd expect). I'm guessing
there's a dead inverter on the cpu set somewhere perhaps? But if that's
the case, why does 420 get set to 420 correctly??
Any advice is most appreciated :)
Jay West
1:18 p.m.
Jay you mention below 'The memory address test program fails though.'
Which memory address test program are you referring to? The M9312?
The M9312 11/34 console emulator has a simple memory diagnostic
that scans the low 28KW, writes the address of each word to the word,
and then rescans, negating each word value in memory. It then adds the
address to the negated word, and halts if the result is not zero.
Successful test execution results in all of memory being cleared.
Normally this test will only be run when you try and boot from some
device in your system.
See the console listing at: http://www.AK6DN.com/PDP-11/M9312/ under
the 'M9312 11/04,34 Diagnostic Console' listing.
If you have the capability to program an M9312 boot PROM I generated
an image for a pseudo-device 'ZZ' that does nothing but run all the
internal M9312 diagnostics forever (processor and memory). I've found
it very useful in situations like this.
joe heck wrote:
Well, I don't have the listing in front of me, but
perhaps there are
multiple passes through the memory test. Maybe it wrote out all the
inverted numbers fine on the first pass, then when it tried to write
the real numbers it failed (or vice versa). That way it will test all
the bits, although not adjacent bit stickiness. So, maybe try to
write the inverted number to 420?
Just my quick thoughts.
Joe Heck
Jay West wrote:
I just brought up my /34a and apparently it's
sick. It has one
DD11-PK. Configuration is as follows:
1 - M8266 (A-F)
2 - M8265 (A-F)
3 - M9312 (A-B), M7859 (C-F)
4 - M7891 (A-F)
5 - Grant (D)
6 - Grant (D)
7 - Grant (D)
8 - Grant (D)
9 - M9302 (A-B), Grant (D)
What works:
Storing & retreiving various patterns from ram via the front panel
works fine in all cases.
Looping on CLR PC loops as expected
Looping on BR . loops as expected
Trap catcher works (first pass halts at 1030 filling ram, then a BR .
loops as expected).
The memory address test program fails though. It halts at 246
indicating a memory addressing error. R1 points to 422. Examining
memory via the front panel shows the following:
420 420
422 177355
424 177353
426 177351
430 177347
So it looks to me like it is able to store 420 in 420, but nothing
after that. I would normally think there is a problem with the memory
board (M7891). However, I have replaced that board with 2 others, and
all 3 boards fail at the same address AND with the same values. I
find that likely to rule out the memory board as really being bad. In
addition, I can deposit and examine values to locations 420 through
430 via the front panel just fine. It's my understanding that the
KY11-LB puts data in memory via the unibus, so I would think this
makes it somewhat unlikely to be a backplane issue. Is it a strong
likelyhood that the problem is the cpu set itself then, as that's
what would be writing the values to memory during the address test?
And as I type this, I just noticed something interesting. The numbers
stored in ram at 422 through 430 are the right numbers, just inverted
logic. More specifically if you invert all the bits in 177355 you get
422, if you invert all the bits in 177353 you get 424, inverting
177351 gives 426 (all the latter values being what I'd expect). I'm
guessing there's a dead inverter on the cpu set somewhere perhaps?
But if that's the case, why does 420 get set to 420 correctly??
Any advice is most appreciated :)
Jay West
1:38 p.m.
New subject: dec /34a issue (more info)
I did test those locations (420-430) and I can read/write the "normal"
values as well as the complemented values VIA the front panel.
It's also not "any data written by the processor is complemented" because
the trap catcher program does write the correct data to locations 0-770.
I'm certain I'm typing in the memory address test correctly. I have no
other -11 handy. Is it possible there's a typo in the program I got? It
follows:
000004 000226 bus error trap
000006 000000
000010 000012 reserved instruction trap
000012 000000
000200 012706 mov #410,sp set the stack
000202 000410
000204 012700 mov #420,r0 set target memory address
000206 000420
000210 010001 mov r0, r1 copy memory address
000212 010111 loop1: mov r1, (r1) write memory
000214 020111 cmp r1, (r1) check write
000216 001401 beq .+2 OK
000220 000000 halt initial check error
000222 005121 com (r1)+ complement the data
000224 000772 br loop1 loop till bus error
000226 012737 mov #6,@#4 reload trap vector
000230 000006
000232 000004
000234 010001 mov r0,r1 copy memory address
000236 005111 loop2: com (r1) complement memory
000240 020111 cmp r1,(r1) recheck memory
000242 001401 beq .+2 OK
000244 000000 halt memory addressing error
000246 005721 tst (r1)+ increment memory address
000250 000773 br loop2
When I enter and run the above program, it halts at 246. R1 contains 422. In
going back after this halt, the program at 200 is unchanged and just as
entered. However, location 4 contains a 6, not a 226.
Puzzled....
J
2:04 p.m.
New subject: dec /34a issue (more info)
On Thursday 19 October 2006 16:38, Jay West wrote:
I did test those locations (420-430) and I can
read/write the
"normal" values as well as the complemented values VIA the front
panel.
It's also not "any data written by the processor is complemented"
because the trap catcher program does write the correct data to
locations 0-770.
I'm certain I'm typing in the memory address test correctly. I have
no other -11 handy. Is it possible there's a typo in the program I
got? It follows:
<snip>
When I enter and run the above program, it halts at
246. R1 contains
422. In going back after this halt, the program at 200 is unchanged
and just as entered. However, location 4 contains a 6, not a 226.
Puzzled....
If it makes you feel any better, simh gives the same results. So,
there's something wrong with the program you have, not your machine. :)
Stepping through it, I catch the error:
000250 000773 br loop2
That actually branches back to the instruction *after* loop2. You
should instead have
000250 000771 br loop2
That works as expected...
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
2:10 p.m.
New subject: dec /34a issue (more info)
On Thursday 19 October 2006 17:04, Patrick Finnegan wrote:
That actually branches back to the instruction *after*
loop2. You
should instead have
000250 000771 br loop2
Crap. I should have checked the result first.... that should be:
000250 000772 br loop2
otherwise you branch back to where r1 gets reset to 420, and the memory
test fails (gee I wonder why:).
Also, you should halt with PC set to 10, when it's all done.
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
20 Oct
20 Oct
1:59 a.m.
New subject: dec /34a issue (more info)
On Thu, 19 Oct 2006, Patrick Finnegan wrote:
If it makes you feel any better, simh gives the same
results. So,
there's something wrong with the program you have, not your machine. :)
Stepping through it, I catch the error:
000250 000773 br loop2
That actually branches back to the instruction *after* loop2. You
should instead have
000250 000771 br loop2
^^^^^^
That should be 000772
That works as expected...
What nobody has mentioned yet is that this memory tester is listed on the
web page "Hints on testing a dead PDP-11". I went through all of this
about six years ago when I was restoring our 11/34. I remember this
fault, and I'm seeing that I had corrected this typo on the printout I did
back then. It seems that the web page has been corrected since then, so
Jay must have used an old printout, too.
Christian
3:50 p.m.
New subject: dec /34a issue (more info)
Christian wrote...
What nobody has mentioned yet is that this memory
tester is listed on the
web page "Hints on testing a dead PDP-11". I went through all of this
about six years ago when I was restoring our 11/34. I remember this fault,
and I'm seeing that I had corrected this typo on the printout I did back
then. It seems that the web page has been corrected since then, so Jay
must have used an old printout, too.
Yes, and no. I did use an old printout. However, when Pat spotted the error,
I went back to the website and the website definitely had the value wrong.
So I copied the section of code right off the website and emailed it to the
owner. I suspect that he changed it (possibly again) before you looked at
it.
Jay
19 Oct
19 Oct
2:23 p.m.
New subject: dec /34a issue (more info)
Boy, I wish I knew PDP-11 assembler better. Someday. :) Jay West wrote:
I'm certain I'm typing in the memory address
test correctly. I have no
other -11 handy. Is it possible there's a typo in the program I got? It
follows:
[...]
000236 005111 loop2: com (r1) complement memory
[...]
000250 000773 br loop2
Er, is "br loop2" numerically correct here? It, er, smells wrong. :)
-O.-
6:05 p.m.
New subject: dec /34a issue (Solved)
O. Sharp wrote....
Boy, I wish I knew PDP-11 assembler better. Someday.
:)
Yes, I do wish I knew it better. Then I may have caught the problem myself
;)
> I'm certain I'm typing in the memory
address test correctly.
And just to be precise, I was typing the program correctly.
The website I
copied it from has it posted incorrectly. I'll email the person who runs the
website to make a correction.
Er, is "br loop2" numerically correct here?
It, er, smells wrong. :)
I wouldn't have likely caught that. Patrick was right
- thanks! It does in
fact pass the test.
Now that I've got enough confidence in the machine being somewhat
functional, I'm gonna grab an RL02 and see if I can boot :)
Thanks for all the input folks!
Jay
21 Oct
21 Oct
7:17 a.m.
New subject: dec /34a issue (Solved)
Jay,
Is this the 11/34 from my garage?
----- Original Message -----
From: "Jay West" <jwest at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Thursday, October 19, 2006 9:05 PM
Subject: Re: dec /34a issue (Solved)
O. Sharp wrote....
Boy, I wish I knew PDP-11 assembler better.
Someday. :)
Yes, I do wish I knew it better. Then I may have caught the problem
myself
;)
> I'm certain I'm typing in the memory
address test correctly.
And just to be precise, I was typing the program correctly.
The website I
copied it from has it posted incorrectly. I'll email the person who runs
the website to make a correction.
Er, is "br loop2" numerically correct
here? It, er, smells wrong. :)
I wouldn't have likely caught that. Patrick was
right - thanks! It does in
fact pass the test.
Now that I've got enough confidence in the machine being somewhat
functional, I'm gonna grab an RL02 and see if I can boot :)
Thanks for all the input folks!
Jay
7:57 a.m.
New subject: dec /34a issue (Solved)
Bob wrote...
Is this the 11/34 from my garage?
Mostly, yes. I acquired three 11/34 carcasses in varying states of
wholeness - yours was by far the most complete. The machine I'm bringing up
now is mostly the one from your garage, but in a different BA11 (the same
front panel however). The leftover parts of the remaining /34 will be
offered to the list or pitched. There's not much leftover though, as I'll
want the regulators in the remaining chassis/panel for spares.
Odd - it boots RT11. It passes some diagnostics. Other diagnostics I can't
tell for sure if it's passing correctly due to lack of documentation on the
diagnostics. I suspect it's failing something though.
Jay
2:17 p.m.
New subject: dec /34a issue (Solved)
There are 3 more RL-01 packs that were left behind.
Some of the packs you have (and some left behind) have
the OMSI Pascal compiler for RT-11.
I also found the ribbon cable and bulkhead fixture that
goes between the RL-11 board and the RL drive cables.
----- Original Message -----
From: "Jay West" <jwest at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Saturday, October 21, 2006 10:57 AM
Subject: Re: dec /34a issue (Solved)
Bob wrote...
Is this the 11/34 from my garage?
Mostly, yes. I acquired three 11/34 carcasses in varying states of
wholeness - yours was by far the most complete. The machine I'm bringing
up now is mostly the one from your garage, but in a different BA11 (the
same front panel however). The leftover parts of the remaining /34 will be
offered to the list or pitched. There's not much leftover though, as I'll
want the regulators in the remaining chassis/panel for spares.
Odd - it boots RT11. It passes some diagnostics. Other diagnostics I can't
tell for sure if it's passing correctly due to lack of documentation on
the diagnostics. I suspect it's failing something though.
Jay
22 Oct
22 Oct
7:13 a.m.
New subject: dec /34a issue (Solved)
"Bob Shannon" wrote:
There are 3 more RL-01 packs that were left behind.
Some of the packs you have (and some left behind) have
the OMSI Pascal compiler for RT-11.
Jay, if you don't want them i'll be happy to retrieve them :-)
-brad
10:25 a.m.
New subject: dec /34a issue (Solved)
Bob wrote...
>Some of the packs you have (and some left behind)
have
>the OMSI Pascal compiler for RT-11.
Brad replied...
Jay, if you don't want them i'll be happy to
retrieve them :-)
No, I'm still planning on getting all this stuff from Bob :) I do however
also currently have Oregon Software Pascal-2 version 2.1F on RX02 floppies,
an original distribution.
Jay
19 Oct
19 Oct
12:59 p.m.
Quoth Jay West, in part:
The memory address test program fails though. It halts
at 246 indicating a
memory addressing error. R1 points to 422. Examining memory via the front
panel shows the following:
[...]
So it looks to me like it is able to store 420 in 420,
but nothing after
that. I would normally think there is a problem with the memory board
(M7891). However, I have replaced that board with 2 others, and all 3 boards
fail at the same address AND with the same values. I find that likely to
rule out the memory board as really being bad. In addition, I can deposit
and examine values to locations 420 through 430 via the front panel just
fine. It's my understanding that the KY11-LB puts data in memory via the
unibus, so I would think this makes it somewhat unlikely to be a backplane
issue. Is it a strong likelyhood that the problem is the cpu set itself
then, as that's what would be writing the values to memory during the
address test?
It sounds like you've already done a good job of eliminating the obvious
hardware issues. :) The fact that the data is _inverted_ afterwards
interests me; that sounds like the sort of complememt-memory test pattern
a memory test program would use in alternation with the first. So I
wonder:
Is the memory-test program corrupted?
If so, is the source you loaded the test from bad, or did the test load
correctly and later get partially corrupted in memory?
If it got corrupted in memory, can you reload it and get it corrupted
again? :) More to the point, would it re-corrupt in a consistent manner?
...That's just what pops to my mind, anyway. It seems like it'd be easier
to have a fault that corrupted the test program than a fault that produced
such peculiar and far-reaching results. :)
-O.-
1:13 p.m.
Jay,
At 2:34 PM -0500 10/19/06, Jay West wrote:
420 420
422 177355
424 177353
426 177351
430 177347
So it looks to me like it is able to store 420 in 420, but nothing
after that. I would normally think there is a problem with the
memory board (M7891). However, I have replaced that board with 2
others, and all 3 boards fail at the same address AND with the same
values. I find that likely to rule out the memory board as really
being bad. In addition, I can deposit and examine values to
locations 420 through 430 via the front panel just fine.
I imagine that's just a small sample showing the results from 420 on.
How far into memory have you looked? It is certainly painful to step
all the way through however much you have (which model M7891?) but
more samples may be necessary.
Are you certain the backplane is wired correctly? In particular, that slot?
John
6399
days inactive
6412
days old
17 comments
10 participants
participants (10)
-
ak6dn＠mindspring.com -
brad＠heeltoe.com -
bshannon＠tiac.net -
cc＠corti-net.de -
dundas＠caltech.edu -
jwest＠classiccmp.org -
jwest＠ezwind.net -
ohh＠drizzle.com -
pat＠computer-refuge.org -
trash3＠splab.cas.neu.edu