KA630 guru?

From: der Mouse <mouse_at_Rodents.Montreal.QC.CA>
Date: Sun Aug 1 14:17:40 2004

>>> But the emulated VAX hangs at selftest step B. The manual I have
>>> (EK-KA630-UG-001) says this means that the IPCR is not working
>> IIRC that's the dorrbell register.

I found the problem here; it was a totally boneheaded mistake on my
part. Two of the IPCR bits are bits 0x0040 and 0x0020 - and I had
coded up my IPCR emulation with those bits at 0x0080 and 0x0040. I
moved them to the correct bits and all of a sudden it started working a
whole lot better.

After a bit of work, the selftest now gets much further. Now it falls
over during test 4. I know exactly why, and I'm not sure what to do
about it.

It's turning on memory management (mtpr $1,$38). But it must be
depending on some idiosyncracy of the chip, because the way the page
tables are set up, the address after that is not valid after memory
management is turned on. In physical memory, we have

00000200: moval 21e,r0
00000205: bicl2 $fffffe00,r0
0000020c: bisl2 $80000000,r0
00000213: brb 218
00000215: halt
00000216: halt
00000217: halt
00000218: nop
00000219: mtpr $1,$38
0000021c: jmp (r0)
0000021e: nop

with this code entered by jumping to 200. But at this point, the way
the page tables are set up...

vax> v 21c
0000021c: P0BR 80000600 + 000004 = 80000604
 -> SBR 00000600 + 00000c = 0000060c
S PTE a4000004 = V=1 PROT=4=UW M=1 OS=00 PF=000004
 -> process PTE physical address 00000804
process PTE 00000000 = V=0 PROT=0=NOAC M=0 OS=00 PF=000000
 -> not valid

However, as you can see, r0 will contain 8000001e at that point, and

vax> v 8000001e
8000001e: SBR 00000600 + 000000 = 00000600
S PTE a0000001 = V=1 PROT=4=UW M=0 OS=00 PF=000001
 -> physical address 0000021e

So the code is obviously depending on the "jmp (r0)" getting executed
even though it's not accessible after MAPEN is turned on. Either MAPEN
setting is getting delayed or it's counting on executing out of
prefetch buffers or some such.

I'm not sure what I want to do about this. I can see two basic tacks
to take here: (1) patch the ROM images to avoid this dependence or (2)
try to emulate whatever the chip is doing. Tentatively, I'd prefer the
latter. But that leaves me with another question:

Does anyone know the KA630 CPU well enough to say exactly how it is
this code manages to work? I can't write an emulation of something I
don't understand, after all. :-)

/~\ 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 - 14:17:40 BST