Just improved the settings file and configuration layout a bit.
Now all hardware-specific settings (which directly affect the emulated hardware instead of output/input) have their settings moved to the architecture-specific CMOS section.
So that means that different architectures now have the older common hardware settings (video settings, audio settings, modem settings and BIOS ROM mode) automatically transferred into the new fields on the different sections for the architectures on load.
So that allows for the user to select different hardware configurations between different architectures (like say a plain accurate IBM XT video and audio on a XT, slightly more modern hardware on AT/Compaq and the latest blazing supported hardware on the newer architectures), with each architecture keeping track of it's own installed hardware.
All of course fully customizable like they already were, but now the settings have been seperated for each architecture instead of using the same settings for all architectures and their used operating systems.
Although things like mounted disks are still not seperated with different architectures, it might prevent weird stuff like changing video cards and other hardware on one architecture (for an OS) and having the other architecture OSes being affected by that. So it basically splits the architectures like a modern VM does (although still having the disk images as a common setting instead of split architecture settings, but that's a whole lot less required to keep track of to prevent things like OSes suddenly getting the different hardware than what they were installed on).
The transferring of settings works just like the CPU settings moving did:
1. Load the old field setting into a variable, defaulting to the actual default value if not present.
2. Load the new setting from the settings file, defaulting to the old value loaded in step 1.
Then, when saving, only the new settings are written to the file (causing the old setting to be removed and the default setting(because the old value isn't present) to become the actual default value when loading the default setting.
Basically, it's just loading the new setting from the file, but instead of defaulting to the actual default, it loads that default from the old setting that actually defaults to the default value itself.
Basically combined with only saving the new location value in the file, this performs the following change to the file when loading (priority below) and saving:
default (if old setting not present)-> old setting(if not present) -> new setting(if present).
The priority order of the effective value is that the setting that's loaded is the last in the chain that's available. And that field is only saved into the new setting field(the old field being effectively removed when saving). That essentially drops the old setting from the chain to allow the new setting to behave normally when loading/saving, with the old setting overriding the default value of the new setting to essentially transfer the old setting (if present and valid type) to the new setting if not present or valid.