(last updated: 15-Aug-2017)
The current configuration is in its original 'as acquired' condition, except that I have replaced the original RZ23 (100MB) drive (with ULTRIX 4.1 installed) with a Western Digital WDE-9100 (9.1GB) drive (with NetBSD 1.5.3 installed).
On-board SCSI Host adapter = #6
Internal SCSI HDD = #3
S3 (internal DIP): UP = Serial Terminal (Printer Port); DOWN = Graphic Terminal
08-Mar-2006
A sticker on the front (asset tag) reads: "University of Colorado / Boulder Campus / 133304"
The model badge on the front has suffered damage. I think it reads VAXstation 3100. I understand that there are various sub-models or configuration so, we'll see what we get.
First, an external vacuuming and wipe down. It was pretty dirty, but not banged up at all, except for the front badge.
* All four stick-on rubber feet are missing from the bottom. I found a sticker on the bottom (photo'd) that reads: "CPU KA42", along with "VS42A".
Time to get inside. Loosened two screws in the rear bezel and the cover slides off toward the front, then up. Wow! Pretty dusty inside!
First, I'll note the storage device types:
- RX23A floppy (3-1/2") supposedly 1.4MB and IBM compatible - RZ23 hard disk (3-1/2") SCSI? (Yep) Conner 104MB
I'm going to remove the drive tray to get to the main board. I loosened the 5 large, captive flathead screws and removed 3 philips head screws from the side opposite the power supply. I disconnected the power cable coming from the power supply and lifted the tray out. Also needed to release the double row ribbon cable at the back. Underneath, plenty of dust! Lint! Dust bunnies!
I vacuumed everything I could reach.
I removed the smaller daughter board at the front of the unit. Turns out to be memory (4MB). The large daughter board is a "VS40X 8 PLANE COLOR OPTION". It has x64 256K chips on it, for 16MB all together, I guess. ROM on the color option board is dated "8935".
The main board was also very, very dusty/linty. I gave it a good vacuuming! Well, I showed those dust bunnies who was boss! :) I photo'd the main board and the 'big chip' which is labeled: "LSIL1A4154", date code "8840". I removed the main board after detaching the power supply cable and the NICAD battery connections. I also removed the power supply. It was very dirty underneath! Real dirt this time. I vacuumed and wiped the inside of the chassis bottom. Looks like the main board has 1MB RAM.
I pulled the drives and control board from the drive tray. Cleaned all of the dust.
Re-assembled the drive tray, then replaced the main board and power supply into the chassis. Then mounted the daughter boards and drive tray.
08-Mar-2006
I decided to try the power supply and plugged the system in after disconnecting the power cable again from the main board. I also disonnected the data cables from the drives. Upon switching the power on the 2 fans in the power supply spun up, but the hard drive didn't start up. Thinking there might be a feedback from the power supply and the mother board, I re-connected the main board power connection. Tried again, same result; hard disk didn't spin up, but I did get the diagnostic LEDs moving through a sequence of some kind. I powered off, reconnected the drives data cables and powered again. Same result.
Looks like I need a screen and keyboard. Also need to get some documentation. See:
http://home.iae.nl/users/pb0aia/vax/vs3khw.html
for an HTML version of the user manual. Should probably do a recursive WGET to snag a copy.
22-Aug-2006
After quite a long summer of not working on my minicomputers, I wanted to first get a good image of all the disks in each VAX system. Given that this system's RZ23 is a SCSI drive, I figured that it would be the easiest so I started with this one.
I have recently been experimenting with some LiveCD versions of Linux (CDLinux, FeatherLinux) and was hoping to use them to make the disk images. I have found no MS-DOS or Windows tool like Linux' dd command. Using dd would make the whole process of generating a raw image of the whole disk extremely simple.
A couple of days ago I bought an Adaptec AHA-1542B SCSI controller for the ISA bus, along with a plain 50-pin ribbon cable. Yes, it's old! I found a few bits of information on the unit from the Adaptec web site, but they don't have a full manual, only the section that gives the jumper settings. In the end, it proved to be enough information, but I had to do a lot of self education on SCSI. I haven't messed with any SCSI gear since the very earliest days of Novell Data Systems (c. 1983) when we used SCSI devices in the "disk unit" boxes.
Once I learned what I could about the Adaptec controller, I wanted to prove that it worked, so I went back to the computer recycler for a SCSI drive that I could experiment with (should have gotten it the day before along with the controller!). I picked up an extra 62-pin cable that matched the drive (with a terminator on one end), AND had a converting connector to the old 50-pin connector on the controller.
I removed the RZ23 from the VS3100 and connected it with the 50-pin cable. The 50-pin cable doesn't have a terminator, but it almost looks like the drive is terminated, so I just put it at the end of the cable, and then connected the other end of the cable to the controller. [2006-08-26: I later learned that, indeed, the drive does have onboard terminators.]
When I booted up, and after loading aha1542.o with modprobe (which caused the drive to spin up), I found that the RZ23 is referenced as /dev/sda. This is what I did to make the disk image:
- Boot to CDLinux LiveCD - Login as root - Load the SCSI driver: modprobe aha1542.o - Create mount point for windows partition: mkdir /root/win - Mount windows disk partition: *See note below* mount -t vfat /dev/hda1 /root/win - Copy the disk to an image file: dd if=/dev/sda of=/root/win/rz23.dsk
If I ever need to restore the imaged disk, I should be able to recreate the hardware settings, and then run the dd in reverse:
dd if=/root/win/rz23.dsk of=/dev/sda
After getting the image, I HALTed the system, and rebooted to Windows (after resetting BIOS boot order). Sure enough, there's the file!
[Note - 2006-08-27: Actually, I mounted the windows partition with '-t msdos' and, yes, it worked. But later when I rebooted into WindowsXP, it complained and spent a couple of hours 'scandisk-ing' the volume to clean things up. All was okay, but I learned the I should have used vfat as the filesystem type instead. I confirmed this with more experiments. '-t msdos' if for old FAT12 and FAT16 systems, where '-t vfat' is for FAT filesystems with long name support.]
I renamed the file to something more descriptive and decided to generate a couple of hashes, just so that I can be confident of the copies that I make to other systems, or to some long-term storage media like a CD. Here's what I came up with:
VAXstation_3100-m38_RZ23.dsk - md5sum = f6fdce297098027b6ae07c4f37402095 - sha1sum = 8c0d2532a372e477088685313ff76554826e06b9
I've located the image file (and confirmed the hash) in the same directory that holds these notes, for now. Eventually, as I get all the other Longmont VAX system's drives imaged, I'll burn them all to a CD or DVD.
25-Aug-2006
Today I reinstalled the hard disk, AND, what do you know, I installed four rubber feet to the bottom of the chassis!
Remembering that while searching the web related to this system, I looked for the two position dip switch S3 on the rear panel that I had read about. See:
http://home.iae.nl/users/pb0aia/vax/vs3khw.html
Nope, couldn't find it. But, sure enough, it's on the motherboard. It's just that the rear bezel doesn't have an opening for it, so I'm going to have to remove the motherboard to change them. The other option is to peel back the labels on the rear bezel exposing the screws that attach it to the chassis. This will never look good again, so I'm going to leave the labels and pull the mother board instead. This switch change will probably be a once-in-a-life change, so I'll take the hard way.
In the meantime, I'm just closing up the system for now.
Also, related to the MMJ connectors for the external terminal, I experimented with cutting the 6-pin RJ-11 jacks on cables that I bought from Jameco. Using my Ryobi Multitool (Dremel) I was able to easily cut away a little bit of the stub the was preventing the jack insertion. Works! The jack won't 'click' into place, and there is no locking tab left on the release lever, but they work!
Also, looking at the video out connector, its just a D15 with standard spacing on the two rows of pins. I think there is a document on the web that shows how to build a connecting cable so that a standard SVGA (or is it XGA?) monitor can be used on this system, see:
http://home.iae.nl/users/pb0aia/vax/vs3khw.html
30-Aug-2006
After some discussion with the classiccmp.org list members about imaging MFM drives, they suggested that if I could get this machine booted to VMS, netbooting the other uVAXen would be very straightforward, allowing me to do a VMS-style dd command to image the disk to a file on this system, then from there to some long-term media.
From my web reading, it seems that this system can use the color option as a console, or a regular character terminal connected to the printer port. Though there appear to be ways to hook up a standard VGA monitor to this system, it will require a connector-bender cable between the monitor and this system. Not wanting to delay for that, I'm going to just go with the character terminal.
According to the "VAXstation 3100" page at:
http://home.iae.nl/users/pb0aia/vax/vs3khw.html
I can flip a little switch S3 next to the diagnostic LEDs on the back panel, to go between the color option, and character terminal. Since my back panel bezel doesn't have the opening to access the switch, I disassembled the system and pulled the main board so that I can change it.
According to the information that website, on S3, down selects the color option, up selects the character terminal. My switch was down. I flipped it up for my upcoming power up. (The switch looks like it is two-wide, but it is actually just a single.)
I hooked up the VT320 terminal and LK201 keyboard using the hacked RJ11 6-pin cable that I bought from Jameco. Hope this works!
It's coming up! I see a screen 
telling me:
cc
c
c
KA42-A V1.2
F...E...D...C...B...A...9...8...7...6...5...4...3_..2_..1?..
? E 0040 0000.0045 ? D 0050 0000.0005 ? C 0080 0000.4001 ?? 1 00C0 0011.700E 4i >>>
This is a very good sign! The machine is still alive, at least. What all this output means, I don't know, but I like it! :) Also, it tells me that I bought the correct cables from Jameco! Woohoo!
Using some information from the website regarding console commands, I typed:
>>>HELP and got a screenful of commands.
>>>SHOW DEV and heard the SCSI drive spin up, the system paused while this happened, then I see:
VMS/VMB ULTRIX ADDR DEVTYP NUMBYTES RM/FX WP DEVNAM ------- ------ -------- ------ -------- ----- -- ------ ESA0 SE0 08-00-2B-0E-44-22DUA2 RX2 DISK RM RX23
DKA300 RZ3 A/3/0/00 DISK 104 MB FX RZ23 ...HostID.... A/6 INITR
>>>SHOW ETHER gives:
ID 08-00-2B-0E-44-22
>>>SHOW MEM gives:
00800000 00000000 007E3800:007FFFFF
>>>SHOW BOOT gives:
....
>>>BOOT (inadvertantly typed!) gives:
-ESA0
and pauses. It looks like it's trying to read in date from the ethernet port. This could be the way to netboot these types of machines.
I'm going to try to boot to the hard disk and see what comes up...
I tried:
>>>BOOT RZ2 and got:
?41 DEVASSIGN, RZ2 84 Fail
I tried:
>>>BOOT RZ23 and got:
?41 DEVASSIGN, RZ23 84 Fail
Then I tried:
>>>BOOT DKA300 and got: Ultrixboot - V4.1 Tue Aug 28 09:23:58 EDT 1990Loading (a)vmunix ...
Sizes: text = 630736 data = 100864 bss = 484856 Starting at 0x2b31
ULTRIX V4.1 (Rev. 40) System #1: Wed Jul 24 09:22:22 MDT 1991 real mem = 8269824 avail mem = 5427200 using 201 buffers containing 826368 bytes of memory KA420 processor with an FPU sdc0 at uba0 csr 0x200c0000 vec 0x1fc, ipl 0x14 rx2 at sdc0 slave 2 scsi0 at uba0 csr 0x200c0000 vec 0x1fc, ipl 0x14 rz3 at scsi0 slave 3 (RZ23) sg0 at uba0 csr 0x3c000000 vec 0x44, ipl 0x14 ss0 at uba0 csr 0x200a0000 vec 0xc0, ipl 0x14 ln0 at ibus0 csr 0x200e0000 vec 0x50, ipl 0x14 ln0: DEC LANCE Ethernet interface, hardware address: 08:00:2b:0e:44:22 Wed Nov 6 15:20:35 MST 1996 Automatic reboot in progress... /dev/rz3a: 565 files, 8562 used, 6761 free (209 frags, 819 blocks, 1.4% fragmen) /dev/rrz3g: 3112 files, 41965 used, 7314 free (1234 frags, 760 blocks, 2.5% fra) check quotas: done. savecore: checking for dump...dump does not exist routed RPC port mapper: portmap. NFS daemons: biod mounting NFS directories:nfs_mount: mod:/mode/users server not responding: port nfs_mount: backgrounding /mode/users nfs_mount: wave:/export/wave server not responding: port mapper failure - rpc tt nfs_mount: backgrounding /wave done. local daemons: syslog sendmail ntpd . preserving editor files clearing /tmp standard daemons: update cron accounting network snmpd printer. start errlog daemon - elcsd Wed Nov 6 :27 MST 1996
/usr/lib/lpd: slate: cannot chdir to /usr/spool/printers/slate
/usr/lib/lpd: hobbes: cannot chdir to /usr/spool/priners/hobbes
and the system hangs at this point. I tried again, pressing the reset button on the rear panel. I saw just the same results. It gets to this point and just hangs. I can halt the processor with a CTRL-C and then CONTINUE, which shows that the processor is alive, but there's no other output, and certainly no login prompt.
30-Aug-2006
I'm thinking that I might install my own SCSI drive and see if I can't get NetBSD loaded. On that note, I realize that my current SCSI drive is 4.3GB and I read last night that the Vs3100 can only handle a 1GB or less sized drive if it's the boot volume.
So, off I went to MAS Computers and picked up a 1GB drive ($2), a 9GB drive ($6), and two old SCSI CD-ROM drives ($2 ea.), a Toshiba XM-3601B (4x), and a Sanyo CDR-H94SMV (?x). I'm hoping that I can use the CD drives to install NetBSD with the least amount of pain. I disconnected the onboard SCSI drive and connected the Toshiba CD drive and it is recognized! I don't know what to do next, but I think it'll work.
I tried the 1GB drive, but it appears dead. I couldn't talk to it on my "silver" PC either. The 9GB drive is good, I've tried that on the PC, but not yet on this system.
Just for kicks I attached the Toshiba XM-3601B 4x CD drive and it works! How do I know? I put in the NetBSD/vax 3.0 CD and tried to boot to it with this console command:
>>>b dka0
and it comes up with the NetBSD boot stuff! Woohoo!
Now let's try the Sanyo CDR-H94SMV drive. Nope, no good. It won't do it. Something to do with 512-byte blocks or something according to what I read on the Vs3100 web page. Well, I have one that works at least.
31-Aug-2006
Tonight I decided to see if I could get both the Toshiba CD drive and a scratch SCSI drive on the same cable. Since the 3100's cable has a single connector, I had to construct a homemade connector made from telephone wire. . The only bad part, after doing all the wire stripping, was that I first assembled the connection with the wires going straight through. This really connects pin-1 to pin-2, pin-2 to pin-1, and so on. Not good. I pulled it all apart and then reversed the wires at one end. Putting this all back together with all those woven wires was a trick, but I eventually got it. Turns out that it works, too! So now I have a cable with 5 device connectors.
I put the 9MB SCSI drive at the end with termination enabled, and put the CD drive midway on the cable. Using the power connections from the original hard drive, and the floppy drive, I was able to power everything up. So far, so good.
I learned enough the other night about booting to specific devices, and after doing a >>>SHOW DEVICES I booted from the NetBSD/vax v3.0.0 CD. Yes, it's bootable. I also tried the v1.6.2 and v3.0.1 CDs and they are both bootable, as well.
Unfortunately, after trying many times, I was unable to successfully install NetBSD on the 9GB hard drive. There must be a problem with it being greater than a 1GB drive as mentioned on various mailing list postings. Apparently, the 3100 has a cow if the disk has to many blocks, and wraps around after 1GB. I don't know why this would affect the partition table, and disklabel, but I kept getting kernel panics while trying to write to the drive.
For kicks, I tried the 1GB SCSI drive again, but to no avial. It's just unresponsive, no matter how I set the jumpers. It spins up and the heads position themselves, but it is just not recognized by the SCSI controller. I guess it's a goner.
So, not quite ready to wipe the original drive, and install NetBSD, I recabled it back up and just booted from it. Using information offered this morning on the classiccmp.org list, I tried to boot with this command:
>>>B/R5:00000001 DKA300
This command works for another list member to put them in single-user mode. He suggested that I might be booting into multi-user mode by default, and that if I can boot into single-user mode I might be able to get a prompt.
Well, that particular command did not work, the system still booted into multi-user mode (I guess) and hung again at the same spot. But, I did experiment now that I had a command template. I tried these commands:
>>>B/R4:00000001 DKA300 >>>B/R3:00000001 DKA300 >>>B/R2:00000001 DKA300
and got either errors or the multi-user mode. But this command:
>>>B/R5:00000002 DKA300
gives me a singe-user mode prompt. No login required. Now I can poke around!
01-Sep-2006
After reading some of the ULTRIX documentation, I find that the command I really want to use is:
>>>B/2 DKA300
This gets me into single user mode with less typing. I found this in the "Guide to Shutdown and Startup" manual, which gives processor specific information.
Turns out there's not much here. The disk looks to be a very minimal installation, most commands refer to files in the /usr directory, which from the boot printout (multi-user mode) is some kind of NFS volume. So, I don't have anything useful by the looks of it. I have scan each directory and CATed out interesting files but there is not anything like distribution files, or the ability to generate new kernels. Looks like I'm okay to wipe this disk if I want to. And I do have an image if I ever want to come back to this point.
Before I went further with a NetBSD installation on the original disk, I remembered having bought a DEC TLK04-AA DAT tape drive in early May ($2!). It's a SCSI device, and I wanted to see if the VS3100 would recognize it. It does, but somehow it fouls the SCSI cable and the hard drive is no longer visible. In any case, with a little pushing and pulling, an already-inserted tape was rewound and I was able to eject it. I learned about the write-protect tab, and played with insertion and ejection. No more trouble.
So, I removed the DAT device, and reconnected the original disk and the CD drives. I tried to boot with the NetBSD 1.6.2 version, but it hangs after mounting 'ffs', whatever that is.
Before trying one of the v3.x CD's I figured out that the power-on test #1 has to do with the ethernet, and I connected up a cable and transceiver box. I rebooted and sure enough I now have no error on the #1 test. Just for kicks I loaded ULTRIX and using ifconfig assigned the IP address 192.168.1.201 and tried to ping it from my PC. Yep, it works! So I have a functional ethernet device.
Now, I'm ready to try the NetBSD 3.0 CD, installing on the original drive. Here goes...
Well, it's a no go. Turns out that the NetBSD 3.0 CD boots fine, but it quickly let me know that I needed at least 250MB of disk space to install. Well, that's it for me tonight. This little RD23 is only 100MB!
02-Sep-2006
Tonight I started messing with getting this VAX doing netbooting of NetBSD. If I can, and what I learn is transferable to the other VAXen, then I should have a pretty easy time of booting each of them as a 'diskless' system, and then dd'ing their drive contents to some image files.
I've been using the infomation from:
http://netbsd.binarycompass.org/Documentation/network/netboot
and I've gotten the MOP stuff working. I thought it would be a breeze after that, since I already had TFTP running on Ricon-Gold for the Xyplex MAXserver earlier this year, but it's not working. It looks like the boot loader gets transferred to the VAX via MOP okay, and the VAX is getting a DHCP address, but from there it fails.
I installed the MOPD package, which was a snap. The BOOTP package was already installed, but commented out in the inet.d configuration file: /etc/inetd.conf. I un-commented it.
Since my Linksys router is also my DHCP server that might explain why the VAX appears to be trying to BOOTP from 192.168.1.1. I don't know. I give up for now, but I'll keep reading.
03-Sep-2006
I moved my Ricon-gold machine to the basement alongside the VAXstation 3100, only cross connected those two boxes with my yellow cross-over ethernet cable.
I could see that MOP was successfully delivering the NetBSD/vax bootloader, so that's good. Moving on to the BOOTP stuff was still problematic.
More efforts, to no avail, but I did get BOOTP's bootptab file setup correctly, just didn't know it. I was confusing NFS problems with BOOTP problems. All of the messages seemed to indicate issues with BOOTP, so I didn't even know that it was working, and that it was NFS, the next stage, that was faulting.
Anyway, I fiddled with this, and with that, and eventually figured out that the BOOTP stuff was working (though I didn't know if my configuration was good or not), but still needed to setup the NFS exports. Aha! Okay, I edited the /etc/exports file and added an entry for the VAX. Still no joy. Same set of errors.
Somewhere along the line, I decided to install (something) on my Debian box. While doing the dselect stuff, I saw that there a couple of 'obsolete' packages: gcc-3.3-base and sysv-rc. Well, I figured I'd just remove them at the same time. Big Mistake! It hoarked my Debian setup. Blast!
I spent the next 4 hours re-installing Debian Woody on Ricon-gold using my CD set. This worked well, except that the whole process on such a slow machine is excrutiatingly slow. After I got it rebuilt (at 5:00AM!) I tried one more time and still had the same results.
Interestingly, when I re-installed the Debian, I noticed that it automatically included the nfs-kernal-server package that should give me NFS support. That was easy!
04-Sep-2006
Today, I started poking around in the syslog file, trying to get anything that might help me pinpoint the problem. After hours of poking around, fiddling with configuration files, and googling the web and newsgroups I finally found out that the nfs-kernal-server package on the Debian box is apparently broken in Woody. If I upgrade my kernel to 2.24 it should work. Or, I can use the nfs-user-server package instead. This is what I finally did.
Using dselect I installed nfs-user-server (which automatically un-installed nfs-kernel-server). I rebooted the VAXstation and it worked! Just like that! I guess my configuration was okay after all. Dang NFS server!
So, to document the working setup, here is what I have:
Packages installed on Debian Woody: - mopd - bootp - nfs-user-serverDirectory/File configuration: - created these directories: - /boot/netbsd-vax - /boot/netbsd-vax/mop - downloaded these NetBSD/vax files: - .../NetBSD-1.5.3/vax/installation/boot.mop -> /boot/netbsd-vax/mop/ - .../NetBSD-1.5.3/vax/installation/netbsd-ram.gz -> /boot/netbsd-vax/ - created symbolic links (ln -s): - /tftpboot -> /boot/netbsd-vax - /boot/netbsd-vax/mop/08002b0e4422.SYS -> /boot/netbsd-vax/mop/boot.mop - /boot/netbsd-vax/netbsd-ram.gz -> /boot/netbsd-vax/netbsd.gz
Server configuration files: /etc/inetd.conf: ... bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 1 ...
/etc/bootptab: VAXstation_3100: :ht=ether: :ha=08002b0e4422: :ip=192.168.1.160: :hn: :bf=netbsd.gz: :rp=/boot/netbsd-vax/
/etc/exports: /boot/netbsd-vax vax(rw,insecure,no_root_squash,no_all_squash)
I don't really understand the /etc/exports file, so I might fiddle with it to see what makes a difference. Why it works with the name 'vax', and not 'VAXstation_3100', I don't know. Are all of those options required? I don't know.
But, this setup works, and that's good enough for me, for now.
I went ahead and got the VAXstation loaded with the installation kernel, etc., and exited to a shell. Trying dd on the SCSI drive didn't work, though. I get an error telling me that the device doesn't exist. My command line was:
dd if=/dev/sd0a of=/dev/null
which comes back with:
sd0: no disk label dd: /dev/sd0a: Device not configured
Hmmm...something fishy. Yep, I can still boot ULTRIX from the drive, so there's something in the NetBSD that isn't recognizing the drive.
I tried the NetBSD 1.6.2 ram installation file (using the same 1.5.3 MOP bootloader), but it just hangs after showing: root file system type: ffs.
I tried the NetBSD 3.0.1 version (again, using the 1.5.3 MOP bootloader), which boot up fine, but I get the same error.
Then I tried:
dd if=/dev/sd0c of=/dev/null
thinking that the naming of the drive might have something to do with it's SCSI address (which I think is 3...I'll check after I shutdown). But it just sat there with a blinking curser, with no output.
I was going to try something else, and hit CTRL-C to stop the dead dd, and this is what I saw:
^C105825+0 records in 105824+0 records out 541818888 bytes transferred in 449.090 secs (120648 bytes/sec)
So, it's working after all! I just need to point dd to the correct device!
I switched back to booting the 1.5.3 version, and did a dd to confirm that it works, with this output:
# dd if=/dev/sd0c of=/dev/null count=1000 sd0: no disk label 1000+0 records in 1000+0 records out 512000 bytes transferred in 3 secs (170666 bytes/sec)
So, now to copy disks!
As a test of my methodology, even though Ricon-gold, my Debian box, doesn't have enough free space to store a whole disk-sized file, I wanted to see if I could use NFS to store the output of the dd commands. I was successful by following these steps:
- when the VAX boots to the NetBSD sysinst menu: - go to the Utility Menu - select Configure Network - set for device le0: - Network media type:- Your DSN domain: - Your host name: vax - Your IPv4 number: 192.168.1.160 - IPv4 Netmask [0xffffff00]: - IPv4 gateway: - IPv4 name server: - exit the sysinst program, to a # prompt - mount the NFS volume on the Debian system: - mount 192.168.1.31:/boot/netbsd-vax /tmp - choose /tmp as present working directory: - cd /tmp - at last, copy the disk image: - dd if=/dev/sd0c of=/tmp/VAXstation_3100.dsk
Voila!
As a final test of this setup, I connected a second drive to Ricon-gold and then followed the above steps. The process started at 20:53 and ended at 21:11, copying the 100MB RZ23.
The output from the process was:
# dd if=/dev/sd0c of=/tmp/VAXstation_3100_RZ23.dsk sd0: no disk label sd0(si0:3:0): illegal request, data = 00 00 00 00 21 00 00 00 00 00 00 00 sd0(si0:3:0): illegal request, data = 00 00 00 00 21 00 00 00 00 00 00 00 sd0(si0:3:0): illegal request, data = 00 00 00 00 21 00 00 00 00 00 00 00 204864+0 records in 204864+0 records out 104890368 bytes transferred in 1069 seconds (98120 bytes/sec)
I made a second copy just so that I can compare them once I copy them to my storage media. They match, and I generated a md5 hash for the image. Okay, so that part is done.
04-Sep-2006
On a lark, since I was now convinced that I had a good image file of the disk, I went ahead and did the whole NetBSD/vax 1.5.3 installation via FTP. I had to make some small adjustments to the FTP directory (inserted /pub/NetBSD-archive/...), but it went very smoothly. I wasn't sure how much space it would require on the hard disk, so I only chose to install the first three sets. When it was all done, I still had about 45MB free on the harddisk!
Unfortunately, I didn't take any photos of the initial boot. Ah, well.
To confirm my operations, I then copied the original disk image back to the hard drive, to make sure that ULTRIX was back. It was!
# dd if=VAXstation_3100_RZ23.dsk of=/dev/sd0c 204864+0 records in 204864+0 records out 104890368 bytes transferred in 2296 secs (45683 bytes/sec)
So I'll have to re-install the NetBSD again, later.
15-Jul-2007
I got the urge to work on some of these VAXen, particularly with NetBSD, and since I had such a good experience with the Vs3100 last year, I decided to work on this one.
First, I wanted to see if I could actually use a bigger SCSI drive in this system. It came with an RZ23, which is only 100MB in size, and would prove to be too small for anything useful.
I began, then, by connecting the system to my VT320 (using the 'printer' port) MMJ connection, and I used the Synoptics AUI-to-10baseT transceiver box to connect to the little hub here on my table. I booted the system and up came NetBSD 1.5.3! I guess somewhere along the line I must have re-installed this OS, even though my notes from last September (has it been that long ago?!).
I just re-read all of the notes above, and discovered that I have already tried to use these extra SCSI drives. The 1MB was unresponsive, and the 9GB was not bootable for some reason. Hmmm... Well, the story becomes more engrosing below.
There was no need to worry about what was on the disk already, since it was just a fresh, clean NetBSD, so I set about re-establishing my MOP/BOOTP/NFS server so that I could do the new install again. I connected my Compaq Aero 'aero-2' (running Debian) and found that though it had the MOP deamon installed, there were no NetBSD files anywhere. So I downloaded 1.5.3 from ftp.netbsd.org and configured the /etc/bootptab.conf file, as well as putting the MOP bootloader file (boot.mop) in /tftpboot/mop, and the intsall kernel in /tftpboot. Hours went by and I could not, for the life of me, get the Vs3100 to boot! I tried different hubs, I tried the direct cross-over cable, and nothing. Finally, I called it quits for the night.
16-Jul-2007
In desparation, I finally brought my other Aero 'aero-6' down and connected it up. When I booted up I was mildly surprised to see that the NetBSD installation files were already onboard and that the MOP and BOOTP services were still configured from last year's events. Well, that saves some time!
While not entirely turnkey, this set up did the trick! There were several strange anomolies where the Vs3100 would download the bootloader but then enter a never-ending loop comaplaining about some extra interrupt. I don't have a handle on that at all, but after a while, I was able to get a good bootloader image dowloaded to the system and as long as I had the local ethernet hub disconnected from the rest of the local LAN, then the Vs3100 was able to get it's address via MOP/BOOTP rather than from my household DHCP server. Once I got that straightened out, the install kernel came over just fine.
Well, one that was all going fine, I decided to try my spare SCSI drives (1GB, 4.3GB, 9GB) and see if I could get them each to boot the system once NetBSD was installed. Remember, I had forgotten about my troublesome adventures a year ago.
I first connected the 1GB drive. Testing with this drive was important to me because I have found several references online that point out that the Vs3100 could only boot from a 1GB or less sized drive. If that were true, then this drive was my real hope of have at least a modestly usable installation. So I tried it. I simply disconnected the RZ23 and connected the 50-pin 1GB drive. It worked! I did a full install of everything via FTP, and then rebooted. It booted just fine!
When doing the NetBSD installation, I used these settings when prompted to configure the network:
IPv4 address: 192.168.1.163 netmask: 0xffffff00 gateway: 192.168.1.1 nameserver: 209.210.176.8
The other fields I just left blank. Sysinst will complain that it can't ping the nameserver, but that's fine. Sisna.com doesn't let their nameservers respond to pings.
Later, after the installation had finished, I went in and edited /etc/resolv.conf to include sisna.com's second name server at 209.210.176.9. Everything else is ready to go, based on the inputs given during sysinst.
I did the same with the 4.3GB drive (using a 50pin-to-68pin adapter) and I got the same results, with one exception. The Vs3100 sees the drive fine, but claims it is 40.2MB (using >>>SHOW DEV). It must be that the trouble is in the system BIOS, but not in the SCSI controller itself since when I booted the NetBSD installer, it saw the entire 4.3GB size. Using NetBSD's sysinst default partitioning, which gave me only a 30MB root partition or so, which is in the lowest cylinders, it should work. It does! I boot NetBSD without any trouble.
Next, I tried the 9GB drive, again with the cable adapter. In this case, >>>SHOW DEV says the drive is 515MB. So it kind of depends on the drive size mod 1GB, I guess. Anyway, same good results with this drive. Bootable and all! 9GB! Woohoo! This system just might be useful as some kind of internet server after all.
As far as these odd drives sizes are concerned, I'm guessing that as long as the root partition is in that first 'see-able' part, then the bootloader should be able to load, and then it goes from there.
16-Jul-2007
First order of business was to get some extra tools. The installation does not appear to include WGET or LYNX, both of which I really wanted to use.
I wasn't at all sure of myself, but I figured that I could download the source packages and build these tools myself. I was right! I FTP'd to the GNU site and downloaded the latest WGET, version 1.10.2. All I did was unpack the tarfile and run:
# ./configure
according the the README. Once that (lengthy) proces was complete, I ran:
# make
When the make was complete, I found the executable in the src/ subdirectory and ran it:
# ./wget
Woohoo! It works a charm! According to the README, I should have run:
# make install
to have placed the executables, and doc in their proper locations. Well, since make generally only actually builds anything if the source or object files are newer than the executable, I figured it would just finish the placement process. Yup, that's exactly what it did, so I now have WGET in my system.
I then used it to download a copy of LYNX from
17-Jul-2007
Sure enough, this afternoon when I checked the make had completed with a "Welcome to Lynx!" message, so I guess the make was successful. I tried it out and it works just fine. So I did the "make install" to put the pieces in their appropriate public places.
Figuring there must be some kind of package system, similar to Debian's APT or RedHat's RPM, I find that NetBSD has a thing called 'pkgsrc'. After a little research it appears to be more rudementary, closer to the actual CVS source code, but I guess it works, so got a copy downloaded. I'm in the middle of undoing the tarfile right now, which has already been 2-1/2 hours! This little VAX is definitely no speed demon! Total time was about 3-1/2 hours to unpack the pkgsrc.tar.gz file. Whew! Don't want to do that very often!
Before doing any more software stuff, I decided to hard-mount the 9GB drive in place of the RZ23. Mechanically, no problem, but when I tried it out, the system did not recognize the drive on the SCSI channel. After much fiddling, I found that if the "SCSI Term" jumper is in place on the drive, the system will recognize it. Short of jumpers, I moved the jumper from the "AUTO START" location and used it in the "SCSI TERM" position. Turns out when I do this, the system will recognize the drive, but the systems 'auto-boot' feature won't work for some reason, and I see a '6?..' on the countdown instead of '6...'. In the end I stole another jumper from the 1GB drive, and so I now have this WDE9100 configured with jumpers on:
- SCSI TERM - AUTO START - SCSI ID1 - SCSI ID0
19-Jul-2007
I decided to try more recent versions of the NetBSD operating system, since they might work better with the pkgsrc facility, and might be better in some ways. It was frustrating, to say the least!
I tried them all: 3.0, 3.1, 3.0.1, 1.6.2, etc., and even went down to 1.4.1. Not a single one worked. Either it would crash on loading the install kernel, running sysinst, or in the case of 1.4.1, it worked for a while, but wouldn't build Lynx. I'm guessing that the later versions require more memory than my measly 8MB. So I've decided to come back to 1.5.3 (now I have to rebuild Lynx and Wget!), and once it's pretty settled, I'll tar it up for backup and then fiddle with pkgsrc some more.
[Note: After doing some work building software packages in July/August 2009, I now believe that the reason that I can't run any NetBSD greater than 1.5.3 has to do with my minimal memory configuration (8MB). Though they may run in that small memory, the newer OS versions can't install.]
23-Aug-2007
During some random internet searching, I came across this on HP's website:
http://h71000.www7.hp.com/faq/vmsfaq_024.html
which lists all of the VAX CPU types and the corrosponding platform/model. This information confirms that my KA42-A CPU is a VAXstation 3100 model 30, not the model 38 that I had suspected until now. I've changed the title of these notes to reflect this new knowledge.
04-Aug-2009
Over the past couple of weeks I've been building software for this system while running NetBSD 1.5.3. First, I've rebuilt the kernel itself, trying to minimize the memory requirements. I had a difficult time selecting the correct CPU type, as well as various options. The CPU selection was the worst. Why? Because neither the options file, nor the source code itself ever refers to the VS3100/30 or it's KA42 processor. At first I tried to use the VSIII selection, since they both use the CVAX processor (2nd generation microVAX chip), but that didn't work. I tried using the KA420 selection, but that failed to. Finally, based on some further online searches (which didn't really answer the question) I chose the KA410. This is identified as the VAXstation 2000 selection, but it also applies to the 3100, as it worked for me. BTW, each kernel build, from scratch, takes almost 24 hours, so each of these attempts was painfully slow, to say the least! I'm glad to have finally discovered the proper CPU option. Once that was done, I rebuilt a couple of times more, configured for ONLY the hardware options on my system. At last I came up with two kernels: 1) specific for my system, with kernel debugging enabled at about 1.08MB, and 2) specific to this system, without the kernel debugging at about 1.03MB. That looks to be as small as I can go. Everything else is already turned off. On other thing, I tried to build in support for the RX33 floppy, but whenever I enabled the RY option in the configuration, it would complain about some stuff not being defined. A quick read of the VAX port section on netbsd.org suggests that support for the floppy once worked, but was lost at some point. Maybe that's what's going on. So, for now, no floppy support in the kernels that I've built. I'm currently running the smaller, no-debugging kernel.
Here are the configuration options that I ENABLED; all others are commented out:
include "arch/vax/conf/std.vax" options "VAX410" # VS 2000 maxusers 8 options NTP # NTP kernel support options INET # IPv4 file-system FFS file-system NFS file-system KERNFS file-system PROCFS file-system CD9660 options QUOTA options SOFTDEP # FFS soft updates support. options NFSSERVER options NFS_BOOT_BOOTP,NFS_BOOT_DHCP # Use bootp <> dhcp options NFS_BOOT_BOOTPARAM # Use the Sun way of netbooting. options WSEMUL_VT100 options WSDISPLAY_DEFAULTSCREENS=8 options SYSVMSG options SYSVSEM options SYSVSHM options COMPAT_VAX1K # Must be present to run pre-1.4 binaries. options COMPAT_43 options COMPAT_09 options COMPAT_10 options COMPAT_11 options COMPAT_12 options COMPAT_13 options COMPAT_14 options COMPAT_IBCS2 # DEC SVR.3 compatilibity options LKM # [NOTE: LOADABLE KERNEL MODULES] config netbsd root on ? type ? mainbus0 at root vsbus0 at mainbus0 # All VAXstations le0 at vsbus0 csr 0x200e0000 # LANCE ethernet dz0 at vsbus0 csr 0x200a0000 # DC-367 DZ-11 lookalike ctlr hdc0 at vsbus0 csr 0x200c0000 # HDC9224 MFM/floppy ctlr si0 at vsbus0 csr 0x200c0080 # VS2000/3100 SCSI-ctlr smg0 at vsbus0 csr 0x200f0000 # Small monochrome display ctlr. rd* at hdc0 drive? # RD5x disks #ry* at hdc0 drive? # RX floppies [NOTE: WOULDN'T BUILD WITH THIS ENABLED] scsibus* at si? sd* at scsibus? target? lun? cd* at scsibus? target? lun? wsdisplay0 at smg0 lkc0 at dz0 pseudo-device loop 1 pseudo-device pty 64 # pseudo-terminals pseudo-device bpfilter 8 # Not supported by de yet. pseudo-device sl 2 pseudo-device ppp 2 pseudo-device tun 2 pseudo-device gif 4 # IPv[46] over IPv[46] tunnel (RFC1922) pseudo-device vlan # IEEE 802.1q encapsulation pseudo-device tb 1 pseudo-device vnd 4 pseudo-device ccd 4 pseudo-device raid 4 # RAIDframe disk driver pseudo-device rnd # /dev/random and in-kernel generator
It occurs to me that I might be able to remove the Loadable Kernel Module and compatibility options and probably most of the psuedo devices. I don't even know what most of them are, so a little research would be in order. I started with the GENERIC config and just removed everything that seemed to apply to all hardware that isn't on this system.
04-Aug-2009
Several packages I had installed way back in 2007, but I've spent some time building others lately. First, what I already had installed during 2007 are: - lynx 2.8.6 - screen 4.0.2
Recent builds: - thttpd-2.25b - perl-5.6.1 (required that after the 'configure' I manually edit config.sh to change ieeefp.h from 'defined' to 'undef' since there is no ieeefp support on the VAX. Took several days to learn this (googling netbsd mailing list helped), and figure out how to handle it. Then it built fine. Still fails four specific FP tests, but otherwise runs well.]
Failed builds: - perl-5.8.8 (bails after claiming it can't allocate more memory, which may very well be true on this small 8MB machine.)
06-Jun-2010
Sadly, the system died last night. I hadn't used it for about a year and since I was working on my small SGI boxes, I wanted to crank this one up also. After cabling up everything (VT510 terminal was used) I fired it up and it booted nicely into NetBSD. After just two or three minutes of use (long enough for me to log in and reorient myself) it just shutdown. Complete stop. Fans stopped turning, no repsonse to terminal input.
Looking at the rear panel showed the status LEDs all dark. So it seems that the PS has died. While investigating, I noticed that I could get a momentary flicker from the status LEDs and the AUI-to-10BaseT transceiver LEDs when I cycled the power.
Today, I opened the box and removed each component, checking the power at each step. Unfortunately (or fortunately) it turns out that the fault is on the main board. The drives spin up when powered on their own, so they aren't the trouble. I disconnected everything from the main board, including the NiCad battery pack and tried again. Same behavior. A momentary jerk of the PS fans, the LEDs flicker, then all out. A quick scan shows no obvious culprit. The handful of small electrolytic capacitors appear normal.
The main board is:
5417312 50-17311-01 H1
I also researched the possible memory boards to increase the RAM in this system:
4MB MS42-AB 54-19051-AA 8MB MS42-KA 12MB MS42-BA 54-18287-01 16MB MS42-CA 54-18324-01
19-Sep-2011
Today, on a lark, I tried this system out again. At first, after connecting up the VT320 MMJ terminal, I powered up. I did see the PS power LED light up (that's good), but didn't hear the hard drive spin up (that's bad). I popped the cover and noticed that both the data cables and the power cables were disconnected! No wonder. But, at least I saw the PS alive.
I let the machine complete it's countdown and then tried a SHOW DEV command which showed only the ethernet board. I powered down and connected power and data to the RX33 floppy drive, and powered up again. After the countdown, I now saw the floppy device, in addition to the ethernet (that's good). Next I powered down and connected the WDE9100 hard disk, and powered up again. After the countdown, I see all three bootable devices (that's good!).
The system's TOY battery charge was depleted so the system didn't automatically boot to the hard disk. When I tried SHOW BOOT it came back with just '.....'. I manually booted with B DKA300, and saw the NetBSD loader and then kernel loaded. It took a looooooong time to boot up since the kernel wanted to do a hard disk check since it thought that the clock had lost 14579 days.
Once up, I reset the date in the TOY clock and let the system run for a while.
24-Sep-2011
I've been wanting to connect a regular graphics monitor to this and my other VAXstations for some time, to see what that looks like. Sadly, the VR262 monochrome monitor that was included with this system is dead and I don't think I am smart enough to revive it. So, I was hoping that I might be able to use a PC-style SVGA monitor instead.
Checking a few websites suggests that this can be done in two ways, depending on the capabilities of the target monitor. If the monitor has sync-on-green capabilities then it is fairly easy to construct a connecting cable. If not, then the cable needs to include electronics in addition to just the cabling and connectors. I found a few websites that discuss this, and cable construction descriptions:
- http://users.bart.nl/users/pb0aia/vax/vs3khw.html - http://www.repairfaq.org/sam/vidconv.htm - http://skygate.bravehost.com/PS2_VGA_cable.html
I built a Rube Goldberg cable according to the suggested wiring diagram on the skygate.bravehost.com page, hoping that my best LCD monitor (HP L1740) would accept sync-on-green. I used RCA-to-BNC converters connected to the VGA-to-RCA cable(s).
Signal VGA D-15 (female) RCA (female) --------- ----------------- ------------ RED Pin 1 RED pin GREEN Pin 2 GREEN pin BLUE Pin 3 BLUE pin RED GND Pin 6 RED shield GREEN GND Pin 7 GREEN shield BLUE GND Pin 8 BLUE shield
After construction, I connected up with a BK23-3J cable from the system to the HP L1740 monitor.
Alas, there seems to be no signal at the monitor. I thought that it was a sync-on-green monitor but I'm now convinced that it is not, and thus will not work without the LM1881 sync separator circuit which is the alternative to this direct signal cable that I've made. Rats! Need to either get a sync-on-green monitor capable of the sync rates of this VAXstation, or upgrade my cable to use the electronic separator.
25-Sep-2011
Since our efforts yesterday did not yeild useful results, and thinking things over a bit more with respect to the VR262 monitor that seems dead, it occured to me that VR262 might only appear to be dead, and that it requires a signal to actually come alive. With this in mind, I opened up this system and set the SW3 to 'UP' to re-enable the console on the graphics video system. Then I connected the VR262 with a BK23-3J cable and fired the monitor and the system up. Sadly, no life in the VR262. Still dead. I returned everything back to the way the were and thought some more.
A new thought occured to me. I received two monitors a year ago with two HP 9000 workstation. Perhaps these monitors were able to operate in a sync-on-green mode, since many online remarks indicate that these HP systems, and SGI, Sun, etc. use SoG. So, with this in mind I dragged the HDS ViewStation 20" CRT monitor (KDM-2077 (Sampo AlphaScan? 30-82MHz Hor. 50-90MHz Ver.)) over and returned SW3 to the 'down' (enable graphics console) position. Then I connected my newly built RGB-to-VGA cable, and connected a LM401 keyboard to the rear panel and fired up.
Lo, it works! This monitor shows several test patterns, then the countdown, then the chevron prompt when the system is powered. Sadly, the system no longer boots NetBSD! I guess the kernel detects the graphical system and terminates, probably because I didn't build the kernel with that option.
Later, I scouted the supported hardware section of the NetBSD website and confirmed that the VAX port does NOT support the color graphics subsystem on this type of system.
I tried the second monitor (HP KR42310114) that was also included in the HP 9000 acquisition and find that it does not work with SoG. Well, I have at least one monitor that I can use that way, thankfully.
Copyright © 2006-2025 Jared Blaser. All rights reserved.