Hey all,
I bumped into someone who has some early (mid 1970 on some of the photos
I've seen) PDP-11 bits - front panel and a handful of boards (the
backplane, PSU, rack, peripherals etc. are long gone). The front panel's
branded as "Industrial 11" though, which isn't something I've seen or heard
of before.
Address bus is 16 bits wide, and aside from the branding, the style appears
to be the same as an 11/05 or 11/10. Were there any differences to the
system internally though, or in the standard set of boards fitted, or was
the "industrial" aspect purely a marketing exercise?
cheers
Jules
Hi, sorry about the delayed reply; been dealing with this:
http://ana-3.lcs.mit.edu/~jnc/jpg/backoak/WholeTreeS.jpg
The cranes arrive tomorrow...
> I took a look at all the lines you mentioned. BDAL3-13, BDIN, BSYNC, and
> BBS7 are all active and jump around in some manner.
Hmm. Well, that shoots down the simplest theory; that a CPU BDAL (or perhaps
BDIN) driver (technically, a transceiver) chip is bad; if you're seeing any
activity at all on a line, the driver must be working. So, either both console
cards have an issue, or something more complex is going on.
Here are some pictures to show you what you should be seeing, and what I'm
seeing with an LSI-11 with no console card. First, normal operation:
http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_OK.jpg
The top trace is BSYNC, the bottom BDAL10 (which should be asserted for
0177560, the console CSR's address; it's the 02000 bit). The timebase on this
one is 1 usec per division. As you can see, it's in a tight loop reading that
register.
The QBUS spec shows that for a DATI cycle, the DAL lines are set up before
BSYNC is asserted (falling edge here, since the bus lines are inverted).
BDA10 is indeed asserted (low) when that happens; shortly after it goes back
to 0 (high) so that device can put its data out on those lines. It stays high,
so that bit in the CSR must be 0.
OK, now a picture of the bus with no console card:
http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_NoCon.jpg
It's a bit hard to interpret what's going on here (note that the timebase is
much larger - 5 usec). The long assertion of BSYNC is undoubtly the CPU trying
to get the console CSR to respond, and eventually timing out. Not sure what
the short assertion following it is - without looking at the ucode for the
ODT, there's no way to know what the CPU's doing.
Even harder to understand is what the BDAL line is doing. It looks like it's
un-asserted (0, i.e. +3V) on the falling (electrically - rising, logically)
edge of BSYN (which would be incorrect - see above). And then it hops around
while BSYNC is asserted, which makes no sense at all to me.
At this point, my best guess at the most likely cause of your problem (given
the 'all the lines are doing stuff') is that both console cards have
issues. Tomorrow, when I'm not outside, I'll try and look at some other BDAL
lines and see if they are doing the same thing with no console card in.
Noel
trying to ID early core stacks from GE 200 series ( like for dartmouth basic machine) or or ERMA. any old times have close up docs or part numbers? I may have found the lost treasure...
we? have a? ?2 each 21 inch? or? ?so? wide? thing? ?with 2? monster ass? stacks? mounted in each one..
one is? intact? and? dirty? but? ? ?intact!
?the other? ?stacks? and? weird other things mounted to metal? frame? work are there? but? ? ?some? stiff is? just? hanging? off it
unit? ?2? might? be? subdivided? and shared .? ? I? have never seen? GE? core? that? was? this? large......
Metal? ?frame? has? log? ?GE? part? number? ? each? stack? has? ?one? ?too
the? game is? afoot!
if? not? solved? rather? ?quickly? they? return to the? warehouse.
thanks? ed sharpe? archivist? for smecc
This just came up on Fess Bouc. I did not know that it existed.
It's an LLVM-backed modern compiler for BLISS.
https://madisongh.github.io/blissc/
--
Liam Proven - Profile: https://about.me/liamproven
Email: lproven at cix.co.uk - Google Mail/Hangouts/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
I took a look at all the lines you mentioned. BDAL3-13, BDIN, BSYNC, and
BBS7 are all active and jump around in some manner. BRPLY is still the only
line that does not have any activity on it. None of the BDAL lines seem
shorted to ground or to each other. My DLV11-J is configured to essentially
factory settings (J3 set as console, 8 bits no parity) except for the fact
that J3 is at 9.6k baud instead of 300, the address jumpers are exactly the
same as the one you provided.
On Sun, May 26, 2019 at 6:35 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:
> Hey, I owe you replies to about a zillion emails; been busy, I'll
> try and get to them tomorrow. A few quick things:
>
>
> > My M8043 (DLV11-J) just arrived today.
>
> Here are the jumpers on mine, which I just pulled from a working system,
> so you can compare and make sure you have them correct:
>
> A5 L
> A9 L
> A12 C
> A10 C
> A11 C
> A8 C
> C2 C
> C1 C
>
> Key: L = jumper from left post to right (component side up, gold pads
> at bottom)
> C = jumper from center post to right
>
> A6 I
> A7 R
>
> I = Insert, R = Remove
>
> B-X-H X-H
>
> I have left out the vectors jumpers, since ODT doesn't use interrupts, and
> the line config jumpers (their setting shouldn't have any effect on the
> ability of the board to respond to ODT).
>
>
> > I have a hard time imagining that both my M8017 and my M8043 are
> > bad, but it could still be possible.
>
> Well, I did mention that the CPU board could have a fault causing it to
> put out a bad address for the console; the other likely cause is that
> both consoles are bad. Not sure which is the most likely.
>
> The blunt hammer debugging technique is to look at the address being put
> out on the bus; you'll need to look at BDAL3-12 and BBS7 (sort of an AND
> of all the high address bits, so devices should work on Q16, Q18 and Q22;
> in fact, the manual says that device should look at BBS7, and hot BDA13
> and up). Best to use a 'scope so you can see what the waveforms look like.
> This is slow and painful, but will allow precise, definitive diagnosis.
>
> If the address is good, look also at BDIN. If that's toggling, it's the
> consoles. Otherwise, CPU issue,which we'll delve into once the data
> points definitively.
>
> Noel
>