Re: Can you MOP boot an install kernel directly?

[Paul Koning <paulkoning%comcast.net@localhost>]

> On Aug 4, 2025, at 5:42 PM, Johnny Billquist <bqt%softjar.se@localhost> wrote:
> 
> On 2025-08-04 17:08, Paul Koning wrote:
>>> On Aug 4, 2025, at 10:45 AM, Johnny Billquist <bqt%softjar.se@localhost>wrote:
>>> 
>>> I'll just top-post to be lazy.
>>> 
>>> First of all, as you know, MOP is the "native" way to netboot DEC machines from back in the day. And MOP sortof fills the place of both DHCP and TFTP in one. But it's more targeted for the explicit need of netbootingand remote management. But in a sense, for VAXen, it would be great if we had the possibility of getting all the netbooting though MOP and not need DHCP and TFTP. Not sure if that is possible, though.
>>> 
>>> I guess MOP didn't really become that relevant with VAXen until the uVAX II (that one was able to netboot, right?). There were net-bootable PDP-11 systems as well, which also used MOP, and which were earlier. But pretty much all the handling of MOP on those machines were actually located in the ethernet controller itself. The CPU was pretty much just in a tight loop until the controller brought it out of there. But that was primarily for the PDP-11. On VAXen, MOP was implemented in the boot monitors. Not sure you can even use the MOP in the controller itself if you're on a VAX.
>>> But so, for simh, the controllers do implement at least parts of the MOP on that side. For VAXen, with something like the 3900, the boot roms from the actual machine are included, if I remember right, and so MOP booting will definitely work there no matter what else simh might do.
>>> 
>>> Johnny
>> I don't think that's entirely accurate.  From the Ethernet device pointof view, MOP packets are just packets, it doesn't know or care what theymean.  (Well, with the exception of the "trigger" packet, for that to besupported requires the device to check for it and yank on the reset lineif one is seen.  Not clear if VAXen ever did this, but I think PDP11s can do this at least with a DEUNA.)
> 
> It does depend on the controller, but what I wrote is not disagreeing with what you say. But the fact is that MOP in the DEUNA, DELUA and DELQA are implemented (in parts) in the controller itself. The host machine (PDP-11) does not talk MOP at all during boot. It just goes into a state where it waits for the controller to break it out of its wait.
> 
> If you want to boot from the boot monitor, you do need boot roms for that to be possible, but if you remote trigger a boot (something MOP can do), then your machine don't even need any boot roms for it to happen.

That's interesting.  I always thought of trigger as something that just yanks ACLO (as you mentioned) and lets the boot ROM do the loading, with the Ethernet NIC as just the device that the ROM code talks to.  Having the job in the controller obviously works too, but I wonder why it would be done that way.

The DMC MOP boot, as far as I know, is in boot ROMs, I remember the M-whatever model variant listing for that.

> It is documented in some parts in the RSX DECnet manuals, and also the manuals for the different controllers. And as far as I know, the only MOP bootable PDP-11 system from DEC is/was RSX-11S.

I know of another: the VT71 typeset system editing terminal.  It uses an LSI-11 driving a custom text-only display processor, and talks to the host via a 9600 baud serial link.  Not RSX based, it's just home grown bare metal code.

Possibly it applies to the VT20 also, the predecessor of the VT71; that uses an 11/05 processor to control two display/keyboard pairs that look a lot like VT05 terminals.  I've only seen one once, never used it, don't know anything further about it.  

There are photos on Bitsavers, and I think the full manual for the VT71 hardware is there also.  Too bad Typeset-11 seems to be lost, it would be fun to bring it back to life.  A really slick editing system, and a DMC-11 based network with routing that predates DECnet Phase III (it uses essentially the same routing algorithm, but the protocols above the data link layer and the code are entirely unrelated).

	paul