At 07.29 08/04/97 GMT, Erik Mooney wrote:
>>>I had a routine that needed to rewrite both GRP registers each line while
>>>updating all three PF registers twice per scanline (non-repeating
>>
>>hmmm... looks like you're working on something very interesting... :)
>
>I was working on a kernel for an Arkanoid-type game, using the playfield
>for the walls and the GRP registers for the capsules (and of course the
>ball for the ball). It wasn't working out the way I had it - there just
Are you still working on it? A good Arkanoid game is missing from the 2600
library, as the old Breakout games are defintely aged, and "Off the wall" is
awful (IMHO).
>weren't enough cycles. Trimming it down to 32 blocks wide and setting
>PF-Reflect so it didn't use PF0 (see Super Breakout),
hehe... I've had to do just the same to add the background grid to my
current demo. The 8 extra blocks that could be obtained with PF0 caused more
troubles than advantages.
And 32 is a power of two...
>>>and checking the ball's Y coordinate and writing to ENABL if necessary
>>
>>There's that incredible PHP trick for this... I always wonder if Stella
>>designers had already it in mind when they created the hardware.
>It is a very nice routine, fast and does not branch.
(...)
>I think the Stella designers must have had this in mind, because what other
>reason is there for ENAxx using bit 1 instead of bit 0 for data? This
>works very well for single-height objects. And considering this routine is
>used in Combat, I'm pretty sure it was intentional.
Uh, maybe the correct question was: had the _6502_ designers that trick in
mind? Afer all, what's the use of PHP if not for tricks like that?! (BTW,
how many years before the 2600 was the 6502 designed?)
>Is there an easy way to modify the PHP routine for a
>multiple height object? Looks like you'd SBC the two numbers and if the
>result is less than N you'd enable the object.. this would work with an
>easy way of setting the Z flag from the carry flag without a branch.
>
>Warning, untested code! For the following code, MissileY equals the LAST
>scanline on which you want the missile to display
The LAST scanline! That's very clever, I hadn't thought of it!
>LDX #$1E ;for ENAM1 - could also be used for ENABL or ENAM0
>TXS
>LDA MissileY
>SEC
>SBC Scanline ;A has (MissileY - Scanline). If it is >=0 but <4,
> ;we want the carry clear.
>CLC
>ADC #252 ;If 0 <= A <= 3, the carry will now be clear.
>LDA #00
>ADC #00 ;If the carry was clear, A now = 0, so Z is set.
>PHP ;Plug it into ENABL.
Looks like it could work...
Usually you will be doing that inside a loop; you can keep LDX#$1E and TXS
outside the loop, then do a PLA after PHP to restore the stack pointer to #$1E.
>Not bad, 21 cycles to handle an object of any height..
(...)
>Comparing with an alternate approach, using branching:
>LDX #0 ;+2 2
>LDA MissileY ;+3 5
>SEC ;+2 7
>SBC Scanline ;+3 10
>CMP #3 ;+2 12
>BCS L1 ;+2 14
>LDX #2 ;+2 16
>L1 STX ENAM1 ;+3 19(18 if branch taken)
>
>This takes 18-19 for one object, 36-38 for two and 54-57 for three, so the
>timing is pretty close to the same. Unless someone can optimize one
>instruction out of either routine?
This way you lose X (or Y), so the PHP trick is definitely better.
Ciao,
P.
--
Archives available at http://www.biglist.com/lists/stella/archives/
E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
