Jump to content
IGNORED

RESPx, NUSIZx, and Player Positioning


Recommended Posts

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.

 

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

post-10599-0-60131000-1435779363_thumb.png

PosWidth2.zip

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...