Is your feature request related to a problem? Please describe.
It is not a real problem, but rather inconsistent. Right now, writing to $d011 or $d012 will implicitly set $d07a.7 (FNRSTCMP), thus enabling raster irq being triggered by the VIC-II course raster line set. While this is ok and probably desired, we have quite a lot of other cases where newer VIC-IV registers are also updated automatically in case a legacy VIC-II register is written to. The hot registers concept is not used for the case explained above, though.
Describe the solution you'd like
It would be more logical if the implicit modification of $d07a.7 when writing to $d011/12 was treated as hot register behaviour that can be disabled. Right now, it is an exception to the concept of hot registers. If a "legacy" register is implicitly changing one of the newer registers on-the-fly (to match what was probably intended or to mimic legacy behaviour), then this is what hot registers are meant for. Users just keeping the defaults will not notice any change. Users who like to control all registers on their own and avoid implicit updates will be able to suppress this behaviour by disabling hot registers.
Describe alternatives you've considered
No alternative, we just need to decide whether this inconsistency should be changed or not. Looking at the VHDL, I believe this would be a small change.
Is your feature request related to a problem? Please describe. It is not a real problem, but rather inconsistent. Right now, writing to $d011 or $d012 will implicitly set $d07a.7 (FNRSTCMP), thus enabling raster irq being triggered by the VIC-II course raster line set. While this is ok and probably desired, we have quite a lot of other cases where newer VIC-IV registers are also updated automatically in case a legacy VIC-II register is written to. The hot registers concept is not used for the case explained above, though.
Describe the solution you'd like It would be more logical if the implicit modification of $d07a.7 when writing to $d011/12 was treated as hot register behaviour that can be disabled. Right now, it is an exception to the concept of hot registers. If a "legacy" register is implicitly changing one of the newer registers on-the-fly (to match what was probably intended or to mimic legacy behaviour), then this is what hot registers are meant for. Users just keeping the defaults will not notice any change. Users who like to control all registers on their own and avoid implicit updates will be able to suppress this behaviour by disabling hot registers.
Describe alternatives you've considered No alternative, we just need to decide whether this inconsistency should be changed or not. Looking at the VHDL, I believe this would be a small change.