Glenn Saunders wrote:
> I've been procrastinating for some time but last night I started tinkering
> around with trying to wedge in the missile code into the Death Derby Kernel
> and I'm thinking that the best I can possibly do would be to generate one of
> the two missiles, with code that would have to span both of the scanlines.
> It doesn't look like I have enough time for even this. The problem with
> using the missiles is there is too much overhead involved vs. the players.
> With the missiles, I have to selectively enable them, set fine control, and
> set width. That's six writes right there if I intend to update both of them
> on the same scanline.
You can reduce this to four writes, if you only enable the missile once
and not always during the drawing.
> Not only that, but to save ROM I'm storing all the fine control and width
> data in the same byte.
> So when I write the width register, I need an additional AND %00110000 to
> mask off the unnecessary bits otherwise I mess up the players in the
> process. Since the significant bits of the width and the motion registers
> are not aligned in an optimal way, I need to shift bits also. All this adds
> considerable overhead!
You don't need to AND *and* shift if you store the bits this way:
mmmmss00 (m=HMMx, s=NUSIZx)
Then you write the HMMx value first, then shift twice and write the
NUSIx value.
Here is a code fragment:
tya ; 2
( sec ; 2) you might be able to avoid this
sbc xPos ; 3
beq .enable ; 2³ this is new!
adc #HEIGHT ; 2
bcc .disable ; 2³
lda (ptr),y ; 5 bytes stored as: mmmmss00
sta HMMx ; 3
asl ; 2
asl ; 2
sta NUSIZx ; 3
.continue: ; total cycles: always 26 (+2)
...
;this code should be positioned outside the main loop to avoid
additional jumps for the long run.
.enable: ; 8
lda (ptr),y ; 5 bytes stored as: mmmmss00
sta HMMx ; 3
lda #2 ; 2
sta ENAMx ; 3
nop ; 2 waste two cycles for constant timing
bne .continue ; 3
.disable: ;12
lda #0 ; 2
sta ENAMx ; 3
sec ; 2 keep carry state constant
nop ; 2 waste four cycles for constant timing
nop ; 2
bcs .continue ; 3
Still you need at least 26 cycles per missile. With two missiles this
would cost you 52 cycles per scanline or 104 out of 152 cycles of your
two line kernel. You know, this is to much :(
BUT...!!!
...you could reduce the vertical resolution (not the positioning!) to two
pixels. Then you would need four (2x2) kernels, depending if your missiles
start at an odd or even line. That way you could reduce the missile
cycles down to 52, plus a few extra cycles (~6..10) because you have to
clear the HMMx registers.
Now let's calculate (best case):
58.. 62 cycles for the missiles (with/without SEC)
34.. 36 cycles for the playfield (28 for drawing, 6..8 for disabling)
36.. 40 cycles for the players (with/without SEC)
13 cycles for the loop stuff (see my last mails)
6 cycles for HMOVE
0 cycles for WSYNC (it think you'll have to go that way)
---------------
147..157 cycles
Boy, this is getting *very* close (and over) to the 152 limit, but I
still think it might be doable.
What could finally kill you is, that you have to do a lot of writes
within a very fixed time. But the only way to find out is, to start to
do the actual coding for the four kernels.
Have fun!
Thomas
_______________________________________________________
Thomas Jentzsch | *** Every bit is sacred ! ***
tjentzsch at web dot de |
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
