Jan,

To tighten up the Video Timing evaluation you must consider that Video generation runs as a Timer Interrupt.

To achieve the determinancy required for sharp video, Craig came up with a method which uses the # of timer ticks since interrupt to index into a path of NOP's to assure consistent entry into Video Interrupt.

As you note Active Video (display field generation) is where all the overhead occurs.

There are three basic types of video line being generated:
1)Black Line; 2)Displaying Line; 3)Synch Line;

Each line begins with a Horizontal Sync pulse within a Blanking Interval.

Both Horiz. Sync and Blanking occur as a port write and timer reload and (pushes/pops). Consequently, the greatest portion of Hsync and blanking intervals ~(10.8us every line) accrues to the foreground and does for every line generated.

Black lines (above and below the display field) and BLANK lines (occuring as 1/2 lines during Vertical Sync) also occur as a port output and timer reload, so the greatest portion of any "static" line also accrues to the foreground.

Finally, for each displaying line, the left and right black borders are also port writes and timer reload. In fact the 256 pixels within each displaying line occurs in a 41us interval between left and right borders. This is to avoid CRT edge effects like "pin cushion" distortion.

So the ballpark max latency in response to an alternative interrupt or foreground event is the 41us + Int Arbitration/overhead (for Horizontal displaying lines).

regards,
p