27 Jan
2015
27 Jan
'15
11:12 p.m.
On 2015-01-27 23:56, Don North wrote:
Could be something wrong with MUL, DIV, ASH, ASHC that
may be used in the print
routine, but would not be used during basic OS operation. XXDP in particular is
designed to run on a very basic CPU so it does not normally use any optional
instructions.
He booted RSX as well.
I'd start with running the 11/34 CPU tests.
I'd start with actually putting in some non-zero values for CSR and
vector when running the RL test. :-)
Johnny
Don
-----Original Message-----
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
From: Johnny Billquist <bqt at
update.uu.se>
Sent: Jan 27, 2015 2:42 PM
To: cctalk at classiccmp.org
Subject: Re: strange number corruption on pdp11/34
On 2015-01-27 21:24, Noel Chiappa wrote:
If it comes as far as booting RSX as well as XXDP, there can't be
anything seriously wrong with the CPU...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
From:
Jacob Ritorto
I'm getting all zeroes nearly any time
there's supposed to be a large
number output to my terminal.
It sounds like the CPU may be too broken to run diagnostics. Why don't you
try writing some small programs to test various bits and pieces of the CPU
(e.g. add instructions, etc), and toggle them in, and try and find what's
busted that way? (Although for 'add', if the thing's that broken, I'm
amazed
it even boots.)
Here's an example:
http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tests/print.s
It's probably too long to toggle in, but you could steal pieces from it
and try them.
I'd probably try out the shift and multiply instruction to start with; trying
to figure out what's probably not used during booting, but could be used
during number printing, those are two good bets.
Anyway, there's no point to running diagnostics until you get that first
problem fixed.