Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #2989 > unrolled thread

Vertical Blank on Apple ][+

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Vertical Blank on Apple ][+ Norman Davie <ecompservices@gmail.com> - 2016-08-22 15:26 -0700
    Re: Vertical Blank on Apple ][+ John Brooks <jbrooks@blueshiftinc.com> - 2016-08-22 16:47 -0700
    Re: Vertical Blank on Apple ][+ roger.shimada@gmail.com - 2016-08-22 17:48 -0700
      Re: Vertical Blank on Apple ][+ mmphosis <mmphosis@macgui.com> - 2016-08-23 02:30 +0000
        Re: Vertical Blank on Apple ][+ Michael J. Mahon <mjmahon@aol.com> - 2016-08-22 22:06 -0500
        Re: Vertical Blank on Apple ][+ "Mark D. Overholser" <marko@markoverholser.com> - 2016-08-23 07:57 -0700
        Re: Vertical Blank on Apple ][+ roger.shimada@gmail.com - 2016-08-23 17:55 -0700
          Re: Vertical Blank on Apple ][+ Michael J. Mahon <mjmahon@aol.com> - 2016-08-23 21:52 -0500
            Re: Vertical Blank on Apple ][+ John Brooks <jbrooks@blueshiftinc.com> - 2016-08-23 20:44 -0700
              Re: Vertical Blank on Apple ][+ Mark Lemmert <mark.lemmert@gmail.com> - 2016-08-23 22:49 -0700
                Re: Vertical Blank on Apple ][+ zellyn@gmail.com - 2016-08-24 07:15 -0700
                  Re: Vertical Blank on Apple ][+ Mark Lemmert <mark.lemmert@gmail.com> - 2016-08-24 19:59 -0700
                Re: Vertical Blank on Apple ][+ Michael J. Mahon <mjmahon@aol.com> - 2016-08-24 11:57 -0500
                  Re: Vertical Blank on Apple ][+ Mark Lemmert <mark.lemmert@gmail.com> - 2016-08-24 20:00 -0700
                    Re: Vertical Blank on Apple ][+ "Mark D. Overholser" <marko@markoverholser.com> - 2016-08-24 23:32 -0700
                      Re: Vertical Blank on Apple ][+ Michael J. Mahon <mjmahon@aol.com> - 2016-08-25 20:51 -0500
                    Re: Vertical Blank on Apple ][+ Michael J. Mahon <mjmahon@aol.com> - 2016-08-25 20:51 -0500
                      Re: Vertical Blank on Apple ][+ gids.rs@sasktel.net - 2016-08-25 21:41 -0700
                        Re: Vertical Blank on Apple ][+ mmphosis <mmphosis@macgui.com> - 2016-08-26 18:52 +0000
                      Re: Vertical Blank on Apple ][+ Mark Lemmert <mark.lemmert@gmail.com> - 2016-08-26 06:47 -0700
              Re: Vertical Blank on Apple ][+ roger.shimada@gmail.com - 2016-08-28 08:33 -0700
    Re: Vertical Blank on Apple ][+ olivier.zardini@itn-group.eu - 2016-08-25 09:18 -0700
      Re: Vertical Blank on Apple ][+ Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-28 14:58 -0700
        Re: Vertical Blank on Apple ][+ Norman Davie <ecompservices@gmail.com> - 2016-08-28 16:19 -0700
          Re: Vertical Blank on Apple ][+ Dave Kay <thavith@gmail.com> - 2023-03-16 03:35 -0700
            Re: Vertical Blank on Apple ][+ Michael Pohoreski <michael.pohoreski@gmail.com> - 2023-03-21 08:59 -0700
              Re: Vertical Blank on Apple ][+ I am Rob <gids.rs@sasktel.net> - 2023-03-21 15:32 -0700
                Re: Vertical Blank on Apple ][+ mmphosis <mmphosis@macgui.com> - 2023-03-23 14:33 +0000

Page 1 of 2  [1] 2  Next page →

#2989 — Vertical Blank on Apple ][+

Did game companies just count cycles to insure they were not writing to the screen outside the vertical blank interval???

[toc] | [next] | [standalone]

#2990

On Monday, August 22, 2016 at 3:26:44 PM UTC-7, Norman Davie wrote:
> Did game companies just count cycles to insure they were not writing to the screen outside the vertical blank interval???

No VBL sync, so the choices are either to double-buffer or design the graphics engine to minimize time between erase & redraw.

-JB
Twitter: @JBrooksBSI

[toc] | [prev] | [next] | [standalone]

#2991

On Monday, August 22, 2016 at 5:26:44 PM UTC-5, Norman Davie wrote:
> Did game companies just count cycles to insure they were not writing to the screen outside the vertical blank interval???

Asides from not knowing when then vertical blank is, I doubt there would have been enough cycles for this type of thing.

For really smooth stuff, page flipping would have been used.

The prototype Apple II mouse card had hardware the could allow finding the vertical blank; see http://www.folklore.org/StoryView.py?project=Macintosh&story=Apple_II_Mouse_Card.txt

[toc] | [prev] | [next] | [standalone]

#2993

From what I gather the vertical blank can be determined without extra
hardware on the Apple II and Apple II+.  The folklore story mentions a tight
loop and another 17 cycle loop.

> To synchronize with the video, Burrell had me fill the Apple II's frame
> buffer so the low bit was on most of the time, but set off at the end of
> the last scan line. I wrote a routine to sit in a tight loop, reading the
> latch. When the low bit changed, we would know the vertical blanking
> interval had just begun.

> The Apple II wasn't fast enough to keep up with its own frame buffer. A
> new byte of video data flew by every microsecond, which was only one
> processor cycle. It took at least 10 processor cycles to iterate through a
> loop, so we ran the risk of never seeing the low bit change. Burrell had a
> way around this, though - if the loop time was relatively prime to the
> display frequency, it eventually had to slip into place. I wrote a 17
> microsecond loop that fit the bill, and we were delighted to see it work
> perfectly.

I wrote routine with a 7 cycle loop that works on at least two emulators.  I
don't have real hardware to test this on.

http://hoop-la.ca/apple2/2015/vbl/

[toc] | [prev] | [next] | [standalone]

#2995

mmphosis <mmphosis@macgui.com> wrote:
> From what I gather the vertical blank can be determined without extra
> hardware on the Apple II and Apple II+.  The folklore story mentions a tight
> loop and another 17 cycle loop.
> 
>> To synchronize with the video, Burrell had me fill the Apple II's frame
>> buffer so the low bit was on most of the time, but set off at the end of
>> the last scan line. I wrote a routine to sit in a tight loop, reading the
>> latch. When the low bit changed, we would know the vertical blanking
>> interval had just begun.
> 
>> The Apple II wasn't fast enough to keep up with its own frame buffer. A
>> new byte of video data flew by every microsecond, which was only one
>> processor cycle. It took at least 10 processor cycles to iterate through a
>> loop, so we ran the risk of never seeing the low bit change. Burrell had a
>> way around this, though - if the loop time was relatively prime to the
>> display frequency, it eventually had to slip into place. I wrote a 17
>> microsecond loop that fit the bill, and we were delighted to see it work
>> perfectly.
> 
> I wrote routine with a 7 cycle loop that works on at least two emulators.  I
> don't have real hardware to test this on.
> 
> http://hoop-la.ca/apple2/2015/vbl/
> 
> 
> 

...and the fastest loop to poll an arbitrary address:

LDA <address>
Bxx  <back to LDA>

is 7 cycles. 

"Vapor lock" has been around for a long time, but it's difficult to
integrate with general code because of the difficulty of maintaining a
constant cycle count. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2998

On 22-Aug-16 19:30, mmphosis wrote:
> From what I gather the vertical blank can be determined without extra
> hardware on the Apple II and Apple II+.  The folklore story mentions a tight
> loop and another 17 cycle loop.
>
>> To synchronize with the video, Burrell had me fill the Apple II's frame
>> buffer so the low bit was on most of the time, but set off at the end of
>> the last scan line. I wrote a routine to sit in a tight loop, reading the
>> latch. When the low bit changed, we would know the vertical blanking
>> interval had just begun.
>
>> The Apple II wasn't fast enough to keep up with its own frame buffer. A
>> new byte of video data flew by every microsecond, which was only one
>> processor cycle. It took at least 10 processor cycles to iterate through a
>> loop, so we ran the risk of never seeing the low bit change. Burrell had a
>> way around this, though - if the loop time was relatively prime to the
>> display frequency, it eventually had to slip into place. I wrote a 17
>> microsecond loop that fit the bill, and we were delighted to see it work
>> perfectly.
>
> I wrote routine with a 7 cycle loop that works on at least two emulators.  I
> don't have real hardware to test this on.
>
> http://hoop-la.ca/apple2/2015/vbl/
>
>


If you can determine when the Vertical Retrace has just started, you can 
update the Screen, just after it, and even if you don't keep up with it, 
there won't be any "noticeable jitter" until the Retrace overruns where 
you are updating the screen.

If you can keep track of the time elapsed, with Cycle Counting, you 
could "pause" your Screen Update, to let the Retrace Pass Over You to 
minimize the jitter...


MarkO

[toc] | [prev] | [next] | [standalone]

#3001

On Monday, August 22, 2016 at 9:30:02 PM UTC-5, mmphosis wrote:
> From what I gather the vertical blank can be determined without extra
> hardware on the Apple II and Apple II+.  The folklore story mentions a tight
> loop and another 17 cycle loop.

You missed a key sentence - it required extra hardware:

"Burrell solved the problem by wiring up the spare flip flop to the low bit of the data bus, using it to latch whatever data the video was displaying so the processor could read it."

IIRC when a mouse card is initialized on II+, it puts up a blank hires screen with a couple of pixels, presumably to figure out when the vertical blank is.

[toc] | [prev] | [next] | [standalone]

#3003

<roger.shimada@gmail.com> wrote:
> On Monday, August 22, 2016 at 9:30:02 PM UTC-5, mmphosis wrote:
>> From what I gather the vertical blank can be determined without extra
>> hardware on the Apple II and Apple II+.  The folklore story mentions a tight
>> loop and another 17 cycle loop.
> 
> You missed a key sentence - it required extra hardware:
> 
> "Burrell solved the problem by wiring up the spare flip flop to the low
> bit of the data bus, using it to latch whatever data the video was
> displaying so the processor could read it."
> 
> IIRC when a mouse card is initialized on II+, it puts up a blank hires
> screen with a couple of pixels, presumably to figure out when the vertical blank is.
> 
> 

Actually, the last-read video byte can be read from any "unconnected" soft
switch address. This is the principle behind Bob Bishop's "vapor lock".

It's possible to sync with the video frame on (at least) any 8-bit Apple II
(I don't know about the IIgs). 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3004

On Tuesday, August 23, 2016 at 7:52:53 PM UTC-7, mjm...@aol.com wrote:
> roger.shimadawrote:
> > On Monday, August 22, 2016 at 9:30:02 PM UTC-5, mmphosis wrote:
> >> From what I gather the vertical blank can be determined without extra
> >> hardware on the Apple II and Apple II+.  The folklore story mentions a tight
> >> loop and another 17 cycle loop.
> > 
> > You missed a key sentence - it required extra hardware:
> > 
> > "Burrell solved the problem by wiring up the spare flip flop to the low
> > bit of the data bus, using it to latch whatever data the video was
> > displaying so the processor could read it."
> > 
> > IIRC when a mouse card is initialized on II+, it puts up a blank hires
> > screen with a couple of pixels, presumably to figure out when the vertical blank is.
> > 
> > 
> 
> Actually, the last-read video byte can be read from any "unconnected" soft
> switch address. This is the principle behind Bob Bishop's "vapor lock".
> 
> It's possible to sync with the video frame on (at least) any 8-bit Apple II
> (I don't know about the IIgs). 
> -- 
> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

Video sync on the GS is easy due to:
c019: Bit 7 = 1 when not in VBL
C02E-C02F: Vertical scan counter & horizontal scan counter

-JB

[toc] | [prev] | [next] | [standalone]

#3005

This thread is an interesting topic to me.

I'm working on an Apple IIe tile-based RPG game with complex hi-res screens and animation. 

I've never tried working with the vertical blank. My understanding is that drawing during the vertical blank reduces issues with flicker when working with single page animation.

My screens are 17x11 tiles, which are 2 screen bytes X 16 lines. Animation is 4 frames. When a dozen or so tiles on the screen were animated, I had no significant problems with flicker. When half or more tiles on the screen were animated, things got really weird. For example, a screen with mostly animated water tiles.

I could see the animation frames being drawn tile by tile, left to right, top to bottom. The screen draw took a second or so but I could still see the different frame states briefly, verified by slo-mo video. Seeing part of the screen in frame 1 (for example) and part of the screen in frame 2, it seemed to create a distortion that could be described as a flicker.

But, my theory was/is that part of the problem occurring was that the screen draw was simply too slow as evidenced by being able to see parts of the screen in different frame states, and thus drawing in the vehicle blank would possibly make it worse by adding delays, or at best only solve part of the problem. Basically, if it's too slow, it's too slow, was my thinking, and I didn't see how altering the draw timing would help that issue.

I solved the problem by using page flipping for animation, and everything has been working great, but I've always been curious if I diagnosed this correctly and/or if I'm misunderstanding something about the vertical blank and how it may relate to this scenario.

Any thoughts? 

I made this change over 6 months ago but if helpful I can probably dig up some video showing the distortion with the single page animation scenario.

Thanks for thoughts anyone has to share.


Mark 

[toc] | [prev] | [next] | [standalone]

#3007

On Wednesday, August 24, 2016 at 1:49:29 AM UTC-4, Mark Lemmert wrote:
> I've never tried working with the vertical blank. My understanding is that drawing during the vertical blank reduces issues with flicker when working with single page animation.

The original article documenting the technique is (I believe) Bob Bishop's "Have an Apple Split": text version at http://rich12345.tripod.com/aiivideo/softalk.html

The problem is that after detecting the sync position, you have to keep cycle-accurate timing from then on. While it's certainly possible to do that in a game engine, it would be challenging…

Zellyn

[toc] | [prev] | [next] | [standalone]

#3010

Great article, thanks!

On Wednesday, August 24, 2016 at 9:15:48 AM UTC-5, zel...@gmail.com wrote:
> On Wednesday, August 24, 2016 at 1:49:29 AM UTC-4, Mark Lemmert wrote:
> > I've never tried working with the vertical blank. My understanding is that drawing during the vertical blank reduces issues with flicker when working with single page animation.
> 
> The original article documenting the technique is (I believe) Bob Bishop's "Have an Apple Split": text version at http://rich12345.tripod.com/aiivideo/softalk.html
> 
> The problem is that after detecting the sync position, you have to keep cycle-accurate timing from then on. While it's certainly possible to do that in a game engine, it would be challenging…
> 
> Zellyn

[toc] | [prev] | [next] | [standalone]

#3008

Mark Lemmert <mark.lemmert@gmail.com> wrote:
> This thread is an interesting topic to me.
> 
> I'm working on an Apple IIe tile-based RPG game with complex hi-res screens and animation. 
> 
> I've never tried working with the vertical blank. My understanding is
> that drawing during the vertical blank reduces issues with flicker when
> working with single page animation.
> 
> My screens are 17x11 tiles, which are 2 screen bytes X 16 lines.
> Animation is 4 frames. When a dozen or so tiles on the screen were
> animated, I had no significant problems with flicker. When half or more
> tiles on the screen were animated, things got really weird. For example,
> a screen with mostly animated water tiles.
> 
> I could see the animation frames being drawn tile by tile, left to right,
> top to bottom. The screen draw took a second or so but I could still see
> the different frame states briefly, verified by slo-mo video. Seeing part
> of the screen in frame 1 (for example) and part of the screen in frame 2,
> it seemed to create a distortion that could be described as a flicker.
> 
> But, my theory was/is that part of the problem occurring was that the
> screen draw was simply too slow as evidenced by being able to see parts
> of the screen in different frame states, and thus drawing in the vehicle
> blank would possibly make it worse by adding delays, or at best only
> solve part of the problem. Basically, if it's too slow, it's too slow,
> was my thinking, and I didn't see how altering the draw timing would help that issue.
> 
> I solved the problem by using page flipping for animation, and everything
> has been working great, but I've always been curious if I diagnosed this
> correctly and/or if I'm misunderstanding something about the vertical
> blank and how it may relate to this scenario.
> 
> Any thoughts? 
> 
> I made this change over 6 months ago but if helpful I can probably dig up
> some video showing the distortion with the single page animation scenario.
> 
> Thanks for thoughts anyone has to share.
> 
> 
> Mark 
> 

I agree with your diagnosis. 

Drawing during vertical blanking is only effective when the actual drawing
can stay ahead of the raster scan. 

If drawing is slower than display refresh, then page flipping is much more
effective, and the flip can be synchronized with vertical blanking for even
better results (if the additional wait is acceptable). 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3011

Michael,

Thanks for confirming!


Do you know if there are applications where drawing during the veritable blank interval would be more desirable than page flipping?

Thinking more broadly than the Apple II hardware, I’m speculating that using the vertical blank for drawing was mainly used on hardware that didn’t have page flipping available. 


Thanks.

Mark




On Wednesday, August 24, 2016 at 11:57:43 AM UTC-5, mjm...@aol.com wrote:
> Mark Lemmert <mark.lemmert@gmail.com> wrote:

> > But, my theory was/is that part of the problem occurring was that the
> > screen draw was simply too slow as evidenced by being able to see parts
> > of the screen in different frame states, and thus drawing in the vehicle
> > blank would possibly make it worse by adding delays, or at best only
> > solve part of the problem. Basically, if it's too slow, it's too slow,
> > was my thinking, and I didn't see how altering the draw timing would help that issue.



> > 
> 
> I agree with your diagnosis. 
> 
> Drawing during vertical blanking is only effective when the actual drawing
> can stay ahead of the raster scan. 
> 
> If drawing is slower than display refresh, then page flipping is much more
> effective, and the flip can be synchronized with vertical blanking for even
> better results (if the additional wait is acceptable). 
> -- 
> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3012

On 8/24/2016 20:00, Mark Lemmert wrote:
> Michael,
>
> Thanks for confirming!
>
>
> Do you know if there are applications where drawing during the
> veritable blank interval would be more desirable than page flipping?
>
> Thinking more broadly than the Apple II hardware, I’m speculating
> that using the vertical blank for drawing was mainly used on hardware
> that didn’t have page flipping available.
>
>
> Thanks.
>
> Mark
>
>
>

My understanding of programming the Atari 2600 is about "Racing the 
Beam" and only changing the Graphics when the Scan Line is not Re 
Drawing your Graphics..


MarkO

[toc] | [prev] | [next] | [standalone]

#3019

Mark D. Overholser <marko@markoverholser.com> wrote:
> On 8/24/2016 20:00, Mark Lemmert wrote:
>> Michael,
>> 
>> Thanks for confirming!
>> 
>> 
>> Do you know if there are applications where drawing during the
>> veritable blank interval would be more desirable than page flipping?
>> 
>> Thinking more broadly than the Apple II hardware, I’m speculating
>> that using the vertical blank for drawing was mainly used on hardware
>> that didn’t have page flipping available.
>> 
>> 
>> Thanks.
>> 
>> Mark
>> 
>> 
>> 
> 
> My understanding of programming the Atari 2600 is about "Racing the 
> Beam" and only changing the Graphics when the Scan Line is not Re 
> Drawing your Graphics..
> 
> 
> MarkO
> 

A perfect example of RAM-constrained programming. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3018

Mark Lemmert <mark.lemmert@gmail.com> wrote:
> Michael,
> 
> Thanks for confirming!
> 
> 
> Do you know if there are applications where drawing during the veritable
> blank interval would be more desirable than page flipping?
> 
> Thinking more broadly than the Apple II hardware, I’m speculating that
> using the vertical blank for drawing was mainly used on hardware that
> didn’t have page flipping available. 
> 
> 
> Thanks.
> 
> Mark

Page flipping is definitely the more general approach, but in
RAM-constrained applications, syncing to Vblank and staying ahead of the
refresh is sometimes a necessity. 

For any animation that can be completed in a millisecond or two, it's
pretty easy. If the animation requires several milliseconds, it may be
necessary to order the updates top-to-bottom to stay ahead of the refresh. 

Lots of games have a large playfield but relatively small moving elements,
so the animation can be done completely during vertical blanking. 

> On Wednesday, August 24, 2016 at 11:57:43 AM UTC-5, mjm...@aol.com wrote:
>> Mark Lemmert <mark.lemmert@gmail.com> wrote:
> 
>>> But, my theory was/is that part of the problem occurring was that the
>>> screen draw was simply too slow as evidenced by being able to see parts
>>> of the screen in different frame states, and thus drawing in the vehicle
>>> blank would possibly make it worse by adding delays, or at best only
>>> solve part of the problem. Basically, if it's too slow, it's too slow,
>>> was my thinking, and I didn't see how altering the draw timing would help that issue.
> 
> 
> 
>>> 
>> 
>> I agree with your diagnosis. 
>> 
>> Drawing during vertical blanking is only effective when the actual drawing
>> can stay ahead of the raster scan. 
>> 
>> If drawing is slower than display refresh, then page flipping is much more
>> effective, and the flip can be synchronized with vertical blanking for even
>> better results (if the additional wait is acceptable). 
>> -- 
>> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
> 



-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3020

On Thursday, August 25, 2016 at 7:51:17 PM UTC-6, mjm...@aol.com wrote:
> Mark Lemmert <mark.lemmert> wrote:
> > Michael,
> > 
> > Thanks for confirming!
> > 
> > 
> > Do you know if there are applications where drawing during the veritable
> > blank interval would be more desirable than page flipping?
> > 
> > Thinking more broadly than the Apple II hardware, I’m speculating that
> > using the vertical blank for drawing was mainly used on hardware that
> > didn’t have page flipping available. 
> > 
> > 
> > Thanks.
> > 
> > Mark
> 
> Page flipping is definitely the more general approach, but in
> RAM-constrained applications, syncing to Vblank and staying ahead of the
> refresh is sometimes a necessity. 
> 
> For any animation that can be completed in a millisecond or two, it's
> pretty easy. If the animation requires several milliseconds, it may be
> necessary to order the updates top-to-bottom to stay ahead of the refresh. 
> 
> Lots of games have a large playfield but relatively small moving elements,
> so the animation can be done completely during vertical blanking. 
> 
> > On Wednesday, August 24, 2016 at 11:57:43 AM UTC-5, mjm...@aol.com wrote:
> >> Mark Lemmert <mark.lemmert> wrote:
> > 
> >>> But, my theory was/is that part of the problem occurring was that the
> >>> screen draw was simply too slow as evidenced by being able to see parts
> >>> of the screen in different frame states, and thus drawing in the vehicle
> >>> blank would possibly make it worse by adding delays, or at best only
> >>> solve part of the problem. Basically, if it's too slow, it's too slow,
> >>> was my thinking, and I didn't see how altering the draw timing would help that issue.
> > 
> > 
> > 
> >>> 
> >> 
> >> I agree with your diagnosis. 
> >> 
> >> Drawing during vertical blanking is only effective when the actual drawing
> >> can stay ahead of the raster scan. 
> >> 
> >> If drawing is slower than display refresh, then page flipping is much more
> >> effective, and the flip can be synchronized with vertical blanking for even
> >> better results (if the additional wait is acceptable). 
> >> -- 
> >> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
> > 
> 
> 
> 
> -- 
> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com


Has anyone determined what size of area can be drawn within a vertical blank period?

[toc] | [prev] | [next] | [standalone]

#3023

> Has anyone determined what size of area can be drawn within a vertical
> blank period?

4550 cycles = 65 cycles * 70 lines, from:

http://rich12345.tripod.com/aiivideo/vbl.html

And, 4550 cycles is just the VBL period, you can get more cycles (17030
total) by "racing the beam" as others have mentioned -- and that's at 60
frames per second!

As, for how much screen area can be painted in 4550 cycles?

Coding for speed:

1137.5 bytes = 4550 / 4 cycle STA absolute instruction

That's painting more than the entire GR, GR2, TEXT or TEXT2 screen with the
same byte.  Or, you could paint over an eight of the hi-res screen with the
same byte.

I think an interesting thing to do would be to flip the graphics modes while
racing the beam:

https://www.youtube.com/watch?v=KD6ocf_0Bkw

[toc] | [prev] | [next] | [standalone]

#3021

That makes sense. Thanks!


Mark


On Thursday, August 25, 2016 at 8:51:17 PM UTC-5, mjm...@aol.com wrote:
> Mark Lemmert <mark.lemmert@gmail.com> wrote:
> > Michael,
> > 
> > Thanks for confirming!
> > 
> > 
> > Do you know if there are applications where drawing during the veritable
> > blank interval would be more desirable than page flipping?
> > 

> Page flipping is definitely the more general approach, but in
> RAM-constrained applications, syncing to Vblank and staying ahead of the
> refresh is sometimes a necessity. 
> 
> For any animation that can be completed in a millisecond or two, it's
> pretty easy. If the animation requires several milliseconds, it may be
> necessary to order the updates top-to-bottom to stay ahead of the refresh. 
> 
> Lots of games have a large playfield but relatively small moving elements,
> so the animation can be done completely during vertical blanking. 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web