# Signetics 2650 & 2636 programming/Sync to VRST

So far our programs have largely been static — the PVI has been set up once and left alone. In this tutorial you will learn how to synchronise to the vertical reset signal and change what is on the screen every frame.

## What is VRST?

    See also: Console Hardware and Analogue TV
VRST is a signal generated by the sync generator chip. It goes high for about 2.7ms in every 20ms frame of the video signal, and during this time the CRT's electron beam is turned off and is being moved back to point to the top of the screen.
This signal is connected to the Sense input of the microprocessor and its state is indicated by bit 7 of the PSU register. The leading edge of VRST also sets bit 6 (VRLE) of register $1FCB in the PVI, though this is not such a convenient place to check.
VRST is significant for two reasons. First, it gives our program a regular clock tick every 20ms that we can use to determine how fast things are moving on the screen. Second, the PVI requires that we set the vertical coordinate of all the primary objects before the trailing edge of VRST. Related to the latter, we also need to start handling other real-time events related to changing PVI registers during the scan, and that will be discussed in the next chapter.

## Tutorial code

The code for this tutorial can be found at Tutorial code - sync to VRST.
These two subroutines are responsible for detecting the state of the VRST signal:
The instruction TPSU tests individual bits in the upper byte of the program status word. The constant sense has been equated to the value $80 by the statement sense equ $80, so we are testing bit 7 of PSU, the sense input of the processor, which in turn is fed by the VRST signal.
In subroutine Vsync0 the program keeps looping while sense is high, or in other words it waits until sense is low. Conversely, subroutine Vsync1 loops while sense is low, or in other words it waits until sense is high.
This is the main loop of the program:
The two subroutines Vsync0 and Vsync1 work together and are effectively waiting for the transition of the VRST signal from low to high. When that happens, the vertical coordinate of object 1 is incremented by one and its horizontal coordinate is decremented by one. The object therefore moves diagonally across the screen, one pixel per 20ms frame and therefore taking about 5 seconds per sweep.
Don't forget that the vertical coordinate must be set up before the end of the VRST period. This is because at that time the value in the register is transferred to a counter which is decremented on every horizontal line until it reaches zero, and then the first line of the object is displayed. So it is a good idea to set the vertical coordinate soon after the start of VRST. The WinArcadia debugger lets us see where this is occurring:
* Turn on the blanking display: Options > VDU > Blanking areas?
* Set a breakpoint at 0033: bp $0033
* Turn on the guide ray: gr
* Step through the program: s
You should see that both coordinates are set during the first few horizontal lines during the vertical blanking period. The X and Y coordinates are also shown in the WInArcadia output window.
It is also important that this is done only once per frame, which is why we sync to the transition of VRST. Without that first subroutine call, Vsync0, the display gets erratic. Try patching it out, either by reassembling the code with a comment at the start of the line, ;bsta,un Vsync0 , or by using the WinArcadia memory editor to replace the code with NOP's, 002D C0 C0 C0.

## Exercises

* Alter the amount the coordinate is changed by every frame.