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