At 22:27 01.11.98 GMT, you wrote:
>Not quite. I tried what you just said - RESP0/RESP1/RESP0/RESP1. The
>first RESP0 occurred on cycles 25, 26, and 27. I get Player 0 sprites at
>pixels (counting from 0) 34, 52, 68, and player 1 sprites at pixels 43, 61,
>77. I'm dead sure about those numbers. Note the 18-pixel gaps between the
>first two copies of each player.
In that case your VCS must be different from mine. When I run
dbltrbl.bin, that John just posted, I get the first copies of
player0 and player1 at pixel 36 and 45. I get the same results
on my 'large rainbow' jr., on my 'small rainbow' jr. and on the
oldest six-switcher that I have (all PAL of course). What model
do you use? Can everybody with a Supercharger please try out
dbtrbl.bin and tell us at which position the leftmost pixel occurs?
Please also mention what VCS model you use.
>If you want to see this effect more clearly, instead of the second STA
>RESP0, make the second instruction STA $2000+RESP0, to delay it an extra
>cycle. The gap between the first two displayed copies of player 0 this way
>makes it clear that the first displayed copy is coming from the first hit
>and not the second - those first two copies do not match any possible NUSIZ
>spacing.
That is a whole different case. As John has mentioned, doing one
cycle more will get you only two copies. I just noticed, that
hitting RESP0 six cycles after a previous RESP0 is two pixels
into the second sprite and not one, as I kept saying. So seven
cycles will be five pixel into the sprite. Therefore I think
the trick to get three copies of a sprite is to hit RESPx
after the counter for the five pixel delay for a sprite to be
displayed has been started, but before it has expired. That
would also explain the half sprites and the fading sprites,
that others experianced.
Ciao, Eckhard Stolberg
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
