[cctalk] Re: Stuff to go or it's off to the dumpster
> From: Chris Zach > So these go *into* RK06 or 07 drives? Yes; per the "Field Guide to UNIBUS and QBUS Modules". Also: https://gunkies.org/wiki/RK611_disk_controller reveals that the RK611 contains "five hex cards" (listed there). Noel
Re: UNIBUS powoer on/off spec
> the later "pdp11 bus hanbook" (which, as mentioned, does not seem to be > online yet, alas) Arck, I'm a moron; Paul has pointed out to me that this is, in fact, online at Bitsavers: http://www.bitsavers.org/pdf/dec/pdp11/handbooks/PDP11_BusHandbook1979.pdf It didn't show up in a couple of pages of results in a Web search for it, though. I have noticed that things on Bitsavers often don't show up high up in Web search results, unless you add 'bitsavers' to the search term. I have been told that at one point Google was 'downgrading' results that used plain HTTP, instead of HTTPS, because they were trying to push people to switch to HTTPS (this was when everyone was hyperventilating over the Snowden revelations). Given the near-ubiquitous use of HTTPS these days, I'd have thought that piece of 'information credit engineering' by our tech overlords was past its 'sell by' date, and now serves primarily to block people from finding the material they are looking for (as here). Noel
Re: UNIBUS powoer on/off spec
> From: Paul Koning > You might give a precise source citation on that page. Done: https://gunkies.org/w/index.php?title=UNIBUS_Initialization=6842=25463=25451 Don't complain to me if the publication data is skimpy; that's all that's in it! (I mean, we all know that DEC is in Maynard, but the book doesn't say it...) Noel
UNIBUS powoer on/off spec
So, I looked at the early editions of the "pdp11 peripherals hanbook", which have good, detailed discussions of UNIBUS operations (at the back; chapter 5, "UNIBUS Theory and Operation", in the 1976 edition), but in contrast to the level of detail given for master/slave operations, and bus requests and interrupts, the level of detail on power up/down is very low, especially compared to that in the later "pdp11 bus hanbook" (which, as mentioned, does not seem to be online yet, alas). So, I have transcribed that section, and posted it: https://gunkies.org/wiki/UNIBUS_Initialization I have yet to scan and post the associated timing diagrams (which are useful, but not critical); the desktop that runs my scanner is down at the moment, alas. (If anyone who has a copy would like to volunteer to scan them, that would be great.) Noel
RE: PDP 11/24 - A Step Backwards
> From: "Rob Jarratt" > I did plug the connector back in, so that DCLO and > LTC are connected, I just removed the ACLO pin. Ah, OK, good. Pulling the pins from those Mate-n-Loc shells without the right tool is tricky; glad you did it, because as Brent Hilpert pointed out, having a working DCLO is important, to reset everything to a known state on power-on. > I didn't look for replacements last night. Is there a modern > equivalent? Not that I know of. Even if you found something with the same pin-out, supposedly DEC selected ones that were 'good enough'. I've never had an issue with NOS ones that I bought from vendors, though. > I may have found a source of NOS. Great; get several, they're a useful chip to have around; the QBUS uses them, as well as the UNIBUS. If the same place has DS8640's (the receiver), save on shipping (and ordering delays) and get a couple of those too. I say that because depending on what else you had plugged into the UNIBUS post ACLO failure, the -15V may have damaged them too. The M9312 (not sure if you had one of those, but the -11/24 manual says it's common in them) uses ACLO (via a DS8640). The KY24 seems not to (as far as I can tell from a quick look - negative results from a quick print scan aren't 100.00% reliable, whereas positive ones are), oddly enough. In EUB memory (not sure which you have), the MS11-L and MS11M MS11-P don't seem to, whereas the MS11-P _drives_ ACLO (through an 8881) - probably to prevent CPU startup until the ECC is cleared). Etc, etc. > I always marvel at how neatly those wires are done, I wish I knew how > to do such a neat job. The same way the old joke says one gets to Carnegie Hall, I expect! :-) (I wonder what the UK equivalent of the Carnegie is - the Royal Albert, probably?) Noel
RE: PDP 11/24 - A Step Backwards
> 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? So, I checked, and the wire that goes from the plated-through hole next to the etch cut on E70p1 winds up at E52p4 (the bus line on that transceiver), thereby connecting the latter directly to UNIBUS ACLO (on pin BF1). So that's almost certainly what caused other gate(s) in E52 to fail. I think I have managed to trace where all the other two wires to that 'new' gate in E52 went to/from, to see exactly what the ECO is. Given that E52 is a transceiver, it was likely substituted for E70 so that the KDF11-U could also _drive_ BUS ACLO. I discovered that E52p5 (the new transceiver's input) is connected to E73p13 (an DS8640 quad NOR used as a bus reciver); that's in the upper left corner of K2. It's BUS PB L NOR BUS PA H - i.e. a parity error has been detected in memory - so it apparently then power-fails the system! The incoming BUF ACLO (E52p6) goes to a PTH next to E70p8. On the bottom, there's a trace from that PTH that goes to E66p13 - which is the inverter shown on K2 which converts BUF ACLO H to POWER OK H. So that probably the answer to my plaint about E70p1 being left floating: perhaps theres an etch cut somewhere that disconnected E66p13 from E70p2, so the former can now be driven by E52p6. I can't see one, but there's a trace from that latter PTH that dives under E70, and I can't see it well, but it looks like it goes to E70p2. It would be interesting to know what they did about the E70p2 -> E66p13 connection. 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: 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
> 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
> 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: PDP 11/24 - A Step Backwards
> From: Brent Hilpert >> 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). > a) "ACLO is only used to trigger a 'power-failing' interrupt" > b) "ACLO is the signal for the CPU to start running" > Only a, or a & b? Sorry, I tried to write only 10 words, when I should have just bitten the bullet and written 40. There are two different circumstances: i) AC power coming on, and ii) AC power going off. (Sorry if you already know this next, but I'm not skipping anything any more: DEC paid careful attention to both, as the PDP-11's were always intended to be able to deal well with un-attended operation over an un-expected power outage. So they had to shut down in an orderly way on ii), and start up in an orderly way on i). Having the operator press a 'reset' button after power-on was not an option! Of course, the software had to be written to handle it all, and not all of it did so; e.g. UNIX V6 didn't deal well with either, whereas RSTS-11 would go through an outage and automagically pick up exactly where it was when power went down.) So when I said "ACLO is only used to trigger a 'power-failing' interrupt", the un-stated circumstance was 'when AC power goes off'. The bit about "de-assertion of ACLO [on power-up] is the signal for the CPU to start running" is something I hadn't known, but just picked up (it's not anything I ever had to pay attention to before) from reading the "Initialization" section in the "pdp11 bus handbook" - which is not (alas) online. (Maybe I should scan, OCR and port that section; it's fairly short.) (There _is_ a "pdp-11 UNIBUS Design Description" document online: http://www.bitsavers.org/pdf/dec/unibus/UnibusSpec1979.pdf but alas it doesn't have anything like the detail given in the "pdp11 bus handbook". 2.5 there, "Initialization Section", has some text about ACLO, DCLO and INIT (which is generated by the CPU, not the P/S), but not much.) Here's what the "pdp11 bus handbook" says (pg. 54): "When [the processor] senses the negation of ACLO, [which happens after the negation of DCLO, which itself happens "5 useconds after DC power is within specifications" - i.e. plenty of time for all logic to reset itself to a known state, after good power is available to it all] the processor starts its power-up sequence." How that happens in the -11/24 I'm not sure; the -11/24 TM doesn't cover it, and the Fonz, which we don't have documentation on, will be involved. > Now these things may well not be a problem here; I'm just looking for > potential failure points because we're looking for an unknown fault by > isolating things, and it's best done without introducing new potential > problems, or at least being aware of the potential. Makes sense. > ACLO exercises influence over DCLO and hence the CPU clock via those > those monostables (we both) mentioned earlier. Right, I had forgotten about those - it was late, and my brain was shutting down as I was tired. > ACLO -edge: > ==> inverted (E70.2/K2) to +edge > ==> triggers FF (E67/K2_PFAIL) to latch high > ==> triggers MonoFF (E126/K6_AC_TIM) > ==> triggers MonoFF (E126.10-5/K6) > ==> asserting K6_BUF_DCLO_L for some period It's not clear to me what the _point_ of that all is; I had previously guessed that "there's a delay between the PFAIL H input .. and _the CPU_'s assertion of DCLO - i.e. if the P/S goes bonkers and indicates ACLO, and doesn't promptly (after a suitable short delay to allow for power-fail action) follow it with DCLO, as it is _supposed_ to, the CPU will indicate DCLO on its own - and do it on the bus so everbody else will freeze too." That might still be correct - I think that perhaps that path through the monostables only operates on power-down (but maybe I'n wrong there, I don't really understand completely how that all works) - on power-up, PFAIL H is going to be a falling edge - so will the two E126 monostables just ignore that? Alas, the -11/24 TM doesn't cover this, as far as I could find. AC TIM winds up being used on K1, on the monostable at top right, which I think generates a bus INIT pulse, when called for by the microcode (MIB14). No idea why they need AC TIM to clear that monostable. > ==> which disables MCLK counter (E41/K1) Right, but does that 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.) > It may be that it
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
> 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
> 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
> From: Rob Jarratt > I found these two signals and ACLO is low (-15V) 'Good news, bad news'... Bad is that something is seriously wrong there; 'allowed' values are 0v (asserted) and +3V (un-asserted). I'm worried that the -15V will have taken out some of the semiconductors that are 'listening' to ACLO (like E70, page K2 of the CPU prints, lower right corner) - and possibly some of the things that are connected to _them_. Good news is that i) this would definitely cause a problem, so we're closing in, and ii) even better, the machine doesn't actuallly _need_ the ACLO (or DCLO) signal from the P/S to function properly. Just disconect them (which may be a bit tricky; IIRC you've got a BA11-A - but you can pull the pin in the connector shell of the power harness from the backplane, details of that here: https://gunkies.org/wiki/DEC_power_distribution_connectors or, worst case, just cut the yellow wire to pin 4 of the 6-pin connector). At that point the pullups on ACLO (on the M9302 and the CPU - page K3 of the CPU prints - that's odd, there's a pullup to +5V there, but a cap to ground; the M9302 does indeed have the pull-up/down resistor pair on both ACLO and DCLO) should pull ACLO high and the clock should now run (CLK LED on) - unless the -15V killed something. If the machine then runs, it's up to you as to whether you get the P/S repaired so that ACLO work properly - your call. (I wonder how the -15V got to ACLO - I suspect a solder bridge from the prior repair - but knowing the answer is not important to getting the machine running.) > DCLO is high and the DC ON light is illuminated Good. > the CPU doesn't do anything presumably because ACLO is asserted. Yes. As long as the CLK LED is off, the machine will definitely be totally dead. If you can get it on, ODT should run (modulo issues yet to be sorted about the minimal functional machine - I'll post on that in a moment). Noel
Re: Loss of Museum in Ukraine
> From: Murray McCullough > One can only hope that D. Cherepanov can rebuild his museum someday Is _he_ OK? (There are too many who aren't.) Noel
RE: PDP 11/24 - A Step Backwards
> From: Brent Hilpert
> But the LED and CPU clock are not driven directly by that RC oscillator
> - there's a bunch of logic in-between the oscillator and the LED / CPU
> clock.
Oh, sure; it was late (for me; the dog woke me up at AM today :-), and it had
taken me a while to get even that far (find the freakin' thing), so I just
wanted to pass the ball forward and crash!
I saw the "STOP OSC H" signal feeding into the production of "PRE OSC L", but
couldn't fully work out all the things that fed into that - and it now looks
like that's not an important thing anyway, "MCLK H" is the one to look at.
> [RC clock] => K1 OSC H/L
> --> [4-bit counter w parallel load] => K1 MCLK H/L
> --> LED
It seems to me that the LED, being driven directly by MCLK L, should be
flashing at the basic clock rate (i.e. dim to the eye) - so if it's totally
off, MCLK L must not be running. So that's thing absolutely numero uno to
investigate.
> --> [driver] => K1 CHIP CLK H (fonz CPU clock)
Yeah; the Fonz also gets "MCLK L" on pin 19, though - not sure what that's
for. Eh, not important at the moment.
> The 4-bit counter looks to be generating some additional phases
Yeah, section 4.2 "Timimg" of the -11/24 TM talks about all the various
clocks in some detail.
> but it's also controlled by a bunch of other signals. One of those
> signals is K6 BUF DCLO L which can hold the counter in reset, i.e.
> disable the Master/CPU clock (and LED). K6 BUF DCLO L is derived
> on-board from K2 P FAIL H
Huh? BUF DCLO L is just BUS DCLO L, run through that DS8641 bus transceiver.
But yes, because DCLO can stop the clock, checking ACLO and DCLO is priority
numero uno in the debugging process, now. (Contrary to my previous fear, the
CPU might be OK, and it might just be a power supply issue.)
> which is derived from K2 BUS ACLO L
I haven't bothered to check to see where BUF ACLO L (generated on K2) goes,
but I assume it's used in power-fail trapping stuff. (ISTR that PDP-11 PS's
sequence ACLO before DCLO, to allow power-fail trapping, before the machine is
frozen as DC power actually goes low.) Likewise, not important at the moment.
> which is input from BF1-in-funky-hex-box which I presume is a bus
> connector pin.
Yes; the ID ("BF2") is an indicator to that.
> Even if ACLO is good, there's a whack of logic on the CPU board -
> including two monostables - just to get from ACLO to DCLO
The import of those two monostables isn't completely clear to me. However,
notice that the output is fed through the DS8641 bus transceiver to _drive_
BUS DCLO; my _guess_ is that there's a delay between the PFAIL H input (which
comes from BUS ACLO L) and _the CPU_'s assertion of DCLO - i.e. if the P/S
goes bonkers and indicates ACLO, and doesn't promptly (after a suitable short
delay to allow for power-fail action) follow it with DCLO, as it is
_supposed_ to, the CPU will indicate DCLO on its own - and do it on the bus
so everbody else will freeze too.
Anyway, I think we've got as far as we can until ACLO and DCLO are checked.
I'm upgrading the CHWiki KDF11-U page to cover the stuff that's not in the
CPU chapter of the -11/24 TM, like the meaning of those on-board LED's, etc.
Noel
RE: PDP 11/24 - A Step Backwards
> From: "Rob Jarratt" > Thanks for the lengthy reply. Glad to help - or try to. > As an aside I have also been trying to find a fault on a Pro 350 which > uses the same CPU chipset. I have a pinout but no datasheet. There doesn't seem to be as lot on the F-11 set. I looked in the DEC semiconductor handbook, and it's not there - although perhaps it had been dropped by the one I looked at (which was mostly uVAX stuff) as obsolete? If you look in the KDF11-A and KDF11-U Tech Manuals, there is a chapter on the F-11 chip set, as used in those cards, and that's better than nothing - it talks a fair amount about the low level details of how the various chips operate and interact, etc. > I don't think the CPU is working at all. The reason being that there is > absolutely no LED activity. Including an LED that is supposed to indicate > a clock. Looking at the KDF11-U prints, I finally found that LED (it's pretty low level - I was worried that it might be a bit in a register, and driven by software, but it's not, it's actually driven directly by the the CPU's internal clock signal; it's on page K1 of the prints, 'Clock, State Decode', in the very upper left corner). (The source of the CPU's internal clock is just an RC circuit, in the lower middle of that page, and the trim pot that's part of it - along the upper edge of the board - can be adjusted to set the clock speed 'properly', per the note at the back of the prints on the page which lists the configuration switches. The 2MHz crystal along the upper edge drives the baud rate generator.) > Having hopefully eliminated all the power voltages it left me wondering > if there was a fault on the CPU or in the PSU. If ODT isn't running, the problem is almost certainly in one of those two areas. > Having had activity on those LEDs recently it seems most likely that it > will be the PSU, particularly as *something* in there blew up. I'm not so sure. Those boards mostly just want +5V; looking a bit more, the CPU chips do seem to use +12V. The RS232 drivers will use +/-12V. I'm afraid that if i) it used to show activity, but no longer does so, and ii) the main voltages (+5V, +12V) look good, something on the CPU card has failed. But it will take a bit of digging to i) verify that, and ii) identify the fault. > The only signal that I can identify that seems likely to have this kind > of effect is LTC, but I don't know enough about LTC to know if its > absence could cause the CPU board not to work at all, although I see > above that you think it unlikely. I have yet to trace how the LTC signal is used in the KDF11-U, but on the KDF11-A, it not being there is a total NOP. (In fact, in the BA11-N/S type mounting boxes, there's a 'Clock Enable' switch on the front panel which turns the LTC signal off - and the machine runs fine with it off - except for the TOD clock not ticking.) That clock signal - totally different from the main CPU clock - is only used as an input to what is in effect a peripheral. > I had a console attached. There is nothing on the console. When I first > got the machine I did get output on the console. Not a good sign, alas. If you have a scope of some kind, and want to keep poking, I'd recommend that you start by seeing if the clock is running, and move forward from there. The KDF11-U prints are online, as is the KDF11-U Tech Manual. Skim the chapter on the CPU (4, I think), and then grovel around in the prints for a bit. Don't try to totally understand it all, just skim through it, so you know roughly where most things are. Noel
RE: PDP 11/24 - A Step Backwards
> From: Rob Jarratt > today I went back to it to check things a bit more carefully. All the > power outputs of the PSU appear nominal. > ... > Presumably, whatever the part is, it is stopping the CPU working, > because previously the CPU did appear to show some activity, although > of course it could still be a failure on the CPU. I am not sure what > other outputs the CPU might depend on. There is the LTC signal for the > line time clock, but I don't know if its absence would stop the CPU > working. I have not been able to test the LTC signal as yet. > Can anyone suggest what else the CPU might need? Or is it LTC? I'm going to start with some meta-comments, and then add some practical suggestions for how to proceed. Reading this, I'm guessing that you're a software person, right? Not that there's anything wrong with that (_I_'m basically a sofware engineer), but if one is going to collect and run (which inevitably means maintain/repair - it was ever thus, including BITD) vintage computers, you need to have mildly decent hardware skills. Yes, to some degree, one can lay this off on others (as has been done here with the power supply - something I'd do myself, as my analog skills are not very good), but I think developing some decent digital hardware understanding would really help. For instance, take your question about the LTC. To some degree, a complete, entirely accurate answer is dependent on the details of the software (bootstrap and/or OS). However, knowing how the LTC works, what the low-level details are of what the CPU hardware does with it, etc would tell you whether it is a cost-effective (in terms of overall 'getting the hardware working' project) thing to spend time on looking at, to begin with. (Parenthetical observation: I reckon that debugging _any_ issue, hardware _or_ software, is a process of 'what's the _cheapest_ [easiest, quickest, etc] test I can do that will produce the _maximal_ reduction in the area that the bug could be in. Rinse, repeat, until you've tracked the problem to its lair.) (You may discover, once you get the machine mostly working, that the LTC _specifically_ isn't working - at which point you can dive into it in detail. But until then, I'd ignore it. It's a relatively small aount of stuff, and the chance of a problem in there is small. And even if it's broken, the likely effects are small. There are better things to look at - below. Having a clear understanding of the machine's major functional units, and how they interact, would have made that clear.) So, in addition that that overview of the major functional units, you definitely need to know how the QBUS works (read the QBUS chapter in the "Microcomputer Products Handbook" or the "Microcomputer Processors" books). (Yes, I know, the -11/24 is a UNIBUS machine, but the two busses differ only in extremely minor details; if you fully understand one, you can learn the other in half an hour. And the -11/24's CPU is a KDF11 CPU, and uses the microcode ODT 'front panel' of the QBUS CPUs.) Having said that, and starting with the "All the power outputs of the PSU appear nominal" (which rules out a large area), this is the process I'd follow to reduce the area the problem is in as quickly as possible. (And maybe I should transform this into a 'fault analysis of QBUS (and some UNIBUS) PDP-11 systems' on the CHWiki.) You need to see if the CPU is _basically working. Two stages to that: i) is the ODT 'front panel' (in microcode) working, ii) is the CPU basically functional - i.e. can it fetch and execute instructions. Answers to those will greatly reduce the area in which the problem (if there's _only_ one - a possibility one must keep in mind). The first will tell you that i) the CPU is basically functional, executing micro-instructions, etc; ii) that the bus is basically functioning (for master-slave cycles; DMA and interrupts will remain to be checked out); iii) that the console port is working. (Yes, on the KDF11-U, the console is on an internal bus, and so in theory a machine could have the ODT 'front panel' working, _and_ still have a problem with the bus, but depending on the exact details of said problem, maybe not.) So, hook up a console, set the machine to 'halt', and power on. Is console ODT working? If so, congrats, you win, go to stage ii) below. If not, you have a reduced area in which you have to investigate - and you'll need a 'scope of some kind to make any progress. (If you don't have one, you're SOL. Get one.). In order i) is the CPU's internal clock (and thus, probably the microcode) running? (At this point you will need to consult the "PDP-11/24 System Technical Manual", EK-11024-TM.) If so, is it trying to talk to the console's registers? (See Section 4.6 of the TM, "Internal Address Decode".) If so, is the UART working properly? (4.7 of the TM, "Serial Line Units".) If so, console ODT is running, you're now at stage ii): you can see if the CPU
Re: DEC ME11-L core memory expansion unit drawings
> From: Steven Malikoff > I have finally got around to scanning the print set for the DEC ME11-L > memory expansion unit Ah, thanks for that. The prints for the boards are available, in the PDP-11/05 Engineering Drawings (on pp. 115-137), but the MF11-L backplane was previously missing. (The -11/05 generally mounts MM11-L sets in the main CPU backplane, so the MF11-L backplane is not included in the -11/05 prints.) It is the non-parity MF11-L backplane (DEC part number 54-09959), not the parity one (part number 54-10331), though. (My theory is that the non-parity version can be upgraded to parity with an etch cut, and some added wires, FWIW.) Noel
RE: Is The M9312 Boot Module Essential?
>> (I have yet to check and see if the KY11-LB asserts SACK if the CPU >> halts on its own accord - probably 'yes', but that's a project for tomorrow.) Yes, it does. I toggled in the following program: 5000 5200 776 0 (what, you all can't program a PDP-11 in octal? :-) and hit 'start' and the SACK light on the UA11 flashed out and came back on when the machine finally halted. So then I looked at CPU tech manual for the KD11-E, and the HALT instruction seems to act exactly like the console has requested a processor halt; it just sets the HLT RQST signal (see Section 4.5.5 "Operate Instructions"). So, either (console halt, or a HALT instruction) will cause the identical response in the processor; see Section 4.10.3 "Halt Grant Requests": the CPU sends HLT GRANT to the console, which returns SACK. As long as SACK is asserted, the processor waits with its clock inhibited: "The user can maintain the processor in this inactive state (Halted) indefinitely. When the HALT switch is released, the user's console releases BUS SACK L, and the processor continues operation" This text is obviously for the KY11-LA; the KY11-LB will operate identically: when the console releases SACK, the processor resumes operation. > From: Fritz Mueller >> when I powered the machine on, it turned out that something was >> asserting SACK when the machine was halted > That is quite interesting, and not what I would have expected! Yes, I was quite surprised; I didn't expect that either. Now that I know that the KY11-LB uses it to talk to the KD11, I can work around it, though. I'll have to write all this up to warn others about it. >> The thing that's puzzling me is that the M8264 seems to exactly >> replicate the functionality of the M9302, with an 'unused' bus grant >> being turned into a SACK. So I don't understand the point of the M8264. > I think the only difference would be that since the M8264 is timer > based, it doesn't need the intact end-to-end path required for > turnaround. So your bus won't lock even if you have a broken grant > chain or a poorly behaved or hung device eating grants. You are right about it being timer-based, but I'm not sure the conclusion follows, at least exactly as stated. If there's a broken grant chain, then as you originally pointed out, the M9302 will jam SACK on. The M8264 could not even be there, and nothing would be any different. Same thing if the CPU asserts a grant in response to a now-removed interrupt request: the M9302 will jam SACK on, etc, etc. I'm racking my brain to think up _any_ circumstance in which the M8264 will assert SACK. in which the M9302 wouldn't. Thinking it through, there has to be a grant, but it can't get to the M9302 (because otherwise it would do its thing), but that failure to get there can't be simply a broken grant chain (ditto). So some device has to be malfunctioning: not passing a grant along, but eating it. So either a hard-failed component in the grant-passing circuit, or some design flaw. (It can't be a glitch; it has to be a permanent thing which prevents passing the grant.) I suppose that's possible, but I can't see any othey way. Noel
RE: Is The M9312 Boot Module Essential?
> From: Mattis Lind > What about the M9300 board? Do you have an idea what the purpose is of > that card? Yes, that one's well-documented and understood. It's intended for use on the 'B' UNIBUS of the RH11-AB, in deployment configuratons where that UNIBUS is in use, but there's no CPU on it to respond to NPR bus requests. (See: http://www.bitsavers.org/pdf/dec/unibus/RH11_Peripheral_Controller_Course.pdf pg. 11 for an example; the 'B' UNIBUS of the -11/45 is used for a separate path into the 45's dual-port FASTBUS memory.) On such a UNIBUS, the M9300 is used at the start of the bus, and is jumpered to allow on-board circuitry to respond to an NPR with an NPG.It also has a SACK timeout capability, documented in: http://www.bitsavers.org/pdf/dec/unibus/RH11-AB_OptionDescr.pdf on pp. 69-70, but I'm not fully familiar with that. Noel
Re: Is The M9312 Boot Module Essential?
First, a minor correction: > the M8264 Sack Timeout module ... there's next to nothing in print > about them There is also some coverage in EK-KD11E-TM-001, at: Section 4.7.2.4 "M8264 NO-SACK Timeout Module" (pg. 4-41, pg. 87 of the PDF), which I found while looking for parity stuff (below). > From: Fritz Mueller > The KD11-E is pretty bare boned... Parity handling was also a quad "add on". ??? The KD11-E/EA doesn't do much with parity (below), so at first I thought that maybe you were thinking of the M7850 Parity Controller (which is actually a memory option, not KD11-E/EA specific; more below), but that's a dual card. The KD11-E/EA does not (like most PDP-11's) calculate parity; PDP-11 memory units do all the work, and signal 'parity error detected' to the CPU over the UNIBUS (using the PB line); the CPU will trap when it sees that (if enabled; the KD11-E and -EA can disable recognition of parity errors, with jumpers). See Section 4.7.2.7, "Parity Errors", in EK-KD11E-TM-001 (at pg. 4-45, pg. 91 of the PDF); the circuit diagram is on page K2-1 of the KD11-E/EA FMPS. The M7850 has to be in the same backplane as the memory, but that can be a different backplane from the one holding the CPU. So it can be 15' away, at the other end of a UNIBUS cable. Anyway, can you say more about the parity add-on? >> So if i) a device requests a grant, and then drops the request at >> _just_ the right time ... and ii) there's a break in that grant line >> ... before it gets to the M9302, which can turn it around as a SACK , >> then ... the KD11-E CPU will hang! > I believe a broken grant chain with an M9302 in place on the far side > results in the grant being pulled up at the M9302, and then continuous > assertion of SACK, hanging the processor straight out the gate. Oh, right you are! (I'm glad _your_ brain is runed on - unlike mine! :-) I happen to have an -11/04 (the -11/34's sibling) on the bench in my work room, with one of Guy's very useful UA11's plugged into it. (BTW, the UA11: http://www.shiresoft.com/products/ua11/Unibus%20Analyzer.html is fantastically useful as a UNIBUS debugging tool. Everyone working on UNIBUS machines should have one.) So I thought I'd go try an experiment. It turned out to be a bit more complicated than I thought, but you're basically right: a break in the grant lines (e.g. missing grant continuity card) causes the downstream card to 'see' 'phantom' incoming grants (open TTL inputs float high), and signal a grant on from there; and if there's an M9302 at the end of the bus, it will see that and jam SACK on. The complication was that when I powered the machine on, it turned out that something was asserting SACK when the machine was halted; if I put it into a 'BR .' loop, that goes away. I looked, and the KD11-D doesn't even _have_ a SACK driver! So I tried un-plugging the KY11-LB, and the 'SACK on halt' went away. (That machine has core, and I set the power-on vector to halt the machine.) Looking at the KY11-LB manual, it does in fact assert SACK (after it has sent the KD11 a 'halt request, and receives a 'halt acknowledge'), to recognize the CPU's acknowledgement of the halt request. (I have yet to check and see if the KY11-LB asserts SACK if the CPU halts on its own accord - probably 'yes', but that's a project for tomorrow.) The thing that's puzzling me is that the M8264 seems to exactly replicate the functionality of the M9302, with an 'unused' bus grant being turned into a SACK. So I don't understand the point of the M8264. Whether the cause of the grant is a rare timing window of a bus request being cancelled, or a broken grant line; with an M9302 in the system, a SACK will result. The only difference between the two is that because of the way grant lines are wired, the M8264 will not respond to a broken grant line 'downstream' of the M8264. The M8264 does add this capability to a system using an M930 terminator - but just switching to an M902 would be simpler. And the M9302 pre-dates the M8264, as we can see from EK-11034-OP-PRE2. So I'm really quite confused as to what the point of the M8264 was. Noel
Re: PMI memory on an -11/93 (Was: Installing an operating system on an 11/83)
> From: Christian Gauger-Cosgrove > From the KDJ11-E module user's guide ... the solder-side of the CD > fingers is left unpopulated, but for the +5 and ground pins. > The only PMI compatible option then would be the KTJ11-B UNIBUS adapter. I forget how the -11/84-94 backplane is wired (it's wierd - the QBUS CD slots are bussed together in a group, they're not in pairs like an ordinary Q/CD backplane - but I forget the fine details), but how does the PMI get from the CPU to the KTJ11, then? I know on the same backplane, it supports PMI memory cards with the KDJ11-B. And speaking of the KDJ11-B, I just looked at one, and _it_ doesn't have any lands on the C/D connectors, side 2, either! Probably because the PMI only uses side 1 lands: https://gunkies.org/wiki/Private_Memory_Interconnect#Pinout Given that the KDJ11-E can do master-slave cycles through the KTJ11-B (to read UNIBUS device registers), it has to be able to do master-slave cycles on the PMI. What I don't know is whether, on a 2MB KDJ11-E, it will try and send memory reads for locations > 2MB out the PMI, or whether all reads below the UNIBUS address space (in 22-bit address terms) are sent to the local memory _only_. Someone with a 2MB KDJ11-E should try it... Noel
Re: 'dd' for Windoze (Was: cctalk Digest, Vol 89, Issue 21)
> From: Rod Smallwood > dd is a linux command. UNIX, actually. (V5, I think: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/dd.c There no 'man'page for it in V4. Anyway...) > I only have windows PC's. There are Windoze versions. I've used this one: http://www.chrysocome.net/dd with success (under XP; probably works under others, too). Noel
Re: PMI memory on an -11/93 (Was: Installing an operating system on an 11/83)
> From: Bill Gunshannon > Just wish I could get some PMI memory for that 93. ?? The KDJ11-E in the -11/93 comes with a minimum of 2MB on the CPU card. That's enough for almost 16 maximum-sized processes (assuming they aren't sharing program texts - almost double that, if they are). Does one really need more than that for vintage retro use? Besides, the on-board memory operates at full speed (same as cache memory on the KDJ11-B); even if you added PMI memory, the KDJ11-E has no cache, so it would be a _lot_ slower than the on-board memory. Noel PS: Can people _please_ trim messages they are replying to, so we don't all have to scroll down past a bunch of irrelevant drek? Thank you.
Re: Is The M9312 Boot Module Essential?
>> On Feb 19, 2022, at 10:51 AM, Noel Chiappa wrote: >> The -11/34 (not the /34A) has something unusual for grant timeouts, >> but I forget the details. I'll look it up. And here it is... > From: Fritz Mueller > I think you are thinking of the M9302, Noel: a far-side terminator card > with integrated SACK turnaround? No; the M8264 Sack Timeout module. What's an M8264, you say? Well, there's next to nothing in print about them, but I think I've managed to assemble enough distant clues to work out their story. Start with EK-11034-OP-PRE2 (I have a hard-copy of it); it gives a clue as to how it all started. In 3.10.2, "End-of-Bus Terminator", it says: "As a result of this [SACK turnaround] circuitry [on the M9302], the SACK timeout feature found on other processors is not required" So if i) a device requests a grant, and then drops the request at _just_ the right time (so a grant gets sent out when there's no device waiting to grab it), and ii) there's a break in that grant line (maybe a missing grant continuity card) before it gets to the M9302, which can turn it around as a SACK , then ... the KD11-E CPU will hang! The M8264 was apparently the first attempt to deal with this. Like I said, there's next to nothing in print about them. EK-11034-UG-001, in Section 1.2, "System Description", does list "M8264 SACK Timeout module (11/34 only)" in the list of components - but says nothing else _at all_ about it! There is one page of circuit diagram of it, in: http://www.bitsavers.org/pdf/dec/pdp11/1134/MP00082_1134_Vol2_Sep76.pdf on pg. 149. The rest of the prints for it (e.g. the PCB layout) aren't there, but I happen to have one - it's a quad board with only a few components on it. Looking at the circuit diagram, it's mostly just a 9602 retriggerable, resettable one shot. (There's also a synchronous 4-bit up/down counter, but that's just there to count events, and display the count in some LEDs - probably just to make sure it isn't happening too often.) Since I'm not a real hardware type, I'm not absolutely certain just from looking at the circuit diagram exactly what it does, or how, but EK-KD1EA-MM-001 Section 4.7.2.4, "No-SACK Timeout Circuitry", shows a very similar circuit, and says it "asserts BUS SACK ... [if the device] does not assert SACK within 22 usec after a grant line has been enabled." Presumably the M8264 does the same thing. Interestingly, that circuit appears in the KD11-EA prints on pg. K2-10; the KD11-E prints have a blank space on that page where this circuit is in the KD11-EA prints. Since the M9302 appears in EK-11034-OP-PRE2, with SACK turnaround, I deduce that the M8264 was produced _after_ that came out, and post-dates the M9302, to fix the potential CPU hang issue I described - and was later dropped when the -11/34 switched to the KD11-EA, with that circuit built in. I'll do a page on the CHWiki about the M8264, and include an image of one. I figure I might use my M8264 on my -11/04, which also doesn't have SACK timeout (on the BG lines, for sure; it looks like it might have it on the NPG line). The M8264 doesn't tie into the CPU, it just looks at UNIBUS lines, so it can be plugged into any UNIBUS machine (near the start of the bus, since the grant lines it monitors are wired sequentially). Noel
Re: rotron caravel fan used in DEC and other cabinets
> From: Vincent Slyngstad > I had to replace one of those recently Where did you source the replacement? I need a few. Thanks! Noel
Re: Is The M9312 Boot Module Essential?
> Neither the KD11-E nor the KD11-EA has built-in termination and pull-ups > ... I haven't yet checked, but it may be the only PDP-11 CPU of which > that is true Also the KD11-D of the -11/04. Noel
Re: Is The M9312 Boot Module Essential?
So, I've made what I think is a significant discovery about the -11/34: > 1B _is_ necessary, but can be provided anywhere on the bus; most > UNIBUS/QBUS CPU [pullups] have it built in I was wrong. Neither the KD11-E nor the KD11-EA has built-in termination and pull-ups (those are both done with one set of components). I haven't yet checked, but it may be the only PDP-11 CPU of which that is true Without _something_ doing the latter of the above, the UNIBUS won't function at all. (The UNIBUS signal lines mostly operate as negative-logic wired-OR; the pull-ups float it high for '0', and any board pulls it low to send a '1'. No pull-ups, then..) This is almost certainly the reason that the manual calls for the use of either an M9301 ROM or M9312 ROM (which include bus termination) at the start of their UNIBUS, in slot 3 or 4 of the CPU's backplane. (The M7859 of the KY11-LB doesn't have pull-ups either; so in a system with a set of KD11-E/EA cards, and a KY11-B, and nothing else, the KY11-B won't be able to examine UNIBUS locations - even though in a system with _just_ a KY11-B, and one of M9301/M9302/M9312, and NO KD11-E/EA, the KY11-B _can_ do UNIBUS operations.) A system with just an M9302, and no M9301/M9312, will _probably_ work, even though the UNIBUS is only terminated at one end (see my previous post, about QBUS termination on one end only); the M9302 will provide the pull-ups needed for the UNIBUS to function (above). I have also made a number of interesting discoveries about the SACK turnaround; I'll put them in a reply to Fritz's message. Noel
Re: Is The M9312 Boot Module Essential?
> From: Jay Jaeger > SACK turnaround capability so that the machine doesn't hang accessing > an address that doesn't respond on the UNIBUS. Umm, I think you're mixing up i) grant timeouts and ii) master-slave timeouts. All PDP-11 CPUs have master-slave timeout handling; after a short delay (10usec or so) with no SSYN (UNIBUS) or BRPLY (QBUS), they resume processing, and take an immediate trap. Most OS's (UNIX, for sure) use this when they are sizing memory. Grant timeouts are less well-documented. I think most CPUs deal with this (not receiving a SACK 'fairly quickly' in response to a grant); I think they basically just ignore t, and keep processing. (That is because there are legitimate causes for not having a grant ackknowledged; e.g. if a device is requesting an interrupt, and then just as the CPU sends out a grant, the device is reset, the device won't respond to the grant, since it's no longer trying to do an interrupt.) The 'SACK turnaround' I think is only used with system health verification; the system wants to make sure that the grant lines aren't broken anywhere. (That's because _if_ a grant line is broken, devices downstream of the break can no longer do interrupts, which generally _will_ hang the overall system, when interrupts don't work as usual.) To do this, the CPU sends an _un-requested_ grant out (on startup), and the SACK turnaround circuitry on the terminator turns it around and sends it back to the CPU; when the CPU sees that, it knows the grant line has no break. It probably caused more problems than it caught, which is my guess as to why no QBUS machine has/uses it. The -11/34 (not the /34A) has something unusual for grant timeouts, but I forget the details. I'll look it up. Noel
KK11-A cache for -11/34A on eBait
Anyone want a KK11-A: https://www.ebay.com/itm/275173894774 US$200 sounds like a lot, I know, but KK11-A'S and FP11-A's are going for that much; an FP11-A just went for US$250. And KK11-A's are rare; this is he first one in a while. Noel
Re: Is The M9312 Boot Module Essential?
> From: Rob Jarratt > I suspect some of the other cards that were in the machine might do the > necessary termination stuff. Different answers for each part of the functionality. 1A and 1C fundamentally have be at the end of the bus, physically. So, unlikely; since _other_ cards aren't, generally, designed to go there. 1B could be anywhere, but I've basically never seen anything but a CPU or a terminator with 1B functionality - probably in part because the same physical components uually do both 1A and 1B. (Oddball exception: M981 UNIBUS jumper, in the -11/40 - but that's 'sort of' part of the CPU.) 2, yes. E.g. the KT24 UNIBUS map has sockets to hold bootstrap PROMs. (Compatible with the M9312's.) Others, too; e.g. the KTJ11-B UNIBUS adapter (although that is not seen in an -11/24). Maybe others, but I can't recall off the top of my head. Noel
Re: Is The M9312 Boot Module Essential?
> From: Rob Jarratt > is the M9312 essential to ever get this machine to boot up an operating > system? Interesting question. I don't have my -11/24 running yet, so this reply is theoretical, not tried in practice (and as we all know, the difference between theory and practice is even larger in practice than it is in theory), but here goes. The M9312 basically provides two things: 1) UNIBUS termination, and 2) boostrap ROM. To further subdivide the former, it provides 1A) analog termination (i.e. a resistance at the end of a transmission line that prevents reflections of signals passing down the otherwise un-terminated transmission lines of the bus), 1B) pullups (so those transmission lines normally float at roughly 3V, unless actively driven by one of the boards plugged into the bus) and 1C) 'SACK turnaround' (a start-up 'safety check' where an un-requested - and thus 'un-grabbed' by any device - bus grant from the CPU on start-up is 'turned around' by the terminator; this verifies that the grant lines are un-broken between the CPU and the terminator - e.g. by someone forgetting to plug in a grant jumper). 1A is not _absolutely_ necessary; this can be seen in small QBUS systems (the QBUS is, at the analog level, sort of identical to the UNIBUS; this an be seen in the use of the same transceiver chips, such as 8641's, on both) which can get away without 1A in small configurations. Whether it's needed on your -11/24 is hard to predict, theoretically; the easiest thing is to just try it and see. Note: it may 'work' without it, but not be as _reliable_ as with it. 1B _is_ necessary, but can be provided anywhere on the bus; most UNIBUS/QBUS CPUs have it built in, and so does the KDF11-U of the -11/24: see pg. of MP01028. 1C is required by _some_ UNIBUS CPUs (ISTR that the -11/04 won't run without it), but the KDF11's in general don't; e.g. the -11/23 definitely runs without it. The KDF11-U might have outboard circuitry to require it, but I'm too lazy to grovel over the prints to see. Easiest to just try it and see. For 2, it all depends on what you're booting from. E.g. the RK11 has a simple enough bootstrap that you can just enter it manually (although it gets old after a while - I remember re-'programming' (think 'soldering iron' :-) a castoff BM-792 someone gave us for our -11/40 so I wouldn't have to). But if you're loading it over the console serial line, e.g. with PDP11GUI, you don't need any ROM bootstrap - the built in console ODT will be enough. You can also load a bootstrap that way; I was booting off the QSIC RK11 with a boostrap loaded over the console serial line; that was faster than the bootstrap in the BDV11. This requires finding - or writing - a bootstrap, which for later DEC mass storage controllers is not trivial. YMMV. TLDR version - probably not! Noel
Re: PDP-11/34 CPU PROMS
> From: Warner Losh > Do those chips have ROM numbers on them? I have updated the: https://gunkies.org/wiki/KD11-E_CPU https://gunkies.org/wiki/KD11-EA_CPU articles with the DEC part numbers for the i) microcode and ii) instruction decode PROms. That's not all the PROMs on the Control card - there are effing bazillions of the damned things (I suspect they used them to reduce the amount of random logic, so the CPU'd fit on two boards) - but it's most of them. I have yet to triple-check them, so there might still be transcription error or two. > From: Rod Smallwood > I am sure somebody will come up with the actual images either the > original files or derived from what we have. I wouldn't be too sure of that; silence so far. I have reached out to Mike Douglas, to ask where the microcode dump on DeRamp came from: perhaps the originator can help with the missing bits. (Although perhaps I should ask Al K; BitSavers also has the dump, and it's older, so perhaps that copy came from the originator.) > We have narrowed the problem down. > Its the instruction decode ROM's that are the issue. > The images of those are whats needed. All of them? Or is just one failed? I'm wondering if you've just had a single one lose a bit or two; that's somewhat common in old PROMs. The chip you reported as failing (E111) almost certainly couldn't have taken out an instruction decode PROM, it's nowhere near them. I ask because we have absolutely nothing on those PROM's contents. With the microcode PROMs, we at least have the contents in symbolic form (see pg. 15 of MP00082; alas, we don't seem to have the KD11-EA equivalent of Table 7-15 from EK-FP11A-TM-002), but for all the instruction decode PROMs - nada. Absolutely nothing. But if they're _mostly_ there, with the partial contents, and a description of the failure mode (e.g. 'SETC doesn't set the C bit'), we might be able to work out what bit got dropped. Failing that, someone's going to have to volunteer to unsolder a set, and read them out - at least, I assume that's what would have to be done. Perhaps a logic analyzer could be attached to an instruction decode ROMwhile the CPU ran diagnostics, and eventually a complete readout of the contents accumulated. Noel
Re: PDP-11/34 CPU PROMS
>>> On Tue, Feb 8, 2022 at 6:18 PM Rod Smallwood wrote: >>> On the M8266 CPU control board a defective 7404 (E111) has killed a >>> bunch of the PROMs holding the microcode. That's pretty astonishing; I've heard of PROMs dropping bits over time, but I'm a bit amazed to hear of a failure in a TTL gate (the 74S04 is a hex inverter; its gates are on pg. 7 of the M8266 prints - they produce uPC03-08) taking out a bunch of other gates connected to it. >> On Tue, Feb 8, 2022 at 7:04 PM Warner Losh wrote: >> I found >> https://deramp.com/downloads/mfe_archive/011-Digital%20Equipment%20Corporation/08%20PDP-11/01%20PDP-1104-1134/05%20PDP-1104-1134%20Microcode/ >> which has the source code... >> >> But I couldn't find the tools to use these files to create microcode >> images. Actually, the "m8266_ucode.v.txt" there seems to actually be the program that produced the symbolic dump (which is also available at: http://www.bitsavers.org/pdf/dec/pdp11/1134/m8266_ucode.out.txt) It looks like the program is in VHDL or something like that, but it doesn't seem to have the actual microcode (was it stored/defined in another VHDL file?); that raises the question of where the actual microcode that it was dumping was. It might be worth inquiring of Mike Douglas (he runs the DeRamp site) to find out where the files in "mfe_archive" came from; perhaps the source has, or knows of, the file which "m8266_ucode.out.txt" was a symbolic dump of - maybe from a complete KD11-EA simulation in VHDL? If that's not possible,it would be trivial to extract the PROM contents (well, partial contents - see below) from the "m8266_ucode.out.txt" file; each uword entry starts with the lines: * PDP-11/34a micro code word for MPC = 000 * (MSB is left, indented fields generated by expansion ROMs) micro word = 0111 1100 1100 1000 1010 0001 1110 from ROM: E105 E103 E104 E100 E98 E97 E99 E106 E107 E108 E109 E110 The address of each uword is the "MPC = xxx" line; the contents of the 12 PROMs, at that address, are given on the "micro word = " line (the PROMs are 4 bits wide). If someone explained what format they needed as input for burning new PROMs, I could easily (like an hour) write a small portable program (using StdIO only, so it could be compiled and run on _anything_) that read that file in, and spat out the 12 PROM files. (Most of the dump could be ignored - all the data that's needed is in that one line.) BUT (and this is why it would be good to get back to the source of that file), that's not a complete M8266 ucode PROM dump. The KD11-EA has a uword address space 1 bit larger than the KD11-E - almost certainly to support floating point instructions; the KD11-EA adds 'uPC 09' (although looking its source at the top of pg. 7 of the prints, I don't quite grok how it is generated - maybe it's fed back through J2 from the FP11-A when one is plugged in). Anyway, uword addresses run up to 02000 in the KD11-EA, and the last uword in that dump is 0777. Interestingly, according to the flow charts of the 'basic' KD11-E/EA ucode in the prints (indexed and annotated here: https://gunkies.org/wiki/KD11-E/EA_microcode in full), they stop at 0757 - but the dump (in "m8266_ucode.out.txt") contains uwords that are 'supposed' to be blank (per the flow charts), as well as above 0757. So that dump must have been prepared from a copy of the 'new' KD11-EA PROMs - the ones including the floating point ucode. (Note that the FP11-A _also_ contains ucode, intended to control the stuff on the FP11-A; but the floating point instructions _also_ use the KD11-A for some stuff - e.g. fetching operands from main memory. Only the ucode address space is shared.) > From: Warner Losh > There's a small chance that the tools.tar.gz link on > http://www.ak6dn.com/PDP-11/M9312/ has these, but that's for a > different module so who knows. Right, a _completely_ different card - a boot PROM, not a CPU; totally un-related - and by a different person (Don North). But just for completeness, I looked in "tools.tar.gz", and it's just bootstrap PROM stuff. Noel
Re: Anyone live in Minneapolis?
> From: Steve at oldcomputers.net > There are some vintage tablets in Minneapolis (Eden Prarire) that would > like, but the seller will not ship. > Any help? When dealing with eBaiters who can't/won't ship, I have had good luck with PakMail (http://www.pakmail.com/); for a usually reasonable fee, they will go pick something up, package it properly, and ship it. In my experience with them, the shipping cost may not have been the absolute lowest possible I could have secured had I been on the spot, looking around, but.. I wasn't on the spot, looking around. And they went to the person's house, picked the thing up, and shipped it. Noel
KW11-L ON eBait
https://www.ebay.com/itm/393915648077 I've already got one for my machines that take one! Noel
Re: Origin of "partition" in storage devices
> From: Tom Gardner > You define logical disks by assigning a logical disk unit number to a > file on a physical disk. You can then use the logical disk as though it > were a physical disk. To me, 'partition' implies a contiguous are of the disk; "a file" to me implies that it might not be contiguous? Or are files contiguous in the RT-11 filesystem? (I know there were filesystems which supported contiguous files.) This reminds me of the swapping/paging area in Windows 95/98 (maybe other versions too), which was kept in a file, and therefore might be scattered all over the physical disk. (Norton disk optimizer would coalesce the swap/paging area to a contiguous area of the disk.) Noel
Re: Origin of "partition" in storage devices
> From: Paul Koning > When did Unix first get partitions? 'Partitions' the mechanism, or partitions the term for the mechanism? The former appeared about V5: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/dmr/rp.c when an RP03 was added; pre-V7, UNIX filesystems were limited to 2^16 blocks, so the 406*10*20 blocks of an RP03 had to be split up into partitions (called 'sections' or 'pseudo-disks' in the documentation) to make all of it useable. The latter? No idea... Partitions may have appeared in DOS/Windows for much the same reason; with 32 KB clusters, FAT16 filesystems were limited to 2GB. I distinctly recall having to use partitions when I bought a 13GB hard drive for my Windows 95 machine (FAT32 only came in with Windows 95 OSR2). Noel
Re: What was a Terminal Concentration Device in DEC's products?
> From: Bob Smith > the original UART was designed by DEC, Vince Bastiani was the project > lead and designer, Gordon Bell was behind the project, and it may have > been his idea. "Computer Engineering: A DEC View of Hardware Systems Design" covers this, in a footnote on pg. 73. I seem to recall reading that Ken Olsen was involved in doing early modem work (presumably on Whirlwind), but maybe my memory is failing, and it was someone else (like Bell, or someone). Too busy to research it at the moment... Noel
Re: What was a Terminal Concentration Device in DEC's products?
> From: Chris Zach > Maybe that is the dhv11. The DH11, DHV11 and DHU11 are all very similar, although not 100.00% program compatible. (The DHQ11 can be set to exactly emulate either the DHV11 or DHU11.) So, all provide DMA output, but not DMA input. Differences with the DH11 include two full word registers for DMA address, hardware ^S/^Q support, built-in diagnostics, etc. The DHV11 and DHU11 differ in hardware echo, output FIFO, a fix for the infamous DH11 input silo level bug, etc. Noel
Re: What was a Terminal Concentration Device in DEC's products?
> From: Paul Koning > DH-11 is unusual in that it has DMA in both directions McNamara's DH11? (I don't know of another DECdevice of that name.) Per: http://www.bitsavers.org/pdf/dec/unibus/EK-ODH11-OP-002_DH11_Asynchronous_16-line_Multiplexer_Users_Manual_Sep76.pdf it's DMA on output only; the input side has a FIFO that has to be emptied by the CPU. Noel PS: I am familiar with the term 'terminal concentrator' from the networking world, but as a generic term, not the name of a particular product. (Although Cisco's first boxes may have included a terminal concentrator, so named.) Noel
Re: Question about DECtape formulation
> From: Gary Oliver > Paul - thanks for the bitsavers reference. Ahem! In any case, it's Al who really deserves the credit, for finding that document, and putting it up. Noel
Re: Question about DECtape formulation
> From: Gary Oliver > I've always thought the physical tape wound on a DECtape spool was a > fairly conventional 'sandwich' of mylar/oxide/mylar ... > Was there some kind of 'lubricating' coat on the data side? It makes > sense, but none of my DEC documents or Googling has any mention of > lubrication ... > If someone has some detail information on the tape construction, I'd am > curious to see it. Dunno if you know of this: http://www.bitsavers.org/pdf/dec/dectape/3M_DECtape_Spec_Nov66.pdf but it doesn't mention any lubrication, just a "Protective Overlay" layer, over the "Coating" (which I assume is the oxide). I'm a bit surprised that "some of the data side of the tape came off on the wipe", though, unless the "various concentrations of isopropanol/water" dissolved the Protective Overlay. Noel
Re: Typing in lost code
> From: Gavin Scott > I think if I had a whole lot of old faded greenbar etc. ... Someone may > even have done this already See: https://walden-family.com/impcode/imp-code.pdf Someone's already done the specialist OCR to deal with faded program listings. Noel
PDP-11/34 FP11-A on eBait
Speaking of FP11-A's: https://www.ebay.com/itm/275096265379 I wouldn't mind having one, but not for that much! I wonder how much it will go for? Noel
Re: 8" Floppy Drives needed
> On Wed, Jan 12, 2022 at 12:16 PM Mike Katz wrote: > I am looking to make a RX01 (and hopefully RX02) disk formatter Something that can format floppies for the RX01 can effectively format RX02 floppies, too. An RX02 drive can convert RX01-formatted floppies to RX02-formatted floppies. Given how arcane the RX02 format is (sector _headers_ are written in single density; sector _data_ is written in double) I'd be pretty surprised if anything except an RX02 can do it. Noel
PDF of FP11-A FMPS available
Just ran across this: http://wwcm.synology.me/pdf/MP00189%20FP11-A%20Field%20Maintenance%20Print%20Set.pdf which isn't available online in this form. (This appears to be a different scan from the one on the Maine Coon site, split up into several TIFF's, as it has the cover which that one doesn't show.) As always, history shows that the best way not to lose things is to have multiple independent copies! So download often! Noel
Re: Plessy core memory
> From: Chris Zach > I'm guessing that the DD11-F is significantly different from the DD11-B? I assume theat "DD11-F" is a typo; there is, AFAIK, no DD11-F, and a Web search revealeddidn't turn anything up. (There are DD11-CF and -CK backplanes, as well as -DF and -DK, but the -CF and -CK differ only in power harness length.) > the 11/24 used +12 on the +15 lines. No idea what was wrong with DEC The: https://gunkies.org/wiki/MS11-M_MOS_memory I'm guessing it used the parts that the IC vendors could provide. > Don't know what would happen if you plugged a RL11 or other hex height > card into one of those slots, probably blow everything up. Not sure. Per: https://gunkies.org/wiki/Modified_UNIBUS_Device#Pinout https://gunkies.org/wiki/Extended_UNIBUS#Pinout These are _some_ of the MUD/EUB pin clashes: Pin EUB MUD AN1 - A21 - Parity P1 AP1 - A20 - Parity P0 BE1 - A19 - Internal SSYN BE2 - A18 - Parity Detect I don't think those would harm anything. Not sure about power pins - and have no incentive to research it, as I have no need/interest in trying it. > I know I ran it with two of these Plessy cards and a RX01 controller but > now that I look at it that would be impossible as both were hex cards Maybe Plessey designed them to go in a DD11-B? I know I've seen other third-party cards that would go in oddball slots. > and both could never fit in a 4 slot backplane with enough space for a > quad spc Why not? The two hexes in slots 2&3, the quad in 1 or 4. > a DA11-F Unibus window Wow; never heard of those. I'll have to do a CHWiki page for them. Luckily, the maint manual is online. There's also a DA11-B. > what would happen if I enabled the KT24 Unibus memory map. All that does is allow DMA devices on the -11/24's UNIBUS access to the entire main memory: https://gunkies.org/wiki/PDP-11/24#System_bus_structure So if you hooked up an -11/10 to an -11/24 with a DA11-F, then with the UNIBUS Map on, the -11/10's CPU and/or DMA devices would have access to the entire EUB memory via the 24's UNIBUS Map, is all. > This is so much fun! That _is_ why we collect old computers! ;-) Noel
Re: Plessy core memory
> an adapter cable to go from a 9-pin male (shell; female pins) to a > 15-pin female (shell; male pins) Sigh, shouldn't try to type when I'm this tired. Female 9-pin (to plug into the BA11-D) to male 15-pin (for the DD11-C/D to plug into). Noel
Re: Plessy core memory
> From: Chris Zach > the DD11-B is a MUD backplane No, it's SPC; other sources, e.g. http://www.chdickman.com/pdp11/Notes/DD11.shtml agree. So if you have a DD11-B, you must have a BA11-D, with the 9-pin power plugs. The best thing to do is get a DD11-C or -D, and build an adapter cable to go from a 9-pin male (shell; female pins) to a 15-pin female (shell; male pins), so you don't have to mess with the harness. Part numbers here: https://gunkies.org/wiki/DEC_power_distribution_connectors Then you can plug in any memory you've got the right voltages for; the MS11-E takes + and -15V (in addition to +5V, of course). Noel
Re: Plessy core memory
> From: Chris Zach > the secondary memory (a Plessy 700101-100) may be shorting the -15 line > for some reason. Working on it, but does anyone have a manual or > anything like that for this kind of memory board? I've got a Plessey core memory manual somewhere, but I can't find it, so I don't know if it's the one you are looking for. I got it from Paul Birkel; it was a duplicate, and he scanned his and sent the scan off, but I don't think it made it online. > Alternately, what kind of Unibus 16k memory board exists to get a 11/10 > from 16kw to 32kw of memory? It all depends on what kind of -11/10 you have. If yours is in a 5-1/4" box, you can't plug a DEC memory card into the SPC slots that some of the CPU-holding backplane versions have because DEC memories (other than the ones like the MM11-L and -U, which are multi-board core systems that require custom backplanes) all require MUD slots, not SPC. All of the CPU backplanes on that machine are for a _specific_ kind of core memory (MM11-L or MM11-U), see here: https://gunkies.org/wiki/PDP-11/05 There are I think some third-party memories which can be used (Dataram, maybe?) but I don't have time to go into them. If you have a 10-1/2" box, you can mount a MUD backplane - but you might still have an issue because the older BA11-D boxes use the old 9-pin power connectors, and the MUD backplanes (DD11-C, -D, etc) all use the newer 15-pin ones. (Again, there are some oddball ones, and again, I don't have time to go into them.) If you're lucky enough to have one of the ones that will take a MUD backplane, an MS11-E/F/H/J: https://gunkies.org/wiki/MS11_32KB_MOS_memory would be an option. > On a related note, where did +20 come from for Unibus and which systems > even supported it? Was it an 11/45,11/70 thing? The later /05's, /40's and /45's were the first ones to provide +20V, for the then-new MM11-U. On machines which took H744 'brick's, the _later_ harnesses could take a H754 +20V, -5V regulator 'brick'. Alternatively, _some_ BA11-L's (used for the /04 and /34) had the right version of H777: https://gunkies.org/wiki/H777_Power_Supply to provide +20V. Noel
Re: The Portable C Compiler (pcc)
> From: Tom Hunter > The original "Portable C Compiler" by S. C. Johnson (also known as > "pcc") had functional support for the Data General Nova. Could somebody > please point me to this original implementation? > ... > I am looking for the original implementation - not any recent work. Of PCC, or the Nova version? The _oriinal_ PCC, released to the world in V7, is there: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/mip https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/pcc https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/doc/porttour That one is dated 1979. I have a slightly later version, from 1982 or so, which is the 68K one done at MIT. Not sure if either of those is any use to you, though. Noel
Re: VAX 780 on eBay
> This: > https://www.ebay.com/itm/275084268137 > ... > Anyway I fully expect it to go ... for a _lot_ more than the opening price. Much to my surprise, it didn't sell at all (although a number of other lots, likely from this machine, did.) I'm rather puzzled that an -11/70 will sell for north of $10K, while a /780 can't fetch $5K. I can only guess that PDP-11'S are seen as more important in the collector world (even though the BSD work, which had such a huge impact on UNIX, which has now - in the form of Linux - taken over the world, was centered on the VAX). Noel
Re: Mate-n-lok connector for H744 Regulator
> From: Rob Jarratt > Does anyone know what the correct one is? This: http://gunkies.org/wiki/DEC_standard_modular_regulators has all the details. (If anyone knows of any PDP-11 hardware or UNIX information which is not on the CHWiki - I'm not interested in DEC PDP-11 software, but if someone would like to take that on, that would be great - please let me know.) Noel
Re: 3-phase power
> From: Jon Elson > It should be 208V Oh, right you are. It's been a long time, and I had a distinct memory that it was less than that, but I looked, and I think that's it. The term for my flavour of 3-phase is apparently "open wye/open delta"; each leg is 240V to the others, but only two are 110V to neutral - the "hi leg" (normally colour-coded orange; normal 3-phase uses black/red/blue) is 208V. The page Jonathan Chapman sent had a good diagram of how it is wired: https://www.engineeringradio.us/blog/wp-content/uploads/2012/02/3-phase-open-delta.jpg When they were doing some work on the pole decades back, I asked the foreman how it worked, and he drew a diagram to show me; I had forgotten it, but seeing that, that is it. The A and C are produced off one feed phase, but the B comes from the second feed phase. Noel
Re: 3-phase power
> From: Scott Quinn > I have seen some roads where the utility has 2 of the phases plus > neutral going down them, not true 2-phase power, but 2 phases 120/240 > degrees apart with the third phase just not present. My street has that. The subdivision as a whole has all 3 phases (down the main road through it), but individual streets off of it have only 1 or 2. (The whole subdivision is on poles, so it's easy to see.) On the ones with 2, some houses are connected to one, some to the other. > I guess they figure twice the loads for only one more wire. No, because most homes are only connected to one phase. I think the main reason to do it is that it allows the total load (of the entire subdivision) to be somewhat balanced across all 3 phases. > Can't remember what it was called but I do remember seeing in some book > somewhere about a "phantom 3rd leg" or something My house has something like that; the previous owner wanted '3-phase service' for machine tools (I think - could have been a compressor, or something) in his basement workshop, so they sold him a pseudo-3-phase service. I forget the exact details of how it works, but the 3rd phase is at 170V to neutral, or something like that. (So I can't power any 110V outlets off the third phase.) I think the way it works is that the two 'main' phases are 220V to each other, 110V to neutral (I think from the usual center-tapped transformer off one of the three main feed phases, i.e. 180 degrees to each other). The third 'pase' is generated by a second, smaller transformer connected to the other feed phase in some arcane way I forget the details of. So it's 120 degrees away from the other two. Noel
Re: 11/785 on ebay (2018) - was Re: VAX 780 on eBay
> From: Grant Taylor > From that last picture, it looks like one of the plugs is five pronged, > and looks very similar to the 120/208V 30A 3? plug in one of the > pictures about the current 780 auction. Not too surprising; the /780 and /785 are basically the same machine. (In fact, one could convert a /780 to a /785 by pulling out the /780 CPU cards and replacing them with a set of /785 cards; basically the same cards, with the 74S chips replaced with 74AS.) Noel
Re: What is a BC01-R
> From: Chris Zach >> Anyone know what an M857 is? I guess it might be a DF11 async answer >> mode? > No, it's a single width full height M series board from the early > 1970's. Argh, digit swappping on my part. The _M587_ is in the DN87 FMPS: http://www.bitsavers.org/pdf/dec/pdp10/periph/MP00068_DN87_Universal_Comm_System_Front_End_Jan76.pdf (pg. 98); it's a dual-width card, an "Async answer modem" (the DF11-BB). The BC01-R cable is in there (pg. 89), but I don't see the M857. (Web searches don't turn it up either.) Noel
Re: VAX 780 on eBay
> From: Jonathan Chapman > Last one that went auction-style on eBay went for $1,178.00 When was that? Do you have any details of the machine's config? That's a pretty good deal for a 780 (IMO). Noel
Re: What is a BC01-R
> From: Chris Zach > a M857 board with a RS232 cable on it and BC01R-25 on it. Anyone know what an M857 is? I guess it might be a DF11 async answer mode? I found this: https://www.computerhistory.org/collections/catalog/102731577 but I think the number there is wrong; I'm not sure exactly which KL10 board is an 'MBOX Control 3' - it might be the M9537. > From:Ethan Dicks > Sounds like it was a generic cable that probably worked with several > devices. Yeah, the BC01-R was used with an M957/M970 header card (not sure what the difference between them is) in the DF11: https://gunkies.org/wiki/DF11_Communications_Line_Adapter Not sure where else. Noel
VAX 780 on eBay
This: https://www.ebay.com/itm/275084268137 The starting price is expensive, but probably not utterly unreasonable, given that: - the 780 was the first VAX, and thus historically important - 780's are incredibly rare; this is the first one I recall seeing for sale in the classic computer era (versus several -11/70's, /40s, etc) - this one appears to be reasonably complete; no idea if all the key CPU boards are included, but it's things like the backplane, etc (all of which seem to be there) which would be completely impossible to find now - if any boards _are_ missing, there's at least the _hope_ that they can be located (780 boards seem to come by every so often on eBait), since people seem to keep boards, not realizing that without the other bits they are useless Anyway I fully expect it to go (because of those, especially i and ii) for a _lot_ more than the opening price. I've sent the seller info on the complete 780 board set, and a suggestion that it's in their own best interest (maximize bidding) to check to see if it's complete. Noel
Cheap PDP-8 boards on eBait
This guy: https://www.ebay.com/sch/m.html?_ssn=jariadkin-0&_sop=10 has a couple of PDP-8 boards for sale that at the moment are going _really_ cheap. Noel
Re: Reproduction DEC 144-lamp indicator panels
> From: Tony Duell > I have _two_. But alas nothing to connect them to. Well, there are still a good flock of machines with IBM channels around, but _you_ don't have one (I can't blame you :-). I wonder if any of the people with IBM channel machines have any need to connect to an -11? Speaking of extant dinosaurs, I wonder if any RF11's still exist? Noel
Re: RC11 controller (Was: Reproduction DEC 144-lamp indicator panels)
> From: Steven Malikoff > Was there ever an indicator panel for the RC11? .. I have a set of RC11 > modules .. No backplane though. I've not found any docs for these, I suppose > they're probably on bitsavers and have overlooked them. Looking at the manual and engineering drawings (at BitSavers, as you guessed), no lights. I've added links to those to the CHWiki RC11 page: https://gunkies.org/wiki/RC11_disk_controller The engineering drawings have the wirelist for the backplane, so it would be possible to wire a new one. (I'm in the process of doing that for my KE11-A.) Not sure it would be much use without an RS64 drive, though. Noel
Re: Reproduction DEC 144-lamp indicator panels
> From: Jay Jaeger > Also, if someone (else, presumably) does up a replica of the indicator > panel board (perhaps with the option to use LEDs, with some resistor > packs that could be bypassed for lamps Two points. First,there's the question 'are you trying to produce something that just _looks_ alike, or do you want something that's electrically compatible (i.e. can be swapped in in place of an original'? If the latter, it might be going to take a little work; it might not be just 'wire up some LEDs and go'. If you look at the indicator panel prints (pg. 190 of the RF11 prints), the incoming lines are tied to the base of a transistor; its emitter is tied to ground, and the light bulb is wired between the collector and +6.5V. This means, I think (I'm basicaly a software guy :-), that one turns the bulb on by putting a voltage on the input, which turns the transistor on, and current flows through the bulb to ground. (If I have that wrong, will someone please orrect me?) Given that the way TTL works is that 'logic' outputs actually sink currect when their output is '0' (i.e. current goes _in_ the 'output' pin), it might take a little work to make the right thing happen. Although maybe not; looking at the RK11-C prints, it seem to drive the indicator panel straight from the output of normal gates. I _think_ what happens is that when a gate's output is '1', the output's voltage floats high, and that's enough to turn on the transistor (above) driving the bulb. (Ditto the request for correction!) But the real issue with 'electrically compatible indicator panels' is the wiring. In the originals, the flat cables that drive them are soldered directly to the indicator panel board, and also to the paddle boards. So the _only_ standard interface location is the paddle boards. I suppose one could put Berg headers on both the indicator panel board and the paddle boards, and use a standard IDC cable betweenthe two... Mention of the paddle board interface brings me to the second point: even if one did produce electrically-compatible indicator panels - where are you going to use them in a PDP-11 system? Not in the CPUs - those all had their own front panels. The only PDP-11 devices which used indicator panels which I know of were: - the DX11 (I don't think anyone's got one of those) - the RF11 (ditto - although Guy was discussing emulating one at one point) - the RP11 (but the indicator panel is built into the controller rack there, so if one has an RP11, one already has the indicator panel) - the RK11-C (and several people who have those already have indicator panels) I agree, the indicator panels look cool - but where are you going to use one in a historical PDP-11 system? Sure, one could use either a electrically-compatible or non-electrically-compatible indicator panel anywhere you want, plugging into some non-historical hardware, but.. (The non-electrically-compatible indicator panel Dave did for the QSIC is initially being used in something which emulates an RK11 and/or RP11, so there's some rationale for it.) Noel
Re: RK11-C indicator panel inlays?
> From: Rod Smallwood > Let me see what artwork I have I'm curious as to what you'd be able to find. Like I said, I'm pretty sure DEC never did an RK11-C inlay; the engineering drawings for the 19" indicator panel (included in the RF11 engineering drawings: http://www.bitsavers.org/pdf/dec/unibus/RF11_EngrDrws_Oct70.pdf on pp. 187-188) list many inlays, but not an RK11 one. Also, I've looked through the RK11-C manual: http://www.bitsavers.org/pdf/dec/unibus/RK11-C_manual1971.pdf but it contains no mention of an indicator panel, which it surely would if there was one. > From: Henk Gooijen > I have *two* DX11 front panels with the 144 lamps & 4 'paddle' > connections boards. ... Given you have 144 lamps panel with the RK11-C > front, what would you do to light up the lamps? Uhhh... plug the paddle boards on the end of the flat cables from the indicator panel into the pre-wired slots in the RK11-C backplane (see the RK11-C engineering drawings: http://www.bitsavers.org/pdf/dec/unibus/RK11-C_schemFeb1971.pdf pg. 36)? :-) Hence my comment that to make use of the _inlay_ I proposed to produce, one had to have an RK11-C _and_ a spare DEC indicator panel... Noel
Re: Need picture of power supply mounted in 11/40 cabinet
> From: Marc Howard
> I've got an 11/40 I'm going to start working on. Problem is that there
> are two power supplies (H742 and H7420) that came with it but neither
> was mounted in the rack.
-11/40's in general only have one of those large H742x suppplies in a rack.
The documentation and prints all show only a single one - in fact, the 11/40
power harness (which is specific to the KD11-A backplane, at the CPU end) can
only attach to one. The KB11 machines (-11/45 and /70) use two, but their
harness has provision for two.
I don't know of a DEC document that lists the difference between the H742 and
H7420, but my CHWiki page for them:
https://gunkies.org/wiki/H742_Power_Supply
gives what I think is a pretty good list; any errors or missing details would
be appreciated.
> Also how is the power cabling routed (I think I'm missing this part)?
That's going to be a hassle, replacing the main harness! Especially since
production of the 8-pin MATE-N-LOK connector shells used to interface to the
H744/etc 'bricks' - part numbers here:
https://gunkies.org/wiki/DEC_standard_modular_regulators
are out of production, although some vendors have residual stocks. Hoard them
while they last!
The "PDP-11/40, -11/35 (21 inch chassis) system manual" (EK-11040-TM-002):
http://www.bitsavers.org/pdf/dec/pdp11/1140/1140_SystemManual.pdf
has pretty good coverage of the harness; the back end of Chapter 6 covers it
in detail. That's a lot easier to understand than the FMPS:
http://www.bitsavers.org/pdf/dec/pdp11/1140/PDP-1140_System_Engr_Drawings_Rev_P_Jun74.pdf
so read that before you tackle the prints.
Note that there are two different kinds of harness, depending on whether the
machine has MM11-L (-15V) or MM11-U (+20V) core memory. Unless you're
planning on using one of those, you can probably ignore that, though.
Any questions, ask here right off; we have a lot of expertise! :-) ('My'
first -11 - as in, one I was in charge of - was a -11/40. Fond mempries!)
Noel
RK11-C indicator panel inlays?
Let me get this out before the list gets shut down _again_... There is discussion of doing a run of indicator panel inlays: http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html for the RK11-C (which is wired for an indicator panel, although as far as I know, DEC never did the inlay). If you're interested... you will need a standard DEC indicator panel light panel (with flat cables with plug-in-cards on the ends). (I don't have any insight on how to get one of those. It shouldn't be _too_ hard to make replicas, but I'll leave that topic for the moment.) All I am proposing to do is create the silk-screened inlay that turns a DEC indicator panel into an RK11-C indicator panel (starting with a functional indicator penel without the inlay). All DEC indicator panels use the same actual light panel and flat cables/plug-in-cards (which have one conductor per light in the light panel); which light comes on is set by the way the backplane slots the cables/plug-in-cards plug into are wired. So from the prints, which give the wiring to the indicator panel slots, I managed to work out what an RK11-C panel would look like, roughly (captions are made up, but the light locations are accurate): http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/RK11-C_inlay.txt Starting with that, Dave Bridgham managed to whip up a rough approcimation of what the inlay would look like: http://pdp10.froghouse.org/qsic/inlay-rk11-c.pdf We had put a certain amount of work into identifying a font which looks like the one DEC used, back when; I worked with a member the UK to produce a bunch of blank inlays (right size/shape, with the black paint on the back with the holes for the lights). Dave then found someone who could print the white lettering on the front, and this is what the result looked like, on an 'RK11-F' (the QSIC with RK emulation microcode) panel: http://ana-3.lcs.mit.edu/~jnc/tech/QSIC/jpg/RK11F-F.jpg You can compare with an original DEC inlay (TC08, IIRC) here: http://ana-3.lcs.mit.edu/~jnc/tech/QSIC/jpg/DasBlinken2F.jpg That's on the same light panel, just the inlay is changed. (The lights in the lower one are from the light panel Dave produced for use with the QSIC; it's totally incompatible, electrically, with the DEC originals; 4 wires, IIRC, run the whole thing (data, clock, latch and a ground), as opposed to the 'wire per light' of the DEC originals. Looks _just_ like the originals (which Tech Sq used to have a lot of, BITD), though. Anyway, if anyone is interested, the next step would be to find out who all wants an RK11-C inlay, and work out _exactly_ what would be printed on it. Noel
Re: Women of Computing
Can we please return to discussions of actual classic computers, before our long-suffering list host shuts the list down _again_ for this sort of argument, this time perhaps forever? Thank you. Noel
Re: PDP-11/70 Boards
> From: Guy Sotomayor > I don't unfortunately have any light masks Dave Bridgham and I were manoeuvreing to be able to produce clones of the one you loaned me (he has access to a computer-controlled milling machine at his maker-space or whatever the name is for them now, and we bought a good-sized sheet of the required plastic to be able to crank them out) when I came down with COVID early in the pendemic, and in the aftermath (I came down with long-haul post-COVID Chronic Fatigue Syndrome) itgot put on hold. The loaner, and a micrometer to measure it, are still siting on the table in my family room, next to my desktop. If anybody needs some, I can probably try finishing the drawing, and get it to Dave, so we can resume that project. Noel
Re: PDP-11/70 Boards
> From the blog of someone who got a KB11-A working It's Fritz Mueller's blog; at about the top of this page: https://fritzm.github.io/category/pdp-116.html he's just turned the machine on for the first time, and you can follow as he chases, finds and fixes CPU problems. The KB11-C/D of the -11/70 is _very_ similar to the KB11-A he was dealing with (they are _basically_ the same CPU, with a cache, and other stuff added on the other side from the CPU, on the KB11-C/D), so there are probably some good lessons to be learned. > dunno if Guy Steele Ooops; sorry, Guy - the brain is starting to drop bits. > if the particular machine the system is being built for has an FP11). > Perhaps the later BSD versions look for the FP11 on startup, and adjust > their behaviour appropriately, but I'm not familiar with them. The way user code deals with the existence/non-existence of the FP11 is pretty simple. In C (other languages probably do something similar, but I only know about C),one gives the '-f' flag to 'cc', and when 'cc' invokes the linker, on machines which don't have floating point support, it uses fcrt0: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s4/fcrt0.s as the machine language startup (the thing that calls main()) instead of crt0. The difference is that fcrt0 sets the UNIX 'illegal instruction' signal, in that process, to go to a handler which emulates the FP11 instructions. In V6, as distributed, the binary of all applications which use floating point are linked this way, so they will all run OK 'as is' on a machine with no floating point (including those which don't suppport any kind of FP11, such as the -11/40). When run on a machine with an FP11, there are no illegal instruction traps, and that emulator code is just never used. I'm not sure what the deal with BSD is, for machines without an FP11; fcrt0.s is still included in BSD2.9, so maybe it's still using this approach. I have this vague recollection that at some point, floating point instruction emulation was added to the kernel, removing all the signal overhead, but that might be a bogus recollection. Noel
Re: PDP-11/70 Boards
> From: Ed Cross > I'm currently restoring a PDP-11/70 system and need the following > boards to complete the CPU: FP11-C >From your mention of the FP11-C, I gather your -11/70 has a KB11-C (later) CPU, not the KB11-B CPU of the earlier PDP-11/70's (prior to 1976 - the difference between the two was whether they took the optional FP11-B or FP11-C FPP). Not that it makes a big difference in your case; the 4 cache cards are the same in both. There used to be a seller on eBait (on the mid-East Coast - Baltimore, IIRC) who was selling -11/70 CPU cards (I bought a whole spare set from him) but alas he seems to have gone away (or sold them all; a quick search, both on eBait, and in my email, didn't turm him up; I can institute a deeper search if need be). >From the blog of someone who got a KB11-A working, you'll really need KM11 cards; dunno if Guy Steele still has those clones he was selling. There are definitely some versions of Unix which will run fine on -11/70's without the FP11 (e.g. V6). The system binary is different for the with/without versions, though: in the assembler code which saves the state of one process before switching to another, there is code like: stfps (r1)+ which will probably get an illegal instruction trap in kernel mode on a machine with no FP11, and is therefore conditionally assembled (depending on if the particular machine the system is being built for has an FP11). Perhaps the later BSD versions look for the FP11 on startup, and adjust their behaviour appropriately, but I'm not familiar with them. V6 as distributed contains system binary for an -11/40, which will run on _any_ -11 UNIX will run on, and can be used to build appropriate system binary. (Diversion: I've never found out whether the KB11-B and KB11-C of the -11/70 used/could use the same backplane or not. By examining the prints for the boards of the FP11-B and FP11-C, and seeing on which pins they exchanged signals, and what signals they exchanged with the rest of the CPU, and on which pins, it should be possible to work it out. Ditto for the M8133 ROM and ROM Control of the KB11-B, replaced with the M8123 in the KB11-C.) (Interesting factoid: the M8123 is the only card shared between any variant of the -11/45 and -11/70: both the KB11-C and KB11-D use it. Of course, I think we're still missing a wirelist for the -11/70 backplane, of any variant; and the ECO history. There appears to have been at least one poorly documented upgrade; see here: http://gunkies.org/wiki/MK11_memory_system#CSR_Access for more.) Noel
Re: The precarious state of classic software and hardware preservation
> From: Adrian Stoness
> [M?]iror everything guys make copies and stash
> From: Paul Koning
> The web can make things perpetual if they are stored redundantly ...
> But anything centralized is just as vulnerable as any centralized copy
> ever was, whether from risk of fire or flood, or abandonment.
I've been thinking about this issue for a while (although I tend to have a
long scope, e.g. looking forward to a time when everyone currently on this
list is dead; so I think things like 'failed states' need to be a concern
too), and I think history has a key lesson for us.
I've been reading up on the history of the Greek cities after the
Pelponnesian War, down through the War of the Successors (the Diadochi) after
Alexander the Great died. One book I read said that the only surviving source
for many major periods in this stretch was Diodorus (a Greek historian from
Syracuse in the first century BC); he wrote a history of the world in 40
volumes, only 15 of which survive today complete. The sad thing is that there
_was_ a complete set in the library at Constantinope, as late as 1453 (and we
know what happened then). So it survived the best part of 2K years, and was
then lost; the parts that _did_ survive, did so because there were copies in
other libraries.
So the lesson is clear: we need to _replicate_ stuff, in a geographically and
nationally distributed way.
The mirroring of Bitsavers is _very_ good news. However, even in the class of
stuff that it focuses on, e.g. old manufacturer documentation, some things
don't make it in there, but do exist in other online repositories (e.g.
Manx's collections). So one thing we need to do is come up with something
like Bitsavers, but with more curatorial work-sharing. Al has done an
_incredible_ job, for which we are all deeply in his debt - but it would be
good to come up with some way to help him.
(E.g. I've been adding links to online versions of manuals, in articles on
older DEC stuff I'm doing the CHWiki, and I often find things which aren't in
Bitsavers. But sending Al an email saying 'hey, xxx is {here}, you might want
to upload it' is just putting all the load on him.)
Getting all this stuff into the replicated, mirrored system is a key priority.
> And in the case of digital data the added complication is the loss of
> the necessary technology.
Multiple independent copies will of course help with this (very real)
problem. The mirrors will likely be using different hardware, and will turn
it over at different times.
We could definitely use more mirrors, though - and geographically
distributed: it looks like there are current (non-US) ones in the UK, and
in Germany - more would be good. New Zealand? Australia? Maybe Japan and
India?
Individual volunteers aren't really what we need ('when everyone currently on
this list is dead'); it needs to be institutions.
> The Long Now Foundation has done some good thinking about this; some
> others have as well.
Jerry Saltzer thought about this, especially the 'generations of hardware',
and 'software formats' (e.g old Word docuents) issues. See:
"Technology, Networks, and the Library of the Year 2000"
http://web.mit.edu/Saltzer/www/publications/inria/inria.pdf
(particularly Section 4.3 "Persistence"), and also:
"Fault-Tolerance in Very Large Archival Systems"
http://web.mit.edu/Saltzer/www/publications/fault-tol/fault-tolerance.pdf
> I'd say more of us need to be more paranoid about mirroring stuff.
Yes. Don't just use a link, copy stuff down to a place _you_ control. (I.e.
not Google Drive. Nothing against Google, but their business might go
somewhere different, like Geocities, etc.) I have a large collection of
down-loaded stuff. Already I've run into cases where stuff has gone offline,
and without my local copy...
Noel
Re: Apple cube cleaning
> rom: Paul Koning > WD-40 is a good solvent to use for adhesives stuck to plastic. It's > unlikely to hurt the plastic but it will soften the glue. My go-to solvent for non-ionized glue residues (use water for ionized) on all sorts of materials has been, for many years, mineral spirits (US name; 'white spirit', in the UK): https://en.wikipedia.org/wiki/White_spirit It scores highly on both i) 'doesn't harm underlying material' and ii) 'softens residues' axes. (I've mostly used it on books, to remove stickers, but my experience should transfer to use on computers.) > As always, check on a hidden part of the case to make sure the > particular plastic doesn't object to the stuff you're using. Sage, and important, advice for _any_ removal method. Noel
Re: Looking for info on memory
> From: Nigel Johnson Ham > an 11/23 will not work without bank zero memory It depends on what you mean by 'work'. If you mean 'ODT does not operate correctly', or 'the CPU won't run', I can assure you that neither of those is correct. Here is a recorded log from a session earlier today on a system here next to my desktop: it contains a KDF11-A (in slot 1Left of a Q-Q backplane) and a console DLV11-J (in slot 1Right), and no other cards: ^@^@ 00 @777560/00 @777564/00 777566/00 777570/? @777640/17 777 @/000777 @777640G Cmd: 177640 @^@^@ As you can see, ODT is working,and the console registers are all responding OK. The thing at the bottom is that hack of putting a small program in the PARs (UIPAR0, in this case). The "Cmd:" prompt is where I told my console program to send a 'break' down the serial line to the -11, stopping the CPU. (The 'run' light had been on, after the "777640G".) (Note: The PAR hack doesn't work in J-11 CPUs; they won't do instruction fetches from PARs.) To confirm that I'm not BSing you, can someone else on the list please do this on their KDF11-A, and confirm that it produces the results I show about? Thanks. > All I get is output of 173000 and the no ability to input. If that's with just a non-LSI11 CPU card and the console serial line, the machine has a problem. As you can see above (the "777560/", etc were my type-in), you should be able to talk to ODT on a KDF11 (and I tried a KDJ11 yesterday, it worked too). (I don't recall if the LSI-11 types _anything_ when started with no working memory at 0; if anyone wants to know, I can fairly easily try it, I have a bunch of working LDI-11's, both quad and dual cards). Noel
Re: Looking for info on memory
> From: Nigel Johnson > I will wait with bated breath! First things first; did you get either/both CPU's running ODT OK in a system containing just i) the CPU card and ii) the console serial interface? Noel
Re: Looking for info on memory
A couple of comments on a number of things touched on in this thread: > From: Nigel Johnson Ham > Ah, well there you see the end of my technical knowledge. My observation is that since varying QBUS PDP-11 CPU's can be swapped in and out (unlike UNIBUS PDP-11's, where the CPU's backplane and front panel are not interchangeable between models), and QBUS machines were therefore often upgraded over their lifetime by switching in a CPU, when starting out with a new machine, one should _always_ start by working out what kind of QBUS backplane one has, and going from there. The BA23 is the one that's part Q/CD and part Q/Q. > No, I don't know if the CPU is good (it is a dual-width KDF11-A btw), > ... > I do have an 11/73 dual width board arriving tomorrow > ... > it is crashing into ODT and not accepting input from the console, which > I remember was a symptom of no bank 0 memory. That's true of all LSI-11's (and it threw me for a while when we first ran across it), but KDF11-A's and KDJ11-A's work fine with _no_ working memory in the machine: i.e. just a CPU board and a console will work fine (as in, ODT works, and one can examine what few registers are on the bus). (I had previously fried the KDF11-A; just tried the KDJ11-A. Probably the KDF11-B and KDJ11-B work too, but I'm toolazy to try them at the moment.) So if a machine with _just_ a CPU and console doesn't work, you've got a problem; but it shouldn't be too hard to find it, with only two boards. > From: Joshua Rice >> "many boards designed for Q/CD slots (such as PMI cards) do not avoid >> the QBUS pins on the CD connectors which contain 'hazardous' (to TTL >> circuitry) voltages." I should note that that text is somewhat questionable; I recently checked the list of PMI pins, and I didn't see any that conflicted with 12V pins on Q/Q slots. But definitely plugging a PMI card into a Q/Q slot will damage it: MicroNote 28 says "MSV11-J MODULES CAN[NOT] BE PLACED IN A Q/Q BACKPLANE SLOT. IF THIS IS ATTEMPTED PERMANENT DAMAGE WILL BE DONE TO THE BOARDS". > From: Jerry Weiss > I don't believe ODT is dependent on working memory. On LSI-11's, it us. Location 0 must respond to a read cycle, or the CPU will spin trying to read it, _before_ ODT will start. Noel
DEC ML11 (Was: DEC KM11 (Was: DEC KL11))
> From: Tony Duell > Were there 2 things called the KM11? > The KM11 that I know is the maintenance unit > From: Paul Birkel > I think that we're all talking about the ML11-A, or at least are > intending to ... although the Subject line has been erroneous from the > get-go ... Well, at least your brains are working, unlike mine! (Age starting to catch up with me?) Yes, the ML11; I tried to correct the erroneous 'KL11' and changed the wrong letter! Noel
Re: DEC KM11 (Was: DEC KL11)
> From: Paul Koning > But the sector format is a different matter. If it's designed for > PDP-11 and friends, presumably it has a 512 byte sector size. For > PDP-10 or -20 use you'd presumably want a sector size consisting of > some round number of 36 bit words. Actually, the -10/-20 MASSBUS situation is even more complicated than that. The MASSBUS can operate in 16 or 18 bit data width (for everyone else; this is totally different from the Q16/Q18/Q22 of the QBUS, which is _address_ width), so it can support 36-bit words directly, using two extra data lines. So for the RP04 and other disks, and their 'controllers' (at least, the part that's in the device), they have to be able to turn the bit-stream from the mass storage device into 18-bit wide words. (And they actually have different sector formats depending on whether they are in 16- or 18-bit mode.) What the KM11 does, I don't know (I'm too lazy to go look at the TM); I would not at all be suprised to find that it can _only_ operate in 16-bit mode (i.e. the array of memory chips is 16 bits wide, and it just ships a line at a time from that out in parallel, so there's no way to even produce 18-bit wide words). The name of the device (KM11) adds weight to that supposition. Noel
DEC KM11 (Was: DEC KL11)
> From: Mark Kahrs There's a typo in your original Subject: line: the KL11 is a very early UNIBUS (probably the very first UNIBUS device ever, looking at the board's Mxxx number) asyn serial line interface: https://gunkies.org/wiki/KL11_asynchronous_serial_line_interface > manx tells me that these documents were known to exist: > .. > But they are not online. I couldn't find out anything about the KM11 with a Web search, but I did see that it's in the DEC PDP-11 fiche set. My set does have the KM11 Tech Manual. I've never heard of the KM11, and as I said, there's nothing about it online. Is it worth doing a CHWiki page for it? (With the fiche, it would be pretty easy to whip up one covering the basics: functionality, component boards, etc. > So I can't say whether they are 18 bit compatible. Huh? The KM11 doesn't plug into the UNIBUS (or QBUS); it's a MASSBUS device (a solid-state storage device, actually), so it plugs into an RH11 or RH70 or something like that. (I should work with the VAX MASSBUS controller, too.) So the question 'is it 18 bit compatible' makes no sense. Noel
Re: DEC UNIBUS and use of cassette
> From: Bill Degnan > Was there a UNIBUS storage system that used a cassette player as the > storage device .., rigged to send receive signals via a serial card > connection. Yes and no. There is the TA11 Magnetic Tape Cassette System, which used the TU60 Dual DECasette Transport (I need to create a page for that in the CHWiki), but it uses a special controller card, the TA11 Magnetic Tape Cassette controller: https://gunkies.org/wiki/TA11_Magnetic_Tape_Cassette_controller There is a small cheap tape system which used a stock serial interface to talk to the computer, the TU58, but those used DECtpe-II cartridges, not standard casettes. Noel
RE: DQ11 prints needed
> From: Jay Jaeger > BTW, I have only the sales brochure for the DM11, near as I can tell. > 114X-00871-1715/J . If you want me to drag the box of sales lit from > the garage, and scan it, me know - could do it next week. No major need for it; I found the DM11-AA Tech Manual in my PDP-11 fiche set. So I doubt the brochure would answer any of the remaining questions; we'd probably need the Engineering Drawings for that. But there's so little on the DM11, it might be interesting to see the brochure. The big issue with the TM is that it has the same erroneous diagram for i) the boards in the DM11-A, and ii) their locations in the backplane, as the one in DEC-11-HDMBA-A-D, "DM11-BB modem control option manual", on pg. 1-5. The diagram there lists: M7245 Transmitter E M7244 Transmitter D M7245 Receiver M7242 Control C M7241 Control B M7240 Control A So two 'M7245's, with different functions listed! And no M7243... The DEC "Spare Module Handbook" shows: M7243 "DM11 transmitter D" M7244 "DM11 transmitter E" M7245 "DM11 receiver" so the M7245 probably _is_ the receiver; but this list shows that the 'transmitter E' card is the M7244, not the M7243 (as would be if the top line from the module diagram had a typo '5' for '3'. Hence my observation that it would probably take takethe ED tostraighten thins out. But as I said recently, no real need; the thing is a total canine, and I doubt very much that there are any left in the world. Noel
Re: DQ11 prints needed
> From: Jay Jaeger > ROTFL - especially given the earlier case, and since Noel knows about > you folks quite well.. The joke's actually on you: DQ11_RevL_Engineering_Drawings_Aug75.pdf 2021-08-09 14:05 I'd actually looked in http://bitsavers.org/pdf/dec/unibus earlier that morning (before I sent my request), and by chance I still had that browser window open. I suppose I could have done a screen-shot... > From: Al Kossow >> You aren't by any chance sitting any DM11-AA manuals, are you? :-) > probably. there are still quite a few drawings to go through That was mostly a joke. I mean, there are no DM11-AA documents of any kind online, so it would be interesting to get some (there are still a few un-answered questions); but there's a good DM11 entry in "pdp11 peripherals and interfacing handbook", 1972 edition, that enabled me to produce a decent entry: https://gunkies.org/wiki/DM11_asynchronous_serial_line_interface which is probably more than good enough - the interface is actually a dog, I doubt any still exist. Noel
Re: DQ11 prints needed
> From: Al Kossow > Date: Mon Aug 9 14:05:07 CDT 2021 Wow! That was _amazing_ speed, to get that uploaded so quickly (even if you had already scanned it in), considering I only posted my request at 14:32 EDT! Thank you very, very much: that allowed me to complete the DQ11 page on the CHWiki: https://gunkies.org/wiki/DQ11_NPR_Synchronous_Line_Interface The MM was unclear on many points (including the backplanes; the MM says, in 2.3.1.2, "double-system unit", making it sound like the option version uses a 9-slot backplane, but it's actually two 4-slot units). You aren't by any chance sitting any DM11-AA manuals, are you? :-) (The weirdest interface I've ever seen; the shift registers are kept in main memory, resulting in many DMA cycles _per character_.) Noel
DQ11 prints needed
Anyone have a set of DQ11 prints? The DQ11 MM is missing some important info, which is apparently only on the prints. Noel
DEC use of switching supplies (Was: Looking for VAX6000 items)
> From: Chris Zach > The older Vaxes had linear power supplies if I recall up to the time > of the Decsystem/2020 (when they went switching at last) Really? The H742 power supply: https://gunkies.org/wiki/H742_Power_Supply (well, technically, the associated 'bricks', such as the H744, etc) from about 1972 were switching supplies, so I'm suprised that the much later VAXen (any of them) used linear supplies. Of course, the H744/etc switching supplies didn't use a lot of the techniques used in modern switching supplies to make them small and light (e.g. stepping up the frequency to allow use of a small transformer); the H742 still has a whacking great transformer in it. But they were switching supplies (as we discussed here a while back at some length), not linear. Noel
KI10/KL10 I/O bus terminator
Hey, anyone need a KI10/KL10 I/O Bus terminator: https://gunkies.org/wiki/File:KIKLIOBusTerm.jpg (H867)? Since I don't have either a KI10 or a KL10, I'm unlikely to ever have a need/use for this one! :-) Noel
Re: PDP-11/05 (was: PDP-11/05 microcode dump?)
> From: Tom Uban > it has the early version M7261E Control Logic & Microprogram board and > the later version M7260 Data Paths board Ah, I'm glad someone found all that stuff I wrote up there useful. As always, I _think_ I got it all transcribed correctly, but do be on the lookout for errors! > it seems like an older/newer combination, but maybe that was common. I > would not have guessed that the four possible combinations would all > work together, but maybe they do? I honestly don't know. As far as I can tell, the DEC documentation doesn't even _mention_ the two different board generations; perhaps a sign that they are functionally interchangeable? (Although even the section on baud rate, in both DEC-11-HKDBB-A-D and EK-KD11B-MM-001, 4.11, doesn't even mention the early board. So maybe the manual just ignores the earlier version completely?) I don't have an /05 up and running at the moment, or I'd check all 4 and see if they all work. > Presently, the machine sometimes runs relatively well and other times > it does not. What are the failure symptoms? (It's almost certainly going to take a 'scope to fix it; I expect you have one?) I'd start by monitoring the CPU clock, and make sure it's running when the failure happens. (Note that the front console is handled by the microcode, so if the microcode isn't running, the machine will be totally dead. EK-KD11B-MM-001 has a good description of how that works.) > my initial messing with KM11 boards, reveals that I can step the > microcode with a KM11 in either the #1 or #2 position, but when two > KM11s are installed at the same time, they do not function properly > together. Is this expected or do I have an issue there too? Not sure. EK-KD11B-MM-001 (available at: http://www.bitsavers.org/pdf/dec/pdp11/1105/EK-KD11B-MM-001_Jan75.pdf and definitely something you need) says, at pg. 5-6 "KM11 switches have the same function in slots KM-1 and KM-2", and on 5-7 "permits the user who has only one KM11 to plug into either KM-1 or KM-2". So that _sounds_ like you should be able to plug two in together. The first indicates that the switches, the only input to the KD11-B from the KM11, are wired in parallel, and the only other thing on the KM11 are the lights, outputs. And why mention "user who has only one KM11", if having two is no use because one can't use two at once? Noel
H960 documentation
So, I have images of two different pieces of DEC documentation for the H960 series of racks/cabinets (the H950 is the bare rack; the H960 is the rack complete with various appurtenances such as side panel, stabilizer feet, etc). I had a request for them, so I've put them online. They are: http://ana-3.lcs.mit.edu/~jnc/tech/H960/DEC_cabinets1.jpg http://ana-3.lcs.mit.edu/~jnc/tech/H960/DEC_cabinets2.jpg The entry in the Direct Sales Catalog which covers them; includes illustrated breakdowns, and the DEC part numbers for everything. http://ana-3.lcs.mit.edu/~jnc/tech/H960/DECRackManual1.jpg http://ana-3.lcs.mit.edu/~jnc/tech/H960/DECRackManual2.jpg http://ana-3.lcs.mit.edu/~jnc/tech/H960/DECRackManual3.jpg http://ana-3.lcs.mit.edu/~jnc/tech/H960/DECRackManual4.jpg http://ana-3.lcs.mit.edu/~jnc/tech/H960/DECRackManual5.jpg The Assembly Guide; it shows in detail how all the bits go together (includes all the captive nuts, bolts, etc). Noel
Re: LCM
> From: Lars Brinkhoff > Chris Zach wrote: >> I'll drop by and see which CHAOSNet card it has. > It may have been removed when we worked on getting ITS booted. For a long time AI used a UNIBUS CHAOSNet card, plugged into an -11 connected up to AI via the Rubin 10-11 interface. (I'm not sure which -11; maybe the TV-11, but I think I remember there was another one used for the CHAOSNet? I think the same -11 that the AI Lab's 3-mbit Ethernet interface was plugged into. If I wasn't so lazy I'd look at TV > and see.) I'm not sure what happened after the Rubin interface died. Maybe they built another KA I/O bus interface (like the one on ML)? Config > might answer that question. Noel
Re: DEC weights
> From: Barry M > H960 120 lbs (not sure if this includes the side panels) The H960 has a whole constellation of appurtenances which can add to the weight: sides, back door, back mounting frame, top fan(s), floor screen, stabilizer feet, etc, etc. I happen to have an empty H960 (well, it does have the two top fans, which I was too lazy to take out - they are only a couple of pounds each) out in my garage, so I stuck it on a bathroom floor scale, and it seems to be about 100 pounds. If you want the weight on any of the other bits (above), let me know, it would be easy to weigh them. Noel
Re: RS64 on a PDP-8?
> Is there a controller to attach an RS64 disk to a PDP-8? The only > controller for the RS64 I can find is the UNIBUS RC11. Thanks. I never saw any reply, so I gather the answer is 'no'. I looked through the stuff on BitSavers for a bunch of other machines (IIRC, PDP-9 and PDP-12 and maybe one more), didn't see anything. The odd thing is that based on the RS64 manual cover/format, it dates to the same time period as the early -11's; and that manual is very careful to separate the drive info from the controller. Very strange that it wasn't interfaced to something else (like an -8 or -9). Maybe there was at one point a plan to do so, but plans changed? I note that there is an RS32 - I onder if they are any relation? Noel
RS64 on a PDP-8?
Is there a controller to attach an RS64 disk to a PDP-8? The only controller for the RS64I can find is the UNIBUS RC11. Thanks. Noel
Re: DEC PDP-11/45 backplane +5 ECO
> From: Eric Smith > The KB11-B (original 11/70) and KB11-C (later 11/70) have essentially > the same changes as from the KB11-A to KB11-D Speaking of which, two of the boards that are different in the KB11-D, from the -A, are _identical_ to boards in the KB11-C - the M8123 ROM & ROM control and the M8132 instruction register decode! (The M8123 is also different from the M8133 board in the KB11-B.) Pretty wierd that the -11/45 and -11/70 CPUs share two boards, but true! (The FP11 boards are the same in both, too.) > It sure would be nice to get backplane wirelists for all four (KB11-A, > -B, -C, and -D). ISTR a previous, un-fulfilled request for the -11/70 wirelist, so it's been missing for a while. We _might_ have the -11/45 wirelist: http://www.bitsavers.org/pdf/dec/pdp11/1145/1145_System_Engineering_Drawings_Jun74.pdf but it's short (pp. 128-132), so maybe it's not complete)? Two other print sets seem to have the same list: http://www.bitsavers.org/pdf/dec/pdp11/1145/1145_System_Engineering_Drawings_Jun76.pdf http://www.bitsavers.org/pdf/dec/pdp11/1155/MP00039_1155vol1_Mar76.pdf (pp. 45-49 and pp 131-135 respectively). > Also, I'm looking for a Field Maintenance Print Set for the RH70. Heh. I didn't see it online; the manual: http://www.bitsavers.org/pdf/dec/unibus/CSS-MO-F-5.2-27_RH70_Option_Description_Feb77.pdf is a CSS document, which makes no sense, because the CPU backplane is laid out to have room for four, so it's an integral part of the /70 CPU - so why is it a CSS product? Anyway, the print set listed there seems like it might be a CSS thing, too. I see that the CHM seems to have a set: https://www.computerhistory.org/collections/catalog/102749003 so maybe Al will take pity on us and scan it! I looked in my /70 print set, and although it contains all sorts of odds and ends (including MJ11 prints - which kind of half makes sense, since that was the only main memory option on early /70's), it doesn't have the RH70. (I didn't see the MJ11 prints on BitSavers, so I was thinking I was going to have to scan them, but on further looking I found them on deramp.com.) Noel
Re: DEC PDP-11/45 backplane +5 ECO
> From: Henk Gooijen > I have the M8120 and 4 M8121 boards (32kW bipolar RAM). It is a bit > weird, but in the 11/55 are also two G114 boards (4kW MOS RAM), IIRC. G114s? Those are the sense/inhibit module from the MM11-U/MJ11. Did you mean G401s? If so, one guess as to what happened there is that the machine used to have two banks of MS11 Fastbus memory, one bipolar, and one MOS, and some of the boards from the MOS bank (the memory control, and maybe some of the matrix boards) got removed? A KB11-[AD] can have two banks of MS11; the only type mixing allowed is that one can be all bipolar, and one all MOS; within each bank they all have to be the same. More here: https://gunkies.org/wiki/MS11_Semiconductor_Memory_System Interesting factoid: the M8110 and M8120 use the same etch. I'm not sure quite what the difference is (the MS11-A MM doesn't say, I couldn't find, and I don't think we have the M8120 engineering drawings, just the M8110); the M8120 has a bunch of ECO wires on it, and maybe there are component changes too. (I don't have an M8110 to compare them directly.) Noel
Re: DEC PDP-11/45 backplane +5 ECO
> I had a look at my /45 ... and it seems to ... look just like those on > Josh's. I'd really want to take pictures of mine .. so I can compare > them directly, though, not depend on visual memory. Yeah, mine (a late /55, actually) has the _exact_ same wires at Josh's. So that's probably the final ECO level. Image here: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/1145CPUBackPlane.jpg if you're interested. (Not a great image, but OK; I can try for a better one if there's a need.) > From: Henk Gooijen > Most of the CPU boards in the 11/55 are the same as the ones in the > 11/45 The -11/45, /50 and /55 are all the same CPU (KB11-A or -D), so the same backplane/everything, but differ only if they were sold pre-configured with the MS11 Fastbus memory. And of course some /45's (especially those sold before the introduction of the /50 and /55 as sales options - I have a /45 price list from Sep, 1972 which lists the /45 and /50 but not the /55; and one from Jan, '73 which only lists the /45 :-) were upgraded (possibly after sale, after the /50 and /55 appeared) with MS11 - or possibly some /50's and /55's had the MS11 removed at some point. So the number doesn't mean anything; one has to look at the boards. Noel
Re: DEC PDP-11/45 backplane +5 ECO
> From: Fritz Mueller > could I ask that you take some closeups around the Mate-n-Locks along > the top? I'd be very interested to see the board traces and the details > of the red bus wiring there. I had a look at my /45 (a later KB11-D - although I think the backplanes for the -A and -D are identical), and it seems to have heavy red wires attached to the upper row of Mate-n-Lok's that look just like those on Josh's. I'd really want to take pictures of mine (I don't want to take the backplane out - too much work - but I can get decent images with it in, I think) so I can compare them directly, though, not depend on visual memory. Noel PS: I wonder how many people here have -11/45's? ISTR one other, but they aren't common.
Re: DEC BA11-K KY11-L mounting brackets -- how?
> From: From: Fritz Mueller > two solutions come to mind -- the one you mention here with nut and > washer, or inserting a hex-head machine screw in the other direction. > Either the nut or the hex-head screw could then be secured with a small > combination wrench. Well, if you put the bolt in first (which you'd kind of have to do, if going from front to back, with the adapter already mounted to the KY11-L), you'd have to hold it in place while you offer the KY11-L up to the BA11-K. Which was why I was originally thinking, put the bolt in in the other direction, which you can do after you put the KY11-L+adapter in place. But that brings up another idea: put the bolt in place (on the adapter), use a first (thin) nut (with washer, if necessary) to hold it in place, then bolt the adapter to the KY11-L bezel, then mount the whole works up to the BA11-K. Not sure which would work better. I'd probably go with the 'pointing forward' bolt, and use a lock-washer (or one of those nuts with integral lock-washer), and then you can mostly tighten with a Phillips driver from the rear. But the extra washer might be easier to put together (if it doesn't push the KY11-L bezel too far forward). Noel
