XBIOS Graphics and Sound Functions
write graphics to a part of memory that is not being dis
played while changing the address, of the physical screen lets
you display another part of memory. In either case, the new
screen memory block must begin on an even page (256-byte)
boundary.
Changing the resolution mode only works if you're us
ing a color monitor since TOS won't let you select a color
mode if you're using a monochrome monitor, or vice versa.
Therefore, you can only switch from medium to low resolu
tion, or from low to medium. Even then, using Setscreen()
to switch resolution modes only works for TOS programs.
GEM cannot adjust to the switch. There is no known way to
change a GEM screen from low to medium, or medium to
low resolution modes, other than going back to the Desktop
and using the Set Preferences menu option. Note that when
you change resolution modes, the screen is cleared and cer
tain other screen parameters are reinitialized.
The graphics display is maintained by an electron beam
in the monitor that scans the screen from top to bottom.
Changes in display memory made in midscan may show up
as momentary glitches onscreen. To avoid this problem, dis
play memory should be changed only during the interval
that occurs when the scan reaches the bottom of the screen,
before it starts over again at the top of the screen. This pe
riod is known as the vertical blanking interval, or vblank. On
the ST, a priority level 4 interrupt occurs during each vblank.
The XBIOS function Vsync() simply waits until the vblank
interrupt is finished. When the function returns, it should be
safe to change the screen. The format for Vsync is
Vsync();
Vsync() can also be used in programs as a timed delay.
Note, however, that the length of the Vsync() delay varies
with the refresh rate of the monitor used. The monochrome
monitor refreshes the screen 70 times per second, while the
U.S. version of the color monitor refreshes the screen 60
times per second. The European (PAL) color monitor re
freshes 50 times per second.
Contrary to Atari's documentation, the Physbase( ) func
tion doesn't wait until the next vblank to return the physical
screen location, nor does Setscreen() wait for a vblank to
change the physical screen (at least not in the preblitter
ROMs). This means that glitches can occur when changing