Re: [stella] Re: the big sprite

Subject: Re: [stella] Re: the big sprite
From: Erik Mooney <emooney@xxxxxxxxxxxxxxxx>
Date: Mon, 6 Apr 1998 14:39:12 -0400 (EDT)
> Colour changes would be possible, but they would be 11 cycles, since
> we have to change colour for both player graphics. The ball and the

Right, forgot about that.

> playfield thing would be a bit difficult, since conditional branches
> would mess up the timing. Also, since the players are moveable, the
> writes to PFx or ENABL would occur at different cycles in the scanline.
> That means graphics left of the player would be affected one line
> earlier than graphics right of the player, which would look a bit 
> jerky.

Alright, playfield is out.  The ball is still possible, even without
branching.  Assuming Y is used as the counter during the draw-sprite
routine, and the stack has been preset to ENABL:

AND #$F8	;this is a constant for ball height - must be multiple of2
PLA 		;to reset the stack pointer

14 cycles, no branching, to do the ball... 15 if you replace the constant
with a variable ball height.  *Barely* enough to do that, the wide sprite,
and colors for said sprite - you said there were 28 cycles free at
double-resolution.  (you said there were only 22 contiguous and six
separate - the PLA can go in the six separate, and the other 22 are

As for display inaccuracy, I don't think it's a concern... given the very
muddy collision-detection of the real MK games, I hardly think that
misplacing the ball or the color by one scanline is a concern.

Archives (includes files) at
Unsub & more at
Don't post pirate BINs to Stellalist.  Be a programmer, not a pirate.
Write the best game, win framed autographs of famous Atari alumni!!

Current Thread