SeaGtGruff Posted June 28, 2015 Share Posted June 28, 2015 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. 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted June 29, 2015 Share Posted June 29, 2015 IIRC the width has no influence. But I haven't tested this too. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 29, 2015 Author Share Posted June 29, 2015 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. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted June 29, 2015 Share Posted June 29, 2015 What was the idea that won't work? Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted July 1, 2015 Share Posted July 1, 2015 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. 1 1 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted July 1, 2015 Share Posted July 1, 2015 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 1 1 Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted July 2, 2015 Author Share Posted July 2, 2015 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. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted July 2, 2015 Share Posted July 2, 2015 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. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted July 2, 2015 Author Share Posted July 2, 2015 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. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted July 5, 2015 Share Posted July 5, 2015 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.