Since the Enhanced //e ROM has only $200 bytes available, a new “passive” boot protocol had to be devised. The new ROM code continuously monitors the network for a broadcast BOOTREQ control packet containing the load address and length of the immediately following boot code data. When the boot image has been correctly read from the network, control is passed to its starting address. This passive boot code only needs to read packets from the net, and so occupies just $190 bytes, which comfortably fits in place of the Enhanced //e ROM self-test code at $C600.
The new boot protocol capitalizes on the fact that boot code is sent as a broadcast transaction, so the machines being booted do not need IDs to receive boot code. A page of “second-stage boot” code is added at the front of the slave machine boot image. This code is given control immediately after the boot image is received, and, when enabled by the “GETID daisy chain”, it sends a GETID request to the machine that &BOOTed it, making use of the code in the full NadaNet boot image to do so (see the BOOT2 code in the NADA.CRATE listing for details).
The GETID daisy chain functions just as it did in the AppleCrate I. The “first” machine is permanently enabled by connecting its PB2 to ground. AN2 of each machine is connected to PB2 of the “next” machine. The second-stage boot code running in each machine initially sets its AN2. Then it waits until it sees its PB2 go low, enabling it to send its GETID request. When its GETID is successful it drops its AN2, enabling the next machine. Then it clears its video display, writes a banner showing the machine ID, and enters its server loop.