There are netBOOT and ATBOOT device drivers in most 68k mac ROMs from the IIsi and up. There is even a mention to network booting in the IIsi dev notes.
I've been unable to find much information about these drivers online, so have been working on figuring out out how they work.
The progress so far is a small tool to set PRAM values sufficient to activate the driver at boot and cause it to send out a boot request with an unknown DDP protocol type. nbpram0.1.cpt.hqx
When the machine reboots after the tool has been run and the PRAM values are set, the screen will show a blank disk icon (similar to the flashing question mark disk, without the question mark), it will then send out some zone information requests, then do an NBP lookup for the server, and if it gets a response, send that server a request with DDP protocol 0x0a.
Here are some of my notes about what is going on:
The .netBOOT driver will be installed and opened if bit 0x80 is set in the byte located in offset 7 of PRAM.
If this flag is not set, the driver will not be opened.
If cmd-opt-n-b are held down, the driver will be opened, then the 0x80 flag above will be cleared, apparently to prevent subsequent netboots.
Holding down the control key will bypass netboot and continue normal booting, leaving PRAM state as is.
The netboot driver will then create a drive queue element that the system will later try to boot off.
When the system tries to boot off this "drive", the netBOOT driver gets a read/Prime call, which will check the protocol byte stored in PRAM and if set to 1, will load and synchronously open the .ATBOOT driver.
The .ATBOOT driver will then load and open the appletalk driver (.MPP).
Once the .netBOOT's synchronous open of the .ATBOOT driver returns back to the .netBOOT's read/Prime call, it will issue a Control call to the .ATBOOT driver with csCode 1,
The .ATBOOT Control call will then query for a server to boot from. The server queried for is determined by a 16bit server id number, which is then translated to an ascii encoded hex representation of the short. Except the ascii sting is backwards (not byteswpped). So, a server id of 0xEBAB will be translated into a server name of "BABE". The appletalk Service type used is "BootServer". So, "BABE:BootServer".
If something on the network responds to that NBP lookup request, it then sends the responding server a DDP packet of protocol 0x0A. This packet contains the machineID and the username, both stored in PRAM.
To clarify, I did the test below on a 660av.
Investigating some more on the IIsi ROM, the .netBOOT driver is not actually enabled. To explain what that means, here is the ROM code to load the .netBOOT driver:
Essentially this code is trying to GetNamedResource('DRVR', "\p.netBOOT"), and if that succeeds, open the .netBOOT driver. This is actually not necessary, since _Open will fail if the driver doesn't exist, and we're not actually caring about the return value of _Open anyway.
But, that doesn't explain why it is disabled. It is disabled because there are flags associated with each ROM resource, and one of them tells the ResourceManager to ignore the resource.
The Resources in the ROM are structured like this:
Offset 0x1A in the ROM is an offset to resource information:
1A 0007 EC10 DC.L $0007EC10 ; offset to resources
At this location is an offset (from the beginning of ROM) to the first resource:
7EC10 0007 EB90 0408 DC.B ' '
This (0x7EB90) is the first resource in a list of resources in the ROM:
I've started on a netBOOT server, using netatalk. There's not much to it at the moment, but I've got a valid reply being sent back to the Mac after its initial query. Since that's all I've got, it's not terribly exciting, since it just sits and retries.
When a valid response is received, the screen changes to show a blank mac:
I'm now sending the Disk Tools disk image, which I don't currently know if that's in a format the netboot driver wants, it's just something to try.
It's not booting the file, but there is a cute progress indicator. The blank Mac icon above gets filled in with eyes, nose, and mouth as pieces of the netboot image are received. Attached is a little video of the boot process so far.
Yeah, I've seen it. It's helpful. But the netboot driver is disabled (its resource entry has an "ignore" bit set) in all pre-AV ROMs, so you'd need the custom ROM to use it anyway. It would probably be easier to implement a different netboot driver.
I've implemented a driver that copies a file from an AFP server into ROM and treats it like a ramdisk, but appletalk isn't actually initialized in ROM prior to OS boot. This netboot driver has code to enable it, which would be a useful starting point to doing it myself, but it is rather involved.
Anyway, it would be nice to have a working netboot server and bits it can boot, but the TODO backlog is long, and this isn't near the top.
I spent a fair amount of time poking at this as well, and was greatly pleased to find this thread. I never go around to writing a server for it either, but I do remember finding the source and noting a "command-option-N-B" keyboard combination that was supposed to do something at boot time. Also never got around to trying this. I'd be interested to read if you'd made any progress lately.