I'm really embarrassed, but guess what? I took apart my RX50 (cleaning/servicing..) but didn't bother to document where all the jumpers/headers go.. Well, when I try to put it back together, there's just 1 3-way header left which has THREE posibilities (board has 3 instances of 3-way male headers), and I don't know which one to put it to. The said 3-wire (red, blue, yellow) header originates from the optical slotted switch which detects (I think) the end of the tracks. It will terminate to one of the 3-way male headers at the SEEK/INTERFACE backboard (which is perpendicular to the main metal chassis. Here's some ASCII art of SIDE1 of the SEEK/INTERFACE backboard with all the headers: A B C V V V +------------------------------------------------+ | ++++ +++++ +++ +++ +++ | | | | | | ++++++ | | ++++++ | | | | | | | | | | + ++++ | | + ++++ | | + +------------------+ | | | |+ +-----+ | | | 2x17 Female BERG |+ +++++ |POWER| | +------------------------------------------------+ So the question is, does the slotted switch cable terminate at headers A, B, or C? /wai-sun

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(a)rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Yes, it's the ROM console code. Yes, that's a nice theory. That's how I would do it and that's how NetBSD does it; I'm not surprised to hear that's how VMS does it. But it is not what I am seeing. Recall I had 00000219 mtpr $1,$38 0000021c jmp (r0) 0000021e nop but the page tables are set up such that P0 address 21c is not valid (the P0 PTE for it is no-access not-valid). However, r0 contains an address, 8000001e, which is mapped to physical address 21e. Thus, I infer that the "jmp (r0)" is somehow supposed to get executed *even though* P0 space is set up such that the jmp does not appear at the place PC points after the MTPR - that place does not exist (there is no virtual mapping for it). Since this code does in fact run on a real KA630, the hardware obviously differs from the simulation. (The code is the KA630 ROM code, so there is nothing inherently wrong with its doing things that depend on its running on a KA630; it doesn't have to care about portability to other VAXen.) I've gone over the page tables and the code that sets them up enough that something like prefetching has become the more plausible possibility. I'm reasonably sure, yes. I read over the setup code and simulated it mentally and came up with the same results. So would I. I went over things in some detail before I convinced myself that it actually is a false assumption, that the code really is depending on something KA630-specific that lets that jmp (r0) get executed even though it looks unmapped. As an experiment, I added instruction-stream prefetching to my simulator. Now it cruises right past that point, executing the jmp out of the prefetch buffer - and falls over later, on something that again looks as though it's expecting to execute out of a prefetch buffer: 20044585: movab 0x2004458d,10(r10) 2004458a: <unrecognized ff ff> 2004458c: nop 2004458d: mtpr $0,$38 ; MAPEN 20044590: jmp *$20044600 20044596: halt In the simulator, when it hits the force-a-trap at 2004458a (which is at that point running in system virtual space at 8000038a), it traps to 8000038c - apparently the previous movab sets up an SCB vector. Then it tries to turn off MAPEN while still running in system virtual space - and the prefetch buffer I gave it (64 bits) isn't big enough to include the entirety of the jmp that follows. Now, it could be that I just haven't given it a big enough prefetch buffer. But I hesitate to just enlarge the prefetch buffer without some reason to be confident that that's really the correct fix. I also really would be more comfortable knowing exactly what events should cause me to flush prefetch (REI is documented to, but, for example, does the trap caused by the ffff opcode do so?) and how prefetching interacts with alignment. I've also wondered if perhaps changing MAPEN is actually delayed by one instruction. This is another thing that could cause the code I see to work, and it wouldn't upset the turning-on-mapping technique you describe. It would, however, break code that expects setting MAPEN to amount from a branch from physical space to virtual space when they _aren't_ mapped to the same place, which according to the VARM I have is perfectly reasonable code. Hence my asking about people who know the KA630 in detail. Most of these things are things I can test on a real KA630 with suitably contrived test code, but things like prefetch have a tendency to work in funky ways that are often hard to discover with black-box testing. /~\ 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

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. I'm nto sure where this "Manx" is; I did some poking around with google and found nothing helpful. :-( Heh. I don't suppose the microcode is available anywhere? 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

I've fallen a little behind in my reading so I forgot to follow this thread. OK. So it sounds like you have strong evidence for a chip bug here. The chances of getting it confirmed are slim :-) - there was a list of Waivers granted to various VAX implementations, but seeing it was on a need-to-know basis. If the console code has such comments in, it's best to believe them. I guess they let the bug pass both because it's relatively harmless and would have been expensive to fix once the chip had been finalised. http://vt100.net/manx Type in 78032 and see what pops up. I don't have the KA630 microcode and I don't know anyone who does. The group I worked with produced the DEMSA and DEMSB which were both based on the 78032, so they must have had example console code lying around. But I can guarantee that's long gone (and was probably long gone before I got there). Antonio -- --------------- Antonio Carlini arcarlini(a)iee.org

[Antonio Carlini, replying to me] I'm not sure I'd call this a _bug_, really; my VARM, at least, does not indicate that changing MAPEN is supposed to do anything to any instruction prefetch buffers - yet the prefetch was clearly considered, since the REI description does specifically say that "[a]ny instruction lookahead in the processor is reinitialized". If anything, I'd say it's the author(s) of the ROM code that are sloppy here, for depending on the ability to execute out of the prefetch buffer. (But given the target for their code, I'm not sure it's fair to say even that much.) I have done tests, and the real thing does in fact execute out of the prefetch buffer after changing MAPEN. Even if it's merely alleged to, I'm inclined to believe them when my own tests indicate that something very similar is in fact going on. :) That's about what I expected. And I can't imagine that it's programmer-visible at the VAX programmer level, so I can't dump it as trivially as I did the console ROM code...ah well. Though it really would have been pretty cool to build an emulator for the micromachine instead and then run the real thing's microcode. :-) [Hans B PUFAL, responding to Antonio Carlini's response to me] Me, no, I haven't. I may eventually if I run up against something I can't handle on my own, but so far I haven't reached that point. I'm now well into the code that selftests the FPU, writing emulations of the various floating-point instructions. Tedious but not difficult. We'll see what I run into once that's done. /~\ 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