11

According to http://www.vcfed.org/forum/showthread.php?62049-The-myth-of-the-vertical-retrace-interrupt-on-EGA-VGA

IBM first implemented a vertical retrace interrupt on the PCjr in 1984.

That implies CGA, released prior to 1984, does not have a vertical retrace interrupt.

Does CGA have any way to synchronize with vertical blank, or does animation thereon just have to put up with tearing?

2 Answers 2

19

It is possible to synchronise with vertical blank, but it involves polling (as does avoiding snow on CGA). Two bits are important in the status register, read from 0x03DA:

  • bit 0 is 1 when the CPU can touch the CGA buffer without causing snow;
  • bit 3 is 1 during vertical retrace.

So a change in bit 3 from 0 to 1 would signal the start of a vertical blank.

12

The synchronization is possible via polling, but it could also be done by interrupt even when no hardware interrupts were provided. It worked on any card that had a "real-time" status register with relevant information. I did that many times along the years, even as late as mid-90s. The trick? Take over the timer interrupt, and use it for two things:

  1. Polling the graphics card status. This could be the CRT controller (CRTC) scan registers, so that the current screen refresh position was known, or a status bit that indicated vertical retrace. The status has to be polled long enough to capture event we're interested in. The number of loop repetitions before the event is captured provides the phase information.

  2. Running a phase-locked loop using the timer interrupt period, using the phase feedback obtained above.

There was some finesse to it so that, in practice, the time wasted for phase-detection polling was minimized. What really happened was that the phase jitter was estimated, and the timer interrupt was triggered only as early as warranted by the jitter. On systems with low jitter, sometimes just a couple of loop iterations sufficed to capture the event (e.g. a status bit changing state, or a CRTC register reaching the desired value). There were also provisions for dealing with sporadic high latency, usually introduced by poorly designed device drivers for other hardware. Interrupt handler interrogated the CTC (counter timer) registers to determine how late it was actually invoked (due to interrupts being blocked), and acted accordingly.

I'm not sure how widespread such practice was, but the approach was so generic that it could be adapted for completely "black box" graphics cards, where no VSYNC feedback was available. Then the trick was to use a simple adapter that fed the VSYNC signal from the graphics card output to a parallel port input pin.

There were few uses for such synchronization, but when you needed it - you couldn't do without it. I remember using this on Tseng cards with multisync NEC monitors to support 80Hz refresh for 3D wireframe visualization with LCD shutter goggles.

1
  • 3
    This. I played around on VGA to get software "copper bars" by synchronizing the timer interrupt to HSYNC/2 (free-running during the frame) and re-locking at the end of VSYNC. It worked quite nice. My test program put a full-color background past the text - but did not do anything else. I used dithering for the timer interrupt frequency for extra resolution (switching between two adjacent period values controlled by an 8-bit error accumulator). Commented Jun 26, 2020 at 22:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .