Added some more information about one of the stranger EKBEE1 tests (TEST 122: KT BEND)

This commit is contained in:
Jeff 2016-11-19 11:32:42 -08:00 committed by Jeff Parsons
commit 0493daef10
3 changed files with 25 additions and 11 deletions

View file

@ -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>

View file

@ -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.

View file

@ -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;