Using Vertical Retrace
Volume Number: 1
Issue Number: 9
Column Tag: C Workshop
Using the Vertical Retrace Manager" 
By Robert B. Denny, President, Alisa Systems, Inc., MacTutor Editorial
Board
This month, we look at some obscure but very useful features of the Macintosh
operating system, and combine them in a complete example program, a CRT saver. The
CRT saver does not require a desk accessory slot, nor must it be run as an application
to get it installed. The example program also illustrates techniques for using low-level
operating system features from C. As usual, the information presented here is meant to
supplement that in Inside Macintosh.
The Vertical Retrace Manager is used to schedule repetitive tasks at timed
intervals. It gets its name from the fact that it is activated when the electron beam that
paints the Mac screen "snaps back" to its starting place after painting the entire
screen from top to bottom. This vertical retrace happens 60 times a second.
Making use of the Vertical Retrace Manager is easy. Simply fill in a data
structure with a pointer to the task procedure you want to schedule and the time delay
(in ticks). Then issue a Vinstall() with the pointer to that data structure. At each
vertical retrace, the delay is decremented. When the number of ticks gets to zero, the
task is called.
After the task completes, the Vertical Retrace Manager checks the number of
ticks. If it is still zero, nothing further is done. If the task re-loads the tick count, the
whole process is repeated. Thus, to have the task periodically scheduled, simply have it
re-load the tick count with the desired interval.
The data structure is a queue element, a structure used for various purposes
throughout the Mac operating system. The different flavors of queue elements have one
thing in common. As suggested by the name, queue elements are used in applications
where things are placed on a queue. Queues are typically used to serialize processing or
to otherwise establish order. Generically, a queue element may be represented as:
struct QE
{
struct QE *QLink; /* Link or NULL */
short QType; /* Type of element */
char QData[1]; /* 1st byte of rest of data */
};
#define QElem struct QE
The type of queue element is indicated by the value in the QType field. Types
include IOQType, for input-output queues, DrvType, for the drive queue, EVType, for
the event queue, FSQType for file system queues, and VType for the vertical retrace
queue. The contents of the rest of the queue element is specific to the type. A structure
definition for a vertical retrace queue element is shown below:
struct VB
{
struct VB *qLink; /* Queue link pointer */
short qType; /* Always 1 (VType) */
ProcPtr vblAddr; /* -> Task to be scheduled */
short vblCount; /* Delay in ticks */
short vblPhase; /* Phase (see below) */
};
#define VBLTask struct VB
When you call Vinstall(), the operating system places your queue element at the
end of the vertical retrace queue. This means that your task will get activated
following those already scheduled. The VblPhase field is used to interleave tasks which
are repetitively scheduled with the same delay so that they are executed in separate
"slots".
You might be wondering why "VBL" is used when describing things associated
with vertical retrace activity. The VBL stands for "vertical blanking" a synonym for
vertical retrace. The two are interchangable.
There are a few things to be aware of when writing a VBL task. The task gets run
asynchronously . Whenever the vertical retrace occurs, the current process is
interrupted and control transfers to the Vertical Retrace Manager, which saves
registers D0-D3 and A0-A3, then calls each task whose tick count has reached zero.
When the last task completes (with an RTS), those registers are restored.
This has major consequences. First, the VBL task must save and restore any
registers (other than D0-D3 and A0-A3) that it uses. Second, the VBL task must never
make Memory Manager requests which allocate or free memory. Since many system
services (e.g., resource manipulation) generate Memory Manager requests, this
severely restricts activities inside a VBL task. Third, the execution time must be kept
short because there may be many VBL tasks scheduled for a particular tick, and all
must complete before the next retrace, 16.67 milliseconds later.
The most common way for an application to use a VBL task is to have it control
flags and/or timers that are used by the application in its event loop. This way, the
timing of application activity is controlled by the VBL task, while the time-consuming
processing is done in the application itself.
Why no Memory Manager activity in a VBL task? Since the task is activated
asynchronously, it may interrupt the application process right in the middle of
Memory Manager services. At that time, the memory management data structures may
be in an inconsistent state; a block may be "partially" deallocated, for example. Trying
to do something else at that time would cause the whole thing to become corrupt.
VBL tasks have many uses. Any time you have animation to do, consider using a
VBL task to make the motion smooth. If you rely on the consistency in timing of your
application's event loop, you may be disappointed. When your system gets AppleTalk
installed, for example, there can be a lot of asynchronous activity, which will upset
your timing loops. Have a VBL task set a flag indicating that a certain amount of "real
time has elapsed, and use this knowledge to animate. Remember that you get sixty
frames a second on the Mac screen, and the VBL task can schedule things sixty times a
second, so there is no loss in scheduling bandwidth.
The Mac system contains several "standard" VBL tasks which handle the
following:
• Check whether the stack and heap are getting too close to each other. This is the
"stack sniffer" (every tick).
• Increment the global variable Ticks, the number of ticks since system startup
(every tick).
• Handle cursor movement (every tick).
• Deglitch the mouse button and post mouse events (every other tick).
• Post a disk-inserted event if a disk was inserted (every 30 ticks).
In the CRT saver, the VBL task periodically examines the amount of time that has
elapsed since the current application got a non-null event. If it has been long enough,
the VBL task blanks the screen and sets a flag indicating this fact. That's it.
The GetNextEvent Filter
There is an undocumented "hook" in GetNextEvent() that allows special
processing to be performed before control is returned to the calling application. In the
global location JGNEFilter there is a pointer to a procedure that gets jumped-to just
prior to returning to the application. In fact, the filter procedure completes with an
RTS instruction which returns directly to the application.
When the filter procedure is entered, A1 points to the event record in the
application's address space. The event has been dequeued and copied into the
application's event record. Finally, the top of the stack contains the address of the
instruction following the application's _GetNextEvent trap, and just under that is the
boolean result being returned by GetNextEvent(). Be aware that this information was
obtained by digging with MacsBug, and may change without notice in future operating
system revisions.
It may be of interest that the "real" filter procedure appears to perform the
following services (there may be more):
• Checks for and beeps the alarm clock.
• Handles the special "command shift" keys, which eject disks, etc.
The CRT saver intercepts the JGNEFilter and keeps track of how long it has been
since the application received a non-null event from GetNextEvent(). Then it jumps to
the "real" filter procedure.
INIT Resources
Each time the Mac is started up, the operating system installs ROM patches, loads
keyboard maps and opens certain drivers. The mechanism used for this process is the
INIT resource. You can make use of this feature of the Mac bootstrap code.
During startup, the boot code looks in the "System" file for up to 32 resources of
type INIT, starting with ID=1. For each such resource found, the following steps are
taken:
1. The INIT resource is loaded into the system heap.
2. DetachResource() is called, which "orphans" the resource, removing it from the
map.
3. A JSR is made to the first location in the resource.
4. When the INIT code returns, via an RTS instruction, the first two locations in the
INIT are bashed with NOP instructions.
This action may seem a little strange, so let's look at an INIT resource which
installs a ROM patch.
First, the resource is loaded and detached, making it invisible to the Resource
Manager. It is important to understand the need for detaching the resource. If you
start an application on a new disk containing a System file, that disk becomes the new
" system" disk. The current System file is closed, the System file on the new disk is
opened, and all system resources start coming from the new System file.
When the old System file is closed, all resources that were loaded from there are
released to make way for those in the new system. If the INIT resources were not
detached after loading, they too would be released, with unfortunate results.