🚀 go-pugleaf

In article <1992Aug3.210504.57823@cc.usu.edu> sl8nl@cc.usu.edu writes:
>> detect the retrace with an interrupt, rather than polling for it.  I want to
>> use this so I can flip screens for animation every retrace - I think this is
>> how it's done?  If anyone has some source, I'd really appreciate it
>
>Question:  If you set the retrace up as an interrupt (possible...by modifying
>the timer interrupt to run at 60 times a second), wouldn't you still have
>to poll for it.  For instance, the polling code sets a flag to true for the
>retrace.  Wouldn't you still have to poll for this flag the same way to
>poll for the retrace?

First of all, you don't use the timer interrupt. Even if you COULD
program it for 60Hz (or 72Hz or whatever rate the mode/monitor is
using), there's no way you could synchronize the timer chip to the
display refresh cycle. And besides, the video card itself is capable of
generating an interrupt request at the start of the vertical retrace.

You set up an interrupt service routine (for INT 2, the interrupt
request level generated by the video card) which swaps display buffers.
When the vertical retrace starts, the ISR is called, and the display
buffers are swapped without any direct action on the part of the
program.

Potential pitfalls: retrace occurs every 60th of a second (varies
depending on video mode). If the animation is not "slaved" to the
retrace rate, some synchronization problems will result. For example:

Suppose it takes the program 1/30th of a second to draw one complete
frame of animation. Suppose the program is drawing on page 1 while page
0 is being displayed. 1/60th of a second later, page 1 is displayed and
page 0 becomes the active page for drawing. Since the frame is only half
drawn when the buffer swap occurs, you have half a frame drawn in one
display buffer and half in another. To solve this, you would put a flag
in an areas of memory shared by the ISR and the main program. If the
flag is set, then the ISR should flip pages and clear the flag; if the flag
is clear, the ISR should do nothing and return immediately. The drawing code
can then set the flag when it has finished drawing the current frame.

Another potential problem arises when a complete frame can be rendered in
less than 1/60th of a second. For the sake of argument, let's say the
code could sustain an animation rate of 120 frames per second. In this
situation, the program could potentially draw more than one frame during one
retrace period. This would result in frames of animation which were drawn but
never seen by the user (and thus wasted). Solution: the frame drawing code has
to set the retrace flag and then WAIT until the retrace has occurred
before starting to draw the next frame. This means the code ends up
polling the retrace flag, though not for the reason sl8nl mentions.

BTW, I should have such problems as too HIGH an animation rate... ;-)