ok here goes.
AT ALL TIMES keep in mind that
1)the n64 THINKS that both the top port, and the bottom EXT. port ARE THE SAME KIND OF medium, a cartridge. the two ports are IDENTICAL down to the pin number.
2)the N64, as soon as it starts reading EITHER port (top or bottom) loads the first available OS into memory.
ON THE DECK. the top port i shall call drive 1, the bottom (EXT.) drive 2. The n64 does a cold boot and starts reading from drive 1 (i dont know which pin though) and tries to load an OS.
1) the drive 1 has a cartridge, which loads it's own OS to manage the deck and I/O.
2) the drive 1 does not have a cartridge, the 64DD is not connected, and nothing happens
3) the drive 1 does not have a cartridge, the 64DD is connected.
-> deck goes on to read drive 2 (as if it were a cartridge) and tries to load OS.
->the OS this time, is the IPL4ROM (Initial Program Loader 4 ROM). This is, as many people know, the initial program loader, which is something that is also found in PCs (but u dont get to hear much about it). It acts somewhat as a driver. A set of instructions if u may in order to manage the drive and the I/O streams (or should I say bursts - the drive itself reads in bursts, but the connector is read like a cartridge).
-->IPL4ROM also includes the mario-runnin around menu, and a full set of fonts FOR ERROR DISPLAY ONLY.games must use THEIR OWN font set.
--->IPL4ROM has taken over the DECK with it's OS. Now, the top drive is forced to be "off" by default and has no primary stream. (that's why u can plug and unplug the capture cart.).
---->IF IPL4ROM determines that there is valid software in the drive, it will not show the mario menu and will start the game. Else it will show the mario menu.
----->While the mario menu is displayed, the drive is on "wait", and will start valid game code as soon as it is present.
4) The drive 1 does not have a cartridge, and a 64DD DEVKIT is connected.
->the 64DD devkit does not have the IPL4ROM (DDROM) inside it, so it must be loaded from the top drive, drive 1.
-->So, N64 deck boots, then reads drive 1, finds IPL4ROM, which instructs it on how to manage the Disk Drive, which is found in drive 2. The rest works exactly like the above description.
5) The drive 1 has a cartridge which supports 64DD "hooks" and the 64DD is attached.
->Gamepak loads its OS into memory WHICH ALSO INCLUDES a basic portion of IPL4ROM (without the mario menu code ofcourse). Thus the 64DD is not reckognized as "being present" in gamepaks that dont have the IPL4ROM code in their OS. This version of IPL4ROM differs however. It is designed to give a "slave" (in EIDE speach) status to the 64DD.
On a sidenote,the expansion pack is initiated (and can be used) as long as the gamepak's OS supports it. This support is also found in IPL4ROM. The Expansion pak also includes the JUMPER PAK circuit. (0, or no voltage = expansion pak circuit off, 1= expansion pak on) The gamepak's OS (or IPL4ROM in the case of the 64DD) is further responsible for the mapping of the extended memory.Gamepaks that include expansion pak detections but don't use it (pokemon stadium Gold/Silver) still "turn on" the expansion pak and map its memory.
All of the above have been a product of personal research and you won't find it in any manual (most of it at least). It is for this reason that I believe it would be interesting enough to be included in the articles section.
Hope this helps!
Barc0de Tech & Dev