Re: [stella] Collaboration

Subject: Re: [stella] Collaboration
From: Thomas Jentzsch <tjentzsch@xxxxxx>
Date: Sun, 19 Jan 2003 20:48:46 +0100
Glenn wrote:
> But the former is more of an issue.  I'd be happy if the 2nd scanline
> was _always_ white if you wanted to make it easy on yourself.

I have commented this problem in the code. Making the second scanline
always white looks like the only solution. Just add
  lda #$0e
  sta COLUPF
before the "; disable grenade:" comment and reduce the following SLEEP
from 9 to 4.

> In BARRIER mode the color tearing might be inevitable I guess unless
> you blanked those lines.

No, instead of loading #GRENADE_COL you could load a variable containing
GRENADE_COL or BLACK and decrease the following SLEEP. But then you will
limit the grenade a little bit more (3 pixels) from the left.

> The other issue is in relation to vertical wrapping.  Skipdraw will not 
> allow for the sprite to appear on screen more than once, so this will force 
> a dead zone while wrapping, right?  I can deal with this but I have to make 
> sure the AI doesn't make the zombies hide in there.  Right now the sprites 
> are popping but on one of the previous builds they were wrapping.  Can you 
> make them wrap next?

I hope that vertical wrapping will just require some changes to the
setup code. Else we would need an extra kernel loop for the top or the

> Also, I noticed that by going to the interleaved missiles, the HMOVE lines 
> are back to being every other line, so sprites COULD show through.  Is the 
> tearing fixed enough to allow the zombies to extend completely across the 
> screen?  If so we can go back to the safe zones being one-playfield-pixel 
> in width which will look a bit more authentic.  (I would still keep the 
> cars from extending.)

Give the background some color and you will see what has changed. The
tearing is nearly 100% removed, only the *very* right you *might* notice
some problems with M0.

> Also we should be mindful of how much RAM is being used.  I see 36 bytes 
> used so far.

> The kernel right now doesn't point to RAM for the tombstones, so remember 
> that it's going to eat up 44 bytes.  So we're already at 80 bytes of 
> RAM.  We're going to need ram for score, sound envelopes, animation, and 
> more.  So it's going to be tight.

There are a few variable remains from the single line code (tmpVar2,
krnlIdx, vecKernel, 4 bytes in total). And some are only temporary
needed for the kernel and can be reused for storing other temporary
variables. But you are right, RAM will be tight (as always 

> Is there any way we can do the tombstones via the Centipede %10101010 / 
> %01010101 bit-masking trick (where each byte stores two rows of information 
> since the mushrooms are spaced out and alternate) or is there not enough 
> time on the 2nd grenade line to set that up?  If we could do that we could 
> gain 22 bytes of RAM.

The missiles already eat up a lot of cycles and make the timing very
close. There are 6 free cycles in the playfield code, but we would need
8 for doing this:
  lda RAM1,x
  and #%01010101
  sta PF1
  lda RAM2,x
  and #%01010101
  sta PF2
  lda RAM1,x
  and #%10101010
  sta PF1
  lda RAM2,x
  and #%10101010
  sta PF2

And we would have to start that code at an earlier cycle. There is no
space for this at the moment, else we would cause some more tearing at
the (very?) right.

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

Archives (includes files) at
Unsub & more at

Current Thread