[stella] counting time instead of lines (was: Re: More playfield graphics(thanks Nick!))

Subject: [stella] counting time instead of lines (was: Re: More playfield graphics(thanks Nick!))
From: Piero Cavina <p.cavina@xxxxxxxxxxxxx>
Date: Wed, 12 Mar 1997 15:57:48 +0100
At 17:42 -0500 11-03-1997, Erik K Mooney wrote:

>    LDY #192       ;We're going to use Y to count scanlines.
>
>;Everything is already set, so let's just count scanlines.
>;We're at the beginning of WBLANK of the first TV line right here.
>ScanLoop
>    STY COLUPF     ;Keep changing the playfield color every line for some
>                   ;neat-looking stripes.
>    STA WSYNC      ;Wait for end of scanline
>    DEY
>    BNE ScanLoop   ;Count scanlines.
>    RTS

I'm currently working on a demo program that includes sprite reuse and
multiple copies. I have a lot of problems with the kernel (the 192, or >200
for Pal, scanlines loop) because it's not obvious to know how many lines
I've already drawn and how many are still to be drawn. This happens because
the screen is divided into zones of different height which change according
to various game parameters.
I think this is a common problem as soon as games becomes complex, and you
haven't planned everything from the beginning (tell me which Atari 2600
programmer ever planned everything...? :-) )

The consequence is that almost every time I improve the program, I lose the
color or vertical sync (or both!) because I haven't drawn the correct
number of lines before overscan and vblank. This is very annoying and slows
down the developement.

Now I have this idea: why don't we handle the kernel loop with a timer,
like we do for Vblank?

In practice:

 - start a timer for 192*76 cycles
 - begin the scanlines loop

 - draw the lines

 - close the loop, we must be sure that we've drawn no more than 192 lines
 - wait until the timer is expired, thus drawing the missing lines

This way the correct number of lines will always be drawn regardless of
what happened during the inner loop, where we could have drawn 188, 190 or
so lines.

A possible problem could be that TIM64 isn't enough for so many cycles, so
we could have to use TIM1024 followed by TIM64.
I hope I've been clear enough. I'll try this idea this evening :-) - let me
know what you think.


Ciao,

P.







--
Archives available at http://www.biglist.com/lists/stella/archives/
E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.

Current Thread