RE: PDP 11/24 - A Step Backwards
> From: Tony Duell > A short in FET Q15 on the bias/interface board in the PSU could do it. > The gate of that FET is driven from an LM339 comparator the -ve supply > of which is -15V. Ah; I hadn't even looked at the P/S prints. (Like I said, I'm really weak on analog: for digital, I have the advantages that i) although I'm basically/mostly a software person, the MIT CS department is part of the EE department, and they made sure that all the CS people had a decent grounding in the fundamentals of digital hardware; and ii) in my early years, I was involved in a number of actual hardware projects, including a UNIBUS DMA network interface that tuned into an actual product. So I'm pretty good with a digital circuit diagram, like these CPU prints. But analog stuff is still a mostly-closed book to me! :-) Anyway, I'm happy to let you provide the analysis of the P/S... :-) > From: Rob Jarratt > [Perhaps] something else on the CPU caused Q15 to fail (if indeed it > did). I'd guess 'unlikely' (if Q15 has failed); UNIBUS ACLO is connected, on the CPU card, to only a single gate (on K2), and that 383 ohm pull-up (on K3), and the 1K pF cap there (the purpose of which I still don't understand, unless it's just a smoother). Although I suppose that if that cap failed, shorted, maybe that could have taken out Q15 somehow. > Perhaps I should ... and disconnect ACLO, DCLO and LTC, they are all on > the same connector Now why didn't I think of just un-plugging that whole connector! Du! My only concern would be leaving inputs floating... DCLO, no problem; it has that pull-up on K3. (Ditto for ACLO, if the buffering input gate isn't dead.) LTC, let's see... It's on K6, upper left corner. I'm too lazy to work out what leaving that input floating will do, and, if it has bad consequences, trace out all the places it goes (it should be connected up to cause an interrupt, somewhere), but there's no point; the KW11 has an 'interrupt enable' that has to be set by software before it can do anything; so at the moment it's safe to just ignore it for now, and stay with a focus on getting the main CPU clock running. (LTC is not on the UNIBUS, so there's no pull-up on the M9302 for it the way there is for ACLO & DCLO.) So unplug that connector, and see if E70 (on K2, lower right corner) is OK. (Remember, the pull-up will give it an Ok input with BUS ACLO disconnected.) If yes, great, go check the main CPU clock. If not, time to i) see how far the rot has spread (e.g. have other gates in that package died - not sure what else is in there; not just looking at things connected to the output - on pin 2), and ii) decide how to repair or temporarily bypass. (Ditto for anything else that got taken out.) I'd be tempted to bypass it (since I doubt you stock 8837's - although I do :-) - ACLO handling isn't needed to get the CPU running. Tie BUF (not BUS!) ACLO to ground, I'd say, and we can move on to look at MCLK. > If that works then I think repair ACLO and see if anything on the CPU > is bad or anything else that might cause a short on the ACLO signal of > the bus. Well, your call, but i) working ACLO isn't needed to get the CPU running - and, in particular, to look for other problems that might be preventing it from running, and ii) fixing ACLO isn't guaranteed to make the CPU work. I'd recommend 'keeping the eye on the ball', and focus on the main CPU clock, getting ODT running, etc. The ACLO issue(s) can be cleaned up at your leisure. Noel
Re: PDP 11/24 - A Step Backwards
On 2022-Mar-31, at 12:36 AM, Noel Chiappa via cctalk wrote:
>> From: Tony Duell
>
>> A short in FET Q15 on the bias/interface board in the PSU could do it.
>> The gate of that FET is driven from an LM339 comparator the -ve supply
>> of which is -15V.
>
> Ah; I hadn't even looked at the P/S prints.
>
> (Like I said, I'm really weak on analog: for digital, I have the advantages
> that i) although I'm basically/mostly a software person, the MIT CS
> department is part of the EE department, and they made sure that all the CS
> people had a decent grounding in the fundamentals of digital hardware; and
> ii) in my early years, I was involved in a number of actual hardware
> projects, including a UNIBUS DMA network interface that tuned into an actual
> product. So I'm pretty good with a digital circuit diagram, like these CPU
> prints. But analog stuff is still a mostly-closed book to me! :-)
>
> Anyway, I'm happy to let you provide the analysis of the P/S... :-)
>
>> From: Rob Jarratt
>> [Perhaps] something else on the CPU caused Q15 to fail (if indeed it
>> did).
>
> I'd guess 'unlikely' (if Q15 has failed); UNIBUS ACLO is connected, on the CPU
> card, to only a single gate (on K2), and that 383 ohm pull-up (on K3), and the
> 1K pF cap there (the purpose of which I still don't understand, unless it's
> just a smoother). Although I suppose that if that cap failed, shorted, maybe
> that could have taken out Q15 somehow.
Note: It's Q14 that controls ACLO, not Q15, Q15 is involved in the +5 startup.
Unless there are two versions of the schematic and I'm looking at a different
one than everyone else.
pdfPg.30 of
http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug80.pdf
>> Perhaps I should ... and disconnect ACLO, DCLO and LTC, they are all on
>> the same connector
>
> Now why didn't I think of just un-plugging that whole connector! Du! My
> only concern would be leaving inputs floating...
>
> DCLO, no problem; it has that pull-up on K3. (Ditto for ACLO, if the buffering
> input gate isn't dead.) LTC, let's see... It's on K6, upper left corner. I'm
> too lazy to work out what leaving that input floating will do, and, if it has
> bad consequences, trace out all the places it goes (it should be connected up
> to cause an interrupt, somewhere), but there's no point; the KW11 has an
> 'interrupt enable' that has to be set by software before it can do anything;
> so at the moment it's safe to just ignore it for now, and stay with a focus on
> getting the main CPU clock running. (LTC is not on the UNIBUS, so there's no
> pull-up on the M9302 for it the way there is for ACLO & DCLO.)
>
> So unplug that connector, and see if E70 (on K2, lower right corner) is OK.
> (Remember, the pull-up will give it an Ok input with BUS ACLO disconnected.)
> If yes, great, go check the main CPU clock.
Removing DCLO and ACLO from the PS to the bus may allow the CPU/clock to work.
Or it may not.
DCLO & ACLO behave as power-on-reset signals to the system. If they are allowed
to just float up as the power supply comes up you have no guarantees as to the
end result ('end' meaning the state of things after the power supply has come
up), without doing an analysis of the pertinent logic under their control.
JFETs are being used as the ACLO/DCLO control devices for a reason. In contrast
to bipolars, the normal/no-gate-voltage state of a JFET is Source-Drain
conducting, thus the initial state at power-up of ACLO-L & DCLO-L will be
0V/low-impedance-to-GND. The point is to maintain that state until the power
supply levels are good so the logic can be forced into a known state.
Those three comparators in the H777 are looking at a time-delay ramp generated
by C14 and the constant-current circuit of Q11.
What is supposed to happen:
- everything is initially 0V: V+5, ACLO, DCLO.
- power is switched on. Internal voltage levels begin to rise.
- after some delay, E4 trips first to start the +5 supply.
- after some more delay, E5 trips, de-asserting DCLO (DCLO = High,+V).
- after some more delay, E6 trips, de-asserting ACLO (ACLO = High,+V).
The delays are presumably of some order of mS.
-15V is the expected level from the E6 comparator output if AC is good. A
Gate-Drain short in Q14 would be allowing that out to the bus. JFETs can be
flaky, a failed JFET wouldn't be a big surprise.
So E6.6 = Q14.G = -15V is expected after power-up but an additional concern
would be that a G-D short allowed excessive current from the bus through the E6
comparator output and damaged E6, or if left on too long burned out pull-up
resistors on the CPU or bus terminator. However the LM301 is supposed to have
current limiting so those things may not have been damaged.
The scope could be used to observe what is going on with the +5, DCLO, ACLO
sequencing at power up (with bus pull-ups, but without CPU).
Removing only the ACLO PS-to-bus connection would allow DCLO to still exerc
RE: PDP 11/24 - A Step Backwards
I made some interesting discoveries this evening. See below.
> -Original Message-
> From: cctalk On Behalf Of Brent Hilpert
via
> cctalk
> Sent: 31 March 2022 21:03
> To: General Discussion: On-Topic and Off-Topic Posts
>
> Subject: Re: PDP 11/24 - A Step Backwards
>
> On 2022-Mar-31, at 12:36 AM, Noel Chiappa via cctalk wrote:
> >> From: Tony Duell
> >
> >> A short in FET Q15 on the bias/interface board in the PSU could do it.
> >> The gate of that FET is driven from an LM339 comparator the -ve
> >> supply of which is -15V.
> >
> > Ah; I hadn't even looked at the P/S prints.
> >
> > (Like I said, I'm really weak on analog: for digital, I have the
> > advantages that i) although I'm basically/mostly a software person,
> > the MIT CS department is part of the EE department, and they made sure
> > that all the CS people had a decent grounding in the fundamentals of
> > digital hardware; and
> > ii) in my early years, I was involved in a number of actual hardware
> > projects, including a UNIBUS DMA network interface that tuned into an
> > actual product. So I'm pretty good with a digital circuit diagram,
> > like these CPU prints. But analog stuff is still a mostly-closed book
> > to me! :-)
> >
> > Anyway, I'm happy to let you provide the analysis of the P/S... :-)
> >
> >> From: Rob Jarratt
> >> [Perhaps] something else on the CPU caused Q15 to fail (if indeed it
> >> did).
> >
> > I'd guess 'unlikely' (if Q15 has failed); UNIBUS ACLO is connected, on
> > the CPU card, to only a single gate (on K2), and that 383 ohm pull-up
> > (on K3), and the 1K pF cap there (the purpose of which I still don't
> > understand, unless it's just a smoother). Although I suppose that if
> > that cap failed, shorted, maybe that could have taken out Q15 somehow.
>
> Note: It's Q14 that controls ACLO, not Q15, Q15 is involved in the +5
startup.
> Unless there are two versions of the schematic and I'm looking at a
different
> one than everyone else.
>
> pdfPg.30 of
> http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug8
> 0.pdf
>
Thanks for pointing that out, I had not noticed the other line going down to
Q13 and Q14.
>
> >> Perhaps I should ... and disconnect ACLO, DCLO and LTC, they are all
> >> on the same connector
> >
> > Now why didn't I think of just un-plugging that whole connector!
> > Du! My only concern would be leaving inputs floating...
> >
> > DCLO, no problem; it has that pull-up on K3. (Ditto for ACLO, if the
> > buffering input gate isn't dead.) LTC, let's see... It's on K6, upper
> > left corner. I'm too lazy to work out what leaving that input floating
> > will do, and, if it has bad consequences, trace out all the places it
> > goes (it should be connected up to cause an interrupt, somewhere), but
> > there's no point; the KW11 has an 'interrupt enable' that has to be
> > set by software before it can do anything; so at the moment it's safe
> > to just ignore it for now, and stay with a focus on getting the main
> > CPU clock running. (LTC is not on the UNIBUS, so there's no pull-up on
> > the M9302 for it the way there is for ACLO & DCLO.)
> >
> > So unplug that connector, and see if E70 (on K2, lower right corner) is
OK.
> > (Remember, the pull-up will give it an Ok input with BUS ACLO
> > disconnected.) If yes, great, go check the main CPU clock.
>
> Removing DCLO and ACLO from the PS to the bus may allow the CPU/clock to
> work. Or it may not.
Well I can tell you it didn't, disconnecting those connectors left the CPU
still not doing anything. However, there is a puzzle. On the CPU I found
that the track from the pull up resistor to E70 has been cut. This would
suggest that E70 pin 2 is floating, which I think means that K2 BUF ACLO H
is also floating (I haven't put a probe on it as yet). But as the cut is
deliberate, there must be a reason. The CPU did work for a while when I
first got the machine. K2 BUS ACLO L however has been patched to E52 pin 4,
which is the output of a gate on sheet K6. Can't say I understand why.
However, for whatever reason it would seem that perhaps the ACLO signal from
the PSU has always been considered bad?
>
> DCLO & ACLO behave as power-on-reset signals to the system. If they are
> allowed to just float up as the power supply comes up you have no
> guarantees as to the end result ('end' meaning the state of things after
the
> power supply has come up), without doing an analysis of the pertinent
logic
> under their control.
>
> JFETs are being used as the ACLO/DCLO control devices for a reason. In
> contrast to bipolars, the normal/no-gate-voltage state of a JFET is
Source-
> Drain conducting, thus the initial state at power-up of ACLO-L & DCLO-L
will
> be 0V/low-impedance-to-GND. The point is to maintain that state until the
> power supply levels are good so the logic can be forced into a known
state.
>
> Those three comparators in the H777 are looking at a time-delay ramp
Is that a typo? This is the H7140 not the H777.
> gener
Re: Loss of Museum in Ukraine
On 3/29/22 10:51, Brielle via cctalk wrote: Yes, saw an article that said he was fine. Not sure if there’s been any updates since that article though given how things have escalated… I exchanged email with Dmitry Cherepanov this morning. He is understandably heartbroken, but he and his family are safe, at least for the time being. -Dave -- Dave McGuire, AK4HZ New Kensington, PA
Re: PDP 11/24 - A Step Backwards
On 2022-Mar-31, at 2:14 PM, Rob Jarratt wrote: >> Those three comparators in the H777 are looking at a time-delay ramp > > Is that a typo? This is the H7140 not the H777. Groan. When this thread came up I went looking for the 11/24 schematic. I found the document I linked earlier for the 11/24 and found 'the' +5 power supply. So apparently I've been looking at the wrong +5V supply (H777) because the rest of you are indeed looking at a different +5 supply (H7140), both of which are in that same 11/24 pdf document. And indeed, the ACLO control is Q15 in the H7140. I really wish when people are asking for assistance or talking about a schematic or circuit they would include a link/reference to exactly what they are looking at (a) so the reader doesn't have to go scratching around to find it and (b) to avoid effort-wasting screw-ups like this. So yes, you can ignore a lot of the details I described, though some of the principals I mentioned are still valid.
RE: PDP 11/24 - A Step Backwards
> From: Brent Hilpert > So apparently I've been looking at the wrong +5V supply (H777) because > the rest of you are indeed looking at a different +5 supply (H7140), > both of which are in that same 11/24 pdf document That's because the H777 is the P/S for the BA11-L 5-1/4" box, and the H7140 is the P/S for the BA11-A 10-1/2" box - both of which are, quite reasonably, covered in the -11/24 print set. > I really wish when people are asking for assistance or talking about a > schematic or circuit they would include a link/reference to exactly > what they are looking at But everone probably _was_ looking at the same document - just different pages! Alas, DEC doesn't number _all_ the pages with a 'unique within the print set' identifier. Still, one could say 'page xx of the PDF'. Noel
Re: PDP 11/24 - A Step Backwards
On 2022-Mar-31, at 4:12 PM, Noel Chiappa wrote: >> From: Brent Hilpert > >> So apparently I've been looking at the wrong +5V supply (H777) because >> the rest of you are indeed looking at a different +5 supply (H7140), >> both of which are in that same 11/24 pdf document > > That's because the H777 is the P/S for the BA11-L 5-1/4" box, and the H7140 > is the P/S for the BA11-A 10-1/2" box - both of which are, quite reasonably, > covered in the -11/24 print set. > >> I really wish when people are asking for assistance or talking about a >> schematic or circuit they would include a link/reference to exactly >> what they are looking at > > But everone probably _was_ looking at the same document - just different > pages! Alas, DEC doesn't number _all_ the pages with a 'unique within the > print set' identifier. > Still, one could say 'page xx of the PDF'. Which is what I do in these sorts of discussions, at least if it has not been specified previously, and especially when dealing with larger docs. E.g. from my previous messages in this thread: ref: pdfPg.152,etc of http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug80.pdf pdfPg.30 of http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug80.pdf (The latter being the page for the H777 I was mistakenly looking at.) Makes it easier for a recipient, everyone following, and yourself if you have to go back to it in the course of subsequent discussion.
RE: PDP 11/24 - A Step Backwards
> From: Brent Hilpert
> DCLO & ACLO behave as power-on-reset signals to the system.
Minor nit: actually, I think it's DCLO which performs that function in a lot
of places; see e.g. the latches on pg. K2 (pg. 153 of the PDF) and K7. (INIT,
usually in buffered form, is used more widely for this function, but I doubly
digress in that observation.)
As I explained, ACLO is only used to trigger a 'power-failing' interrupt; CPU
operation is otherwise un-affected by ACLO (so the CPU can get ready). DEC P/S's
carefully sequence ACLO and DCLO such that on power-down, ACLO is asserted
first (to allow the CPU to get ready); on power-up, DCLO is de-asserted first
(the later de-assertion of ACLO is the signal for the CPU to start running).
However, you make a good point with:
> If they are allowed to just float up as the power supply comes up you
> have no guarantees as to the end result ('end' meaning the state of
> things after the power supply has come up)
DEC specs state that DC power has to be up and stable 5 usec before DCLO can
be de-asserted ("pdp bus handbook", pg 53). This is precisly so that
everything is in a known state when operation commences.
So I guess I'll go back to my original suggestion: disconnect the ACLO from
the P/S (with its bogus -15V), leaving DCLO, so that it can properly set
everything to a known state on power-on, and then you can see see if E70 has
been fried, or is still working.
> Manually connecting/disconnecting bus-ACLO to GND after power-up will
> ... disable the clock.
I can't see anything in the clock circuitry on pg. K1 (pg. 152 of the PDF),
where all the clocks are generated, that looks at ACLO, or its inverted form
POWER OK, or its latched form, PFAIL (both generated in the bottom RH corner
of K2)? Did I miss something? All I can see is DCLO.
I'm too burned out right now to check for uses of ACLO/POWER-OK/PFAIL, to see
definitively what it does do; tomorrow.
Noel
Re: PDP 11/24 - A Step Backwards
On Fri, Apr 1, 2022 at 12:13 AM Noel Chiappa via cctalk wrote: > > I really wish when people are asking for assistance or talking about a > > schematic or circuit they would include a link/reference to exactly > > what they are looking at > > But everone probably _was_ looking at the same document - just different Actually I wasn't. I was working from the 11/44 printset (I recognised the power supply as being the same number) -- on paper. And I am not going to start counting pages. However I did say 'bias/interface board' which I am pretty sure is not a part of the H777 PSU. -tony
Glass memory?
Hey all, found this on eBay: https://www.ebay.com/itm/Corning-Glass-memory-/125087612899 I can't find any info on it - was it some kind of delay-line or magnetic laminate stack? Interesting!
Re: Glass memory?
On 2022-Mar-31, at 8:05 PM, Anders Nelson via cctech wrote: > Hey all, found this on eBay: > > https://www.ebay.com/itm/Corning-Glass-memory-/125087612899 > > I can't find any info on it - was it some kind of delay-line or magnetic > laminate stack? > > Interesting! Very interesting - there were glass/quartz delay lines used in TV but never seen such before for digital. So first guess was it's a SAW device (Surface Acoustic Wave) delay line, but wondered how the path would be long enough for delays needed (path too short for waves too fast). Second guess then could be a quartz internal reflection delay line. See pdfPg.9: https://www.pearl-hifi.com/06_Lit_Archive/02_PEARL_Arch/Vol_16/Sec_53/Philips_Tech_Review/PTechReview-25-1963_64-234.pdf The period is right, those Sylvania ICs in the unit place it in mid-late 60s. I've analysed a couple of magneto-strictive wire acoustic delay lines so have some feel for properties/numbers there, but don't know how glass/quartz compares.
RE: Glass memory?
Here is some pretty good information. https://archive.org/details/TNM_Glass_computer_memories_-_Corning_Electronics_20171206_0185 Mark -Original Message- From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Brent Hilpert via cctalk Sent: Thursday, March 31, 2022 11:53 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Glass memory? On 2022-Mar-31, at 8:05 PM, Anders Nelson via cctech wrote: > Hey all, found this on eBay: > > https://www.ebay.com/itm/Corning-Glass-memory-/125087612899 > > I can't find any info on it - was it some kind of delay-line or magnetic > laminate stack? > > Interesting! Very interesting - there were glass/quartz delay lines used in TV but never seen such before for digital. So first guess was it's a SAW device (Surface Acoustic Wave) delay line, but wondered how the path would be long enough for delays needed (path too short for waves too fast). Second guess then could be a quartz internal reflection delay line. See pdfPg.9: https://www.pearl-hifi.com/06_Lit_Archive/02_PEARL_Arch/Vol_16/Sec_53/Philips_Tech_Review/PTechReview-25-1963_64-234.pdf The period is right, those Sylvania ICs in the unit place it in mid-late 60s. I've analysed a couple of magneto-strictive wire acoustic delay lines so have some feel for properties/numbers there, but don't know how glass/quartz compares.
