test-drb February 2022

test-drb@ccmp.vtda.org

99 participants
82 discussions

by a.carlini＠ntlworld.com

I have three AlphaServer 2100 systems in storage in the UK (Oxfordshire). The storage, however, is due to be demolished (soon, but no fixed date). I won't have room to store these three systems, so if anyone would be interested in offering them a home, then please get in touch! I can probably get some pictures in the next day or two. These systems were SMP Alphas and could sport as many as 4 CPUs. I'm not sure of the configuration of these systems but I can probably find that out soon. They have not been run since ~2003 so they may be in need of some TLC. OTOH they are not rusted to death so you have a chance of getting them back to life. Just so you know what you might be dealing with these systems are about: 700mm H x 430mm W x 810mm L. I can't find the weight in any of my references right now but they are very heavy. Three people can move them up a slight slope with some effort but you would not successfully lift it into a car (assuming that it would fit). I'm planning to dismantle them to move them (i.e. remove PSU/PSUs etc. until they are light enough to move). A tail-lift would probably be the sane way to go (and is, indeed, how they got to their current location. I'm hoping that someone can step forward and offer one or more of these machines a new home. Please contact me off-list (once you're sure you understand what you are getting into :-)). Antonio -- Antonio Carlini antonio at acarlini.com

2 years

Installing an operating system on the 11/83 - update.

by rodsmallwood52＠btinternet.com

Hi All ????? I did find some RX50 images of the MicroRSX distribution. ???? So I fired up my DEC Celebris FX. It runs W95 and has a 3.5 inch floppy, a real RX33 5.25 inch drive and a CD-R. ?? Its accessible on my network so getting files onto it is not a problem. ??? So install putR.com , and transfer the image files. ? ? Huh! putR says the RX50 disk is write protected. Its not and the drive works normally with the disk from the MS DOS prompt. ? ?? So much for putR writes RX50's on RX33! ??? Rod

2 years

Racking a PDP-11/24

by robert.jarratt＠ntlworld.com

I am wondering if I have racked my 11/24 correctly. As you can see here: https://robs-old-computers.com/2022/02/10/pdp-11-24-progress/ I have put the CPU at the top and the two RL02 drives underneath. The problem is that the CPU enclosure catches on the RL02 underneath. There is a bit of play in the mounting bracket: https://rjarratt.files.wordpress.com/2022/02/cpu-mounting-bracket.jpg. With a bit of manipulation I can get the CPU to slide in. However, I am wondering if I have racked it correctly? I don't think there is room to move the RL02s down and it would presumably leave a bit of a gap below the CPU. There seems to be very little clearance between the CPU and the RL02 at the front but more at the back, but I am sure that the rails are mounted horizontally. Is it just a matter of tightening the big screws that hold the mounting brackets to stop the play? If so I am not sure I have a big enough screwdriver! Regards Rob

2 years, 1 month

Tandon TM 848-02

by bill.gunshannon＠hotmail.com

Does anyone have anything on the jumper settings for this drive? I would like to jumper it so it can read DEC RX01/RX02 floppies. I am looking at being able to read disks on a non-DEC systems but I would also like to be able to use it on my Andromeda card in a real PDP-11. bill

2 years, 1 month

RQDX3/RD31/RX50 jumpers

by rodsmallwood52＠btinternet.com

Hi ????? Is the correct setting: ?????? 1. DS1 on the RD31 and the RX50's move up to DU1 and DU2. ?????? 2. DS3 on the RD31 and the RX50's are DU0 and DU1 I've tried both and it still? tries to access the RD31 and the RX50 at the same time. Its on a standrd BA23 R

2 years, 1 month

Is The M9312 Boot Module Essential?

by jnc＠mercury.lcs.mit.edu

>> (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

2 years, 1 month

Is The M9312 Boot Module Essential?

by jnc＠mercury.lcs.mit.edu

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

2 years, 1 month

Is The M9312 Boot Module Essential?

by jnc＠mercury.lcs.mit.edu

> 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.p… 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

2 years, 1 month

Is The M9312 Boot Module Essential?

by jnc＠mercury.lcs.mit.edu

>> 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

2 years, 1 month

Information about an unknown IC

by clemarjr＠gmail.com

Hi I'm looking for information about Texas Instruments TB-759933 IC. Does anyone have the datasheet or any other information about this IC? Thanks.

2 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb February 2022