At 03.07.2002, 05:17, Paul Slocum wrote:
> I just spent a couple of hours playing with my kernal, and I don't think
> it's going to be possible to animate the marbles. The problem is that
> there is so much going on in my kernal that I had to resort to filling
> zeros into the page that has my player image data.
Hm, if that helps, I found you a few cycles. Instead of:
lda INPT0 ;3
bmi paddles1 ;2 or 3
sty padVal1 ;3
paddles1
...
STA WSYNC ;5
which will cost you 13 cycles, you could do:
lda INPT0 ;3
bmi paddles1 ;2 or 3
sty.w padVal1 ;4
paddles1a
; the following code must be positioned outside the main loop, but
inside 128 bytes (e.g. before scanLoop or quitScanLoop):
paddles1 ;
bpl paddles1a ;3 = 9
By avoiding WSYNC you can save 4 cycles here.
And then I found this:
txs ;2
...
tsx ;2
txa ;2
ldx #ENABL ;2
txs ;2
cmp temp3 ;3
php ;3
cmp pwr1y ;3 <- timing was wrong here!
php ;3
tax ;2 = 24
Here you could save two cycles by writing:
stx tmp ;3
...
ldx #ENABL ;2
txs ;2
ldx tmp ;3
cpx temp3 ;3
php ;3
cpx pwr1y ;3
php ;3 = 22
And you could even setup the stackpointer somewhere else, e.g. directly
before loading X with a different value. That would give you another 6
cycles. But I'm not sure if this will work, because you are using the
stack register already.
If you wouldn't use it, you could this too:
ldx #ENABL
txs
cmp temp3
php
cmp pwr1y
php
txs <- setup stackpointer for the other kernel!
That could save you two cycles in total.
And then there is the jump to messageDisplay, maybe a branch to a jump
to messageDisplay could save you one cycle there.
> Not only that, but I
> couldn't even find enough time or memory to cut off the drawing of it near
> the top of the page, so I had to use TWO pages to represent the player
> image with two different offsets. So as is, I have to use 512 bytes for
> each player shape! Ouch! :o(
Can you explain a bit more detailed why/where exactly you need those 256
bytes twice? A few more comments inside the kernel would be helpful too
(e.g. what is inside the X-register which you have to change quite
often?).
And why did you have to do code 26(!) kernel lines? Can you describe
what is going on in each of those lines? It looks that you are doing the
same over and over and use the remaining cycles for
paddles/colors/looping etc. Maybe with some optimizing you can reduce
the number of kernel lines too.
If we find some extra cycles, you might be able to avoid wasting 256
bytes for each object and perhaps use my "skipDraw" code. But that would
require finding at least 18 cycles (now: 2*8, skipDraw: 2*17) and I
think that's nearly impossible.
Even with your current code, the full 256 bytes make no sense, because
the values for Y are not ranging from 0..255 when drawing the ball. You
initialize Y with 156, so that's the maximum of bytes you should have to
waste.
> If I could find a way to reduce it to 256 bytes per player graphics shape,
> I could add at least a few different shapes. But I haven't been able to
> figure out a way to do it. I've pretty much conceded that I won't be able
> to animate the marbles, but I figured I'd post my kernal and see if anyone
> wants to try to squeeze a few cycles out. Kernal A has less free cycles
> than Kernal B, so that's the one to look at. I only found about 10 free
> cycles in the 13 line kernal loop (one of the WSYNCs can be removed).
Without total timings, it's hard to optimize here, so I've added some
@xy. :-) (But the extra cycles from above might already help :-)
BTW: I found some places where you timed lda(),y with 4 instead of
5 cycles.
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/
