PDP-11/05 clock interrupt

[Lee Gleason]

I've been trying to get the clock interrupt to work on an 11/05. I set up
vector 100 to point to 2000, where I store a 0, to halt it when the
interrupts comes. I set 100 octal, bit 6 set, in 177546 to enable the
interrupt. I can read back this value with an EXAMINE, so I know the value
got stored there. At location 1000 I have a 777 (branch on self). I put
700 in SP to give it some stack. I start it up at 1000, and it loops
forever - no interrupt, no halt. A look at 177546 shows 200 - bit 7 set,
which happens when the interrupt should have occurred, and bit 6 has been
cleared.

The 11/05 doccos don't mention any jumpers or switches to alter the
expected clock behavior to this. Anyone ever seen this happening on an 11/05
or 11/10? Or do I have some time with the oscilloscope ahead of me?
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.g...@gmail.com

[Dale R Worley]

"Lee Gleason" <lee.g...@comcast.net> writes:
> I've been trying to get the clock interrupt to work on an 11/05. I
> set up vector 100 to point to 2000, where I store a 0, to halt it when
> the interrupts comes. I set 100 octal, bit 6 set, in 177546 to enable
> the interrupt. I can read back this value with an EXAMINE, so I know
> the value got stored there. At location 1000 I have a 777 (branch on
> self). I put 700 in SP to give it some stack. I start it up at 1000,
> and it loops forever - no interrupt, no halt. A look at 177546 shows
> 200 - bit 7 set, which happens when the interrupt should have
> occurred, and bit 6 has been cleared.

You don't describe how you set the PS register. In order for the
clock to interrupt the CPU, the CPU's priority has to be lower than
the priority of the clock (which I don't remember, but you can look it
up). Generally, one sets the CPU priority to 0 during "ordinary"
code, which can be interrupted by every device.

I don't recall exactly how you set the priority from the console. I
seem to remember that you can set many of the bits in the PS
(including the priority level) by examine/deposit of 177776 from the
console. (Beware that in other PDP 11 models there are multiple PSs,
selected by the kernel/executive/user mode bits in the PS.)

Since an interrupt loads a new PC and PS, make sure you set up the new
PS at location 102 as well as the new PC at 100. I don't think that
makes a difference in your case, but if you have a real interrupt
routine, it will, especially the new priority level.

Be careful if you start your program by the start key on the console.
START does a number of initialization operations, including sending a
Unibus RESET signal, which IIRC clears the interrupt-enable bits on
all devices. Instead, enter code at 1000 to set up interrupt enable
before looping, or start the program by setting the PC via DEPOSIT and
then start the program with CONTINUE.

Dale

[Lee Gleason]

"Dale R Worley" wrote in message news:ypv61zi...@nntp.theworld.com...

"Be careful if you start your program by the start key on the console.
>START does a number of initialization operations, including sending a
>Unibus RESET signal, which IIRC clears the interrupt-enable bits on
>all devices. Instead, enter code at 1000 to set up interrupt enable
>before looping, or start the program by setting the PC via DEPOSIT and
>then start the program with CONTINUE.

That was it - the RESET from the start key was the problem.

Loading the PC from the console and using CONTINUE, and loading the IE bit
via program both work.

Thanks!

[glen herrmannsfeldt]

Lee Gleason <lee.g...@comcast.net> wrote:

> "Dale R Worley" wrote in message news:ypv61zi...@nntp.theworld.com...

> "Be careful if you start your program by the start key on the console.
>>START does a number of initialization operations, including sending a
>>Unibus RESET signal, which IIRC clears the interrupt-enable bits on
>>all devices. Instead, enter code at 1000 to set up interrupt enable
>>before looping, or start the program by setting the PC via DEPOSIT and
>>then start the program with CONTINUE.

> That was it - the RESET from the start key was the problem.

> Loading the PC from the console and using CONTINUE, and loading the IE bit
> via program both work.

Reminds me of many years ago, booting what I believe was an 11/03.

If you didn't turn off the front panel clock switch it would sometimes
fail to boot, which I believe happens when a clock interrupt comes in
before the system is ready for it.

Seems like it should have been masked off, though.

-- glen