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.
Joel:
-----
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.
Chris:
------
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
noMarbleReset
lda (pMarble),y ;4*
sta GRP0 ;3
marbleReset
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
