<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 05-Sep-18 06:16, Mark Pizzolato
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:03006E3FC39B5A48AB9DBCCC101090A8344A084C98@REDROOF2.alohasunset.com">And
      it would bring us closer to being able to handle PDP-11 host and
      <blockquote type="cite">
        <pre wrap="">network boot.
</pre>
      </blockquote>
      <pre wrap="">
A ROM could be used to network boot a PDP11 just as it could be used to
boot from a disk.  The network (XQ) and all disks are already bootable in 
the PDP11 simulator with the per device boot mechanisms.
</pre>
    </blockquote>
    You're describing client-initiated boot - e.g. sim>b XQ.<br>
    <br>
    I mean host (network)-initiated boot (and dump), initiated by
    receipt of an ENTER MOP message with the correct password.  As in
    the DMC/DMR remote boot - see section 3.5.4.2 and the flow chart on
    p 3-32 of the DMR11 UG, appendix E of the DMR technical manual, and
    the M9301/M9312 technical manuals.<br>
    <br>
    The DEUNA/DEQNA use the same mechanism to support remote and
    power-up boot, although they also contain additional ROM.  <br>
    <br>
    This is not currently supported.  The non-network (host only) case
    is similar.<br>
    <br>
    For -10 comm front ends, a bit in the -10 interface (DL10 or DTE20)
    causes the M93xx (or other) ROM to assert AC LO on the Unibus,
    allowing the host to gain control of the -11 for load or dump.<br>
    <br>
    Any emulation of these (and there's been recent discussion of it)
    would need an equivalent mechanism.<br>
    <br>
    If a ROM device emulation provided an API for this feature, that
    cause would be advanced.  <br>
    <br>
    There are two parts to making it work: <br>
    <br>
    Adding an API in the CPU of the form assert_powerfail( vector) -
    where the default is the usual 24/26, but a ROM can specify an
    alternate (usually its base address + 24/26).    This is common to
    all initiators.<br>
    <br>
    Getting the ROM, host interface, or network device to call it (or
    expose a suitable API) to gain control of the CPU.  This varies by
    device.<br>
    <br>
    For the -11, the existing boot snippets could be migrated to set the
    switches & use the "real" ROMs, though as you point out, this is
    not necessary.  Originally, it seemed simpler to extract (or
    recreate) small fragments from the boot ROMs than to find emulate
    all the ROM variants.  But SimH & its community has grown, and
    with current demands, moving to a more faithful emulation would be
    appropriate.  There's no rush - it can evolve.  But if the GT40 (and
    somewhere on my list, ANF-10 network, plus the attempts at KA/KI/KL)
    emulation provide the mechanism, in the long run it would be a
    better emulation.<br>
    <br>
    For the KS10, the hardware works differently - and calling
    assert_powerfail() would be an error that traps to the simh>
    prompt.<br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>