[Simh] Install VAX/VMS 4.4 on a simulated VAX-11/780

[Johnny Billquist]

Clem, never found time to comment earlier, but a couple comments below 
as well. Both on your comments, and others.

On 2018-03-29 19:52, Clem Cole wrote:
> below...
> 
> On Thu, Mar 29, 2018 at 7:51 AM, Henk van de Kamer <simh at vandekamer.com 
> <mailto:simh at vandekamer.com>> wrote:
> 
>     Clem Cole schreef op 25-3-2018 om 23:23:
> 
>             A small suggestion...   while you can probably get the 780
>             to recognize and support a TU58, booting from it may be
>             difficult (I did not find it mentioned in any SDP or other doc).

I would say it's impossible. But see more below.

>     In another post I gave a link which suggested that it could be present.

Making assumptions on booting a VAX, based on how you boot a PDP-11 are 
not a good idea.

> ​Yeah, Mark has it in the simh configuration.  But be careful, there are 
> lots of the things you can do with the simulator that was never done in 
> real life.   Also there may be 'latent' support in the OS for some 
> things.  For instance, Tru64 will boot and operate just fine with an 
> Adaptec SCSI controller ​in it.   That actually the configuration I ran 
> in my office at DEC, but it is not official in the 'Software Product 
> Description' (/a.k.a./ SPD)  because it will screw up (in that case an 
> Adaptec can not support fail-over so it was only officially support on 
> Alpha/NT systems - but we ran engineering systems with them all the time).
> 
> So you need to check the SPD for the specific release.  That will tell 
> you what DEC tested and supported in the field.  Anything else, you are 
> in the ocean without a life preserver -- you can swim and you might be 
> safe, but don't bank on it either.

Right. And generally, unless people know pretty well what they are 
doing, and knows a lot of the implications, and how things work under 
the hood, they should not try and do things in ways that DEC didn't 
design it for back in the day.

A most typical example is what was done here. Trying to boot a machine 
looking like a VAX-11/780 from a TU58 just is *not* something people 
should do, unless they enjoys exploring what is going on under the hood.
It is not supported, was not possible on the real hardware, and no 
procedures would ever expect this kind of a scenario.

>             The 780 family has a dedicated PDP-11 with RX floppy drives
>             that runs as the 'front end' for it and boots it. The PDP-11
>             run an small OS RSX-11/S (I think - but man those bit in my
>             brain are long
>             lost) and can reach in the SMI to load the OS image into memory
>             from the disk and then points the system at it.
> 
> 
>     I searched what the TU58 exactly was and found [1]. They say it could be
>     used to bootstrap the RT-11 [2] operating system on a PDP-11. That seems
>     to be the one :-)
> 
> ​Could be - as I said, those bits in my brain have long ago rotted.  

Unless I remember wrong, the FE of the 11/780 does not even run RT-11. 
It runs a simple, dedicated system just playing frontend. Finding a site 
that explains how too boot RT-11 on a PDP-11 from a TU58 will, somewhat, 
explain the steps for how you boot a PDP-11 using a TU58 in general, but 
it has very little point when we talk about booting a VAX-11/780. Yes, 
there is a PDP-11 in the front end, but booting the VAX consists of more 
things than just getting the PDP-11 running.
It is just crazy to try and go with a TU58 if you have a VAX-11/780 
(simulated or not). The proper and correct media is RX01, and that does 
not become less try just because the machine is simulated. The RX01 and 
TU58 are not interchangeable, even though they fulfill the same purpose.

>   The 780 and the KL10 both had a PDP-11 spliced into them to boot them 
> up as a front end.   The system console (which was typically a 
> DECwritter-II) is connect to a DL-11 on the PDP-11.   When typing to 
> something on the main computer the local OS on the front-end reads the 
> uart on the DL-11 and passes the characters to/from the host.    I 
> thought I remembered that it was a modified RSX-11 called RSX-11S that 
> ran on the front-end, but I could be confusing with another application.

The 11/780 have a T11 as the front end. The KL10 uses a PDP-11/40, while 
the 8600 uses an F11. (Some other VAX models used a Professional, which 
was a PDP-11 in a PC format, which I'm you know, Clem.) Usually you 
actually had a DECwriter III, but that is just a nitpick.

The VAX-11/780, as I said, runs a rather dedicated system. I think that 
one RX01 is a bit too small to even have something close to a reasonable 
RT-11 system on it. Thus, if you want to run diagnostics from the FE, 
which I think is running in a more RT-11 like environment, you need to 
boot from a different RX01, and the system actually consists of several 
diskettes. But it's been so long since I touched an 11/780 that I might 
just misremember some details as well.
The KL10 front end (the PDP-11/40) actually runs something called 
RSX-20F, which is a kind of bastardized RSX-11D, with some bits of 
RSX-11M thrown in. It runs without any MMU, and is a bit familiar, but 
also a bit weird, if you know RSX. The 11/40 can boot from RX02, or a 
shared RP06 (shared with the KL10).
The F11 of the VAX 8600 runs normal RT-11, booting from an RL02.

The connection between the FE and the main CPU have some differences, 
but basically yes, the console communication works like you say. On the 
KL10, you normally have all serial terminals going through the FE, while 
on the VAXen, other serial lines are connected directly to the VAX cpu.

FE storage also usually runs through the PDP-11 on the VAXen, but on a 
KL10, FE storage is using a dual path disk, to which both CPUs have access.

> The key point for you is that the 780 when it turns on is a bunch of hot 
> rocks.   It needs to have its microcode loaded before it can do 
> anything, as its microcode is stored in ram, not rom.  The system 
> microcode lives on the floppy disk in the front-end​.   Once the 
> microcode is loaded, a vax bootstrap can begin.

I'm trying to remember if the microcode really was loaded from disk on 
the 11/780, but you might be right. For the 11/750 this is definitely 
not the case, and for the 8600 this definitely is the case. So it 
depends on the model.

> As a cost reduction on the 750, Dave Cane (HW design lead) developed it 
> without PDP-11 front-end (which was probably a marketing requirement).  
>   I've forgotten the complete sequence, since the 750 also had 
> microstore.  IIRC: the front panel on the 750 (and the 11/34 and few 
> other systems) is an microprocessor.   The 11/34 used a i8008.   I think 
> the 750 its was an i8085, but I do not remember.   I think one thing is 
> does is load the microcode, but that's stored in the micro's rom's not 
> on a floppy like the 780 and KL10.  But the microcode might be in ROM, I 
> just don't remember  (I'll ask Dave if he does next time I see him).

The 11/750 uses the 8085 as far as I can remember as well. (And so does 
the KS10 if I remember right.)
The microcode on the 11/750 however is in rom. So there is no need for 
any front end TU58 media in order to boot a VAX-11/750.
However, the 11/750 CPU have some ram for microcode as well, and the ram 
can overlay rom addresses, allowing you to patch the microcode of the 
CPU on the running system.
Both VMS and various Unixes does this, to fix some bugs in the 
microcode. NetBSD still ships the microcode patch in the distribution.
(http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/vax/stand/pcs/pcs750.bin.uue)

The booting then, of the 11/750 is done through boot roms that needs to 
be installed in the CPU. You can have four different boot roms 
installed, and you select which one to use through a rotary switch on 
the face of the 11/750. 11/750 booting is very primitive compared to the 
11/780. The boot rom have enough code to read in the first block from a 
device, and then jump in there, where booting continues. So the 11/750 
was an odd exception in the early VMS history in that it was the only 
machine that required a boot block. (Well, the 11/730 and 11/725 might 
be in that same group). All other early systems used VMB to boot VMS, 
and VMB was stored on the FE storage, and read into memory by the front 
end, and then started. VMB in turn understood the VMS file structure, 
and continued by setting up the system, reading in the OS image, and 
kicking off the rest of the boot procedure.

Booting the standalone backup could be done through VMB, if I remember 
right, but the front end also had a more straight forward way of just 
loeading VMB in and kicking it off, which is used when booting from the 
front end storage, which is how you got the initially bootstrapping off 
the ground on the machines.

MicroVAXen use a method much like the 11/750, and later larger VAXen 
usually have VMB in rom.

> The TU58 and the DECwriter might actually be directly connected to the 
> microprocessor, but again I've forgotten the details (look at the 
> prints), but there is some way they are available to the Vax directly, 
> which is a difference than the 780.

Yes, they are connected to the microprocessor. Diagnostics and things 
are done through there. But the microprocessor makes these devices 
available very transparently to the VAX as well. But are just on serial 
ports, so they are very simple. (Talking about the 11/750 here.)

The serial port as such is accessed the same way on both the 11/750 and 
11/780. There are some cpu internal registers that are architecture 
dependent, that implements the console. The FE have different registers, 
and different functions, if we talk about the TU58 on the 11/750 
compared to the RX01 of the 11/780.

> The point being that the TU58 driver in the host OS has to know how to 
> interface to the device.  Again IIRC, the HW design of the the TU58, as 
> you noted is an RS-232C serial device (basically predated the current 
> USB idea by about 25-30 years).

Right.

>     In another post the same was suggested. However I only found three TU58
>     tape files with the standalone backup 4.0.
> 
> However, I bet they that was only tested on a 750 and only on specific 
> configs as defined in the SPD.

They essentially have no chance of working on an 11/780. Even if you 
have a TU58 connected to a 11/780, it will not be connected in a way 
that would be compatible with how it is connected on an 11/750. So as 
soon as the code read in from the TU58 used for 11/750 bootstrap tries 
to access any more data from the TU58, it will be trying to talk to 
nonexistent CPU registers on the 11/780, unless the bootstrap code is 
clever enough to try and detect what hardware it is running on, and have 
provisions to work out where the storage is on some other model, which 
in itself is also a very complex thing to try and figure out.

> The trick if you are really trying to be period relevant is get a copy 
> of the SPD and make sure vax750.ini file you create is actually one that 
> defines hardware that was tested and released for that version of the OS.

Yup.

> Anything else, might work, but you could be running into a number of 
> ways that things are almost but not quite.

High chances that it won't even work, especially if you talk about the 
early stages like the initial booting, and the different devices.

> If you can find something like Will Senn's Installing and Using Research 
> Unix Version 7 In the SimH PDP-11/45 and 11/70 
> <https://drive.google.com/file/d/0B1_Jn6Hlzym-Zmx1TjR3TENDQTA/view> for 
> VMS and the 750 and 780, I think you'll find like Will did, that he 
> needed to have a tape.ini file (which is on page 4 of his document) that 
> was exactly what Ken and Dennis described in their release.   The same 
> will be true for the Vax and VMS.

One problem is that VMS was not intended, or designed to be bootable 
from tape back in the day. Later in life, this had to change, with the 
MicroVAXen with only TK50 for distribution. (But it is still not 
possible on the early machines. There you still need the standalone 
backup on a bootable media, which means RX01 for the VAX-11/78x, TU58 
for the VAX-11/750, VAX-11/730 and VAX-11/725, and an RL02 for the VAX86x0.)

Back when it was designed, it was always the case that you had some kind 
of mass storage of the front end, on which you already had standalone 
backup available, and you were always supposed to boot that, and then do 
a restore of the distribution tape. So any VMS tapes one might have, are 
not bootable!

This whole design also led to some pains for Unix, since there was no 
easy way to bootstrap Unix with the tools and ideas that DEC provided 
with the VAXen. Unix expected the machine to be able to boot from tape. 
So you can find old Unix manuals and documentations pertaining to 
bootstrapping and installation, which will explain how to boot from tape 
on the different VAXens, by depositing a bootstrap into memory by hand. 
I certainly typed it in multiple times for a VAX 8650 from the MtXinu 
manual back a long time ago.

> FWIW: If you are asking questions, please list as Will does, the foo.ini 
> files you are using at each step when you ask more questions.   Make it 
> clear exactly how you have configured things - I personally have not 
> been able to easily parse some of your messages.

Agreed. I also almost decided to just ignore the posts because of the 
problem understanding what was being done, not to mention trying to do 
things which more or less was obviously wrong anyway.

> If the bits you are using are not somehow corrupted, the system needs to 
> be configured as VMS expected it with only the HW devices and 
> versions/models of those devices that were supported by VMS at that time.

Yup.

And, having written all of this, I'm still wondering if I misremember 
and the 11/780 had an RX02, and not an RX01...?

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol