Jochen Kunz <jkunz_at_unixag-kl.fh-kl.de> wrote:
> Sorry, no. The m76 has a Rigel.
Yes.
> Looks so. It seams to support only NMOS-VAX (VS2k), CVAX (VS3100
> m30/38/40/48) and maybe SOC. I think SOC is the CPU in the VXT2k.
Yes, VXT2000 has SOC. Last night I finally downloaded the whole VXT software
and ran strings(1) on the VXTEX image, and I see mention of three machines:
VS2000, VT1300, and VXT2000. VT1300 is the CVAX-based KA42-A, the same system
board as in VS3100 M30.
Fred N. van Kempen <Fred.van.Kempen_at_microwalt.nl> wrote:
> It might run on the 3100-M38, although I believe
> that's a "non" 3100, too.
VS3100 M38 differs from VS3100 M30 (which is the same hardware as VT1300 except
for the latter lacking the mass storage controller board) only in speed (M30
has 90 ns cycle time giving you 2.8 VUPs and M38 has 60 ns cycle time giving
you 3.8 VUPs). VS3100 M30 is KA42-A and VS3100 M38 is KA42-B. The difference
between the two boards are a different crystal oscillator, KA42-B has chips
rated for higher speed, and a byte or two in the ROM is twiddled.
> I would assume that they kept the CPU
> support library as small as possible, meaning only the generic series
> of machines they "sortof" intended the VXT software set for, i.e. the
> 2000, 3100 and alike systems and their hardware features (as needed.)
This is all true, but I'm still wondering about VS3100 M76. Although it has a
different CPU chip (Rigel), other than knowing about its SID code, supporting a
different CPU chip entails nothing more than slightly different cache control
and machine check handling. In every other way VS3100 M76 (KA43) was designed
to be a direct successor to earlier models (KA42). In particular all hardware
other than the CPU chip, i.e., what the bulk of system code is concerned with,
is absolutely unchanged.
But the million dollar question remains: what will the existing VXT boot image
do upon detecting SID top byte equal to 0B? Will it scream and give up, or will
it treat it as a VS3100/VT1300?
> Yup, it's basically some "NanoVMS" kernel, with minimal runtime and a
> VMS DECwindows subset.
Are you sure it's based on VMS and not Ultrix? Doing strings(1) on the VXTEX
image showed a few bits that bring Ultrix to mind.
Of course any Ultrixisms would not be in M76's favor, as DEC had the stupidity
to make Ultrix not run on M76, almost artificially I have to say. Having a copy
of the Ultrix V4.20 sources has given me the pleasure (and disgust) of seeing
just why. Its CPU type determination logic simply assumes that everything with
a Rigel CPU must be a VAX 6400! So when you try to boot it on a VS3100 M76, it
goes looking for XMI... If that logic were tweaked to treat KA43 as KA42, it
would have probably worked. (And if someone added a couple dozen lines to the
KA42 code to handle Rigel/KA43 machine checks and cache ops, it would have
worked solid.)
> Which means (methinks..) that it most likely
> wasnt stripped from its GPX and SPX(+) drivers.
Not most likely, but absolutely certain. VXT2000 video *is* SPX, so it has to
have the SPX driver. VT1300 was color, so it had to have some add-on video
board, and I think it was GPX, not SPX. Oh, and it works on VS2000, which would
certainly have GPX and not SPX. So both GPX and SPX drivers are most certainly
there. The only concern is that if the real DEC VT1300 indeed had GPX and not
SPX, would it accept a VS3100 with SPX. It should unless some asshole
artificially blocked the SPX driver in the VT1300 configuration. (But the
latter possibility seems unlikely given how they even supported VS2000.)
> Dang! Now you got me curious. I have all three (2000,M38 and M76) so
> will set them up tonight or tomorrow and see what they do.
I would greatly appreciate a test on VS3100 M76. I want to put together my own
VXT X terminal and I'm inclined to do it on a VS3100 rather than VXT2000
hardware. If I could use an M76 instead of M30 or M38, it would be great.
MS
Received on Fri Jan 17 2003 - 14:10:01 GMT
This archive was generated by hypermail 2.3.0
: Fri Oct 10 2014 - 23:36:01 BST