Re: Help identifying UNIBUS PDP-11 CPU upgrade

[Mattis Lind via cctalk]

> Right, that's what's confusing me. I can't work out what you could possibly
> be cabling to, on the new CPU board!
>
> Those two connectors on the M7859 are used only with the 11/34, not the
> 11/04
> (the cable from the M7859 to the programmer's front panel must be there,
> with
> both); they are there for the micro-code single-stepping function on the
> 11/34, etc. (One cable carries uclock, the other uPC data.)


Actually it should work with the 11/04. The 04 does have one 10 pin
connector on the board. Have a look in the manual. Page 7-1.


http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp11/1134/KY11-LB_MaintMan.pdf



> Since the new CPU probably doesn't have that ability (on the LSI-11 and
> F-11
> chipsets, the micro-word bus is accessible outside the chips, but AFAIK the
> same is not true of the J-11), I'm not at all sure what those two
> connectors
> might be.
>
> Perhaps they are serial lines using the 'new' DEC standard pinout, which
> also
> use 10-pin headers?


As far as I can see there are no RS-232 level tranceivers neither any UARTs
on the board but I might be wrong. Some chips are hard to read.

On the other hand there are a bunch of 74S381 / 74S182. Curious of what
kind of arithmetic they are performing.


/Mattis


> Noel
>

Re: Help identifying UNIBUS PDP-11 CPU upgrade

[Jerry Weiss via cctalk]

> On Jul 1, 2017, at 1:08 AM, Mattis Lind via cctalk  
> wrote:
> 
>> Right, that's what's confusing me. I can't work out what you could possibly
>> be cabling to, on the new CPU board!
>> 
>> Those two connectors on the M7859 are used only with the 11/34, not the
>> 11/04
>> (the cable from the M7859 to the programmer's front panel must be there,
>> with
>> both); they are there for the micro-code single-stepping function on the
>> 11/34, etc. (One cable carries uclock, the other uPC data.)
> 
> 
> Actually it should work with the 11/04. The 04 does have one 10 pin
> connector on the board. Have a look in the manual. Page 7-1.
> 
> 
> http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp11/1134/KY11-LB_MaintMan.pdf
> 
> 


The unused 10 pin “could" be for enabling an upgrade on a machine with a 
KY11-LA 
as Mattis suggests. It probably is NOT a serial port.

The KY11-LA (Operators Console) was also used on the 11/34 (and 11/04).  It 
only had
controls for power (DC), HALT/CONT and BOOT/INIT.  The PDP 11/34 
System Users Manual (EK-11034-UG-001) has an overview of the signals involved 
in 
Figure 3-1 which come from a 10 pin cable attached to CPU backplane 

With the KY11-LB there is no cable attached to the backplane, as the M7859 
supplies them 
(and more) via a 20 pin cable to the Programers Console.

So it would appear the upgrade board makes provisions for both situations.

Both used a seperate 10 pin cable from the H777 and controls this power supply. 
If you left
this one connected to the Console it would still enable the DC controls.

Regards,
Jerry 

Re: Help identifying UNIBUS PDP-11 CPU upgrade

[Noel Chiappa via cctalk]

> From: Jerry Weiss

> So it would appear the upgrade board makes provisions for both
> situations.

I'm not sure that the two situations that the upgrade board supports are in
fact different, from its point of view. (Assuming that the two situations you
refer to are the two different consoles.) Yes, the _system_ supports two
situations: i) the KY11-LA connecting directly to the backplane, and ii) the
KY11-LB going via the M7859; but the DEC CPUs don't seem to draw any
distinction between the two.

Looking at the KY11-LA prints, the connector to the backplane cable (the one
which is unused with the KY11-LB) carries signals like "Halt Request" and
"Halt Grant", which are generated in the M7859 (which has its own direct
backplane connection) when using the KY11-LB.

So as far as the consoles are concerned, those signals come to the backplane
via different paths, but as far as the CPU is concerned, it sees the same
things through its backplane connection, no matter which is in use - so how
would the upgrade board be any different?

The _only_ cable(s) that ever connect(s) to the CPU board (in the KD11-D or
KD11-E) are from the KY11-LB: those cables are the ones that carry the signals
to support the microcode single-stepping. How would the upgrade board use
these?


One thing that might help untangle the function of those two headers on the
upgrade board is to look and see what chip(s) they connect to. If they aren't
EIA transmitters/receivers, yes, they aren't serial lines. (I only suggesgted
that because I couldn't figure out what _else_ they could be.) Can that be
done?

 Noel

Re: Help identifying UNIBUS PDP-11 CPU upgrade

[Noel Chiappa via cctalk]

> From: Noel Chiappa

> (One cable carries uclock, the other uPC data.)

Minor goof there; the low bits of the uPC are in one cable, along with the
"Manual Clock Enable" and "Manual Clock" signals; the other cable carries the
high bit/bits (depending on whether it's a KD11-E or KD11-EA) of the uPC.

This is because...


> From: Mattis Lind

> Actually it should work with the 11/04. The 04 does have one 10 pin
> connector on the board.

Hi, thanks for catching that. I looked for a Berg header on an M7263 boards,
and didn't see one, which is what misled me.

It's actually just a group of bare pins (in the upper left hand corner of the
M7263).

I looked for the connection in the KD11-D engineering drawings, but it's not
shown!  E.g. on page 7 of the drawings (center bottom) you can see "Manual
Clock Enable" and "Manual Clock" but they are shown as connected to backplane
pins (DS1 and DU1). The connector is only described on page 1 (upper left hand
corner).


So that explains the odd division of signals between the two cables: the
KD11-D in the -11/04 apparently has one less bit of uPC (smaller uprogram), so
its signals can all fit in one cable.

Just to create maximal confusion, in the KD11-EA, there's one more bit of uPC
than in the KD11-E, along with some other signals (e.g. "FP11-A Attached") in
the second cable: this is to allow support of the optional FP11-A floating
point unit, which seems to have a bunch of private ucode, in an extension to
the uaddress space.

The KY11-LB, although it pre-dates the KD11-EA, will probably still show the
uPC correctly with an FP11-A present, as it's apparently prepared to display
up to 4 bits from the 'high' connector.

Noel

Model M case screws

[Jules Richardson via cctalk]

Can anyone tell me the size of the Model M keyboard case screws? The one I 
use on my main 'modern' PC could use a good clean, but the case recesses 
are a little too narrow for a typical socket to fit - I either need a nut 
driver, or to shave a little material off the outside of a socket to narrow 
it some.


Google suggests that they might be 7/32", but I'm not sure; that's less of 
a common size (vs. 3/16" or 1/4", say) - I'm not even sure I could find a 
driver like that around here.


cheers

Jules

Looking for a 22 bit Qbus chassis...

[Mike Niswonger via cctalk]

Looking for a Qbus chassis to put an 11/73 system back together with.

Anyone have anything they're willing to part with for a reasonable price?

I'd prefer something in the southeast US to minimize shipping cost...

 -- Mike Niswonger

Re: Help identifying UNIBUS PDP-11 CPU upgrade

[Josh Dersch via cctalk]

On 7/1/2017 8:59 AM, Noel Chiappa via cctalk wrote:

 > From: Jerry Weiss

 > So it would appear the upgrade board makes provisions for both
 > situations.

I'm not sure that the two situations that the upgrade board supports are in
fact different, from its point of view. (Assuming that the two situations you
refer to are the two different consoles.) Yes, the _system_ supports two
situations: i) the KY11-LA connecting directly to the backplane, and ii) the
KY11-LB going via the M7859; but the DEC CPUs don't seem to draw any
distinction between the two.

Looking at the KY11-LA prints, the connector to the backplane cable (the one
which is unused with the KY11-LB) carries signals like "Halt Request" and
"Halt Grant", which are generated in the M7859 (which has its own direct
backplane connection) when using the KY11-LB.

So as far as the consoles are concerned, those signals come to the backplane
via different paths, but as far as the CPU is concerned, it sees the same
things through its backplane connection, no matter which is in use - so how
would the upgrade board be any different?


Since I feel like I'm talking to a wall here, let me explain how things 
are set up.


In the original 11/34 configuration you have (from slot 1 on down)
1 - M7266
2 - M7265
3 - M9301/M7859
4 - SPC/MUD

The front programmer's panel is connected via a 20-pin cable to the 
M7859 in slot 3.


With the upgrade installed, you have:

1 - Empty
2 - Empty
3 - Upgrade CPU
4 - Upgrade Memory

The front programmer's panel is connected via a 20-pin cable to the CPU 
in slot 3.


The M7859 is removed from the equation.  There is nothing to provide the 
front panel signals to the backplane, so the header on the CPU board is 
(apparently) used to take care of this.  This is backed up by the 
observation that *if the 20-pin cable is disconnected, the front panel 
does nothing and if it is connected, then the HALT/SS and BOOT switches 
are functional*.  Nothing else on the programmer's panel appears to do 
anything, and that doesn't surprise me.


There is also a 10-pin header on the CPU.  I do not know what it is for, 
but Jerry's suggestion sounds valid.  It does not appear to be a serial 
port; there's nothing that looks like a UART onboard.  I've spent a 
couple of minutes trying to trace things out but I haven't made much 
headway.  This board is dense and multilayer and nothing in the 
immediate area seems to connect to it.




The _only_ cable(s) that ever connect(s) to the CPU board (in the KD11-D or
KD11-E) are from the KY11-LB: those cables are the ones that carry the signals
to support the microcode single-stepping. How would the upgrade board use
these?



Yes, the 11/34 CPU didn't connect to the front panel in any way.  I 
don't understand why this precludes a CPU upgrade that replaces large 
portions of the original hardware from doing so in order to support the 
front panel in a minimal way.





One thing that might help untangle the function of those two headers on the
upgrade board is to look and see what chip(s) they connect to. If they aren't
EIA transmitters/receivers, yes, they aren't serial lines. (I only suggesgted
that because I couldn't figure out what _else_ they could be.) Can that be
done?


See above.

- Josh




  Noel

Re: Help identifying UNIBUS PDP-11 CPU upgrade

[Noel Chiappa via cctalk]

> From: Josh Dersch

> There's a 20-pin header on the CPU upgrade board which connects to the
> front panel. ... the programmer's panel loses most of its functionality
> .. but the HALT/SS and BOOT switches are functional with the cable
> connected. ... With the 20-pin cable from the front panel disconnected,
> the HALT and BOOT switches are non-functional.

That's interesting. There aren't 'HALT' and 'BOOT' lines in that 20-conductor
cable; the data sent across that cable is keyboard scan codes, which the 8008
on the KY11-B quad board has code to decode. So the upgrade board must have
something to scan the KY11-B keyboard, and translate the scan codes...

> If so, the one on the CPU doesn't appear to conflict with the M7856 I
> already have in the /34.

Hmm, maybe one of the undocumented jumpers/switches (forget which this card
has) is an enable/disable for an on-board serial console?

The other possibility which just came to mind (thinking about the fact, above,
that apparently the upgrade board is prepared to replace the M7859 of the
KY11-B, instead of leaving it in situ, and interacting with it over the
backplane, the way the -11/04-34 do) is that that connector is for use with
the KY11-LA - instead of plugging the cable that comes out of the KY11-LA into
the backplane, it plugs into the replacement card instead?

It would be very interesting to know what chips that 10-pin header is
connected to!

Noel

Re: Help identifying UNIBUS PDP-11 CPU upgrade

[Jerry Weiss via cctalk]

> On Jul 1, 2017, at 10:59 AM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: Jerry Weiss
> 
>> So it would appear the upgrade board makes provisions for both
>> situations.
> 
> I'm not sure that the two situations that the upgrade board supports are in
> fact different, from its point of view. (Assuming that the two situations you
> refer to are the two different consoles.) Yes, the _system_ supports two
> situations: i) the KY11-LA connecting directly to the backplane, and ii) the
> KY11-LB going via the M7859; but the DEC CPUs don't seem to draw any
> distinction between the two.
> 
> Looking at the KY11-LA prints, the connector to the backplane cable (the one
> which is unused with the KY11-LB) carries signals like "Halt Request" and
> "Halt Grant", which are generated in the M7859 (which has its own direct
> backplane connection) when using the KY11-LB.
> 
> So as far as the consoles are concerned, those signals come to the backplane
> via different paths, but as far as the CPU is concerned, it sees the same
> things through its backplane connection, no matter which is in use - so how
> would the upgrade board be any different?
> 
> The _only_ cable(s) that ever connect(s) to the CPU board (in the KD11-D or
> KD11-E) are from the KY11-LB: those cables are the ones that carry the signals
> to support the microcode single-stepping. How would the upgrade board use
> these?
> 

Yes,  the upgrade board console wiring support exists only to ensure minimal 
plumbing
changes to the chassis and backplanes of the system being upgraded, and of 
course to 
signal the KDJ11.  There’s no need or benefit to connect the consoles to the 
UNIBUS backplane.
Its just peripheral bus after the upgrade (i.e. neither a CPU or Memory Bus) 
similar to an 11/84.

My assumption is that the Upgrade Board only requires/provides signals to 
either type
of console to support basic human controls.  Just HALT, Boot, INIT(?). The
consoles are reduced to being toggle switches and a few indicator lights. 
ODT replaces the limited 11/34 conversational console emulator (?) 
and/or the programmers console.  NO SS, DIS AD, LAD, LSR, etc
functionality. 

I haven’t looked at the details of the LA/LB prints to see if the actual 
signals 
involved are really differ much between the two, other than the connector 
wiring.

I’d be curious as to how/whether the M9301 bootstraps are used. 
The original bootstraps may not visible from the KDJ11 until some 
unibus mapping is enabled. Perhaps this is hidden by the upgrade board.

The upgrade board seems like a smooth upgrade path.  Sorry I didn’t
hear about back in the day.  Would have extended the life of more than
a few of our systems.


> 
> One thing that might help untangle the function of those two headers on the
> upgrade board is to look and see what chip(s) they connect to. If they aren't
> EIA transmitters/receivers, yes, they aren't serial lines. (I only suggesgted
> that because I couldn't figure out what _else_ they could be.) Can that be
> done?
> 

Agreed.


Jerry

Re: Model M case screws

[Adam Sampson via cctalk]

Jules Richardson via cctalk  writes:

> Google suggests that they might be 7/32", but I'm not sure; that's
> less of a common size (vs. 3/16" or 1/4", say) - I'm not even sure I
> could find a driver like that around here.

Yes, they're 7/32", but in a narrow hole that means some bits won't
reach. Xcelite do a nut driver that fits nicely:
https://stuff.offog.org/model-m-screwdriver.jpg

I got mine in the UK a few years ago from Mouser, part numbers 578-997
for the driver and 578-99-1 for the handle.

-- 
Adam Sampson  

Re: Model M case screws

[Tony Duell via cctalk]

On Sat, Jul 1, 2017 at 8:12 PM, Adam Sampson via cctalk
 wrote:
> Jules Richardson via cctalk  writes:
>
>> Google suggests that they might be 7/32", but I'm not sure; that's
>> less of a common size (vs. 3/16" or 1/4", say) - I'm not even sure I
>> could find a driver like that around here.
>
> Yes, they're 7/32", but in a narrow hole that means some bits won't
> reach. Xcelite do a nut driver that fits nicely:
> https://stuff.offog.org/model-m-screwdriver.jpg
>
> I got mine in the UK a few years ago from Mouser, part numbers 578-997
> for the driver and 578-99-1 for the handle.

That's what I use as well, Xcellite System 99. I bought almost the complete
range over the years, it's the easiest way to get Bristol spline keys (needed
for the Friden Flexowriter, IBM5155 monitor, etc) in the UK.

Incidentally the System 99 torx bits on an X5 extension will fit the recessed
screws of a Mac Plus (etc).

-tony

Re: Model M case screws

[Chuck Guzis via cctalk]

On 07/01/2017 09:28 AM, Jules Richardson via cctalk wrote:

> Google suggests that they might be 7/32", but I'm not sure; that's less
> of a common size (vs. 3/16" or 1/4", say) - I'm not even sure I could
> find a driver like that around here.

That's exactly what I use--get a decent one; some of the Chinese imports
have too thick a "shell" to work in this application.  I think a 5.5mm
driver will also work, but I haven't tried it.

--Chuck

Re: Model M case screws

[Tony Duell via cctalk]

On Sun, Jul 2, 2017 at 12:09 AM, Jules Richardson via cctalk
 wrote:

> Anyway, I picked up a cheap 7/32" deep socket from Menards ($3 or so) - and
> as it happens, it Just Works without modification. It's not marketed as
> thin-walled; I expect they just made it cheap by leaving out a bunch of
> metal, but that works in my favor in this case. (It's a Master Force one,
> just in case any future beings reading this need to know)

I was told years ago that in general the thinner-wall sockets are better
quality -- they have to be made from stronger steel alloy to work at
all. Obviously there are exceptions

-tony

Re: Model M case screws

[Jules Richardson via cctalk]

On 07/01/2017 02:12 PM, Adam Sampson via cctalk wrote:

Jules Richardson via cctalk  writes:


Google suggests that they might be 7/32", but I'm not sure; that's
less of a common size (vs. 3/16" or 1/4", say) - I'm not even sure I
could find a driver like that around here.


Yes, they're 7/32", but in a narrow hole that means some bits won't
reach.


Hmm, well I'll see what I can find when I go into town in a little bit - 
looking at websites for local stores though it seems I'm probably not going 
to have any luck with a 7/32" driver.


It does look like I can get a 7/32" socket for a couple of bucks, though - 
so maybe I'll go that route for now and just shave it down a little with 
the bench grinder. It can live on the shelf with the homebrew Mac case 
dismantling tool ;)


cheers

Jules

Re: Model M case screws

[Chuck Guzis via cctalk]

On 07/01/2017 01:23 PM, Jules Richardson via cctalk wrote:

> It does look like I can get a 7/32" socket for a couple of bucks, though
> - so maybe I'll go that route for now and just shave it down a little
> with the bench grinder. It can live on the shelf with the homebrew Mac
> case dismantling tool ;)

Don't.   You need a *thinshell*  nutdriver--ordinary sockets are too
thick. Like others, I use a 7/32 Xcelite full-size driver.

--Chuck