Re: [stella] Asymmetrical Reflected Playfield

Subject: Re: [stella] Asymmetrical Reflected Playfield
From: Erik Mooney <erik@xxxxxxxxxx>
Date: Fri, 21 Sep 2001 22:33:33 -0400
On Fri, 21 Sep 2001 15:41:55 -0700, you wrote:

>For Death Derby I envision that PF0 gets written once at the start of the 
>playfield after the score, and then never has to be rewritten again across 
>the entire psuedobitmap screen.  So I'd only have to do 4 writes to the 
>playfield registers.  I could then have a 2-line kernel where on odd lines I 
>draw the tombstones and on even lines I quickly blank out the middle of the 
>playfield and load up the sprites.  And hopefully in the spaces between 
>there will be enough time for the necessary logic involved in all this.  The 
>compromise would therefore be for the tombstones to be striped, but the PF0 
>border would still remain solid.
>I'd then only need 4 20-byte-long strips of RAM for each playfield write and 
>no last-minute bit shifting or masking would be necessary to get them onto 
>the screen.

Have you given thought to stealing from Centipede?  What if you set up the
tombstones like the Centipede/Millipede mushroom field?  Each byte in RAM
actually stores two rows of playfield data, and you mask them with AND
%01010101 or AND %10101010 .  That halves your RAM usage.

Then, what if you rigged it to have a little space vertically between rows
of tombstones, again like 2600 Centipede/Millipede?  Put two blank
scanlines between rows of tombstones.  Then in the two extra lines, do
your masking calculations, doing a load/AND/store for each of the four
playfield bytes to four RAM locations.  Now, the code that does all the
tight-timing PF rewriting only needs to make static zeropage loads at 3
cycles each, instead of longer indexed loads and worrying about loop
control!  That might even get enough cycles back to not have to stripe the

Archives (includes files) at
Unsub & more at

Current Thread