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.
Interesting info, Dan8! Thanks for sharing! Based on the assembly I'm reading, I think the bits in the combo mask are read in reverse order, so 0x18 would mean that it's only enabled for combos 3 and 4. 0x78 means it's enabled for combos 1, 2, 3, and 4. From what I can tell, the AV Macs already default to a combo of 4, so this makes sense.
bbraun, were you testing your IIsi ROM with an actual IIsi, or an older Mac? It looks like the IIsi actually has a default combo of 4, so it should already be loading the netBOOT driver, unless I'm terribly mistaken. But the IIci (and presumably other older Macs) have a default combo of 1 or 2. IIci=1, IIfx=2, for example. So they wouldn't load the netBOOT driver unless their combo was changed in PRAM. Also, combo 4 appears to be "no FPU" but combo 3 means "FPU". If a Mac is listed as combo 4, but it has an FPU, it gets changed to combo 3 at boot.
It seems that ATBoot wants a very special type of disk image. The image buffer is called as a function several times in the boot process.
The prototype of it would look like OSErr image_code(short command, DGlobals *g, int **var1, int **var2). The command selector selector can take a value of getBootBlocks, getSysVol, or mountSysVol. Apparently var1 and var2 aren't used for anything.
The image code itself is responsible for copying boot blocks into a buffer in the globals passed to it (turns out I was wrong about that. ATBoot confused me). It has to prepare the system volume itself. The NetBoot driver gives control when an external file system _MountVol call is made to the NetBoot drive (NetBoot sets up a code hook. The condition is probably triggered while the boot blocks are being run). The image code is expected to replace the NetBoot driver by itself when this happens, as neither NetBoot nor ATBoot contain actual RAMDisk driver code. I'm not sure if it has to do anything else. I wouldn't be surprised if it did.
This is a crazy complicated piece of code and I believe we have no source or working examples of it. Did Apple ever use this NetBoot feature?