QUICK START: Do you have one of these and you just want to make it go, maybe just to test it? If you need hookup help, check out Connections, then skip to here for a one-click netboot server.
The VXT2000 is one of several dedicated X Terminals released by Digital Equipment Corporation in the early 90s. I believe it came out circa 1992. While I'm sure they intended it primarily for use with their workstations, with X being what it is, you can use it with anything that supports the X11 protocol, be that Unix, Linux, VMS, etc. From what I understand, the R doesn't matter - X11R4/R5/R6 should all function. I have tested my VXT against Red Hat Linux 6.1 (1999) and had... moderate success. That should be encouraging, right?
From what I can tell, the VXT2000 is the only VXT that existed; there were also VT1000, VT1200 and VT1300 X terminals, but they are considerably different designs; I don't believe they'll use the VXT software, and in one case (1200) they don't even need it. That said, I can't confirm that unless anyone wants to send me one.
If you're in a hurry, read the little box above to get started fast. Otherwise, I'll give a little bit of background.
Great question! Vague answer!
Simply put, "X Terminal" (which I'm going to abbreviate 'Xterm,' incorrectly) means "a computer that's not meant to run anything other than an X Windows server."
This is sort of like how a textmode "dumb terminal" is really a computer in it's own right, but different. Sure, every VT100 contains a Z80 or 6502 or whatever, because you just can't do anything stateful (like store text on a screen) without something computer-shaped, but usually that Z80 or 6502 is vastly inferior in speed and complexity to the machine it's being connected to. This is... not as consistently true with Xterms, because X Windows is a really heavy piece of software. There is no way to make a remotely "dumb" machine run it.
Instead, Xterms offer a delightful variety of "oh, they used that?" CPUs paired with [altoids voice] curiously large amounts of RAM. I've seen 80186, Motorola 88000 (a harvard architecture proc), intel i960, the works. Anything other than the flavor-of-the-month best-in-class microprocessor was fair game.
The DEC VXTs are particularly lovely, because they are apparently entire VAX systems. By various reports, the VXT2000 is "just a VAXstation" with some parts removed. I am not sure this is strictly-speaking a fact, but it seems to be close enough to true, and by Reports, it runs "VAXELN", a weird little RTOS DEC wrote that can run on VAXen instead of VMS. I suspect the VT1300 is similar, while the VT1200 actually runs on some kind of Texas Instruments graphics processor - but I digress.
As far as you're concerned, the VXT2000 is an Appliance which serves a Function. That Function is that it lets you get a graphical terminal off of another machine running unix/linux/VMS/etc. If you're familiar with X Windows as a concept, you'll know that the entire point of it is that you can design a graphical app that can run on one computer while being displayed on another - and indeed, the computer running the display can mix together windows for apps from multiple unrelated systems, and display and interact with all of them on a single desktop. It's a real neat trick, insofar as almost nobody needs to do it anymore.
The reason these were invented is that, for a period in the 80s and early 90s, businesses and schools were buying Big computers that could support lots of simultaneous users, but to access those machines from rooms other than the Computer Room, you needed something that could run X, and it cost too much to give every user a Real Computer (read: with a hard drive and OS license.) Xterms are just enough computer and not an inch more.
For this reason, they pretty much universally netboot - since they have no local storage, they need to download their operating system and X server from something else on the network every single time they're powered on. Some terminals (especially later ones) could be equipped with flash memory cards so this wasn't necessary, but the VXTs could not do this.
If you're thinking, "Hey wait, I don't have any machines that I need to hang multiple X sessions off of," or "Hey wait, I have like 500 laptops that'll run Linux, aren't I better off just using the X server on those," both of those are very good points. In fact, even by 1998 people were asking "why not just use a PC" - but in 92, it wasn't practical yet. And there's your explanation.
There is positively no reason to run an X terminal in the modern era except to soak in the vibes of past decades and thank your lucky stars that you don't have to live like this.
Did I mention X terminals are really slow?
I already told you, it's an X termin- oh right, that's like a page and a half up there. Sorry. But really: It's an X Terminal. It connects to a unix, linux, VMS, etc. machine over Ethernet and gives you a graphical interface.
From what I've read, this is an excellent Xterm. I found Usenet posts suggesting that it was very fast for its time, and it supports color (8-bit) graphics at pretty high resolution (1280x1024.) It originally shipped with either 17 or 19 inch displays that I'm sure were quite high quality.
Above you can see a typical image of the VXT in operation, displaying the local management tools and status window, a couple apps running on an HP-UX machine over the network, and a local terminal emulator. Oh, that's a really interesting detail.
While it is not equipped with a full-fat operating system, the VXT does have several local applications and capabilities. Perhaps the most intriguing are the local ports: it sports both serial and parallel, and you can use both without connecting to a remote host.
As far as the parallel port, you can print from apps running on a remote host... but only if you install the special driver on said host and then manually run a command to spit the file back at the VXT over the network. I have not investigated what platforms this supports, but if you were hoping X had a printer tunneling feature, sadly, no. The parallel port CAN be used locally to print the screen. I have not tried this and am somewhat afraid to.
The serial port is more interesting. There is no way to forward this across the network; it's actual purpose is to allow the VXT to act as a serial console connected to some additional box e.g. a MicroVAX with no framebuffer. You can run this in many modes - it actually simulates DECterm, which in turn was DEC's equivalent of Xterm, e.g. a software terminal emulator that ran inside their graphical environment, DECwindows.
Much like Linux's xterm, DECterm supported many different formats and flavors. You can of course use it for a simple VT100 simulation, as we're all used to, and that's what you see in the image above: The terminal is talking to a XENIX tty appearing over a USB serial adapter from a TRS-80 Model 16 emulator running on a linux machine. However: it also supports VT300/340 mode, which mixes text and graphics! That's right folks: You can output Sixels to this thing.
You can see a sixel happening in the lower right there - I sent this over from a modified sixkcd using a USB serial adapter.
While this is a comical trick in the modern era, it's important to observe that in '92 when this came out (and '90 when it's predecessor was released) the value of a highly compatible serial terminal was immense; I can believe that many people routinely used this feature, firing up their Xterm without ever actually connecting to an X host.
Another thing you'll see above is the help viewer, which gives access to a host of VXT-relevant documentation, and part of the Terminal Manager, a graphical configurator for all the (myriad!) local settings on the device, including a list of saved hosts and sessions and lots of customizations. However, these are only available in "Server Mode." Ah, about that.
As far as I can tell this was the last and greatest of the DEC Xterms. It was preceded by the VT1000, 1200 and 1300, which were all less performant (Usenet post linked above suggests the 1200 was 1/6th as fast) but also suffered from one major problem: No virtual memory. Since they lack hard drives, if the user should launch enough programs to fill up the terminals RAM, it will simply start denying requests. I don't know how catastrophic this is, but it sounds bad!
The VXT2000 solves this by offering virtual memory; if it runs out of RAM, it can use a swapfile! Problem: The VXT also lacks a hard drive, so... how is this possible? By relying on a network server for swap! Because THAT makes sense!
Well, actually, it does. The server in question is the DEC InfoServer, a fascinating gadget running another proprietary RTOS, whose sole job in the world is to be a NAS. This is best discussed in depth another time, but suffice to say, to make a VXT2000 work correctly, you need an InfoServer, so you can run in "server-based mode."
This is not to say that you need an InfoServer. The VXT can ALSO run in "host-based mode," in which it simply loads its software via BOOTP/TFTP and runs everything locally with no virtual memory. However, this disables a couple features (including many of the Terminal Manager options, supposedly) and is completely dependent on RAM; if you run out of memory, Bad Things Happen (details unknown.) If you can pack 12 or 16 megs into the thing, maybe this works fine; I'm not sure because mine only has the stock 6, which is inadequate to even try.
Footnote: Per the original manual the stock RAM is 4, not 6. I do have the RAM carrier board installed, but no sticks in it. Does the carrier board have a built in 2MB? Unknown at this time.
Since it is recommended that you run in Server-Based Mode by every resource I can find, and it's just generally a good idea to have virtual memory for an X server, I recommend you just do it that way. I provide a prerolled InfoServer emulator on this page that will get you going instantly.
Ah, yes - The Eternal Problem with non-x86 hardware. Naturally the VXT uses a keyboard and mouse from Mars. Yours came with both, right? Right? Right? Right? Right? Ri
Captain America voice so you got a DEC machine with no peripherals. Happens to the best of us. The trick now is to figure out how committed you are to this bit.
The keyboards are weird (they use an RJ12 phone plug) but aren't that rare - look up LK201 on eBay, you should be able to get one for about thirty bucks. There's also the LK401, LK402, LK421, LK443 and LK444; these all have different layouts, but are compatible. I'm sure someone out there has also built some Arduino sketch that will convert a PS/2 or USB keyboard in a pinch.
The mouse is harder. The only one DEC made that fits this model is the VSXXX-AA, a miserable little puck-shaped thing with a 7-pin mini-DIN plug. You will not pay less than $70 for one of these, they look ergonomically nightmarish, and it's a ball mouse; ugh.
"Fortunately," I can assure you that there is an Arduino sketch that will adapt a PS/2 mouse, because I made one adapted one that someone else wrote. You can find it here; all docs on how to build the adapter are in the .inc file comments.
Does this work for the other DEC mice that use RJ11 plugs? Maybe. I don't know. Anyone have a machine and want to try it out? Mail me electronically with the results.
Next, you'll need to hook up the network. This is trivial: Go to ebay and buy an AUI to twisted pair / 10baseT converter, also known as an MAU. Various combos of those search terms will get you one for cheap; they made 500 billion of them.
An important thing to be aware of is that this is strictly 10mbps, and many gigabit-and-faster switches will not, and cannot negotiate ten megabit ethernet, because negotiation wasn't invented yet. If you can't get the MAU to sync, buy a 10/100 switch and pass it through.
Oh, I guess you could also get a 10/100 hub with a 10base2 port and use a BNC coax cable. But like. Why?
Now, at long last: The video situation. Ugh.
The VXT uses a delightful plug called 3W3. You might have heard of 13W3, the video connector that appeared on Suns, SGIs, a few IBMs, and other things. Adapters for that are incredibly common, but 3W3... is not so much.
The signal itself is not so exotic; it's just Sync-On-Green RGB, sent over three mini coaxial plugs. From left to right it's Blue, Green, Red. Many LCD monitors and scalers (such as the Extron RGB 300 HDMI) support SoG, and all you need for testing is the green line; simply get it finagled up to the green wire on a VGA cable, some way, somehow, and plug it into a few different LCD monitors; one of them will probably sync. The picture will look awful though unless you can get the ground wire onto the outer half of the coax plug, and this is... quite hard to do in any kind of sustainable way without a proper cable.
What to do about this? Well, ideally you'd get a 3W3 cable... but they're quite rare. IBM sold them under the FRU "58F22903" and I bought one on ebay by searching for that, but there aren't any others available right now. Searching "3W3" may get you results, but they'll be quite pricey. Are there other options?
Well, if you're really impatient, you could do what I did: Get a 13W3 adapter (they are INCREDIBLY common and cheap on ebay,) break it apart, extract the mini-coax connectors, and solder them to a VGA cable. This is a huge pain in the ass; you have to slice off the external PVC covering, which is quite thick, then you'll probably find out that it's potted inside.
Don't give up though; if your potting is milky-white like mine, it's probably hot glue. Hot glue is extremely susceptible to isopropyl alcohol; pour some on there, give it a minute, then use a pair of pliers to break it apart. You'll destroy all the wires; doesn't matter, you're reworking it anyway.
You'll have to snap the end tab off the 13W3 plug to separate the halves so you can get the plastic wedge out which contains the coax plugs, then cut those out with wire cutters. I told you this was a pain in the ass! It took me 45 minutes! But in the end I had three little coax barrels, which I soldered to a cable, and voila, I had a picture.
I guess you could also try to find an actual 3W3 plug. They're still sold, there's just 50,000 SKUs on digikey and almost all of them have power pins instead of coax. I found a VCfed post saying these ones worked, but they come from China so you'll be waiting a while.
This section is for getting up and running as quickly as possible. If you have issues, read the entire page.
If you're here, I'm going to assume you have a keyboard, mouse, ethernet connection and video output for your VXT2000, and that you have powered it up and gotten the boot prompt, seen above.
Ideally, you should not see those lines that say ?? 001, ?? 003. Those are self-test failures; "QDZ" usually means your mouse or keyboard weren't detected. "VNI" means no ethernet was detected. I don't know what "SPX" is; it stopped happening on mine.
To get the VXT booted, you need an InfoServer hosting the software files. I have preconfigured an emulator to provide this service, which you can get here.
InfoServer> prompt.
At this point you should be able to power on your VXT2000 and, assuming it's connected to your network, it should find the IS and begin loading firmware - it's pretty unmistakable so you'll know if it's doing it.
If it doesn't work after a minute or so, the very first thing you should do is try to clear a path between your two devices. I have found that the managed (Juniper) switch in my home network blocks DEC's special LAST packets for some reason, and I bet others do too. Try to get the dumbest switch you can and put it between the VXT and your PC.
Assuming your terminal is now up and running, you may wish to see some tasks you can do with it.
This section is included for those who want to do this on real-steel or just to understand better how this all fits together.
Yeah, I know, real exciting, right? No, but really: if you're not using the quick start option, it's because you want to understand what's actually going on. I... don't really know what's going on, so I'm not the best teacher, but I understand a little bit and I can tell you that what's going on is... weird, if you're used to remotely modern computing. It's really kind of from Mars, honestly.
DEC lived in their own whole universe in terms of networking. They were actually one of the major drivers behind the uptake of Ethernet, but they had their own protocol suite...s. Both DECnet and LAT seem to have been their inventions, used in different eras of their homegrown gear, and from what I can tell they fairly reek of early networking.
There's a lot of autodiscovery that "just works," for instance. If you share some hard drives over LAT, you can jump into a VMS machine and just ask "what services are available on the network?" and every single share on every single machine will show up.
This is fairly unthinkable nowadays, partly due to security concerns, and probably partly because vendors got a lot more gun-shy about broadcast traffic in the 90s as network load levels skyrocketed, along with collisions. Sending a single "who's out there" packet and hoping everything else will reply was probably fairly reliable in 1982, but in 1990, I don't think you could trust that you'd caught every reply, so the "master browser" approach used by LANman et al was far more practical. That said, it's possible LAT is doing the same thing; I don't really know.
Anyway, one of the other components offered by DECnet in particular is MOP, or Maintenance Operations Protocol. I can't speak to everything this can do, but at a minimum it appears to be a combination of telnet, BOOTP and TFTP. You can use it to get a remote console off a machine, and you can use it to netboot a machine.
The reason you need to know about all this is because when the VXT runs in Server-Based Mode, it talks to its symbiotic host - the DEC InfoServer - exclusively over DECnet, and these packets are so weird that they might actually fail to make it across your network.
I actually struggled to get my VXT running for a while until it occurred to me that my Juniper managed switch (which has committed crimes like this before) might be blocking the traffic; this proved to be true, and bypassing through an unmanaged 10/100 switch got the terminal working.
So, if you're taking the scenic route to getting your VXT going, you are very possibly going to need to run packet captures, and even assuming you have any networking experience, those are not going to look like anything you've seen before. Obviously there will not be any IP addresses - there will be MAC addresses though, since this is still Ethernet, so you'll want to filter by those.
Also, it should be clear by now that the VXT finds its boot host not through something like a DHCP directive, but through DEC's own special methods. Basically, it broadcasts a message - "Does anyone have VXTLDR?" - and if anything does (and it's local policies permit it) it responds and offers a download.
The thing that actually serves these files is an InfoServer. These are very odd devices. I believe they started life circa 1991 with the Model 100 or 150, which was basically a VAXstation running a DEC RTOS instead of VMS, and the lineup ended with the Model 1000, a tiny little gadget that actually mounts in a 5.25" bay so it can go in a CD-ROM tower.
The InfoServers are dedicated NASes; their sole purpose is to serve files to DEC hosts (and swap space to VXTs.) I don't know if you can really talk to these things from other platforms, though it seems like it might be possible since they don't seem to work in a file-based manner. The IS seems to solely serve disks as block devices, and allows clients to use whatever filesystem they prefer.
The InfoServer generally doesn't know what's being served from disks, but it is seemingly capable of understanding DEC's preferred filesystem, ODS-2. This is also known as Files-11.
ODS-2 is a hierarchial filesystem with, among other things, a permissions system and intrinsic versioning. Files all end with a ;1, which increments to ;2, ;3, and so on when edited. Referring to a file without the number gets you the latest version.
The InfoServer can read ODS-2 in a pinch, but it also has it's own filesystem, which is used internally, and also on special CD-ROMs made specifically to install the OS, licenses and applications. I don't think these can be read on anything else.
I don't have a lot more insight into the inner workings of the IS. It behaves mostly like an embedded system, with a command interpreter that works more like a Cisco router than a typical computer OS. The primary interactions I've had with it are simply the creation and sharing of disk partitions; this becomes relevant.
The InfoServer can make a seemingly infinite number of partitions on its attached drives. It can then share these to the network as "services"; you can have multiple service names attached to a single partition if you like. Okay, now for why this matters.
The InfoServer netboots clients over MOP, the Maintenance Operations Protocol, which in turn runs on top of DECnet. For the record, MOP can be served off of a Unix or Linux machine (using "mopd") but cannot provide swap services, which is why you still need an InfoServer.
In a normal, VMS-based MOP environment, I think it would work much like TFTP: You have a folder ("/tftpboot") full of files, and if something asks for a file that's in the folder, the MOP server offers it up. In InfoServer land, it's... different.
Although the IS can read ODS-2 drives, and can offer their contents over MOP... for some reason this is not permitted with the VXT.
Instead, the IS needs to have one partition per file, and one share per partition, named after the file. So for your VXT to boot, your IS needs to offer a share called "VXTLDR" to get the initial bootloader, then another called e.g. "VXT021KT10.SYS" (differs by version) for the actual program image.
Why is this? I have no idea. I have tried placing the files in an ODS-2 partition, in the desired hierarchy, but it will not serve them, and the install script does it the way I described above. This gets weirder, too.
MOP partitions do not have filesystems; each one is a single file. To load contents into a MOP partition, you share it over the network, then mount it from a VMS machine as a raw block device and write a file to it - like, imagine 'dd'ing an executable or a manual document or a config file directly into /dev/sda1.
Why do this? I don't know. And why does DEC call a MOP transfer a "downline load"? I don't know that either, but they do, everywhere. I told you we weren't in Kansas anymore.
You should be able to see by now that this is not a process you can just muddle through. Know how I know? Because it took me ten hours the first time. I made zero progress until I obtained the manual that explains specifically how to do this; had I found that in the first ten minutes, I think this whole process would have been over in half an hour.
Despite all this complexity however, I will still be saving you considerable effort on the "slow path." While I support "doing it the hard way" for the sake of learning, what I burned a whole day on wasn't actually doing it the right way, but rather, fixing a mistake made several decades ago.
The correct way to set up an InfoServer to serve X terminals is to install the OS, then insert the VXT support software CD and type "UPDATE VXT DK2:". Unfortunately, as far as I can tell, that CD has not been preserved online. Instead, there are three files floating around:
The last item is actually what we want; if it were in its original CD format, all you would need to do is install IS on an emulator, mount the image, type "UPDATE VXT DK2:" and you'd be done. The reason it took me so long to get mine working is because I had to teach myself how to use VMS so I could import that backup, extract it, push it over to the InfoServer, and figure out how to execute it from there.
Having done that however, it never needs to be done again. This disk image is equivalent to the InfoServer software CDROM; please make sure it doesn't get lost or fall out of circulation so nobody has to go through this again. Thanks!
Having now given you much of the periphery of the process, the actual setup will be remarkably anticlimactic.
Assuming you're using the emulator (there's just one: open-simh) I can't really think of a reason you wouldn't use the prerolled image here, unless, I guess, you have an existing setup that you want to enhance with VXT support. Fair enough; I'll assume then that you already have it set up. If not, use a tutorial like this one; that's what I did.
Once up and running, all you need to do is attach the disk image linked above; let's assume you attached it to disk 3 ("attach rz3 vxt-install-files-infoserver.ra92" in the INI.)
Once booted, log in, then perform "UPDATE VXT DK3:VXT". If this works, you'll get a friendly setup script; simply answer the questions in the affirmative and you're done.
If the command fails, do "show part dk3:" and see if the VXT partition shows up. If not, you didn't mount it right.
Once the install is done, verify it by typing "SHOW SERVICE". You should see about 32 services linked to 32 matching partitions.
The VXT should immediately become bootable. If it doesn't, try "SET SERVER MOP ENABLE". If it still doesn't work, try "SHOW MOP"; you should see the received packet counters incrementing whenever the VXT requests VXTLDR. If not, there's a network issue. Make sure you attached to the right Ethernet device.
This really should be all there is to it. If you're on a real InfoServer... well, that's another story. I've never tried this and I don't know what it would look like. I think your best bet would be to do a condensed version of what I did to create the disk image. This will require a VMS machine, ideally an emulated one (so you can mount the media easily.) If you need to set up a VMS system, I had great success with this tutorial.
I can't stress enough that I have never tried this, but it seems like it should work.
Okay, it's running, now what?
Obviously the primary function of this device is to connect to other devices. And it offers a lot of options! To get started, you'll want to go to Create > Other..., and you'll get the window above.
The top of this dialog is a list of saved sessions. If your terminal isn't in a workgroup you can't save anything here, so see the section below about fixing that; it's easy! Once you've done that, you can save a session by clicking the up arrow to add it to the list (if it's not already present) and then the Save button to actually commit the list.
Some of the applications are a bit confusing:
Now, in addition to the type of session, you can also choose the transport. TCP/IP is obviously the standard IP transport we're used to; Serial is the local serial port on the VXT, and is only applicable to DECterm and Motif sessions.
The other two, LAT and DECnet, are weird. They're both Ethernet protocols, but more-or-less exclusively used by DEC's own stuff. Maybe you can run these on *nix, but they're universally supported on VMS and various PDP operating systems. In any case,
I should point out that the IP/LAT/DECnet transports are also available for the DECterm/3270 modes. For DECnet and LAT I think these use bespoke protocols built into those suites, but for IP, is it telnet, rlogin, something else? Unknown at this time.
Sadly, you cannot run an X session over the serial port, or set up PPP/SLIP to get IP transport over same. This broke my heart to learn.
The VXT can't save any settings or server addresses until you build a workgroup. Good news! This is incredibly easy, at least in Server-Based Mode. If you're in host-based you have to manually create a config file on a TFTP server; instructions for that are in the manual.
Let's assume you're doing Server-Based, because it's better and also weirder and thus cooler. Unsurprisingly, you actually do all the post-install setup right from the VXT itself!
Once you have the VXT up and running, you'll see a message in the terminal status window that says it's "unregistered", and possibly that it's in read-only mode. To resolve this, go to the Customization menu, then to Configuration > Resource Management.
From here, go to Create > Create Work Group
Select the "LAD_" entry at the top; that's your InfoServer, it'll populate the top field. Put whatever name you like in the name field, then pick a password. A simple one, IMO. Hit OK and your workgroup should be created.
Now go back to Create > Create Terminal
Pick the LAD_ entry. Fill in the MAC address for your VXT - it's visible on the main menu. Enter the workgroup you created, and a name - it looks better in the list, I found out. Hit OK, and you'll be registered.
Double click the LAD_ server in the list, then double click the workgroup you created, and you should be able to see your terminal. Hooray! Note that nothing will work until you reset the session, which you can do from Session > Reset
Now, what's the point of all this? Bureaucracy! What else? But in a good sense.
If you select the IS, or a workgroup, or an individual terminal, you can configure absolutely everything the user could - and lock out customizations. And create configs that'll be inherited. And wipe a user and revert them to the group settings. It's Active Directory, but for X Terminals! This is really quite impressive for 1992.
Supposedly the VXT does not need RAM upgrades in Server-Based Mode, but I have to assume that with the stock 4MB it would perform terribly, swapping constantly. I need to test this, but let's assume it's true, or that you want to run in Host-Based Mode, in which case you need at least 10MB.
First, you're going to need the RAM carrier board. If your specimen boots up at 4MB... sad news, you don't have the carrier board. If you did, you'd have 6MB, because the carrier has 2MB soldered onto it, so don't bother opening the thing up.
Assuming you have the carrier, begin by opening the case. Make sure you unplug the power! The IEC cable physically blocks the case from opening. Once you've done that, find the two plastic tabs on the right side (viewed from the back), push then in, and lift that side of the case. It hinges on the left, then comes away as you lift it.
The carrier is plugged in at the back of the machine; to remove it, pull back the black clip on the right side, then lever up the now-free corner of the board a bit. Put your other thumb on the other side of the bulkhead connector connecting to the motherboard, then push up and rock the board until it comes free. This requires a LOT of force; be careful.
Note the two metal tabs at the back that the board slots into. When reinstalling it, you have to put it into those first, then drop the front down and push it firmly to seat the plug.
You will now see three slots for 72pin SIMMS. I am not sure how much RAM the VXT tolerates; the manual suggests at least 16, but mine is running 18 happily. Great news: You do not need to match the SIMMs. Mine has like... a two and a couple fours? I've even seen it accept a 1MB, but you probably won't have luck with 16s or 32s; I didn't.
Install whatever RAM you have, then reseat the board and power on. If it worked, you'll see more RAM; if not, try another stick. I am PRETTY sure that everything I used was just plain EDO, not ECC or parity, but it's really hard to tell with this stuff.
There are some important things I need to do; these are notes for myself.
Test host mode: Everyone on usenet says host mode sucks, but they're saying that from a 1992-94 perspective, when RAM was pricey. If I install 16MB I bet it works just fine - though it still won't be able to swap if it exhausts that 16MB. I should still see how that works, because in theory the BOOTP/TFTP setup is easier to use in a generic environment.
Here are files you will find useful.
update VXT DK3:VXT (assuming you mounted it to disk ID 3)