Saturday, September 18, 2021

VAXstation 1 Software Install - Part 1 - downline loading

   So I have a bunch of old QBUS boards kicking around here, including cards for  an old VAXstation 1. I figured, it's old and slow enough to be an interesting retro machine. I could run VMS 4.7 on it and use VWS (VAX Workstation Software). I always liked it better than DECwindows (DECwindows has the dread stench of UNIX-think all over it), and I liked the spinning cube idle time VWS demo program it came with. I decided to assemble the cards into a system.

  I had an unused BA23 to house it in. I stuck the two MV I CPU cards in it, along with a 2 MB QBUS memory card. So far so good. Now, I needed a disk controller. I had a bunch of RQDX3s to choose from, since I have been buying them to get the  T11 processor chips on them, for other projects  I put in one that I hadn't harvested the T11 from yet. I connected it to an RD32 disk - it'll be tight on space, but good enough for testing. Next I put in an old DEQNA card. I picked a DEQNA instead of a DELQA, because DEQNAs are so richly hated - it will add  to the retro-funk theme. VMS 4.7 still supported DEQNAs, so no problem there I have a QVSS card I'll install later, to turn it into a Vaxstation, after I get it running as a MicroVAX first

  Heck, I thought, I'm damn near finished - now to install some software and we'll be on the air. Man, did I get a wrong number there. I did what I usually do when I want to install VMS on a small system - tried to boot it as a satellite into a cluster.. That way I can just BACKUP/IMAGE a system image to the local satellite disk and Viola! - done. Not gonna happen this time. Turns out that MicroVAX I's were never supported as Ethernet cluster members. The cluster satellite image loads and then fails , with an unsupported CPU error message. I ZAP'ed out the CPU type check in NISCS_LOAD.EXE, the cluster load image, (sometimes things are unsupported for other-than-technical reasons, so I figured I'd try bypassing that check), but, no joy there - it gets a few steps further and then fails with some pretty legit technical sounding CPU related error messages. 

  Well, that was discouraging. But, here at Gleason's Garage, we're no strangers to hard work and disappointment - I'll just have to install it from tape, I figured. I installed a TK50 drive and controller into the system, and started trying to boot standalone backup, as a prelude to restoring a system image...to my surprise, it turns out that MicroVAX 1s don't support booting from tape! Yikes! What next?

  At this point the situation has progressed beyond retro funk, to a true pain in the sitz-platz. At this point, you are starting to think that I should research things a little more thoroughly  before I start a project, but it's way too late in my computer career to start doing that. I didn't want to spend time juggling around multiple hard drives to and from this  thing to boot STABACKUP and load VMS from. I also didn't have an RX50 distribution of VMS 4.7 handy, nor did I have the inclination to feed this thing floppies for a day or two while doing an install. 

  I almost dumped the whole idea - I could always build another 11/73 system in this cabinet instead. After all, there's no such thing as too many RSX systems. But I've been doing a lot of PDP11 projects these last few years, and I wanted to do a little more VAX work. I recalled a MultiTasker article from many decades ago. The article was discussing a similar situation, where a couple of guys needed to install RSX on a system without a tape drive or a floppy drive. One of them jokingly said they should write a standalone, no OS program to access the network card and the disk drive, that would download and write an OS to the disk. They could load this program via ODT. In the article, they had a nice chuckle about the idea and then went off to borrow a tape drive from somewhere. Clearly, it was a crazy idea. But was it crazy enough to work? I decided to give it a try - I'm retired, so I have unlimited time to waste....

  A look at the architecture manual for the MicroVAX 1 (EK-KD32A-TD-002), and VAX/VMS Internals and Data Structures by Lawrence Kenah and Ruth Goldenberg (the best book I've ever read - it's right up there with Methuselah's Children) showed that it's possible to do a lot with any VAX, without turning on virtual addressing. This project isn't big and complicated enough to need virtual addressing - and I had no desire to write a complete virtual operating system. This really simplifies things - I can just treat it like a 32 bit PDP11 with a funny instruction set and a flat 22 bit address space

  To make a long story short (I know - too late for that already), I got it to work. It will load a local RD54 on the MicroVAX 1 from another VAX on the network in around an  hour. Using a serial port to do it would be 10 times or more than that. The program that does it is too long to explain in detail, but I'd like to cover some of the things I learned along the way. Here's part I - how to downline load your code to a MicroVAX 1 (although in  general, the techniques described will work on any VAX that supports loading over the network.

  I had a look at NISCS_LOAD.EXE - the program that downline loads to boot a satellite system into a cluster. ANALYZE/IMAGE shows it to be linked as 

  /map/notrace/nodeb/system=0/header


  So I wrote a little program that only contained a halt instruction...no .entry mask or transfer address needed - it's a system image.


    .psect    $code,con,rel,novec,rd,nowrt,exe,pic,shr,long

    halt

    .end

  Assembled it...

$mac halttest

   Linked it

$ link/map/notrace/nodeb/system=0/header halttest

  And set it as the load file for the DECnet entry for the node that got created when I tried to boot it as a satellite cluster member

$ mcr ncp set node negato load file dua0:[mvax1]halttest.exe
$ mcr ncp sho node negato char

Node Volatile Characteristics as of 18-SEP-2021 10:01:36

Remote node =   10.103 (NEGATO)

Hardware address         = 08-00-2B-26-2F-84
Load file                = DUA0:[MVAX1]HALTTEST.EXE

I powered on the MicroVAX 1, halted it before it tried the disk, and typed...

>>>B XQA0

  It responded

ATTEMPTING BOOTSTRAP

  On the load host console, I got the typical load request messages

%%%%%%%%%%%  OPCOM  18-SEP-2021 09:29:24.50  %%%%%%%%%%%
Message from user DECNET on UNDEAD
DECnet event 0.3, automatic line service
From node 10.1 (UNDEAD), 18-SEP-2021 09:29:24.50
Circuit QNA-0, Load, Requested, Node = 10.103 (NEGATO)
File = DUA0:[MVAX1]HALTTEST.EXE, Operating system, Ethernet address = 08-00-2B-26-2F-84

%%%%%%%%%%%  OPCOM  18-SEP-2021 09:29:29.50  %%%%%%%%%%%
Message from user DECNET on UNDEAD
DECnet event 0.3, automatic line service
From node 10.1 (UNDEAD), 18-SEP-2021 09:29:24.51
Circuit QNA-0, Load, Successful, Node = 10.103 (NEGATO)
File = DUA0:[MVAX1]HALTTEST.EXE, Operating system, Ethernet address = 08-00-2B-26-2F-84


 The MicroVAX then printed this

00007001 06
>>>

  Which was good - when a MicroVAX 1 halts due to a HALT instruction, it prints the PC and 06, which is the code for, halted due to halt instruction. So it's success. Pretty much, more or less. It's odd that it halted at 00007001, instead of 0000001. More testing showed that even though the programs are assembled and linked at address 0, they load at address 7000 on the MicroVAX - dunno why. I couldn't puzzle out how to change that. It's no enormous problem - it just meant that I'd have to write all of the code for this as Position Independent Code - aka PIC. It's not the hardest thing in the world to do. It's actually a trivial matter on PDP11s. On the VAX, it's a little trickier, due to all the addressing modes that can use the assembly time value of a label. You just need to keep aware of the relocation when you deal with addresses.

  Alright - I can now download a program that does...nothing...and then halts. Next post will be part 2..communicating with the console.



  

No comments:

Post a Comment

Comments?