Quote:
Originally Posted by Daedalus
Hmmm, interesting. My understanding was that it would override the ROM, provided that driver wasn't already in use (i.e., a storage drive with a volume mounted), but it is a long time since I've looked into that end of things. I must look at this again...
|
BindDrivers skips configdevs that don't have cd_Flags CDB_CONFIGME bit set (="I don't have driver yet"). Expansion.library always sets it. ROM driver normally clears it. If autoboot is disabled, BindDrivers loaded driver clears it (if matching driver was found).
Quote:
|
From what I can tell, it depends on the intention of the driver. If it is to execute code (e.g. to patch something in Kickstart) as opposed to simply presenting a DOS node, then it will present itself as a diag module, which is copied to RAM and executed.
|
More practical reason:
Part of ROM is always copied to RAM (Expansion.library checks DiagArea to find size and type of ROM) but reason why driver part of ROM is copied is very simple: ROM needs to be at least 16-bit wide to be executable, most boards use single 8-bit ROM (A590/A2091 uses 2x8 = rom is executable) and define only small DiagArea (with nybble wide size because of KS 1.3 byte-wide expansion bug), tiny "loader" code allocates memory, copies rest of ROM to RAM, using byte copy (to save ROM space, nybble wide would waste half of ROM). This also explains why nearly all 8-bit autoconfig ROM dumps have corrupt looking data at the beginning (nybble-wide part) with the rest of ROM looking normal. (clear ascii text, m68k code)