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.
Right.
The uVAX II implemented it to allow for the
possibility of multiple
CPUs in one box. I don't think anyone really used it.
I know someone who did. He was doing robotics, but a KA630 was not
beefy enough to run the control law and a general-purpose OS both. So
we got an auxiliary CPU (a KA620, not a 630, but they are very similar)
and I built a _very_ stripped-down kernel for the auxiliary to run.
We found a bug in the hardware, actually. Doorbell interrupts would be
dropped some tiny fraction of the time (less than 1%, maybe as little
as a few ppm, I forget). After convincing DEC that the problem really
did exist (some very simple test programs, small enough to be typed
into consoles and understood in toto), we eventually were told that the
design should never have worked at all and the only reason it did was
that DEC overdesigned heavily. (Some etch run crossed the whole board
and the capacitance was far more than it should have been.)
They even created an ECO that fixed it - lowering a pullup resistor, I
think. But few people used interprocessor interrupts, and of those
that did only a small proportion minded if a tiny fraction of the
interrupts got lost, so you had to ask for the ECO to get it - but last
I heard, you could still get it if you knew to ask for it. (Of course,
that was a long time ago; I don't know if there even _is_ any service
organization behind KA6[23]0s any longer.)
You can find a description of it in the KA680 Tech
Manual
(EK-KA680-TM, available on all good Internets ...).
EK-KA630-UG-001 contains a fairly good description of it; that's what I
wrote my emulation to.
Since you have a KA630 you could try "SHOW
QBUS" and see what it
really comes back as, but 0x0020 is my guess.
"SHOW QBUS"? That must be a far newer ROM rev than I have.
You need to handle accesses to the Qbus address where
that register
lives and make sure the right value is returned.
Well, I'm fairly sure I've got it simulating what the KA630 book says.
But I've found the book misdescribing the hardware once already, so it
could be getting it wrong again, I suppose.
I've been considering ways to run the real thing under tracing, since
in the simulator it never does anything that would cause a tracing
program to lose control (so if the real thing does I've found a
difference, and if not I should be able to find a difference anyway).
Should be interesting.
[...], but
ends up with an error at step 7 - apparently it can't
find any working memory(!).
Did you remember to give it any :-)
:-) Indeed, if I give it under 16M of RAM, I see machine checks happen
as it sizes RAM.
Exactly how does it die? I presume that some time ago
it politely
asked the memory controller for what might be happening and got
"dunno" as the reply ...
As far as I can see there is no memory controller as far as software's
view of the machine is concerned.
I'm no guru - I don't meditate enough :-)
Hey, this is a VAX, not an Amiga! :)
I did get some VAX selftest software from a helpful listmember (of
another list), which when I get the time I'm going to try on my
simulator. We'll see what happens.
/~\ 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