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
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: 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: 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: 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
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
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
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
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 >> 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: 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: 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: 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: 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: 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: 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: 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: 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
> 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 > 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
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: 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
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: 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
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: 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: 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: 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: 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: 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: 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
KW11-L ON eBait
https://www.ebay.com/itm/393915648077 I've already got one for my machines that take one! 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
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: 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: 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: 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
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: 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
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?
> 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: 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?
>> 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: 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: '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: 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: 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: 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?
>> (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: 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: 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 will
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: 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: 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: 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: 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: 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: 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 >> 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 jus
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
> 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
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
> 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
> 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
> 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
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: 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&curid=6842&diff=25463&oldid=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
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
[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
eBay: PDP-11/70 backplane?
This: http://www.ebay.com/itm/252820125010 looks like it might be an -11/70 backplane, but I'm too lazy to look up the part number. Noel
Re: eBay: PDP-11/70 backplane?
> From: Pontus Pihlgren > The 11/70 backplane is wirewrapped. Oh, right you are! I don't know where my brain has fled to these days! It's actually an MJ11 (-11/70 core memory) backplane (I checked the part number - plus someone pointed out that you can see "MJ11" written somewhere). Noel
MC68K's on DEUNA's
So all the DEUNA's I've seen have L10 (ceramic package, 10Mhz) 68K's in them. Has anyone tried using anything else, and did it work? I _assume_ an x12 would work, but until someone has acutally tried it... The Pxx's (plastic packaging) might not work - according to the datasheet, they are 2mm wider than the ceramics (why, I have no idea - it probably means they aren't interchangeable, which makes no sense at all to me). Noel
Re: MC68K's on DEUNA's
> From: John Wilson > I think this is DELUA? Yes, that's right - sorry! > I'm getting old ... could have it wrong. No, _I_'m the one who's getting old! (But in this case, that's not it - I always get the names of those two mixed up!) > I'd be inclined to just try it. I hadn't bought anything yet... :-) In particular, there's a source of really cheap P12's, but if the 2mm width difference means the Pxx's won't fit, no use paying good money for them, right? > the definitely-fried CPU (right?) that's in there now? The definitely-missing CPU that's not in there now, actually! ;-) Noel
RE: MC68K's on DEUNA's
> From: Bill Gunshannon > Considering that I have never seen any sockets that were 2mm different > in width ... I really can't imagine any CPU not fitting. I think you're right. I took another look at the drawing, and I'd been looking at the package width dimension: there's also a separate pin-pin distance (horizontal), and that _is_ the same for plastic and ceramic. Ooops! Sorry. Noel
Re: MC68K's on DEUNA's
> From: Bill Gunshannon > I doubt Motorolla was in the business of custom making different size > chips, even for DEC. So, that triggered a question in my mind: why was DEC using the 68K on this board, anyway? They had plenty of in-house chips the could have used, e.g. the J11. The MC68000 had only a 16-bit bus, so it's not that dissimilar in capabilities. Why buy out? Did Motorola offer them a price they couldn't resist, or what? Noel
PDP-11/20 in Iowa (x3)
> From: Philipp Hachtmann > The 11/20 is the simplest 11 as far as I know. 'Simplest' in what sense? They certainly aren't the easiest ones to understand, with all that random control logic! The -11/04 is far easier to understand (for me, at least; YMMV). > From: Ethan Dicks > Was there ever a quad MOS memory board for the 11/20? I'm pretty sure there was never a UNIBUS quad memory card from DEC. > if anyone knows where to get a crate of 110V Boxer fans for around > $5/each, let me know New ones (not exactly the same as the originals, but the right size in the X/Y directions, if not identical in the Z, and 110V, with the same kind of power connector) are available on eBait for around $10 each. Look for "120mm 110V fan". Noel
Cross-talk square-wave?
Hi, a question about generic analog stuff. In the process of getting SD cards to work, Dave is seeing square-wave noise on a line. (1V of square wave, with pulses about 400ns long, running at 375kHz.) The line runs through a flat cable of modest length, along with other signal-carrying lines. (No, we were not smart, and didn't put ground lines between each pair of signal lines!) Could cross-talk cause this kind of noise? We would have thought that you'd only get spikes, associated with the rising and trailing edges of a signal in a parallel wire, not a whole square-wave. During the constant-current period in the middle of the pulse, there shouldn't be any cross-talk? Is there some mechanism I/we don't understand that could do that? (My guess is there's a leakage path in the circuitry on one end or the other, not cross-talk in the cable, but...) Thanks! Noel
Re: Cross-talk square-wave?
> From: Dwight Kelvey > Is there any load resistance at the end of the line? Yes, 270K to ground (i.e. pretty large). How does that have an effect on whether cross-talk can create a square wave? Sorry, I'm not understanding. Noel
RE: Cross-talk square-wave?
I should mention that this is a pre-prototype; the final thing won't have a cable at all; so this isn't a fundamental issue with the design (if it is cross-talk). And the SD card isn't even plugged in when we see this - if it is cross-talk, it has to be some other signal carried in the cable. We're just trying to figure out how cross-talk can possibly produce an induced square-wave. Noel
Re: Cross-talk square-wave?
> From: Eugene (W2HX) > I am still not convinced it is coupling at all. ... I just don't think > you can get square waves from square waves. ... > it is even harder to believe one could successfully couple a square > wave onto such a transmission line unless the signal is actually being > asserted on the line at a low impedance ... > Looking at this picture ... this shows exactly what I would expect to > see with cross talk the little glitches on the CS line that correspond > to edges on the clock signal. Exactly. That sort of cross-talk we understand (and have seen before). But a square wave? How can that be? That was the motivation for my original post. It's not super-critical to understand, because like I said, this is on a pre-prototype, and the actual unit will be arranged nothing like this (no cable, etc, etc), so we're just going to fix this with whatever kludge makes it go away, so we can focus on the things we really do need to work on. But we'd still like to understand what is happening here, and how. Could cross-talk (of whatever form, inductive or capacitive) do this, or does this more or less have to be signal leakage (on the board at one end, or the other) somehow? Noel
Re: Cross-talk square-wave?
> From: Allison > FYI this is the same problem designers hit with DRAMS back 40 years ago. This didn't ring (pun not intended) a bell for me; can you say a bit more? > From: Chuck Guzis > I'll offer a suggestion that if your SD card *must* be a significant > distance from its host Like I said, this is a pre-prototype; on the production units, there will be _no_ cable. The SD socket will be about 1-2" from the FPGA. > From: Dwight Kelvey > this behavior on my PDP-8/e where a 7474 flip flop chip was bad. The > input looked great and the output was "half baked" There's no chip at all on the driving end of the line (just that 470K resistor); we see this with the SD card _unplugged_. And we see the exact same thing on several lines. I'm still not clear, from the discussion, how exactly that nice 'square-wave' interference is happening - could it be capacitative crosstalk? (I'd have thought capacitative cross-talk would be inverted - driving a positive voltage on one 'side' of the 'capacitor' would, I would think, induce an oppposing voltage on the other. But I'm clearly no EE! :-) Noel
Re: Cross-talk square-wave?
> From: Brent Hilpert > I don't have a full enough picture of the circuit and circumstances to > provide a definitive suggestion but, some principles: > ... > It's not clear C-coupling is what's going on here (the wave shape looks > pretty sharp for what I understand of the circuit/layout). Thanks for taking the time for that detailed message. I suspect, however, that Jon Elson has nailed it (thanks Jon :-); if that's what's happening, it explains why we couldn't understand what the devil was going on! > (You've mentioned both 470K and 270K for the R, could make a difference > to the analysis). Yeah, that was just a typo; going from memory. Noel
Re: KDJ11-B PDP 11/73 getting stuck in Exit standalone mode diag #56
> From: Glen Slick > the Q22/Q22 backplane is not good for an 11/83 CPU ... M8190 boards and > both have PMI signals on the CD half of the CPU board. So I seem to recall hearing tales of PMI cards emitting smoke when plugged into a Q/Q/ backplane. That doesn't seem to have happened here: >> I confirmed the KDJ11-B works fine in a BA23, getting past test 56. So I wondered if his off-brand backplane didn't have +12V or -12V wired up - whatever it is that causes the damage. So I compared a list of PMI pins with a QBUS pinout, trying to see if it was the +12V or 12V that would be the problem. However, I don't see any PMI pins that conflict? (Well, some of them are ground, or +5V, but will that harm bus driver TTL?) Here's my list of PMI pins: CB1 PSSEL CD1 PUBMEM CE1 PBCYC CF1 PUBSYS CH1 PHBPAR CJ1 PSBFUL CK1 PLBPAR CM1 PRDSTB CP1 PBLKM CR1 PBSY CV1 PUBTMO DB1 PWTSTB DC1 PBYT DD1 PMAPE Anyone have any idea which pin(s) is the issue, when plugging a PMI card into a Q/Q slot? Noel
Re: Info Needed: DATARAM DR-111 PDP-11 Unibus 16KW Core Memory
> From: Steven Malikoff > I've scanned the full version of this manual that comprises the > installation guide, description, system specifications, theory of > operation, timing chart, full schematic and manifest. Oh, wow! You get the Documentation Preservation Gold Star! A needed, and useful, manual. Thanks very much for doing this. Noel
Re: DOS-11/BATCH-11 manuals on Ebay
> From: Mattis Lind > One of them does not seems to be at bitsavers. That's on my list of items to get. I have a page-feed scanner, so will easily be able to scan this (although I'll have to get some instruction on exactly what incantation to use to Acrobat to turn the TIFF's into a PDF; apparently "PDF/A", supposedly for archival purposes, is apparently not in fact desirable for that). Noel
Re: RTX-2000 processor PC/AT add-in card (any takers?)
> From: Sean Conner > I really think it's for *this* reason (the handler() example) that C > doesn't allow nested functions. I wouldn't be sure of that; I would tend to think that nested functions were left out simply because they add complexity, and didn't add enough value to outweigh that complexity. (In ~40 years of programming in C, I have never missed them.) C seems (well, until the standards committees got ahold of it) to have added things as a demonstrated need was felt for them (see DMR's evolution of C paper), and maybe they just never found a need for nested function definitions? I suspect that Ken probably knows; he's not (AFAIK) on the Unix History list (TUHS), but several of his early co-workers (including Stephen Johnson, who did PCC) are, and could relay a question to him, if it were asked over there (if we really want to know). Noel
Re: If C is so evil why is it so successful?
> From: John Wilson > It would have been nice if it had stolen FORTRAN-77's idea of declaring > a variable in the size that you want (I'm talking about INTEGER*2 vs. > INTEGER*4 etc.), instead of just "knowing" what the difference is > between int and long Back in the late 70's, trying to write network code, even before we actually ported anything (but could see it coming in the distance), it became clear that C's type system was pretty worthless. We defined a whole new type system, using syntax of the form 'XXXY', where 'XXX' was the type (unsigned, bit field, etc) and 'Y' was a character giving the length (1, 2, 4, bytes; the machine's native word length - 'w'; etc, etc). So 'bitw' was a bit-field of the machine's native word length, 'unss' was a 16-bit unsigned, etc, etc. So then we had an #include file "pdefs.h" which, depending on the setting of 'cc' -Dxxx command flags (this was before they starting getting set automatically to indicate the machine type) included '11defs.h' or '68defs.h' or whatever the case might be), so there were no #ifdef's in the source files at all. We used this everywhere, and it worked very well indeed. So well that, at one point, on a dare, I moved our real-time OS to a new architecture (the 29K) overnight (really - started at around 5PM one day, and had it running the next day sometime - forget exactly when). Well, I'd already gotten the debugger (written in C in the same style, with a bit of assembler for the low-level operations) running on the 29K, so I knew where all the pot-holes were, but still... Most of the code modules were supposed to be portable .. and they just were. Didn't have to touch it, just compiled for the new machine (so the exact same source compiled for both, no ugly #ifdef's, just compile and go). > if it's not portable then it might as well be assembly and get the > benefits that come with that. Sorry, I don't agree. It _is_ possible to write portable code, but even ignoring that, the benfits of writing in a higher-level language (good control structures, complex expressions, etc, etc) are well worth it. I had the pleasure of working with the best MACRO-11 code I'e ever seen (a real-time OS called 'MOS'), where the guy who wrote it (Jim Mathis) had worked out a sdet of macro definitions that allowed him to define structures (and the PDP-11 had an addressing mode, with a pointer to the base of the structure in a register, that allowed you to access elements) - but even so, it wasn't as good a tool as C. Like I said, control structures, complex expressions etc all make things so much clearer in C - which means they are easier to understand (when in someone else's code), easier to debug, easier to modify, yadda-yadda. Unless I were writing code that I _simply could not do in C_, I would not use assembler. Noel
Re: If C is so evil why is it so successful?
> From: Alfred M. Szmidt > No even the following program: > int main (void) { return 0; } > is guaranteed to work I'm missing something: why not? Noel PS: There probably is something to the sports car analogy, but I'm not going to take a position on that one! :-) Interesting side-question though: is assembler more or less like a sports car than C? :-)
Re: If C is so evil why is it so successful?
> From: Rod Smallwood > All computer computer languages are only as good or bad as the person > using them. True words. I'd rather work on a program written in assembly language, done by a _really good_ programmer, than a program written in _anything_, done by a bad one. (My classic example: that MOS OS done by Jim Mathis in PDP-11 assembler.) Noel
Re: Harry Huskey, Bob Taylor -- sad news
> From: Al Kossow > Harry did an oral history at CHM There are also a pair at the Smithsonian: http://amhistory.si.edu/archives/AC0196_husk730419.pdf http://amhistory.si.edu/archives/AC0196_husk720309.pdf and the CBI did one too, but alas it does not seem to be on-line (it's not in their OH index, and although Google searches for other ones from there turned them up, not this one): Harry D. Huskey, OH-83 Interviewer: Christopher Evans Date of interview: 1976 Anyone have a pointer to it? Noel
Extra copy of DOS Programmer's Handbook available
I have an extra copy of: DEC-11-SERA-DDisk Operating System Monitor Programmer's Handbook, February 1971 if anyone has a use for it. Noel
Horrible error in "pdp11 bus handbook"
Just a heads-up that the 1979 edition of the "pdp11 bus handbook" has a very serious editing error in it, in the description of UNIBUS arbitration. On page 38, immediately after step 13 of the NPR Arbitration Sequence ("13. SACK must be negated before BBSY may be negated."), it says "A bus master may issue an interrupt command to the interrupt fielding processor." Despite its location in the text, this does __NOT__ apply to the "NPR arbitration sequence" being discussed above. There is an editing error - this text is (or _should be_) separate from the "NPR Arbitration Sequence" section just before it; it belongs with "BR Interrupt Arbitration Sequence" - that header (on pg. 39) was put in the wrong place. The 1975 "peripherals handbook" has very similar text, but it _does_ have a section header after the NPR details (line 13 is identical), and before the start of the (very similar) BR text ("A bus master that has gained control ... through a BRn/BGn arbitration transaction may issue an interrupt command to the processor."). Noel
Re: Did we miss the 20th anniversary of classiccmp?
> On Apr 21, 2017, at 1:26 AM, Pontus Pihlgren wrote: > It makes me wonder, what is the oldest still running mailinglist? I don't have access to my _old_ email (i.e. from the 80's) to confirm this, and I don't think they still have copies of the very oldest mail, but the IETF list has got to be pretty old (first meeting was early '86, but they may not have had a mailing list for a while, yet). Risks started in the summer of '85, so that one's older. Noel
Copy of UNIBUS Interface Manual available for trade
Hi, all, continuing the process of getting rid of duplicate DEC documentation: I have an extra copy of the the UNIBUS Interface Manual, Second Edition (DEC-11-HIAB-D); I'm interested in trading it for any interesting PDP-11 documentation or stuff you'd like to part with which I don't have. One DEC book I really crave, but _cannot_ find, is the "PDP-11 Systems Handbook" ("Featuring: MicroPDP-11/83 MicroPDP-11/73 MicroPDP-11/53 PDP-11/84"). If anyone has an extra copy of this they're willing to part with, please let me know, I have a lot of odds and ends I can trade (or plain $$$ if that works). Noel
RE: Did we miss the 20th anniversary of classiccmp?
> From: Bill Gunshannon > Surely there were Mailing Lists prior to the existence of the Internet, > yes? Absolutely. They started on the ARPANet, fairly early on. E.g. SF-Lovers (one of the first 'non-mission related' mailing lists) started in September, 1979, and MsgGroup (an 'official-busines-related' one) considerably earlier, in June 1975. Header-People started at about the same time, but alas, we have lost the first two volumes of the archives, so I don't know exactly when. I maintain archives of these lists on my page: http://mercury.lcs.mit.edu/~jnc/tech/archives.html if anyone wants a look. The variety of header formats is kind of amusing. > Do any Lists that started on UUCP still exist today? Perhaps. Do you count newgroups? (Of course, UUCP considerably post-date the ARPANet.) Noel
Re: Genuine KM11 board
> From: Tony Duell > Are any DEC enthusiasts here jealous of this Actually, not me! I'm an old enough campaigner that I recall when real light bulbs were standard, and they were a total PITA! So when LED's arrived, we all though they were the greatest thing since sliced bread. So I'm now very happy with my LED-equipped KM11 clones - I still have that anti-bulb bias! :-) Noel
Re: Vaxstation 3100 of odd sort on epay
> From: Jim Stephens > I'm interested in whether this is a wound down or ongoing Dec material > operation, or the operation of an e waste recycler. > Vendor name on ebay is EFI. May have other aliases. Oh, Efi! All hardened DEC collectors know about Efi (well, many of us do :-). They are indeed an ewaste recycler. Good people. The company name is ComUsed and/or TopLine. They used to be in Silver Spring (the place was the personification of 'gomi' from "Neuromancer" :-), but it got too small, so they moved. (Sniff. I miss the old place!) They got started on DEC stuff when they bought some DEC collector's entire collection after that person passed; most of that's long gone (it's been _thoroughly_ picked over :-), but they occasionally get more DEC stuff. Noel
Re: FTGH Large amount of DEC/Misc Classic computer hardware
> From: Guy Sotomayor Jr >>> We need to move our business and I have about a ton of >>> classic cimputer junk in the SFBA that need to go or get scrapped: >>> Symbolics 3645? (from Guy Sotomayer a few years back) >>> PDP 11 > I stopped by and picked up some stuff from Peter today. ... He did > mention that he has to be out of his space by May 31st and anything > that isn't picked up will be scrapped. > I did take some pictures that I'll put up sometime tomorrow but what > Pete has on his list below seems pretty accurate. WHat kind of -11, do you happen to recall? I assume someone will have grabbed the 'Bolics machine... Hyper-desirable. I do hope someone will be able to scoop up all this stuff. Even if all you do it put it up on eBay, that's still better that having it go to scrap! Noel
Re: BBS software for the PDP 11
> From: Systems Glitch > You need split I&D for 2.11BSD ISTR reading that the network code runs in Supervisor mode, so you need that to, technically (although all -11s CPUs with Supervisor also have I+D, and vice versa). Does the 2.9 include networking code? If so, it must use overlays like crazy on a 'small' machine (/40-/34/-/23)... Noel
Re: BBS software for the PDP 11
> From: Chuck Guzis > Well, okay--but then let's be period-correct. The PDP-11 dates from > 1970, when, AFAIK, BBSes, if they existed, were far from what people > think they were. You're thinking of the -11/20, released in 1970. But that was only the first PDP-11 model; the -11/23 dates from 1979, and the last -11 model, the /93-/94, was released in 1990. Noel