More PDP-11 problems

Pete Turnbull pete at dunnington.plus.com
Sun Jan 1 10:52:55 CST 2006


On Dec 31 2005, 19:32, Charles wrote:
> As I posted previously, the 26.667 MHz master clock oscillator had
> failed on the KDF11-BA cpu (probably from rough handling). For now
> I have a 30.000 MHz module from the junkbox. Looks like I spoke
> too soon (I had the J17-18 always-ODT jumper installed so seeing
> the ODT prompt was not a surprise). I don't know if this minimal
> overclocking is causing my current problems though:

10% is not minimal.  It might be enough to make a difference.

> I have found two substantially different tables showing how to set
> the CPU DIPswitches. KDF11-B Maintenance Manual (MM), and KDF11-BA
> Users Manual (UM). The UM says I should have switches 1-8 set to:
>
> 1-On:  CPU diagnostic
> 2-On:  Memory diagnostic
> 3-Off: No DECNet boot
> 4-Off: Turn-key boot (sel. sw 5-8)
> 5-Off:
> 6-Off:
> 7-On:  RL01/02 boot
> 8-Off:
>
> I don't have the MM handy, it was .TIFF pages, but for the same
> functions only switches 5 and 7 were On.

The switches are just mapped to a register that the boot ROMs -- or
indeed any other code -- can read.  It's the Configuration and Display
Register (CDR) at 777524.  It's nothing to do with microcode, nor is it
anything that directly affects the hardware.

The effect of the switches depends entirely on how they're interpreted
by the bootstrap code, and the description you list above is correct
for the original BDV11 bootstrap and for the early PDP-11/23plus
bootstrap (which was almost the same).  It's not correct for the
microPDP-11/23 bootstraps.

The early microPDP-11/23 (KDF11-BE) bootstrap used switch 1-8 ON to set
up for ANSI VDU console terminal, and 1-7 ON to enable the quick memory
diagnostic.  Usually 1-1 to 1-4 would also be on and 1-5 and 1-6 off,
to select the MSCP aiutoboot.  All off would inhibit autoboot.  All six
on would loop the self-test.  There were 25 defined boot settings, and
37 reserved or unused.

If you tell us what ROMs you have on the board we can tell what
firmware version you have.

> with the RUN light off, state LED's=1111. Manual says 17 octal
> means the CPU is not in power-up mode 2, but J18-19 is correctly
> installed. I don't get any memory test messages or identifying
> text either, just the ODT prompt.
>
> According to the UM page 2-5, it looks like the internal boot
> address of 173000 is being generated correctly, but if BHALT L is
> being (incorrectly) asserted, the result is entry to ODT and a
> halt. Which matches what I see happening.
>
> If I set the front panel HALT switch and flip RESTART, the CPU
> immediately halts with state LED's=0001 which is correct. So it
> doesn't look like the HALT line is shorted to ground.
>
> Also, I can examine memory using ODT at the boot EPROM address of
> 773000 and read the following:
>
> 112737
> 000016
> 177524
> 000005
> 012700
> 000340
> 106400
> 012706
> 177524...
>
> I don't have a PDP-11 disassembler handy but that looks like some
> kind of executable code, hopefully the bootstrap.

Looks like bootstrap setup code.  The first few words are

> 112737	MOVB #16, @#0177524 ; set low 4 bits of display reg
> 000016			    ; this turns the LEDS off
> 177524
> 000005	RESET		    ; resets the bus and the MMU
> 012700	MOV #340, R0        ; set bits 5-7, which are interrupt
> 000340			    ; priority in the PSW
> 106400	MTPS R0		    ; set Processor Status Word
> 012706	MOV #177524, R6	    ; prob. to read the config register
> 177524

Looks like an 11/23plus bootstrap, rather than, say, a microPDP-11/23
boot.

> When I examine memory at 173000 it's all 1's (177777) but I can
> deposit and read data correctly into locations there. Shouldn't
> the bootstrap program be copying its code there?

No copying involved.  When you're using ODT, you use 18-bit addressing
(at least on this CPU), and 173000 then is simply the 8th bank of
memory (bank 7, counting from zero).  773000 is the I/O page, where the
bootstrap lives, and apparewntly you realised both those facts, but
perhaps didn't realise that when the CPU is running, any reference to
bank 7 (160000-177777) asserts the BBS7 (Bus Bank Select 7) signal so
when a program accesses 173000, it actually gets the boot ROM.

That's hardwired, in fact; it doesn't even use the MMU.  In effect,
accessing the highest-addressable bank always gets the I/O page (this
is a slight oversimplification, because it depends on devices
recognising the BBS7 signal, but it will do for this discussion).

> Again, if the
> HALT line is being set for some reason, then the copy operation
> can't take place... is that where I should be looking or am I
> following a false trail?

False trail.

Start by double-checking all the jumpers, especially J16/17/18/19 (you
probably want J18-19 and nothing on 16 or 17).  Check even the things
that should never have changed, eg that the test jumpers are all in the
correct places (J6-7, J8-9, J20-21, J34-35 not 33, J26-27 not 25).
 Check there's nothing on J15, that J22/23/24 are set for whatever type
of ROM/EPROM you have, etc.

-- 
Pete						Peter Turnbull
						Network Manager
						University of York



More information about the cctalk mailing list