There are two immediately obvious possibilities (there
may be more,
but it's late and I'm off to bed after sending this :-)). Either
you've made a mistake somewhere and the P0 address *is* expected to
be mapped by the tables or the KA630 (as you suggest) delays the
effect of the MAPEN by one instruction.
It's not the latter. I tried a small test program:
# p0 00000000 -> phys 00000000 p0br+0 = a0000000
# p0 00000200 -> phys 00000400 p0br+4 = a0000002
# p0 00000400 -> phys 00000200 p0br+8 = a0000001
# s 80000000 -> phys 00000600 sbr+0 = a0000003
# s 80000200 -> phys 00000800 sbr+4 = a0000004
# sbr = 800
# p0br = 80000000 = phys 600
00000000 78 09 01 50 ashl $9,$1,r0
00000004 78 1d 05 51 ashl $0t29,$5,r1
00000008 d4 52 clrl r2
0000000a 78 1f 01 53 ashl $0t31,$1,r3
0000000e d0 51 c2 00 movl r1,600(r2)
06
00000013 c9 02 51 c2 bisl3 $2,r1,604(r2)
04 06
00000019 c9 01 51 c2 bisl3 $1,r1,608(r2)
08 06
0000001f c9 03 51 c2 bisl3 $3,r1,800(r2)
00 08
00000025 c9 04 51 c2 bisl3 $4,r1,804(r2)
04 08
0000002b da 53 08 mtpr r3,$P0BR
0000002e da 8f 00 08 mtpr $0800,$SBR
00 00 0c
00000035 da 02 0d mtpr $2,$SLR
00000038 da 03 09 mtpr $3,$P0LR
0000003b 94 c2 00 02 clrb 200(r2)
0000003f 94 c2 00 04 clrb 400(r2)
00000043 da 01 38 mtpr $1,$MAPEN
00000046 96 c2 00 02 incb 200(r2)
0000004a 01 nop
0000004b 01 nop
0000004c 01 nop
0000004d da 00 38 mtpr $0,$MAPEN
00000050 01 nop
00000051 01 nop
00000052 01 nop
00000053 11 fe brb .
On both a real KA630 and my simulator, the byte that gets incremented
is the one at (physical) address 400, not 200. As a check, I swapped
the incb with the mtpr just before it; then, both the real thing and
the simulator incremement the byte at (physical) 200.
I now favour the "executing out of prefetch buffer" theory, reinforced
by the following comment snippet someone sent me, supposedly taken from
the source to MicroVAX console ROMs:
; To turn on MMGT and execute the following REI depends on a "quirk"
; of the MicroVAX chip. Namely, if the MTPR and REI instruction are
; both fetched as part of the same instruction prefetch, then the
; REI will be executed regardless of the enabling of mmgt. However,
I'm going to try to concoct a test program using mapping tricks like
the ones in the program above to see if I can get convincing evidence
either way on this matter.
Hop on over to Manx and type in 78032 -
I'm nto sure where this "Manx" is; I did some poking around with google
and found nothing helpful.
The kind of detail you need may no longer be in
anyones head.
:-(
It might have to be determined either by experiment or
by reading the
chip microcode.
Heh. I don't suppose the microcode is available anywhere?
You should be able to find some KA650 ROM code as part
of SIMH.
Given that you probably know the ROM code pretty well by now (!), how
does the KA650 implement this test (if at all). If it's the same,
how does SIMH pass the test?
I'll have to have a look at that, yes. I'll also try to construct
tests to probe the KA630's behaviour in this regard.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B