Glenn Saunders wrote:
> I'm hoping the stuff at the top of the
> screen that Thomas mentioned before isn't there anymore.
Yes, it's gone.
But now you have another major problem:
In the kernel you are using the stack-pointer without restoring it
before the end of the subroutine. This may work with Stella, but not
with z26 or the real thing. After I fixed that, the screen looks ok.
> I also went through and tried to optimize a little bit to help eliminate
> some badly timed playfield rewrites around the border area. Changed some
> labels and other minor stuff.
> I also realigned the sprite graphics and put in as much of the sprite setup
> code as I could without actually running it. Actually, a lot of it is
> running, it just never draws sprites. I'm hoping Thomas and Manuel can
> take a look at it to see if I'm setting this all up correctly.
I'm not sure, if P0_CurrentFramePtr will become the pointer to the car
data, then it's setup looks ok.
The value for CarDataAlign seems to be a bit high ($65 = 101), I don't
think your kernel will be 101*2 lines tall. Y is loaded with
PlayfieldHeight = 88, so that's would be enough for CarDataAlign too.
But that doesn't hurt anything, as long as your data fits into the rest
of the page.
> I do have a question though, regarding the sprite stuff.
> If it takes all 76 cycles to get to the point where a sprite's graphics are
> written to the register, then that does prevent the sprite from appearing
> on that scanline, doesn't it?
No, the sprite is still showing the old data. When all writes occur at
cycle 76, then the sprite will look like it's moved down one line.
> Or more to the point, if the sprite is going
> to show up in mid screen, if it takes longer than half of 76 cycles to
> figure out whether to draw the sprite and if so, where to get the sprite
> graphics, then you aren't going to be able to display him in time.
> I was wondering what the effect of this timing tends to be.
> I'm a little concerned that if it takes me all of every other scanline to
> figure out how to position all 4 objects and write to their registers that
> on those scanlines I'll have weird problems with sprites getting rewritten
> in the middle (like a tearing effect) or just not showing up at.
You'll get a tearing effect, when the writes happen to late. If all
objects can be displayed at the very left, then all your writes have to
finished before cycle 22.
But you can try to move many preparations into the previous scanline.
Now, there are still lot of NOPs, which you could use for that
preparation code.
Actually the result will be, that the first part of the PF-lines is used
for displaying the playfield and the second part for the objects. And
then in the object-lines you'll may also have to prepare some setup for the
PF-lines.
So the whole kernel code is moving a partial line before the actual
display line.
This might getting a bit complicated. To help solving this problem, I'm
calculating for each TIA write the interval, where it might occur (i.E.
PF1 = L2_59..L1_27), and the time I need to load and write it. Then I'm
trying to bring those little pieces into a good sequence, but still
keeping in mind possible other restrictions.
I still expect the timing to get *very* close, because you want to
position all objects with single line precision. It might not be
possible without some compromises.
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/
