Subject: Re: VBL on apple II
Newsgroups: comp.sys.apple2.programmer
From: dempson@actrix.gen.nz (David Empson)
Date: Thu, 6 May 1999 02:02:32 +1200
Message-ID: <1drcvga.hcaucd1g1opcoN@dempson.actrix.gen.nz>
References: <7gn9u3$i35$1@nnrp1.dejanews.com>
Organization: Empsoft
X-Newsreader: MacSOUP 2.3
NNTP-Posting-Host: 202.49.157.176
X-Trace: 6 May 1999 02:00:41 NZST, 202.49.157.176
Lines: 114
Path: lobby!newstf02.news.aol.com!portc01.blue.aol.com!news-peer.gip.net!news.gsl.net!gip.net!cyclone.news.idirect.com!island.idirect.com!usenet.net.nz!news.iprolink.co.nz!news.actrix.gen.nz!dempson



<bobryan9@my-dejanews.com> wrote:

> How many processor cycles can execute between VBL of the video circuits?

It depends how fast the processor is running and whether there are any
interrupts active.

VBL goes true at the same rate as the screen refresh, which is either 60
Hz (16.67 ms) or 50 Hz (20 ms), depending on the country for which the
machine was manufactured (the IIgs has a setting to run at either
speed).

For a IIe or IIc, the processor is probably running at 1.0227 MHz (US
IIe), except for a PAL (international) IIe or IIc, which is a little bit
slower.  The IIgs may be running at 1.0227 MHz or 2.8 MHz (with overhead
for RAM refresh).  An accelerated machine could be running considerably
faster.

Assuming a standard unaccelerated United States Apple IIe (60 Hz
refresh), with a CPU clock speed of 1.0227 MHz (14.31818 MHz divided by
14) and no interrupts, you get about 17045 CPU cycles between the time
at which consecutive VBL periods start.

Looking at "Understanding the IIe", I see that the exact figure is 17030
CPU cycles.

An international IIe may have 50 Hz screen refreshes, so you get more
like 20000 cycles per screen refresh.

If you have interrupts going all the time (particularly on the IIgs, or
if you have the IIc mouse active, or the IIe mouse to a lesser extent)
then you might get a lot less CPU time between VBLs.


Another point to consider is how long the VBL period lasts.  I can't see
a figure mentioned in this book, but it does show the events divided
into display lines.  Assuming this is accurate, the VBL period lasts for
70 scan lines (the non-blanked period is 192 scan lines), with 65 CPU
cycles per scan line, so the VBL period is 4550 cycles.

A few points to consider here:

- If you are waiting for VBL to redraw the screen, then you can start
drawing during the VBL period and keep drawing after the normal scan
starts, as long as you draw the top part of the screen first.  From the
time VBL starts, you have 4550 cycles to finish the first line, then
another 65 cycles to finish each subsequent line.  e.g. if you can
redraw the top half of the screen in about 4000 cycles, then you have
another (96 * 65) = 6240 cycles during which to redraw the bottom half
of the screen.

- If you use both pages (assuming hi-res graphics), then you can draw an
entire frame on the hidden page, and wait for VBL to switch to
displaying the other page.  Assuming you can redraw the page in less
than 17030 cycles, you can get 30 frames per second using this method.
If you need more time to draw the next image, you will have to make do
with a lower frame rate.

> I am trying to decide if I want to use VBL interrupts with the mouse card,
> or just make a program loop waiting for the VBL.
> 
> ex1)
> 
> VBL interrupt handler
> take care of VBL
> restore registers
> return to program
> 
> ex2)
> 1 If VBL then take care of
> 2 goto 1
> 
> When I want to detect a VBL with example 2 (I know it is not real code), how
> long could I be waiting for a vbl?

Assuming the loop is:

WAITVBL LDA $C019
        BMI WAITVBL

then you will get a sampling latency of anything up to 7 cycles (4 for
the LDA, 3 for the branch assuming it is taken and no page boundary is
crossed).

On entry to this loop, you might be waiting as long as 12480 cycles
(give or take a few) before VBL arrives.  If VBL is already active, then
you might start a redraw too late to avoid a "tearing" effect on the
screen.

In general, if you are syncing to VBL for redraws, then you would tend
to start by waiting for VBL to go away, then wait for the next VBL to
start, then arrange for all subsequent code to complete and get back to
the VBL wait in less than 17030 cycles.

> Using interrupts, I read that you can be up to 3 cycles late to handling
> the interrupt (the current instruction has to execute before the interrupt
> handler can get to it)

3 cycles?  Hardly.  Assuming interrupts are not locked out by the
non-interrupt code, then you have a worst case interrupt latency of 7
cycles on a 6502 (the slowest addressing mode is indirect indexed), but
you then have all the overhead of the interrupt itself:

- Processor saves program counter and processor register onto the stack
- Processor fetches interrupt vector and starts executing main interrupt
handler.
- Depending on the machine, firmware version and operating system, this
could take anything in the order of 20 to 200 cycles (possibly worse)
before your user interrupt handler is called.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand