Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!ames!ucbcad!ucbvax!USC-ECLB.ARPA!Chris
From: Chris@USC-ECLB.ARPA (Christopher Ho)
Newsgroups: mod.computers.vax
Subject: XDELTA on VaxStation II?
Message-ID: <12272844645.40.CHRIS@USC-ECLB.ARPA>
Date: Wed, 21-Jan-87 23:29:09 EST
Article-I.D.: USC-ECLB.12272844645.40.CHRIS
Posted: Wed Jan 21 23:29:09 1987
Date-Received: Thu, 22-Jan-87 06:23:16 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 19
Approved: info-vax@sri-kl.arpa

I'm trying to use  XDELTA to delve  into some pseudo-device-driver-  and
ACP-level code I'm writing on a  VaxStation II, but am having  problems.
At indeterminate times while single-stepping through my C ACP (using the
normal VMS debugger)  the VaxStation stops  responding to the  keyboard.
The mouse still  generates response,  and I can  use a  terminal on  the
console line to login.  If I use  the console to generate a break,  then
set IPL to 5 (so XDELTA gains  control), my OPA0: window opens up and  I
find the system doing:
	80008B1F: brb	80008B1F
This looks suspiciously like what I imagine the NULL process loop to be.
It  somehow  seems  that  my  keyboard  interrupts  (at  presumably  low
priority) are being locked out.

Does anyone have any idea what is going on here?  I doubt there's a  bug
in my code,  as there's  so little  of it  so far.   Maybe there's  some
interaction among XDELTA, the VMS  debugger, the VWS software and/or  my
driver/ACP?  Am  I doing  something that  is, for  some strange  reason,
"unsupported"?
-------