Jochen Kunz <jkunz(a)unixag-kl.fh-kl.de> wrote: Yes. 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(a)microwalt.nl> wrote: 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. 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? 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.) 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.) 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