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
tombstones.
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
