dec /34a issue

[joe heck]

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