On 2013-05-17 21:08, Bob Armstrong wrote:
Unibus VAXen basically means VAX-11 machines.
They booted either from VMB on console media, or
(for the 11/750) from a boot block.
TO be fair, the limitation on booting was mostly just that nobody bothered
to implement support for any other device in VMB. It wasn't any kind of
hardware limitation.
True. As long as you actually even used VMB to boot, which only VMS did back then. VMB did eventually add the capability of booting Unix as well, but that was later. So Unix booted without VMB.
Also, the VAX-11/750 do not even use VMB...
Later versions of VMB (e.g. in a MicroVAX) could boot directly from
various tape devices.
Right.
Really? Not from tape? Interesting design choice...
Old VAXes booted standalone BACKUP from the console media (TU58 or RX01).
SA BACKUP then could talk to tape drives just fine. It's all you need to
install VMS, so that was all they did.
Yes. And of course, nobody ever wanted to boot anything but VMS... ;-)
Johnny
On 2013-05-17 21:00, Cory Smelosky wrote:
On Fri, 17 May 2013, Johnny Billquist wrote:
Unibus VAXen basically means VAX-11 machines. They booted either from
VMB on console media, or (for the 11/750) from a boot block. No network
capabilities there. They could not even boot from tape.
Johnny
Really? Not from tape? Interesting design choice...
That's one way of putting it. Another would be "annoying".
Yeah. VMS distribution did come on tape, but you also got a floppy or TU58 from which you booted the standalone backup on the VAX, and then did the installation using that.
Now, if you instead wanted to install something like Unix from a tape, you had to enter an initial bootstrap by hand into memory. At least the MtXinu distribution actually have the bootstrap codes for all VAX-11 systems listed in the manual.
(Quite helpful when I was installing 4.3 Reno from tape, as it turned out those bootstraps worked for my Reno tape as well, on an VAX 8650.)
Johnny
Unibus VAXen basically means VAX-11 machines.
They booted either from VMB on console media, or
(for the 11/750) from a boot block.
TO be fair, the limitation on booting was mostly just that nobody bothered
to implement support for any other device in VMB. It wasn't any kind of
hardware limitation.
Later versions of VMB (e.g. in a MicroVAX) could boot directly from
various tape devices.
Really? Not from tape? Interesting design choice...
Old VAXes booted standalone BACKUP from the console media (TU58 or RX01).
SA BACKUP then could talk to tape drives just fine. It's all you need to
install VMS, so that was all they did.
Bob
On Fri, 17 May 2013, Johnny Billquist wrote:
On 2013-05-17 19:18, Cory Smelosky wrote:
On Fri, 17 May 2013, Bob Armstrong wrote:
John Wilson wrote:
this is a ridiculous security risk
so that's why MOP had a magic number
Yep, even the DMR has a boot "password", which is just an 8 bit value
set
by dip switches on the board, that has to match up with the MOP message.
They DMA a small program into memory
Ah, I was wondering about that, because there aren't any separate boot
ROMs on the DEUNA. I bet the "small program" is just part of the T11
code.
And I'm assuming that this scheme didn't work on any UNIBUS VAXes - only
PDPs.
I'd assume so as well. On a semi-related note, wasn't it not possible
to netboot a UNIBUS VAX with a DEUNA? I seem to recall that from the
manual. It required an intermediate bootloader or something, right?
Unibus VAXen basically means VAX-11 machines. They booted either from
VMB on console media, or (for the 11/750) from a boot block. No network
capabilities there. They could not even boot from tape.
Johnny
Really? Not from tape? Interesting design choice...
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
On 2013-05-17 20:51, Clem Cole wrote:
On Fri, May 17, 2013 at 1:57 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
Unibus VAXen basically means VAX-11 machines. They booted either
from VMB on console media, or (for the 11/750) from a boot block. No
network capabilities there. They could not even boot from tape.
Amen, and seemingly hard to believe. It seems so primitive by today's
standards. But it actually makes sense. Disks in those days were a
huge expense within the total system price, but definitely part of it.
A system in the Vax class really needed to be self-supporting. So the
concept of it not have local storage would have been strange and frankly
not able to be sold.
Let's also not forget that in those days Ethernet HW was not
particularly cheap either. The 3Com stinger taps cost about $500 each,
and that did not include the $~2-3K for the 3Cxxx for the Unibus.
Well, in all honesty. We did just cover network booted PDP-11s. Not to mention that PDP-11s could boot from tape pretty much from day 1.
On the other hand, VAXen (as well as PDP-11) came out on the market before Ethernet existed.
However, later VAXen definitely supported network booting, as well as totally being diskless. But those were not using the Unibus. :-)
Johnny
On Fri, May 17, 2013 at 1:57 PM, Johnny Billquist <bqt at softjar.se> wrote:
Unibus VAXen basically means VAX-11 machines. They booted either from VMB on console media, or (for the 11/750) from a boot block. No network capabilities there. They could not even boot from tape.
Amen, and seemingly hard to believe. It seems so primitive by today's standards. But it actually makes sense. Disks in those days were a huge expense within the total system price, but definitely part of it. A system in the Vax class really needed to be self-supporting. So the concept of it not have local storage would have been strange and frankly not able to be sold.
Let's also not forget that in those days Ethernet HW was not particularly cheap either. The 3Com stinger taps cost about $500 each, and that did not include the $~2-3K for the 3Cxxx for the Unibus.
I remember when Apollo announced the "Twins" machines were 2 nodes with a shared single disk in ~1984/85 - which actually did work reasonably well. Sun did the "diskless" Sun-3 in response, and they did not. I do not think DEC even tried.
The funny part is that Sun's answer was an accidental marketing genius - because it became the worlds best add in disk upgrade business for them (diskless Sun's were known as having the lack of male anatomy).
I was leading the networking group at Masscomp at the time, and my team refused to do diskless support - because thought it was a stupid product (there is a infamous email I sent to all of the company with a dyslexic typo in it - which I wish I still had). I was technically 100% right. A WS-500 cost $1.5K less that and equivalent Sun 3. But, end users could buy a diskless Sun3 for $2K less than the WS-500. -- only to discover the performance sucked. So would have to go back to Sun at $5K a crack to get the disk subsystem.
The genius was the sales got the original sale, and you wer not going to through out the Sun3 and get the cheaper system. You would spend the $5K later and make it better - sigh.
Clem
On 2013-05-17 19:18, Cory Smelosky wrote:
On Fri, 17 May 2013, Bob Armstrong wrote:
John Wilson wrote:
this is a ridiculous security risk
so that's why MOP had a magic number
Yep, even the DMR has a boot "password", which is just an 8 bit value
set
by dip switches on the board, that has to match up with the MOP message.
They DMA a small program into memory
Ah, I was wondering about that, because there aren't any separate boot
ROMs on the DEUNA. I bet the "small program" is just part of the T11
code.
And I'm assuming that this scheme didn't work on any UNIBUS VAXes - only
PDPs.
I'd assume so as well. On a semi-related note, wasn't it not possible
to netboot a UNIBUS VAX with a DEUNA? I seem to recall that from the
manual. It required an intermediate bootloader or something, right?
Unibus VAXen basically means VAX-11 machines. They booted either from VMB on console media, or (for the 11/750) from a boot block. No network capabilities there. They could not even boot from tape.
Johnny
On 2013-05-17 19:05, Bob Armstrong wrote:
Johnny Billquist wrote:
"A Trigger Instruction (remote console request to boot) can
be executed if the local host system contains the appropriate
BOOT ROM for loading the boot code from the DELQA module."
Sounds like they're saying that the DELQA just does a BINIT and then it's
up to the boot ROM to figure out what happens after that.
Read through more stuff, and apart from the fact that the DELQA also provide boot code for the PDP-11 (albeit in a different way than the Unibus ones), it actually pulls the BDCOK, to it simulates a power fail.
And then the host is supposed to request the DELQA to dump the boot code into memory, and then jump into it by itself.
Johnny
From: "Bob Armstrong" <bob at jfcl.com>
You missed my point - the issue was not "where does the small program
execute from", it was "where is the code for the boot program stored
(permanently) before it gets DMAed into the host".
[misunderstanding since resolved]
Also when they say small they mean *small*! IIRC it just loads a few
vectors, sets a variable or two, and then does a branch-self, so it's just a
few words. The *actual* boot code comes from SECUNA.SYS/SECLUA.SYS (secondary
bootstrap in T11/68K code) and TERUNA.SYS/TERLUA.SYS (tertiary boot in PDP-11
code).
The DEQNA was such a mistake. Why DEC would break from eons of tradition and
make the Q and U versions of something be not in the slightest compatible is
beyond me. Apparently fitting on a dual-height card was more important.
I think it does have a CPU (i8051?) but its ROM is mostly full of the PDP-11
boot/diag code (since the boot is way too big to fit in a typical PDP-11
boot PROM so all that does is suck the real boot out of the 8051). So they
didn't have space for doing MOP in firmware.
There's a *fantastic* writeup on how to call the QNA/LQA boot/diag PROM in
the RSTS source code (I think it's basically the entire relevant part of some
internal manual, pasted into a .REM block).
To be clear: the UNA/LUA actually yanks AC LO L, which *causes* INIT L to
be pulled but also makes the CPU jump through the vector that's just been
reloaded.
I agree that the purpose of all this must surely be to remotely revive
crashed systems, which won't be useful with emulators if it's actually the
emulator and/or host system that's crashed (but *will* work if the crash
was in PDP-11 code). But it's too much fun not to do anyway! I had a
blast getting it working in E11 even though I can't imagine one single person
besides me has used it. But that's not the point! Also if the system was
booted manually, then what it reboots automatically might not be the same,
so you wave a magic wand and a computer in the other room will switch from
RSTS to RSX, in an entirely PDP-11-y way (not like you just telneted into
the most machine and told *it* to reboot the emulator). Or whatever.
I would think the other emulators support Ethernet booting too, but if
any of them don't, I'd be happy to contribute my reimplementation of the
QNA/LQA boot/diag ROM code (with MACRO-11 source).
John Wilson
D Bit
Dave McGuire wrote:
On 05/17/2013 04:32 AM, Oleg Safiullin wrote:
I bet you wouldn't have trouble cooling a real PDP-11 in a Russian winter. ;)
Some PDP-11's are smaller and cooler than PC's :)
http://pdp-11.org.ru/~form/files/pics/1183/1183-d.jpg
That's a great "hacking around" setup! Very nice!
There're other pictures at http://pdp-11.org.ru/~form/files/pics/1183/ -- the history of my 11/83 :)