DaMi1 wrote:
During playing with Deneb's flash rom, I found out I have several duplicities in a list of resident romtags. Although I empty Deneb's flash rom, Scout still shows several duplicities. Can anybody please explain why? Or are they not duplicities? :-)
It's been a long time since I touched these things in detail, so please don't beat me to death if this wrong or twisted: There are two lists: the ResModules and the KickPtr with optional KickMem list (highlighted in Scout). The first one is initially generated by exec by scanning the Rom contents, the second one contains additional RomTags that may or may not be used to insert or replace modules into the list of ResModules depending on its version number. The ResModules are those that are used during startup of the machine. If the rom module is replaced or added due to higher version (or non-existence), you will find it in the ResModules list (not highlighted in Scout) as a duplicate (with the same address, as for most RomTags in your screenshot). If it not used, it will not show up in the ResModules (as with the NoIDE tag, probably due to higher version number of the scsi.device patched in by SetPatch over the NoIDE romtag you installed).
Depending on which boot loader your using (permanent or standard), the RomTags from the Deneb will either go into the ResModules list directly every time you boot (standard) or be added to the KickTagPtr and KickMemPtr once (permanent).
The only exception are RomTags that need to be added very early during the boot, such as exec.library updates or anything that's before diag init (bootloader code from Zorro II AutoConfig), which will always be added to KickTagPtr and then reset the machine to make it become effective by the standard exec mechanism that builds up the ResModules list.
