strange number corruption on pdp11/34

[Jacob Ritorto]

  ok, it's after four, here, and I'm calling it a night. But I felt the
need to briefly summarize and have to seriously thank all of you for the
brilliant input and observation.  I got it running and solved the zeroes
problem.

Based on your input, I looked more informedly at my inventory and it turned
out that I had two 11/34a board sets, one of which had the fp board with
it.  I ended up taking js's advice and ditching the fp board and
mix-and-matching 8265 and 8266 boards from the old and new sets to make a
system that doesn't bus error and doesn't print weird zeroes.  Also,
thankfully, no more power-up hanging and manually entering ODT at 165200.
(I wonder if there's something numeric that happens there that's affected
by the bug?)

  I'm so excited that this thing is actually working again after so long --
thank you all again for the insights and interest!

  If anyone is really interested in debugging these "bus error /
zero-inducing" cpu boards to find out what on earth was causing the
problem, I'd be happy to loan them out.  Heck, I might even try to do what
we were talking about initially and write up some little math tests if
you're really curious.

It's been a really long and wonderful pdp11-filled day.  See you tomorrow
with more interesting hacking on the next hurdle: emulex controllers and
smd disks!

ttfn
jake

P.S. John, it was initially a Mac using screen(1) to talk to a PL2303
serial dongle.  When you suggested terminal insanity, I switched out to an
old CIT-101 terminal I had lying about.  Same results.  Although I concur
with your suspicions because the dongle really fouls up talking to 2.9bsd
for some reason and is, I agree, a pretty shady (insane) terminal.

On Tue, Jan 27, 2015 at 6:38 PM, Don North <north at alum.mit.edu> wrote:

> On 1/27/2015 3:13 PM, Johnny Billquist wrote:
>
>> On 2015-01-28 00:05, Noel Chiappa wrote:
>>
>>>      > From: Johnny Billquist
>>>
>>>      > If it comes as far as booting RSX as well as XXDP, there can't be
>>>      > anything seriously wrong with the CPU...
>>>
>>> Yeah, I see your point, but why all the zeros, then? That's what I
>>> could't
>>> work out.
>>>
>>> Anyway, it should be really easy to make sure e.g. ASH, MUL and DIV are
>>> working; it's vaguely plausible that one of them is broken. (Unix V6, I
>>> think,
>>> might even boot even if MUL was broken. I know the bootstrap uses DIV, to
>>> calculate the cylinder in the disk driver.) If not, cross that off the
>>> list,
>>> and try the next thing... Which is?
>>>
>>
>> Is noone paying attention to the fact (and my previous comment) about
>> using 0 for CSR and vector???
>>
>>     Johnny
>>
>>
> No, but it is likely those values are OK, but are being printed as ZERO
> the same way all the other numbers are ...
>