superfury wrote on 2024-02-03, 13:19:

The main issue is when "blanking end" after "retrace end" horizontally (as well as retrace usually) it's on the next scanline? So when the horizontal retrace and blanking ends, before the start of the next video memory being rendered (until horizontal total and after that the horizontal display enable skew, if used. So basically back porch until start of active display from VGA pov), the DAC will start outputting on the next scanline. But since the active display isn't started yet, the input status 1 register bit 0 is still indicating 'retrace'? So the software would think it's either on the next scanline or not yet? Is the DAC color assumed 'set' during the start of horizontal retarce (which gives correct results) or assumed from the end of 'retrace' (which would be incorrect as the back porch's overscan area is there as well)?

Yes. If the horizontal character count exceeds "blanking end", the CRT beam is in the left overscan areas of the next scanline. The attribute controller will send the color number in the "overscan color" register to the DAC, and the DAC will output the selected RGB color. The DAC never latches a color value from the attribute controller (for more than a pixel worth of time), nor it postpones CPU color updates. So if copper bars are implemented by changing the DAC values while "input status 1 bit 0" is set, the update will take place during the blanking/retrace period, and at the very end of the horizontal CRTC cycle, the left overscan is already drawn using the new color.

With copper bars, I never observed artifacts in the right overscan area. This need not imply that the input status 1 bit 0 is clear during overscan, because the latency from detecting that this bit is set until the DAC is accessed (using 8-bit ISA I/O) might be high enough to cover the complete right-hand overscan area.