I haven't done much disassembling of these beyond the initial entry points, it was mostly intended as a starting point for you to take a look. 
However, DRVRs shouldn't be branching directly to stuff outside themselves. They'll use A-Traps and reference low memory globals, but that's more or less it. The A-Traps here will typically show up as an undisassembled data constant, although if you include the trap_names file from one of the ROM disassemblies on the FDisasm site, FDisasm will correctly display what A-Trap is being called. Including the abs_names file will do the same thing for low memory globals.
The caveat to calling out to another resource is a driver can load another resource using GetResource or similar (it'll show up as an A-Trap, if you include that file), then once loaded, start executing it. The .netBOOT driver does this, it loads the .ATBOOT DRVR resource, installs the driver, then opens it.
However, DRVRs shouldn't be branching directly to stuff outside themselves. They'll use A-Traps and reference low memory globals, but that's more or less it. The A-Traps here will typically show up as an undisassembled data constant, although if you include the trap_names file from one of the ROM disassemblies on the FDisasm site, FDisasm will correctly display what A-Trap is being called. Including the abs_names file will do the same thing for low memory globals.The caveat to calling out to another resource is a driver can load another resource using GetResource or similar (it'll show up as an A-Trap, if you include that file), then once loaded, start executing it. The .netBOOT driver does this, it loads the .ATBOOT DRVR resource, installs the driver, then opens it.