test-drb

test-drb@ccmp.vtda.org

101090 discussions

by robert.jarratt＠ntlworld.com

I had the H7140 PSU in my PDP 11/24 repaired a little while ago and I posted about it here: https://robs-old-computers.com/2022/02/10/pdp-11-24-progress/ I have since had the PSU fixed again and it came back a couple of weeks ago. When I installed it and applied power to the input, I heard a reassuring relay click. So I powered it on. The fans turned, but there was a crackle and I smelt something burning. I couldn't locate the smell, there were no lights on the CPU board, but the fans continued to turn. I had to leave it a few days and today I went back to it to check things a bit more carefully. All the power outputs of the PSU appear nominal. However, the ripple seems quite high, with an amplitude of 600mV on the +5V output: https://rjarratt.files.wordpress.com/2022/03/pin-1-5v-ripple.jpg. The DC ON light comes on, but the M7133 CPU LEDs show no activity whatsoever. There is no apparent damage to the CPU or to the M7134 that was also installed. So, I guess the component that blew up must be inside the PSU. 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? Regards Rob

2 years

PDP 11/24 - A Step Backwards

by robert.jarratt＠ntlworld.com

Its 600mV, but it is more of a spike than a ripple. Here is a trace: https://rjarratt.files.wordpress.com/2022/03/pin-1-5v-ripple.jpg Regards Rob > -----Original Message----- > From: Wayne S <wayne.sudol at hotmail.com> > Sent: 28 March 2022 23:15 > To: rob at jarratt.me.uk; Rob Jarratt <robert.jarratt at ntlworld.com>; General > Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> > Cc: Chris Zach <cz at alembic.crystel.com> > Subject: Re: PDP 11/24 - A Step Backwards > > How bad is the ripple? > Anyone on the list know what?s acceptable? > > > Sent from my iPhone > > > On Mar 28, 2022, at 14:46, Rob Jarratt via cctalk <cctalk at classiccmp.org> > wrote: > > > > > > > >> -----Original Message----- > >> From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Chris Zach > >> via cctalk > >> Sent: 28 March 2022 20:57 > >> To: cctalk at classiccmp.org > >> Subject: Re: PDP 11/24 - A Step Backwards > >> > >>> 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. Having hopefully eliminated all the power voltages > >>> it left me wondering if there was a fault on the CPU or in the PSU. > >>> Having had activity on those LEDs recently it seems most likely that > >>> it will be the PSU, particularly as *something* in there blew up. > >>> 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 suppose the fault could be > >>> something I can't see on the CPU board, particularly as there do > >>> seem to be some quite large spikes, otherwise I am not sure if there > >>> is anything else from the PSU that could prevent the CPU getting going. > >> > >> I'm on a nice long train trip right now but I recently got my 11/24 > >> running again. One thing that baffled me was it would not do anything > >> on the serial port. No ODT, no nothing. > >> > >> Turns out you really need to make sure the slots are filled properly. > >> The CPU top, then the memory map, then for the next 4 boards one has > >> to be either a properly configured MS11-PL (the 128kw board) or the > >> memory boards specific to that type of 11/24. Or you have to put > >> G7273's in the CD slots. > >> > > > > I have been reluctant to put everything back in, in case the PSU fries > something. And the ripple I noticed is certainly something that bothers me. > Previously I had a burning smell from the memory board. I have since > replaced all the electrolytics on the memory board, but I have not tried > putting it back in the machine since. Just checking my notes, it seems I have > had *intermittent* lack of activity on the CPU LEDs before, so it may be > worth trying to put everything back in, although the ripple makes me > hesitant to do so. For the record, right now I have only the M7133, M7134 > and G7273 installed. > > > > > >> Next you need proper devices or G7273's in the next two slots and a > >> proper terminator in the left sockets of the last slots and a G7273 in the > center slots. > >> Only then will ODT work. > >> > >> Another oddity is that the 5.25 inch box has +5 and +12 I think and > >> the > >> 10.5 has +5 and +15. There are different memory boards that work in > >> one and not the other, or both depending on jumper settings that have > >> to be right. Unibus drives me bonkers sometimes with the number of > >> different voltages requires (+5, +12, +15, +20, -15, etc....) It > >> doesn't help that the +15 and +12 are on the same pins. > >> > >> Plus it's possible someone screwed with some switches, make sure they > >> are set properly (ie: default is a good start). > >> > >> If you're still stuck next week drop me a line and I'll fire up my > >> 11/24 and see if I can replicate your failure. > >> > >>> > >>>> > >>>> 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. > >>> > >>> I had a console attached. There is nothing on the console. When I > >>> first got the machine I did get output on the console. But that was > >>> before the PSU first failed on me, which is quite a few years ago now. > >>> > >>>> > >>>> 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 run. Deposit a 0777 ('BR .') in a likely location (I usually > >>>> use > >>>> 0100 or 01000); read it back to make sure the write succeeded. (If > >>>> not, > >>> likely > >>>> either the UNIBUS or the main memory has a problem.) Start the > >>>> machine; the 'Run' light should come on - if you're lucky! > >>>> > >>>> Depending on which bin you wound up in, further assistance s > available. > >>> :-) > >>>> > >>>> Noel > >>> > >

2 years

PDP 11/24 - A Step Backwards

by jnc＠mercury.lcs.mit.edu

> 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

2 years

PDP 11/24 - A Step Backwards

by jnc＠mercury.lcs.mit.edu

> 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 run. Deposit a 0777 ('BR .') in a likely location (I usually use 0100 or 01000); read it back to make sure the write succeeded. (If not, likely either the UNIBUS or the main memory has a problem.) Start the machine; the 'Run' light should come on - if you're lucky! Depending on which bin you wound up in, further assistance s available. :-) Noel

2 years

PDP 11/24 - A Step Backwards

by jnc＠mercury.lcs.mit.edu

> 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

2 years

PDP 11/24 - A Step Backwards

by elson＠pico-systems.com

On 3/28/22 21:55, Jon Elson wrote: > On 3/28/22 17:22, Rob Jarratt via cctalk wrote: >> Its 600mV, but it is more of a spike than a ripple. >> > That's probably not real.? It looks like noise pickup from > the probe ground lead.? Try disconnecting the probe tip > and see if you still get similar signals.? I have seen > similar noise lots of times when measuring things with > switching power supplies.? The high frequency content is > pretty unlikely to be actually there on the power rails, > with a bunch of decoupling caps all over the boards. > > Jon >

2 years

Loss of Museum in Ukraine

by c.murray.mccullough＠gmail.com

Without getting political I was saddened to hear of the destruction of the Club 8-Bit museum in Mariupol, Ukraine. One can only hope that D. Cherepanov can rebuild his museum someday keeping classic computing in that part of the world alive. Murray--

2 years

FTGH: DEC Networks & Comm Buyer's Guide, Letterprinter 210/LA50 manuals

by toby＠telegraphics.com.au

Hi, Digital Networks & Communications Buyer's Guide 1987 April-June Also some DEC Letterprinter 210 and LA50 Printer manuals, ask for a list. For postage from Toronto Canada. --Toby

2 years

Webinar: Ethernet's Emergence from Xerox PARC: 1975-1980

by tom94022＠comcast.net

Ethernet invented in 1973-74 at Xerox PARC in Palo Alto, CA, evolved over many years. This April 13th Webinar will trace the history and development of Ethernet as a 10 Mb/s product up through the release of the DIX (DEC-Intel-Xerox) spec in 1980. This was the starting point for the ongoing IEEE 802.3 Standard activities. Speakers include Gorden Bell, Dave Liddle, Bob Metcalfe and seven other pioneers who were there for the transition. More detail at <https://r6.ieee.org/sv-techhistory/?p=1030> SVTHC website Register <https://www.eventbrite.com/e/ethernets-emergence-from-xerox-parc-1975-1980- tickets-301085664327> Tom

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

Jump to page:

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