Re: PDP-11/10 repair started

[Noel Chiappa]

> From: Tony Duell

> if it behaves as you describe, it would appear that if placed at the
> remote end of the bus it could lock the bus by forcing SACK/ asserted
> (as the M9302 does) if a grant chain is open [and there's a board with
> a pull-up on the grant input just after the break], whereas if it is
> placed at the CPU end it can't.

YP;IF.

But yeah, good point - this smarter board actually works _better_ at the
start of the bus, than at the end.

Noel

Re: PDP-11/10 repair started

[william degnan]

My 11/05 S's have the names of the cards printed on the chassis wall.  The
cards and their slots are listed in the 11/05 S docs.  I have always
referred to these unambiguous sources.  As long as you have the matching
mounting box for the version of model S of course.

Bill Degnan
twitter: billdeg
vintagecomputer.net
On Oct 5, 2015 9:17 PM, "j...@cimmeri.com"  wrote:

>
>
> On 10/5/2015 10:24 AM, Henk Gooijen wrote:
>
>>
>> =
>> Sorry for the delayed answer, I don't have email available at work -:/
>>
>> I have one M930 in slot 3 position A-B, because that is the termination
>> for the processor. I am pretty sure (not 100%) that I also have an M930
>> in slot 9 position A-B. To be complete, this is the current state.
>> slot 1 A-F : M7260
>> slot 2 A-F : M7261
>> slot 3 A-B : M930   C-D : G7273
>> slot 4 A-B : M9970  C-D : G7273
>> slot 5 C-D : G7273
>> slot 6 empty
>> slot 7 empty
>> slot 8 empty
>> slot 9 A-B : M930
>>
>> Slot 6-7-8-9 is for core memory, respectively G235, H217D, G114, M8293.
>> The documentation says that a G727 should go in slot 3-4-5 position D.
>> I hate those "knuckle-busters". Plus, I am lazy to check NPR continuity
>> on the backplane, so I installed G7273s instead of G727s. Always good.
>>
>> I totally forgot that the GT40 is based on the 11/05. Great tip in case
>> it turns out that I have a "different" CPU module! You never know ...
>>
>
>
> Henk, I'm confused by your slot arrangement, but maybe my 11/05 is
> different than yours.
>
> My module utilization is as follows, and is an 8k backplane (the 16k
> backplane is also different):
>
> slot 9 A-F : M7260
> slot 8 A-F : M7261
> slot 7 A-F : G110
> Slot 6 A-F :G231
> Slot 5 AB : M930   C-F : H214
> Slot 4 AB : blankC-F G727 in D4.
> Slot 3 AB : M930   C-F G727 in D3
> Slot 2 AB: KM11 Maint  C-F G727 in D2
> Slot 1 AB: DF11 Comm  C-F G727 in D1
>
> John
>
>
>

RE: PDP-11/10 repair started

[tony duell]

> 
> > Yes, it is a pity that the later board set (a) has the jumper to
> > disable the built-in console port and (b) has the switchable divider
> > allowing higher baud rates so you generally don't need to :-)
> 
> Well, except for those of us who don't have any 20mA gear, and want to
> standardize on EIA... :-)

Converting between genuine 20mA loop and RS232 is not that hard. Converting 
between
a DEC current loop port (where you can make assumptions about the voltage swing 
and 
which side will be driven, etc), is even easier. Or if you don't mind modifying 
the hardware
you can pick up TTL level signals at the UART.

I can't rememebr if DEC routed those to the BERG pins on the 11/10. Maybe not. 
From a 
quick glance at the GT40 prints (older version CPU without the disabling link) 
it appears 
that the needed signals are at least brought out to backplane pins, but I have 
not checked
any further


>> Adjusting the RC clock is not hard given a frequency counter, and it
> > doesn't have to be that precise.
> 
> The prints actually give the time for the pulse width on the two different
> speed groups, so a well-calibrated 'scope should do it.

Indeed. It is not that difficult. Heck, the first serial interface I ever made 
(to drive
a 110 baud 'Teletype' [1] used a 555 as a clock. I think I set it by tweaking 
it one way
until I got bit errors, then tweaking it the other way until I got bit errors, 
then setting it
midway between, Still works...

[1] A Data Dynamics 390, which uses ASR33 mechanics with Data Dynamics 
electronics 
(in place of the Teletype Call Control Unit). I remember a single-step facility 
for the reader
and a few more goodies like that.

> > The grants are the only (I think) unibus signals to be active high.
> 
> Yup. A source of great confusion to me when I started working with the QBUS,
> where they are asserted _low_!

Now that I had forgotten. How evil

> Interestingly, I think the M9302 was a _later_ solution to this problem in
> the 11/34. In the early ones, there's a 'SACK Timeout Module' (M8264) which I
> think performs the same function, but at the _start_ of the bus. (I say
> 'think' because this module is poorly documented - e.g. I don't know of
> anything which definitely states which slot to plug it into.)

I have one of those somewhere I remember a 4 bit counter and LEDs, possibly 
to
count errant grants, but it's been a long time since I looked at those prints 
too. I 
always assumed it went in the last SPC slot, but I am not sure.

-tony

RE: PDP-11/10 repair started

[tony duell]

> 
> > Converting between genuine 20mA loop and RS232 is not that hard.
> 
> Yes, but I'm i) lazy, and ii) overwhelmed with other projects! :-)

True, but sometimes (and I have been guilty of this) it takes longer to post 
and moan
about the problem than to dig into the junk box, grab the soldering iron, and 
fix it.

[SACK timeout board]
> Well, looking at the print (it's in the 11/34 Vol. 2 set that's online), it
> looks like it should work plugged in anywhere; the circuit just seems to look
> for any BGn/NPG that's been on 'too long', and when it sees one, asserts
> SACK.

I can't be bothered to download the prints for just that one board (see above 
;-))

But if it behaves as you describe, it would appear that if placed at the remote
end of the bus it could lock the bus by forcing SACK/ asserted (as the M9302 
does)
if a grant chain is open, whereas if it is placed at the CPU end it can't. 

-tony

Re: PDP-11/10 repair started

[Noel Chiappa]

> From: Tony Duell

> Yes, it is a pity that the later board set (a) has the jumper to
> disable the built-in console port and (b) has the switchable divider
> allowing higher baud rates so you generally don't need to :-)

Well, except for those of us who don't have any 20mA gear, and want to
standardize on EIA... :-)

> Adjusting the RC clock is not hard given a frequency counter, and it
> doesn't have to be that precise.

The prints actually give the time for the pulse width on the two different
speed groups, so a well-calibrated 'scope should do it.


>> So, how did the M9302 see a 'grant' to start the whole process? Noise
>> on an open input? Or maybe it powers up in that state?

> The grants are the only (I think) unibus signals to be active high.

Yup. A source of great confusion to me when I started working with the QBUS,
where they are asserted _low_!

I'd done a couple of DMA network interfaces on the UNIBUS, and so was totally
familiar with how it worked, and when I recently switched to QBUS (I had used
LSI-11's extensively BITD, but not done any hardware on them), that (and a
few other similar quirks) really threw me until I got a grip on them!

> So if the grant chain is open at any point, the next device along
> (which might be the terminator) will have a grant input which is pulled
> high by the pull-up resistor.

Not always! Some devices (e.g. KW11-P) do have a pull-up, but others (e.g.
DL11) only have a pull-down. I looked through a couple of UNIBUS handbooks,
to see if there was a spec for how to terminate a grant line, and there
isn't, which probably explains the variance in practice.

But any which do have a pull-up will generate a bogus 'grant' when there's a
break in the grant line between them and their upstream. But my theory of
noise on an open input may not apply (unless there are devices with _neither_
pull-up not pull-down - I'l too lazy to exhaustively look at UNIBUS device
prints ;-).

> when that device gets the grant signal it will handle SACK and also
> will not pass the grant on to subsequent devices ... So obviously there
> is no way the grant should get all the way to the terminator. But in
> some cases (I think a device deasserting the request before it gets the
> grant is one) the grant can get all the way along the bus.

Exactly. Device is requesting interrupt, but is e.g. reset at the same time
the CPU grants the interrupt - result, unwanted grant.

> I am not sure why that was deemed to be a problem on later machines and
> not older ones (which run quite happily with the M930 terminator at
> each end of the bus)

I think the deal is that an un-wanted grant can cause things to come to a
halt until a 'grant timeout' (the '75 Peripherals Handbook says this is 5-10
usec) happens, so the M9302 speeds that up.

Interestingly, I think the M9302 was a _later_ solution to this problem in
the 11/34. In the early ones, there's a 'SACK Timeout Module' (M8264) which I
think performs the same function, but at the _start_ of the bus. (I say
'think' because this module is poorly documented - e.g. I don't know of
anything which definitely states which slot to plug it into.)

Noel

Re: PDP-11/10 repair started

[Noel Chiappa]

> From: Tony Duell

> Converting between genuine 20mA loop and RS232 is not that hard.

Yes, but I'm i) lazy, and ii) overwhelmed with other projects! :-)


>> there's a 'SACK Timeout Module' (M8264) which I think performs the
>> same function, but at the _start_ of the bus. (I say 'think' because
>> this module is poorly documented - e.g. I don't know of anything which
>> definitely states which slot to plug it into.)

> I remember a 4 bit counter and LEDs, possibly to count errant grants

Yeah, that LED counter looks like a nice feature; I should find one, play
with it.

> I always assumed it went in the last SPC slot

Well, looking at the print (it's in the 11/34 Vol. 2 set that's online), it
looks like it should work plugged in anywhere; the circuit just seems to look
for any BGn/NPG that's been on 'too long', and when it sees one, asserts
SACK.

More complicated than the M9302 circuit, which depends on being last, plus
they could cram that onto the terminator, is probably why they switched to
the M9302 approach.

Noel

Re: PDP-11/10 repair started

[william degnan]

What are the DC LO and AC LO values off the backplane?  Do they change when
you insert the CPU card.  (one at a time).

On Mon, Oct 5, 2015 at 12:01 PM, Johnny Billquist <b...@update.uu.se> wrote:

> On 2015-10-05 17:56, Henk Gooijen wrote:
>
>> -Oorspronkelijk bericht- From: Johnny Billquist Sent: Monday,
>> October 05, 2015 5:44 PM To: cctalk@classiccmp.org Subject: Re:
>> PDP-11/10 repair started
>> Ok. I got the initial impression that you only had the CPU in. Thanks
>> for the expanded info.
>>
>> When you don't have any core memory, I wonder if you might need bus
>> grants in those slots as well...? It's not as if they aren't a part of
>> the Unibus... Memory sits on the Unibus, just like everything else,
>> remember? Needs to check further if any special wiring are in place for
>> those slots, though.
>>
>> Johnny
>>
>> =
>>
>> I am not sure the "core slots" would need grant cards. The documentation
>> is clear about slot 3-4-5 as SPC, needing grant cards. I never saw any
>> doc where the core memory slots, when optional, but not installed, could
>> be used as an SPC slot. I certainly am Not "trying" that ...
>> I did try the system *with* the core slots filled with the correct boards
>> but the behavior remained the same.
>> To make fault finding not more complex, I removed the core board set.
>>
>
> Ok. Not sure if it makes it more complex or not, but I guess it's not the
> issue right now anyway.
>
> But my original comment about the behavior you described being very much
> like what I've seen on other machines with bad/no termination still
> applies. CPU seemingly stuck, but doing a master reset sortof gets it out.
> But not functioning as it should.
>
> Well, no more ideas here at the moment.
>
> Johnny
>
>


-- 
Bill
vintagecomputer.net

Re: PDP-11/10 repair started

[Henk Gooijen]

-Oorspronkelijk bericht- 
From: william degnan 
Sent: Monday, October 05, 2015 8:59 PM 
To: General Discussion: On-Topic and Off-Topic Posts 
Subject: Re: PDP-11/10 repair started 


What are the DC LO and AC LO values off the backplane?  Do they change when
you insert the CPU card.  (one at a time).
--
Bill
vintagecomputer.net

=
I measured AC LO and DC LO with a scope while both CPU boards are in
the backplane. Both measured 4.6 V, there was a ripple of 130 mV
(looked like a sawtooth signal). I did not see spikes.

- Henk

Re: PDP-11/10 repair started

[william degnan]

good news as far as power supply goes.

On Mon, Oct 5, 2015 at 4:02 PM, Henk Gooijen <henk.gooi...@hotmail.com>
wrote:

> -Oorspronkelijk bericht- From: william degnan Sent: Monday,
> October 05, 2015 8:59 PM To: General Discussion: On-Topic and Off-Topic
> Posts Subject: Re: PDP-11/10 repair started
> What are the DC LO and AC LO values off the backplane?  Do they change when
> you insert the CPU card.  (one at a time).
> --
> Bill
> vintagecomputer.net
>
> =
> I measured AC LO and DC LO with a scope while both CPU boards are in
> the backplane. Both measured 4.6 V, there was a ripple of 130 mV
> (looked like a sawtooth signal). I did not see spikes.
>
> - Henk
>



-- 
Bill
vintagecomputer.net

Re: PDP-11/10 repair started

[Johnny Billquist]

On 2015-10-05 07:26, tony duell wrote:


You have no memory, and probably no devices to complete the
Unibus. So, it is quite likely showing the Unibus is in a
jammed state.  At the least, you need a Unibus terminator,
and any bus grant cards between the CPU and the terminator
(you'd have to check the manual to see how the Unibus is wired.)


The specific issue of an open grant chain locking the Unibus is a quirk
of the M9302 terminator (which asserts SACK under such conditions). This
is unlikely to be a problem on an 11/10.


Why? The 11/10 also have a Unibus, and also needs the terminator as well 
as the SACK and other signals in order.



But you do need some kind of termination/pullups on the Unibus. At least
fit the CPU-end terminator (M930 in the right slot near the CPU boards) if
you haven't done so already.


You most likely want to terminate the other end as well.

Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: PDP-11/10 repair started

[j...@cimmeri.com]

On 10/5/2015 10:24 AM, Henk Gooijen wrote:


=
Sorry for the delayed answer, I don't 
have email available at work -:/


I have one M930 in slot 3 position 
A-B, because that is the termination
for the processor. I am pretty sure 
(not 100%) that I also have an M930
in slot 9 position A-B. To be 
complete, this is the current state.

slot 1 A-F : M7260
slot 2 A-F : M7261
slot 3 A-B : M930   C-D : G7273
slot 4 A-B : M9970  C-D : G7273
slot 5 C-D : G7273
slot 6 empty
slot 7 empty
slot 8 empty
slot 9 A-B : M930

Slot 6-7-8-9 is for core memory, 
respectively G235, H217D, G114, M8293.
The documentation says that a G727 
should go in slot 3-4-5 position D.
I hate those "knuckle-busters". Plus, 
I am lazy to check NPR continuity
on the backplane, so I installed 
G7273s instead of G727s. Always good.


I totally forgot that the GT40 is 
based on the 11/05. Great tip in case
it turns out that I have a "different" 
CPU module! You never know ...



Henk, I'm confused by your slot 
arrangement, but maybe my 11/05 is 
different than yours.


My module utilization is as follows, and 
is an 8k backplane (the 16k backplane is 
also different):


slot 9 A-F : M7260
slot 8 A-F : M7261
slot 7 A-F : G110
Slot 6 A-F :G231
Slot 5 AB : M930   C-F : H214
Slot 4 AB : blankC-F G727 in D4.
Slot 3 AB : M930   C-F G727 in D3
Slot 2 AB: KM11 Maint  C-F G727 in D2
Slot 1 AB: DF11 Comm  C-F G727 in D1

John

RE: PDP-11/10 repair started

[tony duell]

> > The specific issue of an open grant chain locking the Unibus is a quirk
> > of the M9302 terminator (which asserts SACK under such conditions). This
> > is unlikely to be a problem on an 11/10.
> 
> Why? The 11/10 also have a Unibus, and also needs the terminator as well
> as the SACK and other signals in order.

The M9302 includes logic to assert SACK if a grant (any BG or NPG) gets to it, 
meaning no device on the bus as intercepted the grant. This causes problems
with an open grant chain in that the CPU sees the SACK, tries to deassert
the grant (which it hasn't asserted in the first place) and the bus is locked 
with
SACK asserted and no grants. The M930 terminator does not include said logic.

As a result an open grant chain will cause problems on a machine where the 
terminator is an M9302. On a machine where it's an M930, an open grant chain
is of course a bad idea (interrupts and DMA will not work properly) but it will 
not
lock the bus and prevent the front panel from working. 

The 11/10 generally uses an M930 terminator.  


> > But you do need some kind of termination/pullups on the Unibus. At least
> > fit the CPU-end terminator (M930 in the right slot near the CPU boards) if
> > you haven't done so already.
> 
> You most likely want to terminate the other end as well.

It may not be a perfect electrical match, but if all you have is the CPU 
backplane, 
or even a BA11-K full of backplanes, I am certain a terminator at the CPU end 
only
will get the machine doing something, even running programs correctly. Totally 
ignoring the front panel is not caused by a missing far-end terminator on such 
a 
small machine.

-tony

Re: PDP-11/10 repair started

[Johnny Billquist]

On 2015-10-05 13:50, tony duell wrote:

The specific issue of an open grant chain locking the Unibus is a quirk
of the M9302 terminator (which asserts SACK under such conditions). This
is unlikely to be a problem on an 11/10.


Why? The 11/10 also have a Unibus, and also needs the terminator as well
as the SACK and other signals in order.


The M9302 includes logic to assert SACK if a grant (any BG or NPG) gets to it,
meaning no device on the bus as intercepted the grant. This causes problems
with an open grant chain in that the CPU sees the SACK, tries to deassert
the grant (which it hasn't asserted in the first place) and the bus is locked 
with
SACK asserted and no grants. The M930 terminator does not include said logic.

As a result an open grant chain will cause problems on a machine where the
terminator is an M9302. On a machine where it's an M930, an open grant chain
is of course a bad idea (interrupts and DMA will not work properly) but it will 
not
lock the bus and prevent the front panel from working.

The 11/10 generally uses an M930 terminator.


Right. However, the SACK signal exists, even on the 11/10.
And if that signal is floating, or non-working, you can still have 
problems. So, termination is still important.
The additional feature of of the M9302 is just to catch if BG signals 
are sent out when noone was actually requesting an interrupt.


So your comment about open grant chain locking is relevant, but do not 
negate the claim that you need to make sure you have terminators in 
place, and that signals are carried through the whole backplane.


Note that my original comment was not about BG/BR continuity as such, 
but termination and signals running through the whole bus. BG/BR is just 
one part of that.



But you do need some kind of termination/pullups on the Unibus. At least
fit the CPU-end terminator (M930 in the right slot near the CPU boards) if
you haven't done so already.


You most likely want to terminate the other end as well.


It may not be a perfect electrical match, but if all you have is the CPU 
backplane,
or even a BA11-K full of backplanes, I am certain a terminator at the CPU end 
only
will get the machine doing something, even running programs correctly. Totally
ignoring the front panel is not caused by a missing far-end terminator on such a
small machine.


The 11/10 do not have a built-in terminator at the CPU end. You are 
supposed to have two M930 on the backplane.


Johnny

Re: PDP-11/10 repair started

[Noel Chiappa]

>> From: Tony Duell 

>> I am working from 2 Printsets, both from Bitsavers. One is the GT40 one
>> (yet another backplane of course, but the same CPU, core memory, etc).

> Ah, thanks for that pointer; I'll see if it shows the same board
> versions as my 'early' hardcopy set.

It does seem to show _basically_ the same as my set; the print revs are
slightly different (slightly later), but it does have what I've called the
'early' boards. The differences with mine are minor - e.g. on the M7261,
there are two extra capacitors in the prints in the GT40 set.


> isn't the switchable divider only present on later boards (the early
> ones being pretty much 110 baud only)?

Ooh, right you are - another way to tell the early M7260 from later ones. If
your memory of a version with a crystal is correct, that does indeed make
three versions of that board. Can all -11/05 and -11/10 owners look at their
M7260, and see if they have one with a crystal? If so, we can institute a
search for the prints of that version.

> This printset _does_ show the jumpers I mentioned. Look at page 75 of
> the .pdf bottom, left-ish. Jumper W1 is described as disabling the
> internal serial port when fitted.

Ah, right you are; maybe I am mis-remembering a long search through the
'early' printset for jumper W1?


>> You have to tweak the trim pot to change from the 110/220/440/880/1760
>> speed set to the 150/300/600/1200/2400! Ugly!!)

> May be easier than finding the right crystal to change a DL11A-E to the
> 'other' set of baud rates :-)

Well, today that's not so easy (although I did stumble on a pair of the 9600
baud crystals on eBay a while back), but back then, it was a lot easier!


> The M9302 includes logic to assert SACK if a grant (any BG or NPG) gets
> to it ... This causes problems with an open grant chain in that the CPU
> sees the SACK, tries to deassert the grant (which it hasn't asserted in
> the first place) and the bus is locked with SACK asserted and no grants.

So, how did the M9302 see a 'grant' to start the whole process? Noise on an
open input? Or maybe it powers up in that state?


>> From: Johnny Billquist

>> You most likely want to terminate the other end as well.

> It may not be a perfect electrical match, but if all you have is the
> CPU backplane .. I am certain a terminator at the CPU end only will get
> the machine doing something

Yes, I think that in electrical terms it would be very similar to the typical
LSI-11, which works fine with termination at one end only. Yes, there will be
more noise on the bus due to the un-terminated end, but it will probably
still work OK.

Noel

Re: PDP-11/10 repair started

[Henk Gooijen]

-Oorspronkelijk bericht- 
From: Johnny Billquist

Sent: Monday, October 05, 2015 4:53 PM
To: cctalk@classiccmp.org
Subject: Re: PDP-11/10 repair started

On 2015-10-05 13:50, tony duell wrote:

The 11/10 generally uses an M930 terminator.


Right. However, the SACK signal exists, even on the 11/10.
And if that signal is floating, or non-working, you can still have
problems. So, termination is still important.
The additional feature of of the M9302 is just to catch if BG signals
are sent out when noone was actually requesting an interrupt.

So your comment about open grant chain locking is relevant, but do not
negate the claim that you need to make sure you have terminators in
place, and that signals are carried through the whole backplane.

Note that my original comment was not about BG/BR continuity as such,
but termination and signals running through the whole bus. BG/BR is just
one part of that.


But you do need some kind of termination/pullups on the Unibus. At least
fit the CPU-end terminator (M930 in the right slot near the CPU boards) 
if

you haven't done so already.


You most likely want to terminate the other end as well.


It may not be a perfect electrical match, but if all you have is the CPU 
backplane,
or even a BA11-K full of backplanes, I am certain a terminator at the CPU 
end only
will get the machine doing something, even running programs correctly. 
Totally
ignoring the front panel is not caused by a missing far-end terminator on 
such a

small machine.


The 11/10 do not have a built-in terminator at the CPU end. You are
supposed to have two M930 on the backplane.

Johnny

=
Sorry for the delayed answer, I don't have email available at work -:/

I have one M930 in slot 3 position A-B, because that is the termination
for the processor. I am pretty sure (not 100%) that I also have an M930
in slot 9 position A-B. To be complete, this is the current state.
slot 1 A-F : M7260
slot 2 A-F : M7261
slot 3 A-B : M930   C-D : G7273
slot 4 A-B : M9970  C-D : G7273
slot 5 C-D : G7273
slot 6 empty
slot 7 empty
slot 8 empty
slot 9 A-B : M930

Slot 6-7-8-9 is for core memory, respectively G235, H217D, G114, M8293.
The documentation says that a G727 should go in slot 3-4-5 position D.
I hate those "knuckle-busters". Plus, I am lazy to check NPR continuity
on the backplane, so I installed G7273s instead of G727s. Always good.

I totally forgot that the GT40 is based on the 11/05. Great tip in case
it turns out that I have a "different" CPU module! You never know ...

When I got the 11/10, all boards were in their correct location, so after
the goof up of wrong placement, somebody more knowledgeable placed the
boards in their correct slots. I guess he hoped to see a working system.
So I do not know which board was place where :-/  That makes guessing
what might be damaged a bit tricky, although in/outs that go to fingers
of the board are first candidate for inspection. A visual check did not
reveal anything abviously blown or burnt.

@Bill : keep us posted of your progress :-)
@Johnny : I do not think an NPR problem exists, unless it is there,
because of damaged hardware.
@Jon : After I checked the correct levels of all power suplly voltages,
I also tried the system with slot 6-7-8-9 filled with the core memory.
Behavior did not change. Again, I am pretty sure NPR is not the problem.
@Noell : thanks for mentioning the possible versions!  Good to keep in
mind!

As Tony says, the M930 terminator close to the CPU (slot 3) should be
enough, especially as all other slots that matter are empty. But I am
pretty sure that for 100% correctness I also have one M930 in slot 9.

Thanks for all support, I hope to continue on Saturday ...
- Henk

Re: PDP-11/10 repair started

[Johnny Billquist]

On 2015-10-05 17:24, Henk Gooijen wrote:

-Oorspronkelijk bericht- From: Johnny Billquist
Sent: Monday, October 05, 2015 4:53 PM
To: cctalk@classiccmp.org
Subject: Re: PDP-11/10 repair started

On 2015-10-05 13:50, tony duell wrote:

The 11/10 generally uses an M930 terminator.


Right. However, the SACK signal exists, even on the 11/10.
And if that signal is floating, or non-working, you can still have
problems. So, termination is still important.
The additional feature of of the M9302 is just to catch if BG signals
are sent out when noone was actually requesting an interrupt.

So your comment about open grant chain locking is relevant, but do not
negate the claim that you need to make sure you have terminators in
place, and that signals are carried through the whole backplane.

Note that my original comment was not about BG/BR continuity as such,
but termination and signals running through the whole bus. BG/BR is just
one part of that.


But you do need some kind of termination/pullups on the Unibus. At
least
fit the CPU-end terminator (M930 in the right slot near the CPU
boards) if
you haven't done so already.


You most likely want to terminate the other end as well.


It may not be a perfect electrical match, but if all you have is the
CPU backplane,
or even a BA11-K full of backplanes, I am certain a terminator at the
CPU end only
will get the machine doing something, even running programs correctly.
Totally
ignoring the front panel is not caused by a missing far-end terminator
on such a
small machine.


The 11/10 do not have a built-in terminator at the CPU end. You are
supposed to have two M930 on the backplane.

Johnny

=
Sorry for the delayed answer, I don't have email available at work -:/

I have one M930 in slot 3 position A-B, because that is the termination
for the processor. I am pretty sure (not 100%) that I also have an M930
in slot 9 position A-B. To be complete, this is the current state.
slot 1 A-F : M7260
slot 2 A-F : M7261
slot 3 A-B : M930   C-D : G7273
slot 4 A-B : M9970  C-D : G7273
slot 5 C-D : G7273
slot 6 empty
slot 7 empty
slot 8 empty
slot 9 A-B : M930

Slot 6-7-8-9 is for core memory, respectively G235, H217D, G114, M8293.
The documentation says that a G727 should go in slot 3-4-5 position D.
I hate those "knuckle-busters". Plus, I am lazy to check NPR continuity
on the backplane, so I installed G7273s instead of G727s. Always good.

I totally forgot that the GT40 is based on the 11/05. Great tip in case
it turns out that I have a "different" CPU module! You never know ...

When I got the 11/10, all boards were in their correct location, so after
the goof up of wrong placement, somebody more knowledgeable placed the
boards in their correct slots. I guess he hoped to see a working system.
So I do not know which board was place where :-/  That makes guessing
what might be damaged a bit tricky, although in/outs that go to fingers
of the board are first candidate for inspection. A visual check did not
reveal anything abviously blown or burnt.

@Bill : keep us posted of your progress :-)
@Johnny : I do not think an NPR problem exists, unless it is there,
because of damaged hardware.
@Jon : After I checked the correct levels of all power suplly voltages,
I also tried the system with slot 6-7-8-9 filled with the core memory.
Behavior did not change. Again, I am pretty sure NPR is not the problem.
@Noell : thanks for mentioning the possible versions!  Good to keep in
mind!

As Tony says, the M930 terminator close to the CPU (slot 3) should be
enough, especially as all other slots that matter are empty. But I am
pretty sure that for 100% correctness I also have one M930 in slot 9.

Thanks for all support, I hope to continue on Saturday ...
- Henk


Ok. I got the initial impression that you only had the CPU in. Thanks 
for the expanded info.


When you don't have any core memory, I wonder if you might need bus 
grants in those slots as well...? It's not as if they aren't a part of 
the Unibus... Memory sits on the Unibus, just like everything else, 
remember? Needs to check further if any special wiring are in place for 
those slots, though.


Johnny

RE: PDP-11/10 repair started

[tony duell]

> 
> When you don't have any core memory, I wonder if you might need bus
> grants in those slots as well...? It's not as if they aren't a part of
> the Unibus... Memory sits on the Unibus, just like everything else,
> remember? Needs to check further if any special wiring are in place for
> those slots, though.

The core memory slots are specially wired (that's why the 8K and 16K
backplanes are different, one is wired for one set of core, the other
for 2 sets, with SPCs in the remaining slots). You do NOT put grant
cards in there.

In any case, an open grant chain will not cause problems at this stage of the
11/10. If you left out all the grant continuity cards the machine would still 
respond
to the console switches, let you load addresses, etc. So let's get that working
first

-tony

Re: PDP-11/10 repair started

[Johnny Billquist]

On 2015-10-05 17:56, Henk Gooijen wrote:

-Oorspronkelijk bericht- From: Johnny Billquist Sent: Monday,
October 05, 2015 5:44 PM To: cctalk@classiccmp.org Subject: Re:
PDP-11/10 repair started
Ok. I got the initial impression that you only had the CPU in. Thanks
for the expanded info.

When you don't have any core memory, I wonder if you might need bus
grants in those slots as well...? It's not as if they aren't a part of
the Unibus... Memory sits on the Unibus, just like everything else,
remember? Needs to check further if any special wiring are in place for
those slots, though.

Johnny

=

I am not sure the "core slots" would need grant cards. The documentation
is clear about slot 3-4-5 as SPC, needing grant cards. I never saw any
doc where the core memory slots, when optional, but not installed, could
be used as an SPC slot. I certainly am Not "trying" that ...
I did try the system *with* the core slots filled with the correct boards
but the behavior remained the same.
To make fault finding not more complex, I removed the core board set.


Ok. Not sure if it makes it more complex or not, but I guess it's not 
the issue right now anyway.


But my original comment about the behavior you described being very much 
like what I've seen on other machines with bad/no termination still 
applies. CPU seemingly stuck, but doing a master reset sortof gets it 
out. But not functioning as it should.


Well, no more ideas here at the moment.

Johnny

Re: PDP-11/10 repair started

[Noel Chiappa]

> From: Tony Duell

> There are at least 2 versions of the 11/10 CPU boards. The later one,
> which I thought was the 11/10S, has soldered wire links to disable the
> arbiter ... I think another link disables the built-in console port.
> And didn't it use a crystal rather than RC clock for the built-in
> serial console port? 

It would be good to know exactly how many there are! I think there are at
least three, because:

There are two sets of 11/05 (let's not bother with the 05-10 distinction, I
think that's just the artwork on the front panel) prints on-line,
"1105_RevAH_Engineering_Drawings_Jul76":

  
http://bitsavers.org/pdf/dec/pdp11/1105/1105_RevAH_Engineering_Drawings_Jul76.pdf

and "1105S_Schem":

  http://bitsavers.org/pdf/dec/pdp11/1105/1105S_Schem.pdf

Both of them show the exact same board revs:

  M7260 Rev C (drawing: date 1-22-73, rev N)
  M7261 Rec F (drawing: date 9-5-73, rev U)

However, I don't think they show the W1 jumper to disable the onboard serial
line, etc (I spent quite a while looking for it in these prints, after hearing
of its existence :-); and they definitely show an RC circuit, and not a
crystal, as the baud rate generator.

So, the board set with those features (jumper + crystal) must be a later set
than the ones shown in those two on-line sets of prints. (One of which is
marked "11/05S", just to be confusing - I didn't check to see if that rev of
the cards has a jumper to allow another machine to be bus master.)


However, I have a set of hardcopy 11/05 prints, and they show an even earlier
state:

  M7260 Rev B (drawing: date 4-07-72 rev H)
  M7261 Rev C (drawing: date 3-19-72 rev J)

On this rev of the M7260, the UART chip is down near the contact fingers, and
'horizontal', not up near the Berg connector to the console, and 'vertical'.
The M7261 is also quite distinct; there's a big gap on the center left of the
card (full of traces). Just to thicken the plot a bit more, I have an M7261
that looks like that, and it is marked "M7261E" in the etch!


So that's '3 versions' at least of the 11/05:

- The latest (jumpers and crystal)
- The middle (in the on-line prints)
- The early (in the hardcopy prints I have)

I say '3' because it's possible there are only early and late versions of
each card, and the '3 versions' I listed are actually 3 different mixes of
old/new cards.


> The original and later boards seem to have the same numbers.

Indeed; there's nothing on the handles, etc to indicate that they are
totally different boards (except for that "M7261E" in the etch.

Any chance you can find a print set that shows the later cards, with the
jumpers, crystal, etc?

Noel

Re: PDP-11/10 repair started

[Noel Chiappa]

> From: Tony Duell 

> I am working from 2 Printsets, both from Bitsavers. One is the GT40 one
> (yet another backplane of course, but the same CPU, core memory, etc).

Ah, thanks for that pointer; I'll see if it shows the same board versions as
my 'early' hardcopy set.

> The other is the 11/05S schematic, which shows the later boards with
> the crystal UART clock

Say what? The "11/05S schematic" from Bitsavers shows the RC clock; look on
page 61, bottom left corner, there's an RC circuit (and a couple of flops)
producing an output "DPH TTY CLK (I) H", which is fed into the baud rate
divider in the upper left corner.

(Ooooh, what an ugly circuit! You have to tweak the trim pot to change from
the 110/220/440/880/1760 speed set to the 150/300/600/1200/2400! Ugly!!)

Noel

Re: PDP-11/10 repair started

[Henk Gooijen]

-Oorspronkelijk bericht- 
From: tony duell

Sent: Sunday, October 04, 2015 8:16 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: PDP-11/10 repair started



Some corrections to my post regarding the console LED behavior.

Voltage levels on the CPU backplane are still good whne the 2 CPU boards
are installed in the backplane, but the processor is not responsive to
the switches on the console panel.


It's been a long time since I've been inside an 11/10 (that will change soon 
as I fix
the one damaged  by the idiot removal men,..) but just to eliminate the 
obvious

check that ACLO and DCLO are solidly high.

On a system like this I would always start by looking at the microcode 
program counter.
What state(s) is it in? If it is sequencing through states, does the 
sequence make any sense?

Does anything happen when you press LOAD ADDR (say)?

Maybe start from one of the switches like LOAD ADDR and see if it is 
generating the right

signals on the processor board.

-tony

=
Oops, I forgot to mention a few other checks that I did ...
AC LO and DC LO are some 4.6V. Both have a 130 mV ripple, no spikes.
That seems OK to me.

As the console ribbon cable was disconnected, I also checked the toggle
switches (LOAD ADDR, EXAM, START, CONT, DEP) and the switches SW0~SW15
and HALT/EANBLE. In the OFF position the signal is 0.06V and in the ON
position I measured voltages between 4.5 and 4.6V. Toggles and switch
signals seems OK too.
I am fairly confident that the console itself is OK.

Thanks for the tip checking the microcode program counter. I hope to
get to that next weekend. Also, with the correct module on extenders
I will check what toggling LOAD ADDRS does signal-wise. Looking at
the console LEDs it does nothing :-/

thanks,
- Henk 

Re: PDP-11/10 repair started

[Henk Gooijen]

Some corrections to my post regarding the console LED behavior.

Voltage levels on the CPU backplane are still good whne the 2 CPU boards
are installed in the backplane, but the processor is not responsive to
the switches on the console panel.

The RUN LED is on, ADDRESS/DATA are all off. When the HALT/ENABLE switch
is in the HALT position and START is toggled ("reset"), the RUN goes off
and the ADDRESS/DATA LEDs all go on.

LOAD ADDR, EXAM and CONT have no response.

When I set HALT/ENABLE switch to ENABLE and toggle START, the RUN LED
goes on and DATA/ADDRESS LEDs go off, except LED "0".

greetz,
- Henk, PA8PDP

RE: PDP-11/10 repair started

[tony duell]

> 
> Oops, I forgot to mention a few other checks that I did ...
> AC LO and DC LO are some 4.6V. Both have a 130 mV ripple, no spikes.
> That seems OK to me.

Sure, those sound OK to me too. But you would have felt a right idiot if you
had spent days working through the microcode and CPU logic only
to find the real cause was something like that. Yes, I've been there,
done that...

[...]

> Thanks for the tip checking the microcode program counter. I hope to
> get to that next weekend. Also, with the correct module on extenders
> I will check what toggling LOAD ADDRS does signal-wise. Looking at
> the console LEDs it does nothing :-/

In general on a microcoded system, assuming a listing of the microcode
is available (as here), the microcode program counter a good place
to start testing.

You should look for several things : 

Is the microcode running, or is it stuck in a particular address? 

If the latter, should it be stuck there, perhaps it is waiting for 
some external input (like a console switch :-)). Try to find some
way of giving it that input and see what happens.

If the former, is the sequence of states reasonable (does it correspond 
with something the microcode could ever do, evem if it shouldn't
be doing that now). Is it a possible sequence of states for what the
machine should be doing (What I mean here is that if the microcode
is say fetching something from memory, interpretting it as a particular
instruction, doing that, and repeating, then the microcode is doing
something that sometimes it should be doing (e.g.. when running a program)
even if it shoudn't be doing it when you have halted the machine from
the console, whereas if the microcode is jumping through an apparently 
random set of states then I would suspect the microcode program
counter register, the control store ROMs, jump logic, etc.

Incidentally, is this an 11/10 or an 11/10S (what are the M-numbers on the 
CPU boards)?

-tony

Re: PDP-11/10 repair started

[Henk Gooijen]

-Oorspronkelijk bericht- 
From: tony duell

Sent: Sunday, October 04, 2015 9:52 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: PDP-11/10 repair started


the microcode is "on the menu" for next weekend ...
The system is a 11/10S, CPU is M7260 and M7261.


Are you sure that's an 'S'? I thought the 'S' was the M8260/M8261 board
set with the links to disable the bus arbiter so it can be used as a slave
processor.

Anyway, getting back to this... I had forgotten that the 11/10 loads the LED
data serially into a shift register on the console board. Is that clock and 
counter
running (on the console board)? Also check round the '150 mux on the data 
path

board, that is the source of the bitstream for the LEDs

The switch logic seems to be sheet CONE in my printset (which is actually 
for

the GT40, but it's the same processor). On the control logic board, ROM
E100 seems to determine the microcode address for console operations.

Start with CONE BUT SWITCHES L, which seems to be an overall enable for 
this.
It starts from the '154 E078 on that board (sheet CONE again). It is 
controlled by

the microcode ROM E105 (sheet CONG). Microcode program counter is E102
and E091 (sheet CONF). Also look at the CPU clock (sheet CONJ). Is it 
running? If

not, look at those gates E013d, etc, that disable it.

That's something to be going one with anyway...

-tony

=

Yup, the clock and counter on the console board are running.
That's why the console maintenance tests 5 - 8 work, producing
the data patterns on the LEDs :-)
Thanks for the pointers!  I haven't looked at the schematics yet.

Yes, it is an 11/10S.
AFAIK, the M7260 and M7261 is used in all 11/10 versions, and
of course all 11/05 versions.  I could be wronge though ...
I guess you are confused with the M7265/M7266 (11/34) and
M8265/M8266 (11/34A).

- Henk 

Re: PDP-11/10 repair started

[ben]

On 10/4/2015 3:04 PM, Henk Gooijen wrote:



=
I define 11/10"S" by the backplane. There are 4 different backplanes
for the 11/10 and 11/05, according to the doc. I have them on my website,
www.pdp-11.nl/pdp11-05/cpu/backplanes.html
I did not know that there were different versions of the CPU boards,
except the Rev.E and Rev.F of the M7261.  Good to know!
Seeing whether there is an XTAL for the console comms line is easy to
spot, but IIRC it is RC on my M7260.

- Henk


Now did check on what version of magic smoke you got?
That may be important too.
Is there any way to tell if all the TTL was fried,
or just few chips by the wrong pins from the schematics?
Ben.
Good Luck ... this email will turn into another copy of windows in 9 8 7 ...

RE: PDP-11/10 repair started

[tony duell]

> Some corrections to my post regarding the console LED behavior.
> 
> Voltage levels on the CPU backplane are still good whne the 2 CPU boards
> are installed in the backplane, but the processor is not responsive to
> the switches on the console panel.

It's been a long time since I've been inside an 11/10 (that will change soon as 
I fix
the one damaged  by the idiot removal men,..) but just to eliminate the obvious
check that ACLO and DCLO are solidly high.

On a system like this I would always start by looking at the microcode program 
counter.
What state(s) is it in? If it is sequencing through states, does the sequence 
make any sense?
Does anything happen when you press LOAD ADDR (say)?

Maybe start from one of the switches like LOAD ADDR and see if it is generating 
the right
signals on the processor board.

-tony

RE: PDP-11/10 repair started

[tony duell]

> 
> Yes, it is an 11/10S.

How do you define '11/10S' ? 

> AFAIK, the M7260 and M7261 is used in all 11/10 versions, and
> of course all 11/05 versions.  I could be wronge though ...

The 11/05 and 11/10 are, by now, the same machine ;-). What I mean
by that is that essentially the difference was what you got with it when 
you ordered it, and of course today you are not going to find the machine
exactly as DEC would have shipped it. 

> I guess you are confused with the M7265/M7266 (11/34) and
> M8265/M8266 (11/34A).

There are at least 2 versions of the 11/10 CPU boards. The later one, which
I thought was the 11/10S, has soldered wire links to disable the arbiter
(the 'S' meaning it can be a _S_lave processor on another machine's 
Unibus). I think another link disables the built-in console port. And didn't it
use a crystal rather than RC clock for the built-in serial console port? 

[The sooner I get my bookshelves made so I can find all my printsets the 
better!]

You're right, I was getting confused over the M numbers. The original and later
boards seem to have the same numbers. The circuitry is very similar, but the IC
references I have given might be wrong. 

-tony


- Henk

Re: PDP-11/10 repair started

[Henk Gooijen]

-Oorspronkelijk bericht- 
From: tony duell

Sent: Sunday, October 04, 2015 9:09 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: PDP-11/10 repair started



Oops, I forgot to mention a few other checks that I did ...
AC LO and DC LO are some 4.6V. Both have a 130 mV ripple, no spikes.
That seems OK to me.


Sure, those sound OK to me too. But you would have felt a right idiot if you
had spent days working through the microcode and CPU logic only
to find the real cause was something like that. Yes, I've been there,
done that...

[...]


Thanks for the tip checking the microcode program counter. I hope to
get to that next weekend. Also, with the correct module on extenders
I will check what toggling LOAD ADDRS does signal-wise. Looking at
the console LEDs it does nothing :-/


[... snip good microcode stuff ...]

Incidentally, is this an 11/10 or an 11/10S (what are the M-numbers on the
CPU boards)?

-tony

=
Tony,

the microcode is "on the menu" for next weekend ...
The system is a 11/10S, CPU is M7260 and M7261.

- Henk 

RE: PDP-11/10 repair started

[tony duell]

> 
> 
> the microcode is "on the menu" for next weekend ...
> The system is a 11/10S, CPU is M7260 and M7261.

Are you sure that's an 'S'? I thought the 'S' was the M8260/M8261 board
set with the links to disable the bus arbiter so it can be used as a slave
processor. 

Anyway, getting back to this... I had forgotten that the 11/10 loads the LED
data serially into a shift register on the console board. Is that clock and 
counter
running (on the console board)? Also check round the '150 mux on the data path
board, that is the source of the bitstream for the LEDs

The switch logic seems to be sheet CONE in my printset (which is actually for
the GT40, but it's the same processor). On the control logic board, ROM
E100 seems to determine the microcode address for console operations.

Start with CONE BUT SWITCHES L, which seems to be an overall enable for this. 
It starts from the '154 E078 on that board (sheet CONE again). It is controlled 
by
the microcode ROM E105 (sheet CONG). Microcode program counter is E102
and E091 (sheet CONF). Also look at the CPU clock (sheet CONJ). Is it running? 
If
not, look at those gates E013d, etc, that disable it. 

That's something to be going one with anyway...

-tony

Re: PDP-11/10 repair started

[Henk Gooijen]

-Oorspronkelijk bericht- 
From: tony duell

Sent: Sunday, October 04, 2015 10:44 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: PDP-11/10 repair started


Yes, it is an 11/10S.


How do you define '11/10S' ?


AFAIK, the M7260 and M7261 is used in all 11/10 versions, and
of course all 11/05 versions.  I could be wrong though ...


The 11/05 and 11/10 are, by now, the same machine ;-). What I mean
by that is that essentially the difference was what you got with it when
you ordered it, and of course today you are not going to find the machine
exactly as DEC would have shipped it.


I guess you are confused with the M7265/M7266 (11/34) and
M8265/M8266 (11/34A).


There are at least 2 versions of the 11/10 CPU boards. The later one, which
I thought was the 11/10S, has soldered wire links to disable the arbiter
(the 'S' meaning it can be a _S_lave processor on another machine's
Unibus). I think another link disables the built-in console port. And didn't 
it

use a crystal rather than RC clock for the built-in serial console port?

[The sooner I get my bookshelves made so I can find all my printsets the
better!]

You're right, I was getting confused over the M numbers. The original and 
later
boards seem to have the same numbers. The circuitry is very similar, but the 
IC

references I have given might be wrong.

-tony

=
I define 11/10"S" by the backplane. There are 4 different backplanes
for the 11/10 and 11/05, according to the doc. I have them on my website,
www.pdp-11.nl/pdp11-05/cpu/backplanes.html
I did not know that there were different versions of the CPU boards,
except the Rev.E and Rev.F of the M7261.  Good to know!
Seeing whether there is an XTAL for the console comms line is easy to
spot, but IIRC it is RC on my M7260.

- Henk 

Re: PDP-11/10 repair started

[william degnan]

I just yesterday started working on assembling an 11/05 S with a BK11-K
backplane.  At the moment I am working through the power regulators to make
sure everything is right before I install the boards.  I am assembling from
parts on hand but I do have the correct cards.  I have M7260/61 and 8K
Core, etc.Just one 9 slot backplane.  Nice simple system.
Bill

On Sun, Oct 4, 2015 at 5:27 PM, ben  wrote:

> On 10/4/2015 3:04 PM, Henk Gooijen wrote:
>
>
>> =
>> I define 11/10"S" by the backplane. There are 4 different backplanes
>> for the 11/10 and 11/05, according to the doc. I have them on my website,
>> www.pdp-11.nl/pdp11-05/cpu/backplanes.html
>> I did not know that there were different versions of the CPU boards,
>> except the Rev.E and Rev.F of the M7261.  Good to know!
>> Seeing whether there is an XTAL for the console comms line is easy to
>> spot, but IIRC it is RC on my M7260.
>>
>> - Henk
>>
>
> Now did check on what version of magic smoke you got?
> That may be important too.
> Is there any way to tell if all the TTL was fried,
> or just few chips by the wrong pins from the schematics?
> Ben.
> Good Luck ... this email will turn into another copy of windows in 9 8 7
> ...
>



-- 
Bill
vintagecomputer.net

Re: PDP-11/10 repair started

[Johnny Billquist]

On 2015-10-04 20:09, Henk Gooijen wrote:

Some corrections to my post regarding the console LED behavior.

Voltage levels on the CPU backplane are still good whne the 2 CPU boards
are installed in the backplane, but the processor is not responsive to
the switches on the console panel.

The RUN LED is on, ADDRESS/DATA are all off. When the HALT/ENABLE switch
is in the HALT position and START is toggled ("reset"), the RUN goes off
and the ADDRESS/DATA LEDs all go on.

LOAD ADDR, EXAM and CONT have no response.

When I set HALT/ENABLE switch to ENABLE and toggle START, the RUN LED
goes on and DATA/ADDRESS LEDs go off, except LED "0".


You mentioned NPR problems before, but I have never seen a broken NPR 
signal cause any problems at power on. Broken NPR normally cause DMA to 
not work.


However, what you describe sounds exactly how I've seen a lot of 
machines behave when the terminator is missing. Check for bus 
continuity, and termination.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

RE: PDP-11/10 repair started

[tony duell]

> 
> > The other is the 11/05S schematic, which shows the later boards with
> > the crystal UART clock
> 
> Say what? The "11/05S schematic" from Bitsavers shows the RC clock; look on
> page 61, bottom left corner, there's an RC circuit (and a couple of flops)
> producing an output "DPH TTY CLK (I) H", which is fed into the baud rate
> divider in the upper left corner.

Yes, you're right. I am not sure what I was thinking of last night But isn't
the switchable divider only present on later boards (the early ones being 
pretty much 110 baud only)?

This printset _does_ show the jumpers I mentioned. Look at page 75 of the 
.pdf bottom, left-ish. Jumper W1 is described as disabling the internal serial
port when fitted. On the next page, just above leftish of centre is W2, 
documented as installed to make a slave processor.

> (Ooooh, what an ugly circuit! You have to tweak the trim pot to change from
> the 110/220/440/880/1760 speed set to the 150/300/600/1200/2400! Ugly!!)

May be easier than finding the right crystal to change a DL11A-E to the
'other' set of baud rates :-)

-tony



Noel