Antonio Carlini <arcarlini_at_iee.org> 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
Received on Fri Mar 19 2004 - 18:03:19 GMT