diff --git a/devices/pdp11/machine/1170/panel/debugger/xxdp/machine.xml b/devices/pdp11/machine/1170/panel/debugger/xxdp/machine.xml
index fe323452f..3cb0f9e70 100644
--- a/devices/pdp11/machine/1170/panel/debugger/xxdp/machine.xml
+++ b/devices/pdp11/machine/1170/panel/debugger/xxdp/machine.xml
@@ -9,7 +9,7 @@
 	<device id="default" type="default"/>
 	<serial id="dl11" adapter="0" binding="print" upperCase="true"/>
 	<panel ref="/devices/pdp11/panel/1170/debugger/front.xml"/>
-	<debugger id="debugger" base="8" messages="" commands=""/>
+	<debugger id="debugger" base="8" messages="" commands="bp 076060"/>
 	<device ref="/devices/pdp11/pc11/default.xml"/>
 	<device ref="/devices/pdp11/rl11/default.xml"/>
 </machine>
diff --git a/disks/dec/rl02k/xxdp/ekbee1/README.md b/disks/dec/rl02k/xxdp/ekbee1/README.md
index d44ff1ac7..fb7e763a4 100644
--- a/disks/dec/rl02k/xxdp/ekbee1/README.md
+++ b/disks/dec/rl02k/xxdp/ekbee1/README.md
@@ -7,17 +7,19 @@ permalink: /disks/dec/rl02k/xxdp/ekbee1/
 EKBEE1: 11/70 MEMORY MANAGEMENT DIAGNOSTIC
 ------------------------------------------
 
-From the [PDP-11 Diagnostic Handbook (1988)](http://archive.pcjs.org/pubs/dec/pdp11/diags/PDP11_DiagnosticHandbook_1988.pdf),
+From the
+[PDP-11 Diagnostic Handbook (1988)](http://archive.pcjs.org/pubs/dec/pdp11/diags/PDP11_DiagnosticHandbook_1988.pdf),
 p. 1-10:
 
 	11/70 MEMORY MANAGEMENT TEST
 
 	ABSTRACT:
 
-		This program was designed using a "BOTTOM UP" approach starting with the smallest segment of MEMORY MANAGEMMENT
-		logic and building up to cover all the logic.  The program begins by testing some of the internal CPU data and
-		address path and address detection logic, then works outward through the MEM. MANAGEMENT registers.  It is assumed
-		that both the CPU and the CACHE have been tested, or are known to be good.
+		This program was designed using a "BOTTOM UP" approach starting with the smallest segment of MEMORY
+		MANAGEMENT logic and building up to cover all the logic.  The program begins by testing some of the
+		internal CPU data and address path and address detection logic, then works outward through the MEM.
+		MANAGEMENT registers.  It is assumed that both the CPU and the CACHE have been tested, or are known
+		to be good.
 
 	OPERATING PROCEDURES:
 			Set the switch register by <CONTROL P>
@@ -65,4 +67,5 @@ the PDF (p. 199 of the source code listing):
     ;*      NEXM TRAP.  IF THIS IS A KB11-E/EM THEN THIS FEATURE IS TESTED.
     ;****************************************************************
 
-
+As noted in the *mapVirtualToPhysical()* function in [cpustate.js](/modules/pdp11/lib/cpustate.js), this test
+begins at PC 076060.
diff --git a/modules/pdp11/lib/cpustate.js b/modules/pdp11/lib/cpustate.js
index 0f3cef429..d4b89da9f 100644
--- a/modules/pdp11/lib/cpustate.js
+++ b/modules/pdp11/lib/cpustate.js
@@ -1574,11 +1574,22 @@ CPUStatePDP11.prototype.mapVirtualToPhysical = function(virtualAddress, access)
      *      As an aside it turns out that it is the memory management unit that does odd address and
      *      non-existent memory trapping: who knew? :-) I thought these would have been handled at access time.
      *
-     * I haven't imported the non-existent memory checks he performed (yet); I would like to see the problems
-     * in action first.
+     * TEST #122 ("KT BEND") in the "EKBEE1" diagnostic (PC 076060) triggers an ODDADDR error using this
+     * instruction:
      *
-     * As for the ODDADDR error that's supposed to generate a BUS error rather than an MMU error, this happens
-     * in TEST #122 ("KT BEND") in the "EKBEE1" diagnostic (PC 076456).
+     *      076356: 005037 140001          CLR   @#140001
+     *
+     * and it expects that instruction to generate a BUS error rather than an MMU error, so we deal with that
+     * next.  However, the test also claims to check for an NEXM (non-existent memory) error, using this
+     * instruction:
+     *
+     *      076170: 005037 140100          CLR   @#140100
+     *
+     * but that error never materializes, so I've NOT included any NEXM checks yet.  I assume that any such
+     * checks would be limited to whatever's recorded in the Memory Size registers (177760), because actually
+     * checking every physical address at this stage -- even in a real MMU -- seems prohibitively expensive.
+     *
+     * TODO: Investigate why the test's NEXM error doesn't occur.
      */
     if ((physicalAddress & 0x1) && !(access & PDP11.ACCESS.BYTE)) {
         this.regErr |= PDP11.CPUERR.ODDADDR;