Re: PDP 11/24 - A Step Backwards

[Brent Hilpert via cctalk]

On 2022-Mar-28, at 4:07 PM, Noel Chiappa via cctalk wrote:
>> 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.)

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.

[RC clock] => K1 OSC H/L
--> [4-bit counter w parallel load] => K1 MCLK H/L
--> LED
--> [driver] => K1 CHIP CLK H (fonz CPU clock)

The 4-bit counter looks to be generating some additional phases, 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, which is derived from K2 
BUS ACLO L which is input from BF1-in-funky-hex-box which I presume is a bus 
connector pin.

Tony mentioned checking ACLO.
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 to enable the CPU clock, as well as 
those other signals controlling the phase counter.

ref: pdfPg.152,etc of 
http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug80.pdf

Re: PDP 11/24 - A Step Backwards

[Jon Elson via cctalk]

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

Re: Loss of Museum in Ukraine

[Adrian Stoness via cctalk]

sad news to hear

On Mon, Mar 28, 2022 at 8:48 PM Murray McCullough via cctalk <
cctalk@classiccmp.org> wrote:

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

Loss of Museum in Ukraine

[Murray McCullough via cctalk]

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

Re: PDP 11/24 - A Step Backwards

[Matt Burke via cctalk]

On 28/03/2022 23:22, Rob Jarratt via cctalk wrote:
> 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
>

I think that's just switching noise. You appear to be zoomed in on the
point where the main switching transistor is turning back on. Here is a
trace from an H7100 power supply (connected to a 70A dummy load) for
comparison:

http://www.9track.net/posts/h7100_trace.png

If you turn on averaging mode on the oscilloscope (acquire menu) then
that should filter our some of the noise and you will be able to see the
actual ripple a bit better. It should be noted though that a
differential probe is required for accurate ripple and noise measurements.

Regards,

Matt

Re: PDP 11/24 - A Step Backwards

[Chris Zach via cctalk]

I have been reluctant to put everything back in, in case the PSU fries 
something. And the ripple I noticed is...

For the record, right now I have only the M7133, M7134 and G7273 installed.

Ok, I do recall that my 11/24 wasn't doing any ODT without some form of 
memory. When I configured a (broken-ish) MS11-PL in it did at least come 
up and allow me to load memory addresses and the like.


But no memory, no deal. I'd say figure out your PSU first, then memory, 
then stuff.


C

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

[Toby Thain via cctalk]

On 2022-03-28 6:34 p.m., Grant Taylor via cctalk wrote:

On 3/27/22 8:50 PM, Toby Thain via cctalk wrote:

Hi,


Hi Toby,


Digital Networks & Communications Buyer's Guide 1987 April-June


Can I get a bit more of a description as to what might be in that document?

I've got an (unhealthy) interest in old networking equipment and might 
be interested in it.






Sorry, I should have updated the thread -- the document itself has been 
claimed.


I snapped the TOC though: https://imgur.com/a/iB81d3U

Not sure if it is on Bitsavers.


--Toby

RE: PDP 11/24 - A Step Backwards

[Noel Chiappa via cctalk]

> 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: Webinar: Ethernet's Emergence from Xerox PARC: 1975-1980

[Grant Taylor via cctalk]

On 3/28/22 12:09 PM, Nigel Johnson Ham via cctalk wrote:
OK, it was wireless, but that brings up another surprise, that wireless 
ethernet came before wired :-)


As others have indicated, I think not.  ;-)

I recently watched the following videos of Bob Metcalfe:

 - Link - Ethernet Briefings in April 1978 by Bob Metcalfe (112 minutes)
- https://youtu.be/Fj7r3vYAjGY

And the follow up:

 - Link - Metcalfe's Law After 40 Years of Ethernet (19 minutes)
- https://youtu.be/f6CJA421aUo

The Ethernet Briefings video goes into fairly good detail comparing and 
contrasting ALOHA net and Ethernet.




--
Grant. . . .
unix || die

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

[Grant Taylor via cctalk]

On 3/27/22 8:50 PM, Toby Thain via cctalk wrote:

Hi,


Hi Toby,


Digital Networks & Communications Buyer's Guide 1987 April-June


Can I get a bit more of a description as to what might be in that document?

I've got an (unhealthy) interest in old networking equipment and might 
be interested in it.




--
Grant. . . .
unix || die

RE: PDP 11/24 - A Step Backwards

[Rob Jarratt via cctalk]

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 
> Sent: 28 March 2022 23:15
> To: r...@jarratt.me.uk; Rob Jarratt ; General
> Discussion: On-Topic and Off-Topic Posts 
> Cc: Chris Zach 
> 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 
> wrote:
> >
> > 
> >
> >> -Original Message-
> >> From: cctalk  On Behalf Of Chris Zach
> >> via cctalk
> >> Sent: 28 March 2022 20:57
> >> To: cctalk@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 

RE: PDP 11/24 - A Step Backwards

[Rob Jarratt via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Chris Zach via
> cctalk
> Sent: 28 March 2022 20:57
> To: cctalk@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
> >> 

Re: HP 9915A failed 8048

[Curious Marc via cctalk]

Awesome! Congrats to everyone involved!
Marc

> On Mar 28, 2022, at 12:24 PM, js--- via cctalk  wrote:
> 
> 
>> On 2022-02-25 16:09, js--- via cctalk wrote:
>> 
>> Hi, folks.
>> 
>>   I've a HP 9915A computer with an interesting problem.   The motherboard 
>> utilizes a ceramic Intel D8048 chip.   The problem is that this 8048 has a 
>> crack right across the top middle of it, and half of the top of the chip has 
>> begun to separate.
>> 
>>  Powering up the machine as-is unsurprisingly results in no activity.   
>> HOWEVER, if I push firmly on the cracked area with my finger the machine 
>> starts to operate normally.   All appearances are that clamping down the 
>> separating piece of the chip re-establishes any broken wire connections 
>> within the chip.
>> 
>>   I've obtained a replacement P8048AH.   My question is: do these chips 
>> simply swap like a CPU, or -- as I fear -- is the 8048 a pre-programmed 
>> piece?More simply put, is this a repairable problem?  Or am I SOL?
>> 
>>   Any thoughts welcomed.
>> 
>> - John Singleton
>> 
> 
> 
> Hi, folks.   With the help of the extremely talented people here, the far 
> less talented me was able to repair this seemingly impossible problem and get 
> the 9915 functional.
> 
> The process was to:
> 
> 1) burn a new 8748 CPU with the 9915's 8048 ROM code.
>   I used a Data I/O 2900 for this purpose.
> 
> 2) remove the remnants of the original 8048 CPU
> 
> 3) install a new milled 40 pin socket
> 
> 4) install the 8748 into that socket and power-on test.
> 
> 
> Thanks to Paul Berger, Will Cooke, and Wayne S for their useful suggestions.
> 
> A very special thanks to Tony Duell for offering to go to great lengths to 
> help.
> 
> A very, very special thanks to Dave McGuire for having done all the hard work 
> in retrieving the 8048's code to begin with (which he had done already for 
> someone else), then providing the 8048 ROM code to me in hex format, plus 
> guidance on how to fix the problem all the way through.
> 
> - John S.

Re: PDP 11/24 - A Step Backwards

[Nigel Johnson Ham via cctalk]

On 2022-03-28 15:49, Jonathan Chapman via cctalk wrote:

What surprises me (a little) is that there is a commercial outfit
willing to work on something so old.

It's essentially what we do. I doubt there's a directory of all the small shops 
that work on legacy equipment,
but consider that some of this stuff runs CNC machines that are still in use. 
Depending on the industry and product,


including Nuclear power stations!



it's *way* cheaper to keep an old machine that's run not-full-time operational 
than to retool and recertify.

Thanks,
Jonathan

Re: PDP 11/24 - A Step Backwards

[Chris Zach via cctalk]

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.


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

RE: PDP 11/24 - A Step Backwards

[Rob Jarratt via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Antonio Carlini
> via cctalk
> Sent: 28 March 2022 07:50
> To: cctalk@classiccmp.org
> Subject: Re: PDP 11/24 - A Step Backwards
> 
> On 28/03/2022 04:57, Tony Duell via cctalk wrote:
> >
> > Very little of the stuff I've bought new has had such seals (with some
> > things, like my audio equipment, you are _expected_ to remove the
> > covers, the user manuals tell you how. They also include the full
> > schematics). Ditto test gear (if there is a seal it voids the
> > calibration only), computer stuff, etc.
> >
> > I don't think DEC ever put such seals on their machines when new.
> > Certainly not on things like power supplies,]
> >
> > -tony
> 
> The RZ28 I have right here has the usual "Warranty Void If Broken" seal on
> the side.
> 
> In this case the PSU was recently sent off for repair: I'm not surprised it 
> came
> back with a similar sticker.
> 
> They're not trying to stop you looking inside, they're trying not to have to 
> fix
> it again for free after you've fiddled.
> 
> What surprises me (a little) is that there is a commercial outfit willing to 
> work
> on something so old.

Me too, but they do!

> 
> 
> Antonio
> 
> 
> --
> Antonio Carlini
> anto...@acarlini.com

RE: PDP 11/24 - A Step Backwards

[Rob Jarratt via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Chris Zach via
> cctalk
> Sent: 27 March 2022 19:48
> To: cctalk@classiccmp.org
> Subject: Re: PDP 11/24 - A Step Backwards
> 
> Bigger question is who repaired the power supply "under warranty"?

A company called Radwell International. Based near me. They succeeded in 
getting the PSU to work, which I have been unable to do as it is just beyond me.

> 
> On 3/27/2022 2:38 PM, Bill Gunshannon via cctalk wrote:
> > On 3/27/22 05:17, Tony Duell via cctalk wrote:
> >> On Sat, Mar 26, 2022 at 11:12 PM Rob Jarratt via cctalk
> >>  wrote:
> >>
> >>> Unfortunately, or fortunately, depending on how you look at it, the
> >>> PSU repair is under warranty, which means I can't do it myself
> >>> without invalidating the warranty, so I will have to send it back. I
> >>> don't know if the ripple is caused by the blown part, but I suppose
> >>> it is likely. I may be able to inspect it without breaking the seals.
> >>
> >> That sort of thing would make me very suspicious as to what they've
> >> done inside the PSU that they don't want you to see.
> >>
> >
> > Pretty much every electronic device I have ever bought had seals on it
> > and a notice that breaking the seals voided the warranty.  Even stuff
> > with easily replaceable (or upgradeable) components.  Nothing unusual
> > here.
> >
> > bill
> >
> >

Re: PDP 11/24 - A Step Backwards

[Jonathan Chapman via cctalk]

> What surprises me (a little) is that there is a commercial outfit
> willing to work on something so old.

It's essentially what we do. I doubt there's a directory of all the small shops 
that work on legacy equipment, but consider that some of this stuff runs CNC 
machines that are still in use. Depending on the industry and product, it's 
*way* cheaper to keep an old machine that's run not-full-time operational than 
to retool and recertify.

Thanks,
Jonathan

RE: PDP 11/24 - A Step Backwards

[Rob Jarratt via cctalk]

Thanks for the lengthy reply. Some responses inline below.

> -Original Message-
> From: Noel Chiappa 
> Sent: 27 March 2022 21:09
> To: cctalk@classiccmp.org
> Cc: j...@mercury.lcs.mit.edu
> Subject: 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? 

Yes, that is correct.

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

I think I have been avoiding learning about the buses, but I think you are
right I will do some reading on them. I have a PDP11 Architecture Handbook
which talks about the Unibus, so I can read that. 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. I tried asking here on cctalk a while ago,
but there doesn't seem to be a whole lot of documentation to help me
understand how the CPU chips actually work. So I do try to understand the
hardware when I can.

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

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 

Re: HP 9915A failed 8048

[js--- via cctalk]

On 2022-02-25 16:09, js--- via cctalk 
wrote:


Hi, folks.

   I've a HP 9915A computer with an 
interesting problem.   The motherboard 
utilizes a ceramic Intel D8048 chip.   
The problem is that this 8048 has a 
crack right across the top middle of 
it, and half of the top of the chip 
has begun to separate.


  Powering up the machine as-is 
unsurprisingly results in no 
activity.   HOWEVER, if I push firmly 
on the cracked area with my finger the 
machine starts to operate normally.   
All appearances are that clamping down 
the separating piece of the chip 
re-establishes any broken wire 
connections within the chip.


   I've obtained a replacement 
P8048AH.   My question is: do these 
chips simply swap like a CPU, or -- as 
I fear -- is the 8048 a pre-programmed 
piece?More simply put, is this a 
repairable problem?  Or am I SOL?


   Any thoughts welcomed.

- John Singleton




Hi, folks.   With the help of the 
extremely talented people here, the far 
less talented me was able to repair this 
seemingly impossible problem and get the 
9915 functional.


The process was to:

1) burn a new 8748 CPU with the 9915's 
8048 ROM code.

   I used a Data I/O 2900 for this purpose.

2) remove the remnants of the original 
8048 CPU


3) install a new milled 40 pin socket

4) install the 8748 into that socket and 
power-on test.



Thanks to Paul Berger, Will Cooke, and 
Wayne S for their useful suggestions.


A very special thanks to Tony Duell for 
offering to go to great lengths to help.


A very, very special thanks to Dave 
McGuire for having done all the hard 
work in retrieving the 8048's code to 
begin with (which he had done already 
for someone else), then providing the 
8048 ROM code to me in hex format, plus 
guidance on how to fix the problem all 
the way through.


- John S.

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

[Paul Koning via cctalk]

> On Mar 28, 2022, at 2:12 PM, Joseph S. Barrera III via cctalk 
>  wrote:
> 
> That was the ALOHA network, which inspired Ethernet but was not Ethernet.

The differences are quite crucial.  ALOHA is a broadcast radio packet network, 
which doesn't have collision detect and probably not carrier sense either.  So 
it's about 1/3rd of Ethernet -- just MA. :-)  A consequence is that the 
theoretical channel capacity is also about 1/3rd; ALOHA tops out around 30% of 
data rate, while Ethernet -- thanks to CS and CD -- can reach pretty much the 
full wire capacity.

paul

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

[Joseph S. Barrera III via cctalk]

That was the ALOHA network, which inspired Ethernet but was not Ethernet.

On Mon, Mar 28, 2022 at 11:09 AM Nigel Johnson Ham via cctalk <
cctalk@classiccmp.org> wrote:

> For years I taught my students that the Ethernet was invented at the
> University of Hawaii in 1971!
>
> OK, it was wireless, but that brings up another surprise, that wireless
> ethernet came before wired :-)
>
> cheers,
>
> Nigel
>
>
> Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
> Amateur Radio, the origin of the open-source concept!
> Skype:  TILBURY2591
>
>
> On 2022-03-28 14:02, Tom Gardner via cctalk wrote:
> > 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  SVTHC
> website
> >
> >
> >
> > Register
> > <
> https://www.eventbrite.com/e/ethernets-emergence-from-xerox-parc-1975-1980-
> > tickets-301085664327>
> >
> >
> >
> > Tom
> >
> >
> >
>

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

[Nigel Johnson Ham via cctalk]

For years I taught my students that the Ethernet was invented at the 
University of Hawaii in 1971!


OK, it was wireless, but that brings up another surprise, that wireless 
ethernet came before wired :-)


cheers,

Nigel


Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype:  TILBURY2591


On 2022-03-28 14:02, Tom Gardner via cctalk wrote:

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

  


Register
  

  


Tom

  

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

[Tom Gardner via cctalk]

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

 

Register
 

 

Tom

 

Re: PDP 11/24 - A Step Backwards

[Antonio Carlini via cctalk]

On 28/03/2022 04:57, Tony Duell via cctalk wrote:


Very little of the stuff I've bought new has had such seals (with some
things, like my audio equipment, you are _expected_ to remove the
covers, the user manuals tell you how. They also include the full
schematics). Ditto test gear (if there is a seal it voids the
calibration only), computer stuff, etc.

I don't think DEC ever put such seals on their machines when new.
Certainly not on things like power supplies,]

-tony


The RZ28 I have right here has the usual "Warranty Void If Broken" seal 
on the side.


In this case the PSU was recently sent off for repair: I'm not surprised 
it came back with a similar sticker.


They're not trying to stop you looking inside, they're trying not to 
have to fix it again for free after you've fiddled.


What surprises me (a little) is that there is a commercial outfit 
willing to work on something so old.



Antonio


--
Antonio Carlini
anto...@acarlini.com