KA630 guru?

From: der Mouse <mouse_at_Rodents.Montreal.QC.CA>
Date: Sun Aug 1 19:35:15 2004

> 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_at_rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Received on Sun Aug 01 2004 - 19:35:15 BST