RE: PDP 11/24 - A Step Backwards
> -Original Message-
> From: cctalk On Behalf Of Noel Chiappa via
> cctalk
> Sent: 03 April 2022 03:41
> To: cctalk@classiccmp.org
> Cc: j...@mercury.lcs.mit.edu
> Subject: RE: PDP 11/24 - A Step Backwards
>
> > It was quite a struggle to separate those nylon connectors, is there
a
> > trick to it?
>
> You mean the Mate-n-lok's? Not really; just make sure the catch is
released.
>
> What did you do about DCLO? (Oh, I think I see the answer, below looks
> like you're relying on the pullup on K3...)
>
> > When I powered on, the CPU LEDs did not light up.
>
> Two of them ('0' and '1') are just bits in a special register, and thus
only do
> anything when the bootstrap code fondles them. When you get ODT
> running, you can amuse yourself turning them off and on manually! :-)
>
> > I did notice that the CLK LED flickered on briefly when I powered it
> > off.
>
> Interesting. Not sure exactly what we can deduce from that; but
interesting.
>
> > I put a scope probe on TP1 (p152 of the PDF), there was no activity,
> > the pin remained high.
>
> Yes; the signal there (MCLK H) is more or less the same one that drives
the
> 'CLK' LED (MCLK L); so no big surprise there. Still, that reduces the
problem
> space to a small part of K1.
>
> > The problem now is that I expect I will need to probe various pins
to
> > find out what is going on. But I don't have a Unibus extender and I
am
> > reluctant to remove the backplane. From what I can tell in the
> > Technical Manual you can't install the CPU in other slots
>
> Basically right; the backplane and CPU are designed to have it go in slot
1.
> It _might_ work in other MUD slots, with some loss of functionality (e.g.
> slot 2 doesn't have grant lines; MUD slots won't have the 'UNIBUS Map
board
> pesent' line - pin FE1, on K11, UB TO MA VIA UBMAP) but I wouldn't want to
> chance it, there might be a clash.
>
> > I am forced to tack solder probe wires to the chips, which works but
is
> > time consuming. Any other ways?
>
> Sorry, I don't have any experience to suggest any; too well supplied with
> extender cards, so I've never had to resort to alternatives!
>
>
> > I *think* I have found something. There could be a fault in E52
(sheet
> > K6, p157 of the PDF). While K6 BUS DCLO L is +5V, I am measuring K6
BUF
> > DCLO H at an average 1.64V
>
> Yeah, that's wrong. E52 is bad, and will have to be replaced.
>
> (From the +5V on BUS DCLO, I guess you're relying on the pullup? DCLO on
> the UNIBUS, with the resistor network on the M9302, should be about 3.5V -
> but now I'm confused, even with the P/S connector unplugged, it should
still
> be 3.5V or so. Oh well, it's late, the brain is powering down... :-)
Sorry if I wasn't clear, I did plug the connector back in, so that DCLO and
LTC are connected, I just removed the ACLO pin.
>
> The 'unused' gate in E52 is the one that the added wires from the ACLO ECO
> went to; I wonder if it was damaged by the -15V, somehow?
Oh, I forgot about that! That would seem highly likely.
>
> > logical 0 output should be 0.4V max
>
> Which is what you should be seeing.
>
> > I also measured K6 BUF DCLO L to be always low, suggesting it thinks
> > the K6 BUF DCLO H is a logical 1.
>
> Yup; and that definitely explains why the clock isn't running - BUF DCLO L
is
> clearing E41 on K1.
>
> Anyway, you'll have to replace E52 (which will be a bit of a pain, with
the 3
> ECO eires tacked to it). The DS8641 is an old chip, no longer in
production, so
> the usual suppliers may not have it, but there are some on eBait.
I didn't look for replacements last night. Is there a modern equivalent? My
initial searches show there isn't but I may have found a source of NOS.
Worried about replacing it with the ECO wires as you say, I always marvel at
how neatly those wires are done, I wish I knew how to do such a neat job.
Thanks
Rob
>
> Noel
RE: PDP 11/24 - A Step Backwards
> It was quite a struggle to separate those nylon connectors, is there a
> trick to it?
You mean the Mate-n-lok's? Not really; just make sure the catch is released.
What did you do about DCLO? (Oh, I think I see the answer, below looks
like you're relying on the pullup on K3...)
> When I powered on, the CPU LEDs did not light up.
Two of them ('0' and '1') are just bits in a special register, and thus only
do anything when the bootstrap code fondles them. When you get ODT running,
you can amuse yourself turning them off and on manually! :-)
> I did notice that the CLK LED flickered on briefly when I powered it
> off.
Interesting. Not sure exactly what we can deduce from that; but interesting.
> I put a scope probe on TP1 (p152 of the PDF), there was no activity,
> the pin remained high.
Yes; the signal there (MCLK H) is more or less the same one that drives the
'CLK' LED (MCLK L); so no big surprise there. Still, that reduces the problem
space to a small part of K1.
> The problem now is that I expect I will need to probe various pins to
> find out what is going on. But I don't have a Unibus extender and I am
> reluctant to remove the backplane. From what I can tell in the
> Technical Manual you can't install the CPU in other slots
Basically right; the backplane and CPU are designed to have it go in slot 1.
It _might_ work in other MUD slots, with some loss of functionality (e.g.
slot 2 doesn't have grant lines; MUD slots won't have the 'UNIBUS Map board
pesent' line - pin FE1, on K11, UB TO MA VIA UBMAP) but I wouldn't want to
chance it, there might be a clash.
> I am forced to tack solder probe wires to the chips, which works but is
> time consuming. Any other ways?
Sorry, I don't have any experience to suggest any; too well supplied with
extender cards, so I've never had to resort to alternatives!
> I *think* I have found something. There could be a fault in E52 (sheet
> K6, p157 of the PDF). While K6 BUS DCLO L is +5V, I am measuring K6 BUF
> DCLO H at an average 1.64V
Yeah, that's wrong. E52 is bad, and will have to be replaced.
(From the +5V on BUS DCLO, I guess you're relying on the pullup? DCLO on the
UNIBUS, with the resistor network on the M9302, should be about 3.5V - but now
I'm confused, even with the P/S connector unplugged, it should still be 3.5V
or so. Oh well, it's late, the brain is powering down... :-)
The 'unused' gate in E52 is the one that the added wires from the ACLO ECO went
to;
I wonder if it was damaged by the -15V, somehow?
> logical 0 output should be 0.4V max
Which is what you should be seeing.
> I also measured K6 BUF DCLO L to be always low, suggesting it thinks
> the K6 BUF DCLO H is a logical 1.
Yup; and that definitely explains why the clock isn't running - BUF DCLO L is
clearing E41 on K1.
Anyway, you'll have to replace E52 (which will be a bit of a pain, with the 3
ECO eires tacked to it). The DS8641 is an old chip, no longer in production, so
the usual suppliers may not have it, but there are some on eBait.
Noel
Re: Core memory
You don’t strictly need an inhibit wire to write cores. You can write the core with just the addressing lines. The inhibit wire is just there to simplify the addressing electronics logic in early core memory, so you don’t need to have per core control of the current in the address lines when writing. You just do it wholesale: scan all address lines with current in one direction during reads, scan once again with current in the other direction during writes, with inhibit when needed. You could certainly use the sense wire as an inhibit. But that gets impractical with a diagonal weave, because you’d have to know in which direction the inhibit works and reverse the inhibit current accordingly. And it’s different for each core depending on the direction the sense wire crosses the core. So it defeats the purpose of simplifying the control logic with an inhibit wire. Therefore I don’t think that scheme is used. In practice, 3 wire systems that use the same wire for inhibit and sense (like some IBM core planes) have the sense go along the address lines, and use a half plane column shift to provide cancellation of the unwanted signal induced from the address line it is running along. We demonstrate such a 3 wire plane here: https://youtu.be/AwsInQLmjXc . So in your plane, the sense wire is likely just used for reads, and the writes are done uniquely with the address wires, like I demonstrate here: https://youtu.be/7ozNMgx7WtQ Marc > On Apr 1, 2022, at 2:14 PM, Brent Hilpert via cctalk > wrote: > > On 2022-Apr-01, at 11:51 AM, Paul Koning wrote: On Apr 1, 2022, at 2:38 PM, Brent Hilpert via cctalk wrote: On 2022-Apr-01, at 6:02 AM, Paul Koning via cctalk wrote: >>> When I looked at that ebay listing of "glass memory" it pointed me to another item,https://www.ebay.com/itm/265623663142 -- described as "core rope memory". Obviously it isn't -- it's conventional core RAM. Interestingly enough, it seems to be three-wire memory (no inhibit line that I can see). It looks to be in decent shape. No manufacturer marks, and "GC-6" doesn't ring any bells. >>> >>> Well, it would still work for 1-bit-wide words, so to speak. One wonders >>> what the application was. >> >> I wonder if the sense wire was used as inhibit during write cycles -- that >> seems doable. It would make the core plane simpler at the expense of more >> complex electronics. With that approach, you have regular memory, not >> limited to 1 bit words. > > Maybe I'm being overly cautious, but offhand I'm initially skeptical without > doing the math or some good vector diagrams, or seeing an example. With the > diagonal wire you're changing the current/magnetic sum vectors in direction > and magnitude. The question is coming up with a current that reliably > performs the cancellation function on the selected core of a bit-array while > reliably *not* selecting another core, while accounting for all the variation > tolerances in the array. > > While there's probably some value by which it would work in theory, I wonder > whether the diagonal wire would narrow the operating margins. From some stuff > I've seen, the hysteresis curves for cores weren't spectacularly square. With > the usual 3D-3wire scheme of a close parallel inhibit wire you have > 'cancellation by simplicity', you maximise the difference (cancellation) > influence on one wire while minimising it's sum influence on the other. > > A related issue is the normal diagonal sense stringing (which this looks to > have) has the wire entering the cores from both directions relative to the > address wires, which is why sense amplifiers respond to pulses of both > polarity. If this diagonal wire is put to use as an inhibit wire, some logic > is needed to decide the direction of the inhibit current from the address, > though that may not be very difficult. > > Some history of the 3-wire development might tell, whether inhibit was first > applied to a diagonal sense stringing or whether sense was first applied to > an adapted parallel-inhibit stringing. The real benefit of the 3-wire > development was getting rid of the diagonal stringing for manufacturing ease. > > >>> There are a couple of Soviet core-rope memories up right now: >>>https://www.ebay.com/itm/294558261336 >>>https://www.ebay.com/itm/294851032351 >> >> Neat looking stuff. It doesn't look like core rope memory in the sense of >> the AGC ROM, nor in the sense of the Electrologica X1. It looks more like >> the transformer memory used in Wang calculators that you documented in your >> core ROM paper. > > Yes, (I was, perhaps lazily, slipping into the habit of referring to both > forms (of woven-wire ROM) as rope).
RE: PDP 11/24 - A Step Backwards
> -Original Message- > From: cctalk On Behalf Of Rob Jarratt via > cctalk > Sent: 02 April 2022 11:58 > To: 'Noel Chiappa' ; 'General Discussion: On-Topic > and Off-Topic Posts' > Subject: RE: PDP 11/24 - A Step Backwards > > > > > Disconnect the bad ACLO, power it on, and see if the CLK LED comes on. > > if not, then we'll have to work out why not. > > This is my plan for later today. OK, so I disconnected ACLO only. It was quite a struggle to separate those nylon connectors, is there a trick to it? In doing so I spotted two backplane wire wrap pins touching and a couple of others that were quite close too, so I separated them and inspected all the backplane pins. I didn't see any other ones touching. When I powered on, the CPU LEDs did not light up. Some random characters appeared on the console, but probably just a bit of noise maybe? However, I did notice that the CLK LED flickered on briefly when I powered it off. I put a scope probe on TP1 (p152 of the PDF), there was no activity, the pin remained high. The problem now is that I expect I will need to probe various pins to find out what is going on. But I don't have a Unibus extender and I am reluctant to remove the backplane. From what I can tell in the Technical Manual you can't install the CPU in other slots to make room for attaching probes either. I am forced to tack solder probe wires to the chips, which works but is time consuming. Any other ways? Using tack soldered wires, I have traced back and I *think* I have found something. There could be a fault in E52 (sheet K6, p157 of the PDF). While K6 BUS DCLO L is +5V, I am measuring K6 BUF DCLO H at an average 1.64V with 50us spikes at 2.08V. According to a NatSemi datasheet for the DS8641 (http://pdf.datasheetcatalog.com/datasheet/nationalsemiconductor/DS005806.PD F) the logical 0 output should be 0.4V max and the logical 1 output should be 2.4V min. I also measured K6 BUF DCLO L to be always low, suggesting it thinks the K6 BUF DCLO H is a logical 1. This seems to suggest that E52 may be faulty. Trace here: https://rjarratt.files.wordpress.com/2022/04/e52-dclo-signal.jpg. Regards Rob > > > > > Noel
Re: Glass memory?
On 2022-04-02 4:27 a.m., Liam Proven via cctalk wrote: On Sat, 2 Apr 2022 at 00:34, Bill Gunshannon via cctalk wrote: And, as you say, an Arduino or a Pi that fits in my pocket is orders of magnitude more powerful and costs pocket money. The comparisons of size, power, storage, cost, power usage, heat output and so on are often made. What is less often observed are the facts that a machine that takes multiple trailers can be repaired with spare parts. Anything made from ICs basically can't, except by replacing the ICs. What if you can't make ICs any more? Or rather, what level of IC fabrication would it be possible to construct from scratch? And if the war were long (sticking to the military context) or the conditions extreme (say, radical rapid global warming and a retreat to polar regions) and so all the factories and infrastructure were lost or had to be abandoned... I'm thinking of the current global chip shortages, and the floods in Thailand that screwed up supplies of hard disks a decade ago. What could be constructed from scratch, given copious amounts of scrap and waste for source materials? And aside from the hardware: Yes, modern computers have vast amounts of storage and power, but we use them all on OSes and apps that need millions of lines of code in dozens of languages, and gigabytes of storage. As a result, although they are vastly quicker, latency is arguably _worse_ now: https://danluu.com/input-lag/ What if... we had to reconstruct entire OSes and software stacks from scratch? Maybe because the authors were dead. Maybe because the computers they needed didn't work any more and couldn't be repaired. Maybe because we had to make new computers and they were smaller and slower. How much could be rebuilt? What could be learned from the mistakes of old? I recently wrote these pieces, which were fun to research: https://www.theregister.com/2022/03/29/non_c_operating_systems/ https://www.theregister.com/2022/03/31/serenityos/ There are so many UNIX-like kernels in C on Github I couldn't count them all. In the many dozens, maybe hundreds. This is doable. But there are fewer in C++. Fewer still in Rust or Go. Very few in anything Wirthian or with garbage-collection. Of course, sometimes I still miss the old days and old ways. :-) But then, isn't that why we are all here? Well indeed! http://collapseos.org/ is relevant to this. But is an 8-bit the biggest we could realistically construct if all the IC fabs were destroyed? Computers need memory, not ALU's. 4K static and 16k dynamic were the last chips that seem to developed by hand. The late 1970's would be a realistic goal to rebuild a civilization to. Looking around even 1985 err 1955 is a good time frame if you want to include time travel,flying cars and hover-boards. :) Ben. PS: Hurry up and drop them nukes, get rid of the X86 forever. :) PPS: Did any computer implement multilevel/trinary bolean logic ( true false unknown )
RE: PDP 11/24 - A Step Backwards
Finally found time to get to this one... > From: Rob Jarratt > However, there is a puzzle. On the CPU I found that the track from the > pull up resistor to E70 has been cut. I don't know about the "pull up resistor" part, but I have several KDF11-U's, and _all_ of them have the trace on the bottom of the card connected to pin 1 of E70 cut, in the exact same place (about 1/8" from the pin). This suggests that it's not a local mod (as you suggest below), but an 'official' DEC ECO. > This would suggest that E70 pin 2 is floating, which I think means that > K2 BUF ACLO H is also floating The input (pin 1) will be floating, but not the output (pin 2); TTL doesn't work that way, I think. I may have this wrong, but I think open TTL inputs float high, so BUF ACLO should be low. I looked, and I don't see any other traces (e.g. on the top side) going to pin 1. So I'm a bit puzzled that DEC allowed that input to float, as open inputs can lead to erratic operaton; they're usually tied high, or to ground. > 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. Me neither; that's an unused (on the prints) driver in the DS8641 (center bottom of the page) - although that gate seems to have been fully wired up (wires to pins 4, 5 and 6) as part of the ECO. There is an ECO list on pg. 167 of the -11/24 prints (2 pages after K14), but I don't see an E52 in it anywhere. The puzzle here, if E70p1 is cut, and the output is low, is why the CPU clock isn't running. The -15V on BUS ACLO shouldn't have taken out any other semiconductors; it's not attached to anything else. (It will have run C6, on the lower right of the card, the wrong way, but i) I think that's a non-polarized item - and 100V rated, per the prints, and ii) I don't think that goes anywhere else, even if it's not.) So what's stopping the clock from running, then? Noel
Re: PDP 11/24 - A Step Backwards
On 4/2/2022 5:49 AM, Noel Chiappa via cctalk wrote: > does [disabling the MCLK counter via DCLO, asserted by the two > E126 monostable chain from ACLO] happen just on power-down, or on > power-up too? I'd need to understand how that two monostable chain > works in both cases, which I currently don't. (I only understand > monostables when pulses trigger them, not edges, which is a big part of > why I don't completely understand it.) So this was bugging me, so I hauled out my TI TTL databook and looked up the LS123. And, if that 'LS123 wasn't made by TI, it could be considered suspect until it has been checked out with a 'scope. I remember, from somewhere back in the day, that not all '123s were created equal, and that TI's were demonstrably better than the others in terms of stability and trustworthiness. I also recall *vaguely* one experience where replacing a '123 made by someone else with a TI one fixed the issue. JRJ
RE: PDP 11/24 - A Step Backwards
> -Original Message- > From: Brent Hilpert > Sent: 31 March 2022 22:48 > To: r...@jarratt.me.uk; General Discussion: On-Topic and Off-Topic Posts > > Subject: 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. Sorry about the wasted time. I think I did say at one point that it was the H7140, but that will be way down the thread somewhere. I will use PDF page numbers in future. > > 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
> and there is some circuitry driving the clear input on the second > 123. Never mind this section. I mis-read the print; the clear input is connected to an _input_ of the flop below (which is also tied high). Noel
RE: PDP 11/24 - A Step Backwards
> > Disconnect the bad ACLO, power it on, and see if the CLK LED comes on. if > not, then we'll have to work out why not. This is my plan for later today. > > Noel
Re: PDP 11/24 - A Step Backwards
> does [disabling the MCLK counter via DCLO, asserted by the two > E126 monostable chain from ACLO] happen just on power-down, or on > power-up too? I'd need to understand how that two monostable chain > works in both cases, which I currently don't. (I only understand > monostables when pulses trigger them, not edges, which is a big part of > why I don't completely understand it.) So this was bugging me, so I hauled out my TI TTL databook and looked up the LS123. According to that, the 123 is triggered by the rising edge on the B (non-inverted) input, when the A (inverted) input is low (which it will be here; it's tied to ground). (Also by the falling edge on A when B is high, which we can ignore.) So I think that chain is probably triggered only on power-down, which will produce a rising edge on P FAIL. (Power-up will produce only a falling edge on P FAIL, once power is up and good.) (Note that the second monostable is triggered, also on B, by the -Q output of the first; i.e. by the 'falling' edge of the first's pulse. But see also at the bottom, below.) So that should happen (if I have correctly understood this, which is not certain, I'm just a software person :-) is that some time after P FAIL goes high - a delay set by the first 123 - the second 123 produces a pulse (of a width set by its RC pair) - which via E52 produces an assertion pulse on DCLO. WTF? (Not that we care in this machine's case, since i) it only happens on power-down, and ii) it's just a pulse, so it's affect on MCLK will be very transient; it can't cause it to stay off. My curiousity has been piqued, is all. :-) The TM does not, after a _thorough_ search (although there are a few mentions of power u/down, but not this), explin why, alas. (The TM for some _other_ -11 CPU, one which contains a similar circuit might, but I'm not _that_ curious! :-) My _guess_ is that the intent is to reset all devices to a good idle state, _before_ power actually goes out. (Don't ask me why it just doesn't use INIT, though!) The potential fly in the ointment of complete understanding is that a 123 can _also_ produce a pulse on a rising edge at the clear input - and there is some circuitry driving the clear input on the second 123. (The clear input on the _first_ 123 seems to be left hanging in space - odd!) It seems to be set off by the mysterious DGP03 signal, generated by the microcode - but the GP table on pg. 4-21 of the TM doesn't contain an entry for '3'? Unless it has a typo - there are two '5' entries. In which case it could be 'Toggle the HALT flip-flop (K6)' (which I don't see on K6, unless it's E78) but yah, pulsing DCLO will probably clear it, wherever it is! This machine is making my head hurt. Disconnect the bad ACLO, power it on, and see if the CLK LED comes on. if not, then we'll have to work out why not. Noel
Re: Glass memory?
On Sat, 2 Apr 2022 at 00:34, Bill Gunshannon via cctalk wrote: > > And, as you say, an Arduino or a Pi that fits in my pocket is orders > of magnitude more powerful and costs pocket money. The comparisons of size, power, storage, cost, power usage, heat output and so on are often made. What is less often observed are the facts that a machine that takes multiple trailers can be repaired with spare parts. Anything made from ICs basically can't, except by replacing the ICs. What if you can't make ICs any more? Or rather, what level of IC fabrication would it be possible to construct from scratch? And if the war were long (sticking to the military context) or the conditions extreme (say, radical rapid global warming and a retreat to polar regions) and so all the factories and infrastructure were lost or had to be abandoned... I'm thinking of the current global chip shortages, and the floods in Thailand that screwed up supplies of hard disks a decade ago. What could be constructed from scratch, given copious amounts of scrap and waste for source materials? And aside from the hardware: Yes, modern computers have vast amounts of storage and power, but we use them all on OSes and apps that need millions of lines of code in dozens of languages, and gigabytes of storage. As a result, although they are vastly quicker, latency is arguably _worse_ now: https://danluu.com/input-lag/ What if... we had to reconstruct entire OSes and software stacks from scratch? Maybe because the authors were dead. Maybe because the computers they needed didn't work any more and couldn't be repaired. Maybe because we had to make new computers and they were smaller and slower. How much could be rebuilt? What could be learned from the mistakes of old? I recently wrote these pieces, which were fun to research: https://www.theregister.com/2022/03/29/non_c_operating_systems/ https://www.theregister.com/2022/03/31/serenityos/ There are so many UNIX-like kernels in C on Github I couldn't count them all. In the many dozens, maybe hundreds. This is doable. But there are fewer in C++. Fewer still in Rust or Go. Very few in anything Wirthian or with garbage-collection. > Of course, sometimes I still miss the old days and old ways. :-) > But then, isn't that why we are all here? Well indeed! http://collapseos.org/ is relevant to this. But is an 8-bit the biggest we could realistically construct if all the IC fabs were destroyed? -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
