RESPx, NUSIZx, and Player Positioning

[SeaGtGruff]

I'm well aware that when you strobe RESPx, the player's "coarse" position will be 5 color clocks after the strobe. But is this affected by the player's width? That is, will the player be positioned 5 color clocks after the strobe even if the player is set to double-width or quadruple-width? I would do a little experiment to answer the question myself, but my Windows 8 computers aren't set up for Atari programming, and my Atari 2600 and programmable carts are currently unavailable anyway.

 

[Thomas Jentzsch]

IIRC the width has no influence. But I haven't tested this too.

[SeaGtGruff]

Thanks, Thomas. I know that at one time Stella was positioning them 6 clocks after the strobe instead of 5, but I never tested it on actual hardware to see what the correct behavior is.

 

I guess it doesn't matter, anyway, since I figured out that my idea won't work.

[ZackAttack]

What was the idea that won't work?

[Omegamatrix]

Width does make a difference. It takes an extra clock for double and quad size just like you see in Stella.

 

 

I wrote a test rom and tried it on a light sixer as well a four switcher:

 

 

PosWidth.zip

 

 

Push left/right to change the coarse position, and up/down to change NUSIZ0.

[alex_79]

It's worth mentioning that the offset for missiles and ball is always 4 pixels, no matter the size of the object.

Here is a slighty modified version of Omega's test rom to show that. The 3 added lines are Missile1 (always 1 pixel wide), Missile0 and Ball (width change when pushing joystick up/down). As you can see, Missiles and Ball are always positioned 1 pixel on the left compared to Player1.

PosWidth2.zip

[SeaGtGruff]

I thought there might be a difference, but I wasn't sure. I gather that the difference is the same for double-width and quad-width, +6 clocks?

 

My idea was to see if I could cover the screen with quad-sized players, lined up to the playfield pixel positions, so that each 40x192 position could be set to the background, playfield, or player colors. Unfortunately there isn't time enough to change sizes, strobe, load/store the graphics data, strobe again, and resize again.

[Omegamatrix]

I thought there might be a difference, but I wasn't sure. I gather that the difference is the same for double-width and quad-width, +6 clocks?

Yeah, double and quad are both +6 clocks. I really wish though that quad was +7 clocks since that would allow you to fine position P0 and P1 without HMOVE (and thus avoid HMOVE bars). The early HMOVE at cycle 73/74 is not compatible with all 2600's so there is some benefit if another way could be found. The idea is simple. While not drawing the Px object, change it's size and hit its RESPx register. Then resize it again and you can draw it at then new position. It would work well in some cases.

 

 

My idea was to see if I could cover the screen with quad-sized players, lined up to the playfield pixel positions, so that each 40x192 position could be set to the background, playfield, or player colors. Unfortunately there isn't time enough to change sizes, strobe, load/store the graphics data, strobe again, and resize again.

You might be interested in the Parrot Kernel then. It uses 18 playfield size pixels per row, and each pixel can be one of three colors. It has variable height and each row can have a different set of three colors.

[SeaGtGruff]

Yeah, double and quad are both +6 clocks. I really wish though that quad was +7 clocks since that would allow you to fine position P0 and P1 without HMOVE (and thus avoid HMOVE bars). The early HMOVE at cycle 73/74 is not compatible with all 2600's so there is some benefit if another way could be found. The idea is simple. While not drawing the Px object, change it's size and hit its RESPx register. Then resize it again and you can draw it at then new position. It would work well in some cases.

 

 

You might be interested in the Parrot Kernel then. It uses 18 playfield size pixels per row, and each pixel can be one of three colors. It has variable height and each row can have a different set of three colors.

 

I was thinking that if the delay for quad-width players were different than for double-width players, it might be +8 clocks, as follows:

 

- strobe ends

- 4 clocks for "start" signal (which isn't generated for "copy 0" until 228 clocks later)

- 1 extra clock ("phantom pixel") for single-width player, then 8 pixels begin (1 clock each)

OR

- 2 extra clocks ("phantom pixel") for double-width player, then 8 pixels begin (2 clocks each)

OR

- 4 extra clocks ("phantom pixel") for quad-width player, then 8 pixels begin (4 clocks each)

 

So:

4 + 1 = 5-clock delay for single-width players

4 + 2 = 6-clock delay for double-width players

4 + 4 = 8-clock delay for quad-width players

 

But the extra 1 or 2 clocks aren't due to "phantom pixels" as I've suggested above, but are presumably due to some extra gates that must be processed before drawing the players can begin, which aren't needed for the missiles and ball. I haven't tried to decipher that particular part of the TIA schematics, so I'm not sure what the extra logic is.

 

That parrot looks great! I wasn't asking for myself, so I don't know how much the restricted width would be a problem. A week or two ago someone asked whether playfield pixels could be 2 colors rather than just 1, because he was working on a "Snake" game and was wondering if he could make it a 2-player game. That got me to thinking about the possibility of using quad-sized players. Now I'm thinking the only feasible solution to that would be to alternate the playfield color between scan lines, and draw the blocks of each player's snake on the even scan lines for the first player and on the odd scan lines for the second player (or vice versa)-- with or without flicker to help remove the "blank" lines within each block.

[ZackAttack]

A week or two ago someone asked whether playfield pixels could be 2 colors rather than just 1, because he was working on a "Snake" game and was wondering if he could make it a 2-player game. That got me to thinking about the possibility of using quad-sized players. Now I'm thinking the only feasible solution to that would be to alternate the playfield color between scan lines, and draw the blocks of each player's snake on the even scan lines for the first player and on the odd scan lines for the second player (or vice versa)-- with or without flicker to help remove the "blank" lines within each block.

Since the 6507 cycle is 3 TIA cycles and each PF pixel is 4 TIA cycles there should be a spot where you can strobe RESP0/1 and have them be in alignment. Once they are in alignment you can strobe RESP0/1 every 36 TIA cycles (12 CPU cycles) to keep them in aligned. Ball missiles and background could be used to fill in the 4 pixel gap between each player graphic.