Added some more information about one of the stranger EKBEE1 tests (TEST 122: KT BEND)
This commit is contained in:
parent
29740f2d7e
commit
0493daef10
3 changed files with 25 additions and 11 deletions
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
|
|||
Loading…
Reference in a new issue