VAX Architecture (was KA620) - test-drb@ccmp.vtda.org

19 Mar 2004

Antonio Carlini &lt;arcarlini(a)iee.org&gt; wrote:

...
  There were, however, other machines
 called rtVAX <some-number>. I forget the exact details
 but at least one of them was based on the CVAX chip. I
 expect that there was something at the board-level that
 would have prevented them running OpenVMS but the chip
 was (I'm pretty sure) a standard CVAX. 
Hmm, did they seek process page tables in physical or in system virtual memory?
If the latter, I don't see how can they be called rtVAX, as that by definition
means the former.  If the former, how can you do that with a standard VAX chip?
Or does CVAX have an undocumented hack pin which when tied opposite to what
general specs say causes it to seek process page tables in physical memory?

...
  There's not a huge difference between STD 032 and
the books.
 There are a few paragraphs missing here and there but I don't
 remember anything hugely significant [...]
 [...]
 [bug lists that were cut] But even these would not help you understand the
 architecture any better. 
OK, I've already figured myself that all the really important "what is a VAX by
definition and how to build one" stuff *is* in the published VARMs, so my
project of building a new VAX is not stuck waiting for KGB to pry STD 032 out
of DEC.  I fully understand the VAX Architecture (and have a solid rigorous
spec definition) based on the 3 VARMs I have (Rev 6.1, 1st ed. and 2nd ed.) and
I should have something exciting on the new VAX front hopefully not too long
...
 from now.  It would still be nice to seize and free the
full DEC STD 032 for completeness, but this task can be left until later when we can
raise a large
enough army (using human cloning, genetic eng. and neurolinguistic programming
to make perfect killing-machine soldiers) to invade and overrun USA including
ex-DEC facilities and archives.

...
  The only major omission is the Virtual VAX stuff
(which was
 done for some three letter agency but never became a product
 - I heard that it just ran way too slowly to be useful).
 It has its own SID (09 IIRC, I guess(0)07 was already taken :-)). 
Ahh, thanks for explaining that!  One fewer mystery.  I have known about VVAX
...
 from the Ultrix sources (which are on my FTP site), but
I didn't know what it was.  Now I know. :-)  Actually Ultrix was made to run on
it too according to
comments in the source, though the actual VVAX-specific machine-dependent code
is not present in the source tree I have, it just has SID and misc. definitions
for it, pointers to VVAX code in the CPU type dispatch table (conditionalised
on #ifdef VVAX), and comments mentioning it.  And yes, the SID code is 0x09.
Now that I know that VVAX was real (and not an Ultrix internal thing - Ultrix
does have some fake SID codes of its own that do not correspond to anything in
hardware), I now know what's in the gap between 78032 and CVAX SID codes. :-)
So they were upset at MicroVAX I for taking 007, huh?

So this only leaves SID codes 0x0C, 0x0D and 0x0F as unexplained gaps.  I
suppose that perhaps 0x0F could have been truly skipped after 78R32 jumped to
0x10 (I guess 78032/78R32 liked power of 2 SIDs), but I can't explain how has
VAX 9000 got 0x0E unless 0x0C and 0x0D were reserved for something (that
apparently never saw the light of day).  Any idea what 0x0C and 0x0D were
reserved for?  Also what SID codes were assigned past 0x14 in the VAX's dying
gasp?  NVAX+ (NVAX in Alpha 21064-mimicking pinout) was given 0x17, wasn't it?
And what about NVAX5 (NVAX in EV5-mimicking pinout)?  Was it also 0x17 or was
it 0x18?  And then I've heard rumours about there being a never-released
NVAX6...  And why were 0x15 and 0x16 skipped?

One reason it's important to understand the complete history of SID code
assignments is that if we start building new VAXen, we'll need a new SID code
registry.  I plan on calling it DANA, for DEC Assigned Number Authority, in
emulation of IANA (Internet Assigned Number Authority).  But to make it proper,
the new registry will have to start assigning codes exactly where the old one
left off.

And DANA won't be just for SID codes - there are also VAXBI device types and all
sorts of ID codes used in MSCP/SCA, etc.

...
  I think I've said before, what you really want is
not STD 032
 but AXE, the tool that runs on your new VAX and checks for
 correct operation of instructions. 
I've never heard about AXE from you, but I have heard about it from other
sources.  Yes, that would really be nice.

Interestingly, however, it appears that at some point there were diagnostic
programs available to the general public that, judging from the descriptions,
apparently do similar instruction testing, though they were presumably intended
for troubleshooting broken hardware rather than for validating new
implementations.  The KA820 Technical Manual, for example, refers to these:

Table 7-2:
Program Code	Program Name	Run-time Environment	Hardware Tested

EVKAA		VAX-generic	Level 4 (stand-alone,	VAX instruction set
		cluster		boot and run from the	used by VDS
		exerciser:	console)
		hardcore
		instruction
		test

EVKAB		VAX-generic	Level 2 (on-line or	Basic VAX instruction
		cluster		stand-alone)		set, nonprivileged
		exerciser:
		basic
		instruction
		exerciser

EVKAC		VAX-generic	Level 2 (on-line or	Floating-point VAX
		cluster		stand-alone)		instruction set, non-
		exerciser:				privileged
		floating-point
		instruction
		exerciser

EVKAE		VAX-generic	Level 3 (stand-alone)	Privileged VAX
		cluster					instruction set
		exerciser:
		privileged
		architecture
		exercise

[descriptions of KA820-specific diags omitted]

The descriptions of these diagnostics sound very much like AXE.  Any idea where
to find these diags?

MS