Re: [stella] Animating the Marbles

Subject: Re: [stella] Animating the Marbles
From: Paul Slocum <paul-stella@xxxxxxxxxxxxxx>
Date: Wed, 03 Jul 2002 16:11:16 -0500
Well, I made a lot of progress changing my level data around to spread across banks. I managed to find some ways to dramatically reduce the size of the level data. So if none of this kernal fix-up works, I think I can at least isolate the two kernals in a bank with nothing else, which should allow for 2 or 3 more player shapes even with the huge 512 byte requirement. And if I can get it down to 256 bytes, I can have some really nice animation.


Unfortunately, since my Marble data is stored in ROM and not copied to RAM, I can't use a ROL/ROR on it. And I don't have any cycles left to do it between reading it from ROM and writing it to the TIA.


That seems like it would work, but I don't see how I could reverse the indexing without using a bunch of kernal cycles or writing another alternate kernal. (I already have two!) :o)

Thomas: -------

I tried the idea of interleaving the color data, but I ran into a problem: to make it work right I have to AND out the zero bit on the X register, which best I can tell, takes as many cycles as doing an ASL on the X like I was doing. I couldn't figure out a way to solve this.

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

I just accepted that as a fact of life early on. :o( But if other games can get away with an HMOVE comb, I figure I can get away with that. !o) It doesn't look quite as bad on a real Atari. I might try to clean up the timing a bit when the game is done and I know the kernal won't change any more.

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.

I just don't think there's any hope of finding 4 bytes. Notice I'm using everything from $80 to $FF during the kernal. I cringe to think about trying to find even 2 bytes.

I think I'm just going to hope to squeeze out enough cycles to do your original trick. It looks like it would take 20 cycles to do both marbles. Maybe I could even find a way to alternate doing this check on player 1 and 2 with each loop cycle. Is there any more efficient way to do this:

Currently I have this:

        lda (pMarble),y  ;4*
        sta GRP0         ;3

And I would change it to this at a max cost of 10 cycles, I think:

        tya               ;2
        adc #13           ;2
        adc pMarble       ;3
        bcc noMarbleReset ;2/3

        sta pMarble       ;3
        jmp marbleReset   ;3

        lda (pMarble),y   ;4*
        sta GRP0          ;3


---------------------------------------------------------------------------------------------- Archives (includes files) at Unsub & more at

Current Thread