>>But, as far as VDEL's original intended use (it's net effect), it is
>>dependent upon where we are drawing in the scanline.
>
>I don't quite grasp how VDEL is used in six digit scoring yet.
Ok, here's the scoop. Each graphic is 8-bits across, or 8 color clocks.
We will need to update the data quite fast. So, the fastest way to update
a register (like GRP) is with a store command, un-indexed, just omething
simple like STA GRP0. This is 3 cycles, or 9 color clocks. Where do we
store all of this data? There is not enough time for loading the stuff and
storing it to the graphics registers when we are directly writing to the
gfx registers in accordance with the electron beam.
To hold the stuff, we have GRP0, GRP1, GRP0A, and GRP1A. But, we can only
hold data in 3 of these at a time, because a store to GRP0 will copy GRP1A
into GRP1, and vice versa. So, one GRPx and it's GRPxA will always be the
same.
We also have the X register , Y register, and the accumulator to hold data.
So, we wait until after the first graphic is drawn, P0, then do stores from
the accumulator, X, and Y registers to move the cached data into the
graphics registers speedily.
>By storing to GRP0 it automatically moves GRP1 data from cache to the main
>register?
Yes.
>So it has the opposite effect on the other player or are you
>illustrating a mode where VDEL is exclusive to a particular sprite?
Yes. Turning on VDELP0, for example and doing a STA GRP0 will put data in
GRP0A, while doing a store to GRP1 will move data from GRP0A to GRP0.
>> GRP0 and GRP1 are what's actually displayed. Now, if we
>>do this store in the scanline AFTER the P1 graphic, P1's graphics will
>>change on the next scanline. If we do it before, P1's graphic will change
>>on that very same scanline.
>
>Which is only an issue with sprite copies, I suppose.
>
Actually, this is quite important in regular gameplay. I don't have a good
example right now, but I know a lot exits. The Alligator People prototype
will tell you as much, as the guy's hair sometimes disappears, probably
because the color register is being updated outside of HBLANK. I know
better examples exist, but I can't think of a good one now.
>So you have to interleave your kernel in a way? Doesn't this have the net
>effect of being like a single line kernel anyway because you are executing
>player write instructions on every scanline?
Yes, but here's what's neat.
You can do this:
STA WSYNC
update P0 graphic
update p0 color
etc..
STA WSYNC
update P1 graphic
update P1 color
etc...
These must almost always be done in HBLANK, because loading these registers
is usually done with an index, which takes more than 3 cycles, i.e.
LDA PlayerGFX,X
STA GRP0
LDA PlayerColor,Y
STA COLUP0
I don't have my cycle counting docs with me, but the stores take 3 cycles
each, and I think the indexed take 4 or 5, making at least 14 cycles lost
during HBLANK. If the playfield has to be updated here too, that's another
few cycles, so not having to worry about a player graphic is a great way to
save cycles. If these were updated on the screen, something might happen
like with the guy from Alligator People's hair. I know I've seen it happen
before. The Super Cobra chopper sometimes has its colors off by one
scanline depending on its horizontal position, if I can remember.
Ooh! And I think Entombed updates its playfield during screen time (hope
that's what I'm thinking of).
>So what I was thinking is that in a 2-line kernel you update the player
>graphics every other line (on the same line) and since the TIA will keep
>drawing whatever you last put into it each line, this has the net effect of
>two scanline high sprites.
Well, they are two scanlines high, but see above. Players would be updated
alternately.
Mentos,
-John K. Harvey
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
