Re: [stella] Animating the Marbles

Subject: Re: [stella] Animating the Marbles
From: Thomas Jentzsch <tjentzsch@xxxxxx>
Date: Wed, 3 Jul 2002 21:13:28 +0200
At 03.07.2002, 18:07, Paul Slocum wrote:
> The idea is that you store each of the indexed playfield bytes in a buffer
> when you have extra time towards the start of the loop, and a few scanlines 
> into the loop, you'll have them all in a buffer.  Before they're in the 
> buffer you have to read them all with indexes which takes an extra 
> cycle.

Yes, I've noticed that. And I understand, that this will help more, if
you have many kernel lines coded.

> Plus I have to use four ASLs on the PF0 data.

You could use a table for that, but then you had to reload the X

BTW: At the top of the loop you store the new value for left PF0 in
pfBuffer and soon after that reload it for calculating the value for
right PF0. If timing allows it, you might be able to get rid of
reloading pfBuffer. 

> The reason there are two 13 line kernals is to alternate which playfield 
> lines are colored, and to alternate which paddles are read.  The kernal is 
> so fragile that I couldn't figure out a way to use one kernal to do 
> this.

I see now.

> The hardest part is the coloring.  The color change in the middle of 
> the screen has to be timed perfectly.

There seems to be a little timing problem, because the left vertical
paddle indicator get the color from the right screen.

> The problem is that to display it at the top and bottom I need roughly 140
> empty bytes above and below the marble image.  That's fine, except there's 
> no way to do it without indexing across a page boundary, which causes an 
> extra cycle on each line.  My kernal totally breaks with an extra cycle per 
> line.

Yes, you must avoid those penalties at all costs. But I have an idea:
If you store the odd and the even lines of the marble graphics in two
tables and use two pointers for each player (this will cost you 4 bytes
of RAM), then you only need 70 Bytes before and after the image. Then
you can overlap the empty bytes of the two tables and still can stay
inside one page.

This will look like this:
    align  256
    ds     70, 0
    .byte  "even lines marble data"
    ds     70, 0
    .byte  "odd lines marble data"
    ds     70, 0

And you can also save every second DEY then. The only problem is, that
you can't divide 13 with 2. But maybe you can reduce the kernel to 12
lines (can be divide by 3, 4 and 6 too :-).

Or you use could some separate code only for the 13th byte.

Have fun!
Thomas Jentzsch         | *** Every bit is sacred ! ***
tjentzsch at web dot de |

Archives (includes files) at
Unsub & more at

Current Thread