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 <[email protected]
<mailto:[email protected]>> 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: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
