Embedded Files
DEC VAxstation 3540
4/18/26
Dan-II Found a 3.5" 4.3GB ST15150N disk in the Museum's collction. He used simh on bismuth (FreeBSD PC that has a SCSI adapter) to install NetBSD/vax 10.1 to an RAUSER image of the same size as the disk. It was a full install, and he copied the GENERIC.MP kernel to /netbsd. I wrote this image to the SCSI disk after verifying it boots under simh using the MicroVAX 3900 personality. First, he connected it to the VAX as SCSI ID 1, keeping the OpenVMS disk at 0. The console command BOOT DKA100 would just hang after VMB printed the "-DKA0" line.
He changed the disk to ID 0 and disconnected the OpenVMS disk. The console command BOOT DKA0 also hangs.
He connected the disk back to bismuth and ATTACHed /dev/da0 directly to simh and moved the UP GENERIC kernel back into place and reconnected it to the VAX. Same hang as before.
He put a 10BASE-T MAU on the AUI port of the VAX, installed mopd on bismuth and placed the NetBSD stage 1 loader (/boot) in the /tftpboot/mopd directory with the filename <VAX MAC address>.DAT
The console command BOOT ESA0 hangs even earlier than booting from SCSI attempts did.
He found from mopd log output that the /boot ELF image needs to be converted to MOP format mopa.out. But the version of mopa.out in the mopd distribution does not support ELF32/ELF64 (it can also be used for Alpha binaries).
He discovered that the version of mopd that OpenBSD used to ship before it was removed from the tree was modified to work on ELF32 binaries. The ELF #ifdefs will not compile on FreeBSD. He fired up an old NetBSD 9 VM and fiddled with the source to get it to build. Eventually got a binary that worked on the /boot binary.
He placed the binary in the directory with the proper filename and noticed mopd was getting further, but then the VAX dumped back to firmware console halting on an exception.
He connected a NeXT SCSI CD-ROM unit to the VAX. The device would not enumerate in firmware SHOW SCSI.
4/22/26
We replaced the batteries behind the front panel with new ones from eBay. Hopefully the boot device configuration will stay now.
We connected a DEC RRD42-AA SCSI CDROM to the system, installed an Ultrix V4.5 CDROM, and tried to boot from the CDROM. After a pause of about a minute and some blinking lights on the CDROM, the VAX displayed an error message on the console. It is hard to say if the CD is bad or the CDROM drive is broken. More testing is needed.
CPU08 >>>show scsi
ADDR VMB DEVTYP DEVNAM NUMBYTS REV CHAR
5.0.0 DKA0 DISK 1588-15 667 MB AS0C
5.1.0 DKA100 RODISK CD-ROM ....... 4.3d RM
5.7 HOST SII-A
CPU08 >>>boot dka100
VMB V1.0
%VMB-F-ERR, PC = 000008EF
%VMB-I-STS, R0 = 000001A4
CPU08 ?06 HLT INST
CPU08 PC = 000010DE
CPU08 Failure.
CPU08 >>>
We tried with a Ultrix 4.3 CDROM and got a similar failure.
CPU08 >>>boot dka100
VMB V1.0
%VMB-F-ERR, PC = 000008EF
%VMB-I-STS, R0 = 000001A4
CPU08 ?06 HLT INST
CPU08 PC = 000010DE
CPU08 Failure.
CPU08 >>>
We tried a NetBSD 10.1 CDROM and got the same result.
CPU08 >>>boot dka100
VMB V1.0
%VMB-F-ERR, PC = 000008EF
%VMB-I-STS, R0 = 000001A4
CPU08 ?06 HLT INST
CPU08 PC = 000010DE
CPU08 Failure.
Using the command boot /R5:0 dka100 didn't change anything.
The nice people at the LSSM said that this would decode the CDROM status:
3_SERVER::$ exit %x1a4
%SYSTEM-F-MEDOFL, medium is offline
The Simh instructions for installing Ultrix say to copy the install image to a disk drive, and boot from the disk. Even though the installation media is referred to as a CDROM, it is not in ISO-9660 format and is really a UFS filesystem. So maybe copying the installation to a disk makes sense.
4/25/26
Dan-II copied the Ultrix CDROM install image onto SCSI disk, installed the disk into the 3540, When we booted from the SCSI disk it printed the Ultrix bootloader information, and the address in the Ultrix kernel that it jumped to, and then hung. Simulating the boot process with Simh showed exactly the same addresses and the Ultrix kernel banner, so we know that the bootloader is working correctly. Mike installed Ultrix on a Simh VAX 3900. That is the closest model to the 3540 because Simh doesn't emulate the 3540. We copied the installed disk image onto a SCSI disk and installed in the 3540. The behavior was the same as with the installation CDROM image.
During the week Mike will try booting a VAX 3100 and VAX 3500 from the installed SCSI disk. Maybe it will boot? If not, Mike will try booting from the Ultrix CDROM and running an installation.
DEC also sold a lobotomized VAX 3100 desktop system with an expansion chassis called an Infoserver. It booted a minimal operating system that allowed it to be a MOP boot server and file server. It could also share it's tape and CDROM drives over the network. You could boot a VAX with an empty disk over the network from the Infoserver using the MOP protocol, and then run an operating system installation. We could try MOP booting 3540 from the Ultrix installation CDROM from the Infoserver and then running the installation.
4/29/26
We disassembled the TK70 tape drive and manually unloaded the TK50 tape cartridge. The tape in the TK50 was bound up and the leader was disconnected from the tape. We used packing tape to tape the leader to the magnetic tape and reassembled the TK50 tape cartridge. This is really tricky to do because it is full of springs and spring loaded levers. We found that the tape drive guide rollers were not moving easily. We sprayed some WD-40 into the bearings and used an electric drill to spin the rollers. After a few minutes the rollers moved much more freely. The tape drive will now load and unload a tape cartridge.
5/2/26
A kind person donated caddys for our RRD40 CDROM drive. This drive was made before the standard caddy was invented so they are a little unusual looking.
We tried booting Ultrix-32 from the RRD40 and just get errors
CPU0B >>>boot dka200
VMB V1.0
%VMB-F-ERR, PC = 000008EF
%VMB-I-STS, R0 = 000001A4
CPU0B ?06 HLT INST
CPU0B PC = 000010DE
CPU0B Failure.
CPU0B >>>
This is the same SYSTEM-F-MEDOFL, medium is offline error that we saw with the other CDROM drives.
After some fiddling we got past the medium is offline error and now the write protect light goes on when it is writing the label on the tape,.
We connected a ViewSonic VGA monitor to the LEGSS RGB graphics boards. The monitor was able to do sync-on-green and displayed the diagnostic test patterns.
We have not found the part number for the keyboard/mouse/tablet cable. The pinout for the DB-15 connector on the system end of the cable is in the maintenance manual so we will make one.
5/5/26
Mike tried the SCSI disks that contained Ultrix and NetBSD on his VAXstation 3100 M38. NetBSD booted right away, but Ultrix hung just like on the 3540. Maybe we need to try to MOP booting the 3540 from a DEC InfoServer?
Dan-II built versions of the NetBSD loader and kernel that will display a lot more messages so we can get some idea of where in the boot process the the 3540 dies. We may have to write 3540 hardware support for NetBSD. That should be a fun project.
We tried the NetBSD 10.1 disk in a VAXstation 4000 VLC at the lab. It booted right up. It will be interesting to try booting Dan-II's instrumented kernel on the 3540 on Saturday.
5/9/26
We discussed why we don't see anything on the serial console from the NetBSD bootloader or the kernel. The 3540 has a 3D graphics board set installed, and has four serial ports on what looks like half of a DZ11. It is possible that NetBSD is writing messages to what it expects for a serial port, a DL11, or it is writing to the graphics console.
We removed the L2004 Graphics Base Board and tried to boot NetBSD from the RZ29B disk. We saw the same output as when the graphics board was installed.
CPU0B >>>show scsi
ADDR VMB DEVTYP DEVNAM NUMBYTS REV CHAR
----- ------ ------ ------- ------- ---- ----
5.0.0 DKA0 DISK RZ29B 4.29 GB 0016
5.7 HOST SII-A
CPU0B >>>boot dka0
VMB V1.0
-DKA0
..
...
At this point we don't know if VMB (Virtual Memory Boot) is actually loading the NetBSD bootloader, or the NetBSD kernel. Dan-II looked through the NetBSD bootloader code and found that support for the VAXstation 3540 was commented out. Maybe this code was untested or just didn't work? We convinced Dan-II to spend a little time on this project. He modified the bootloader and kernel to add support for the VAXstation 3540. He copied the updated bootloader and kernel onto the SCSI disk and we tried to boot it again. The results were the same.
It is possible that there is a problem with the serial console code and we are not seeing any of the boot messages.
5/13/26
We tried booting OpenBSD 5.8, the last version that supported the 3520 & 3540 from three different CDROMs. No luck on any of them even after cleaning the lenses.
Saturday we will get MOP booting working and see if we can determine why NetBSD doesn't display any messages when booting.
Hardware Notes
CPU0B >>>t 50
KA60 V1.1
MID MODTYPE ID SLOT ERR
0 01010001 L2008 9
1 01020310 L2007CA 8
2 01010108 L2001 7
3 01010108 L2001 6
4 01020110 L2007BA 5
5 01010004 L2003 4 ?
7 01010002 L2004 3 ??
CPU0B >>>t 5 4 100 0 1
ADDR VMB DEVTYP DEVNAM NUMBYTS REV CHAR
----- ------ ------ ------- ------- ---- ----
5.0.0 DKA0 DISK ST43400 2.91 GB 0103
VID: SEAGATE PID: ST43400N
ANSI = 2, ECMA = 0, ISO = 0, RSPDATFMT = 2
CPU0B >>>t 5 4 100 400 1
ADDR VMB DEVTYP DEVNAM NUMBYTS REV CHAR
----- ------ ------ ------- ------- ---- ----
5.4.0 DKA400 DISK 1588-15 667 MB AS0C
VID: MICROP PID: 1588-15MB1036511
ANSI = 1, ECMA = 0, ISO = 0, RSPDATFMT = 1
CPU0B >>>t 5 4 103 400
%SCSI-E-STS = 01510392
%SCSI-I-EXTSTS, USRMOD
CPU0B >>>t 5 4 103 400
%SCSI-E-STS = 01510392
%SCSI-I-EXTSTS, USRMOD
CPU0B >>>t 5 4 104 400 0
%SCSI-E-STS = 01510492
%SCSI-I-EXTSTS, USRMOD
CPU0B >>>t 5 4 106 400
%SCSI-S-STS = 00000601
CPU0B >>>t 5 4 108 400
BLKSIZ = 00000200
MAXBLK = 0013E5F3
%SCSI-S-STS = 00000801
CPU0B >>>t 5 4 10B 400
%SCSI-E-STS = 01510B92
%SCSI-I-EXTSTS, USRMOD
Page updated
Report abuse