>
> Before I reinvent the wheel, can anybody comment on the feasibility of
> producing a non-repeated playfield by writing PF0, PF1 and PF2 chasing the
> scanning beam before data required for the repeated section? Of course,
> there would be two lots of writes required per scan line, but I'm interested
> to know if its been done. What I'm asking, I guess, is when it comes to
> drawing the right half of the PF, does the hardware re-read the PF
> registers, or is it buffered internally somehow?
It was done in Combat. If you look at the source code, you'll notice
that the scores for the left and right player are drawn into the exact
same register, at different times.
Indeed, this is REQUIRED to use the playfield for much of what it's
used for, such as in Pac-Man and Centipede, Crystal Castles or any
other game where the playfield is modified according to where the
player moves. Oh, and Dig Dug and Oystron and, hey, INV too!
Probably also Circus Atari. Oh, yeah... Donkey Kong also, it
did this at single-scanline resolution with mobile sprites, though
on a narrow playfield. And any of the Breakout-like games.
I think my cycle-counting guide goes into how to do this. It's
an essential skill. If it's not covered, I should update it.
What I's really like to explore is the drawing engine for Amidar.
Now that's impressive. Single-scanline resolution sprites, a
playfield that's dynamically generated for the most part, and also
single-scanline most of the way through. And, there are more than
two sprites. That is genius work.
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html
