Ball, Missile copy/flicker limit questions.

[BladeJunker]

Figured I'd throw some examples up of mid-line color change paired with scan line color changes. Sort of modern art with some variations and one based on a T-shirt I saw. Still looking for feedback so holler at me.

[BladeJunker]

The aspect ratio of a color clock (often referred to as a "pixel") on the 2600 is roughly 5:3. Assuming that Paint's pixels are square or have an aspect ratio of 1:1 (which really depends on the screen resolution of the desktop), then if you draw an oval with an aspect ratio of 3:5 in Paint-- say, 300 pixels wide and 500 pixels tall-- you can convert the drawing to pixel data. When you draw that same oval on the 2600, it should come out very close to a circle due to the pixels being wider than in Paint. Of course, the 2600's drawing area is usually only 192 scan lines or so. Just multiply the desired height in scan lines by 3 and divide by 5 to get the width:

 

192 lines tall x 3 = 576, 576 / 5 = 115.2 color clocks wide

191 lines tall x 3 = 573, 573 / 5 = 114.6 color clocks wide

190 lines tall x 3 = 570, 570 / 5 = 114.0 color clocks wide *

etc.

 

The best choices would be where the height is a perfect multiple of 5 lines, so the ideal width is a whole number of color clocks:

 

190 lines x 3 = 570, 570 / 5 = 114 color clocks

185 lines x 3 = 555, 555 / 5 = 111 color clocks

180 lines x 3 = 540, 540 / 5 = 108 color clocks

etc.

 

I've just been trying out your conversion table and thankfully my approximation isn't too far from it which is a relief. I think in terms of level construction my approximation should suffice but for large compositions like my perfect circle and title screens your formula will save me a lot of time spent on my trial and error approach so thank you kindly for the handy guide.

[SeaGtGruff]

The aspect ratio isn't exactly 5:3, but that seems to be a pretty close approximation. Once I made a "square" out of playfield pixels based on this aspect ratio-- I think it may have been 24 playfield pixels wide and 160 lines tall (24*4 = 96 CCs, 96/3 = 32, 32*5 = 160 lines)-- then displayed it on my TV and used a ruler to see if its width and height were equal, and they were pretty close to being exactly equal. This was on my HD LCD TV, and the results may vary depending on the TV (especially on different CRT TVs), so it isn't "scientific," but it was good enough for me!

 

The 5:3 value is based on the idea that a 4:3 screen with square pixels can have a resolution of 800x600 (800/4 = 200 and 600/3 = 200). There are other resolutions with the same pixel aspect ratio (1:1) and screen aspect ratio (4:3), such as 640x480 (640/4 = 160 and 480/3 = 160), or 1024x768 (1024/4 = 256 and 768/3 = 256), but 800x600 is the most convenient screen resolution for this purpose. Old 8-bit home computers typically had a "hi res" screen resolution of about 320x200. The 8-bit Atari had only 192 lines by default, or 24 rows of 8-line-tall characters (24*8 = 192 lines), but other home computers had 25 rows of 8-line-tall characters (25*8 = 200 lines). However, 320 pixels per line is really only 160 color clocks, so you can figure the resolution was 160 CCs by 200 lines. So if you divide 800 by 160 you get 5, and if you divide 600 by 200 you get 3, hence the CCs have an aspect ratio of about 5:3.

 

The reason this isn't exact is because it assumes a 160x200 screen has a screen aspect ratio of 4:3, which isn't necessarily true. A 160x200 home computer screen is usually a bit smaller than the TV's screen-- there's a border around the computer's screen area to help ensure that some of its pixels don't fall outside the viewable area of the TV due to the way many TVs (especially older TVs) overscan the picture. But 5:3 seems to work pretty good as a pixel aspect ratio when designing mockups of Atari screen displays.

 

Your question about color changes doesn't have a simple answer, because there's different factors to consider. The main factors are the address mode used to load the color values from ROM or RAM, which graphics objects are being used, and how they're being used.

 

Let's ignore the graphics objects for a moment, and focus on changes to a single color register. For example, suppose you've disabled all the graphics objects (set all of their graphics bits to 0), so that the only thing "visible" on the screen is the background color (COLUBK). The absolute fastest color changes you could do would be if you loaded the accumulator, X register, and Y register with three color values ahead of time, then write them to the COLUBK register one after the other:

 

STA COLUBK

STX COLUBK

STY COLUBK

STA COLUBK

STX COLUBK

STY COLUBK

etc.

 

It takes 3 machine cycles to write to COLUBK, and 1 machine cycle is equal to 3 color clocks, so 3 machine cycles are equal to 9 color clocks. If you think of each color change as creating a "pixel" of color on the screen, each pixel is 9 CCs wide, which is just slightly more than twice as "fat" as a playfield pixel. There are 160 CCs per line, and 160/9 = about 17.8, so that would be a screen resolution of less than 18x192-- extremely "lo res"! And since you have to load A, X, and Y ahead of time (which you could do during the horizontal blanks), this limits you to only 3 colors per line.

 

If you decide to load a different color before each color change, the fastest load instruction (using immediate mode) takes 2 machine cycles, so it takes a total of 5 cycles to load and store each color. That's 15 CCs per "pixel" of color, or a screen resolution of less than 11x192 (160/15 = about 10.7)-- even more "lo res"!

 

Most address modes take more than 2 cycles-- zero-page loads take 3 cycles, absolute loads take 4 cycles, and indexed modes can take 5 or 6 cycles. So if you add the 3 cycles for storing the color after you load it, that's a total of up to 9 cycles per color change, giving a "pixel" width of up to 27 CCs!

 

To get smaller pixels of color, you need to use the various graphics objects. This gives you pixels as small as 1 CC (a single-width player, misile, or ball)-- but since the playfield is the only graphics object that can cover the width of the screen, most of the pixels on the screen will be 4 CCs (the playfield pixels).

 

If you combine mid-line color changes with the graphics objects, you can make it look like some of the pixels are smaller. For example, if you change the playfield color in the middle of a playfield pixel, you can effectively divide the playfield pixel in half, such that the left half is one color and the right half is a different color. But keep in mind that you're still limited to a certain number of color changes per line, depending on the address mode used to load the new colors. For example, it's impossible to change a player's color fast enough to make one of its pixels be a different color than the others. The only way to get pixels of different colors inside a player shape is to turn off some of its bits to create "holes," and position other graphics objects behind it (or on top of it)-- in other words, stack different graphics objects and "punch holes" in them so the colors underneath them show through the holes.

 

Normally you don't stack different graphics objects on top of each other per se, but it happens anyway-- with the normal graphics priority the playfield is displayed on top of the background, player1 is displayed on top of the playfield (or background), and player0 is displayed on top of player1 (or the playfield or the background). As objects are moved around on the screen, the "holes" (or 0 bits) in their shapes let the colors beneath them show through. So if you have holes in player0, the holes will be drawn in the background color, or the playfield color, or the player1 color, depending on what's behind player0. That means if you draw a man with player0 and his eyes are holes in the player0 shape, his eyes will change color depending on whatever he's moving in front of-- the background color, or the playfield color, or the player1 color.

 

If you want to create a display where any pixel can be any one of 4 colors, you can't do it. The best you could do is create an 8-pixel wide area by stacking player0 on top of player1, which will let you get any one of 3 colors in any one of those 8 pixels-- the player0 color, or the player1 color, or the background color. If you turn on the playfield pixels, you can get a 4th color, but since each playfield pixel is 4 CCs wide, you can't make any of the 8 pixels be any of the 4 colors. Instead, you'd get any of 3 colors, where the 3rd color can be either the playfield color or the background color for a given 4 CC-wide area, like this:

 

pixel1 pixel2 pixel3 pixel4 pixel5 pixel6 pixel7 pixel8

pixels 1-4 can be any of COLUP0/COLUP1/COLUPF or COLUP0/COLUP1/COLUBK

pixels 5-8 can be any of COLUP0/COLUP1/COLUPF or COLUP0/COLUP1/COLUBK

 

If you use the ball, you can get COLUP0/COLUP1/COLUPF/COLUBK in a given 4-CC area, but you can't reposition the ball fast enough to get COLUPF/COLUBK for any pixel. And anyway, we're talking about a tiny fraction of the screen-- 8 CCs wide.

 

If you want to create a "paint" program for the 2600, you can make some colorful pictures by changing colors from line to line, as well as mid-line, but the overall screen resolution will be lo res (40x192, which is the playfield resolution), with some hi-res areas (the players, missiles, and ball), although the hi-res areas will be limited in size and number. Still, if you're careful in planning the positioning of the sprites and the mid-line color changes, you should be able to draw some nice pictures if you work creatively within the limits of the 2600.

[Tjoppen]

Let's ignore the graphics objects for a moment, and focus on changes to a single color register. For example, suppose you've disabled all the graphics objects (set all of their graphics bits to 0), so that the only thing "visible" on the screen is the background color (COLUBK). The absolute fastest color changes you could do would be if you loaded the accumulator, X register, and Y register with three color values ahead of time, then write them to the COLUBK register one after the other:

 

STA COLUBK

STX COLUBK

STY COLUBK

STA COLUBK

STX COLUBK

STY COLUBK

etc.

Don't forget SAX -> 4th color.

[Thomas Jentzsch]

[deleted]

Edited March 6, 2012 by Thomas Jentzsch

[BladeJunker]

The aspect ratio isn't exactly 5:3, but that seems to be a pretty close approximation. Once I made a "square" out of playfield pixels based on this aspect ratio-- I think it may have been 24 playfield pixels wide and 160 lines tall (24*4 = 96 CCs, 96/3 = 32, 32*5 = 160 lines)-- then displayed it on my TV and used a ruler to see if its width and height were equal, and they were pretty close to being exactly equal. This was on my HD LCD TV, and the results may vary depending on the TV (especially on different CRT TVs), so it isn't "scientific," but it was good enough for me!

 

Seems scientific enough for me since you used actual math and exacting results doesn't seem possible given the properties of the hardware.

 

The 5:3 value is based on the idea that a 4:3 screen with square pixels can have a resolution of 800x600 (800/4 = 200 and 600/3 = 200). There are other resolutions with the same pixel aspect ratio (1:1) and screen aspect ratio (4:3), such as 640x480 (640/4 = 160 and 480/3 = 160), or 1024x768 (1024/4 = 256 and 768/3 = 256), but 800x600 is the most convenient screen resolution for this purpose. Old 8-bit home computers typically had a "hi res" screen resolution of about 320x200. The 8-bit Atari had only 192 lines by default, or 24 rows of 8-line-tall characters (24*8 = 192 lines), but other home computers had 25 rows of 8-line-tall characters (25*8 = 200 lines). However, 320 pixels per line is really only 160 color clocks, so you can figure the resolution was 160 CCs by 200 lines. So if you divide 800 by 160 you get 5, and if you divide 600 by 200 you get 3, hence the CCs have an aspect ratio of about 5:3.

 

Funny I've been using 800X600 as my test stretch resolution, had no idea it was ideal or most convenient when I decided upon it.

 

The reason this isn't exact is because it assumes a 160x200 screen has a screen aspect ratio of 4:3, which isn't necessarily true. A 160x200 home computer screen is usually a bit smaller than the TV's screen-- there's a border around the computer's screen area to help ensure that some of its pixels don't fall outside the viewable area of the TV due to the way many TVs (especially older TVs) overscan the picture. But 5:3 seems to work pretty good as a pixel aspect ratio when designing mockups of Atari screen displays.

 

I'm familiar with overscan, I was trying to make a 3D cross platform game for PC and console (PS2 & Xbox era) a while back, never finished it but I did learn about overscan standards. As far as retro height resolutions I was thrilled when VGA and SVGA came around and 320X240 became a standard since I never liked dealing with the stretch issues of 320X200. Also I always thought the C64 kind of overdid it with its overscan border. Anyway yeah 5:3 is a good standard.

 

Your question about color changes doesn't have a simple answer, because there's different factors to consider. The main factors are the address mode used to load the color values from ROM or RAM, which graphics objects are being used, and how they're being used.

 

I'm getting used to that answer when learning about the 2600 lol. Actually from the start I concluded that I could have saved my self a lot of trouble and concentrated on 5200 or 7800 based graphics design but the 2600 is the trailblazer of the three systems.

Still I kind of figured there would be a heavy cycle cost to pay and that the number of mid-line color changes would be extremely limited and have significant drawbacks otherwise I'd see more obvious examples of it everywhere.

 

Let's ignore the graphics objects for a moment, and focus on changes to a single color register. For example, suppose you've disabled all the graphics objects (set all of their graphics bits to 0), so that the only thing "visible" on the screen is the background color (COLUBK). The absolute fastest color changes you could do would be if you loaded the accumulator, X register, and Y register with three color values ahead of time, then write them to the COLUBK register one after the other:

 

STA COLUBK

STX COLUBK

STY COLUBK

STA COLUBK

STX COLUBK

STY COLUBK

etc.

 

It takes 3 machine cycles to write to COLUBK, and 1 machine cycle is equal to 3 color clocks, so 3 machine cycles are equal to 9 color clocks. If you think of each color change as creating a "pixel" of color on the screen, each pixel is 9 CCs wide, which is just slightly more than twice as "fat" as a playfield pixel. There are 160 CCs per line, and 160/9 = about 17.8, so that would be a screen resolution of less than 18x192-- extremely "lo res"! And since you have to load A, X, and Y ahead of time (which you could do during the horizontal blanks), this limits you to only 3 colors per line.

 

If you decide to load a different color before each color change, the fastest load instruction (using immediate mode) takes 2 machine cycles, so it takes a total of 5 cycles to load and store each color. That's 15 CCs per "pixel" of color, or a screen resolution of less than 11x192 (160/15 = about 10.7)-- even more "lo res"!

 

Most address modes take more than 2 cycles-- zero-page loads take 3 cycles, absolute loads take 4 cycles, and indexed modes can take 5 or 6 cycles. So if you add the 3 cycles for storing the color after you load it, that's a total of up to 9 cycles per color change, giving a "pixel" width of up to 27 CCs!

 

Okay you're basically saying the pursuit of more than one mid-line color change per line will result in even less Playfield resolution, weird widths where color changes actually occur, and a severe cycle and color clock costs. So what is the bad news. ^_^

 

To get smaller pixels of color, you need to use the various graphics objects. This gives you pixels as small as 1 CC (a single-width player, misile, or ball)-- but since the playfield is the only graphics object that can cover the width of the screen, most of the pixels on the screen will be 4 CCs (the playfield pixels).

 

If you combine mid-line color changes with the graphics objects, you can make it look like some of the pixels are smaller. For example, if you change the playfield color in the middle of a playfield pixel, you can effectively divide the playfield pixel in half, such that the left half is one color and the right half is a different color. But keep in mind that you're still limited to a certain number of color changes per line, depending on the address mode used to load the new colors. For example, it's impossible to change a player's color fast enough to make one of its pixels be a different color than the others. The only way to get pixels of different colors inside a player shape is to turn off some of its bits to create "holes," and position other graphics objects behind it (or on top of it)-- in other words, stack different graphics objects and "punch holes" in them so the colors underneath them show through the holes.

 

Normally you don't stack different graphics objects on top of each other per se, but it happens anyway-- with the normal graphics priority the playfield is displayed on top of the background, player1 is displayed on top of the playfield (or background), and player0 is displayed on top of player1 (or the playfield or the background). As objects are moved around on the screen, the "holes" (or 0 bits) in their shapes let the colors beneath them show through. So if you have holes in player0, the holes will be drawn in the background color, or the playfield color, or the player1 color, depending on what's behind player0. That means if you draw a man with player0 and his eyes are holes in the player0 shape, his eyes will change color depending on whatever he's moving in front of-- the background color, or the playfield color, or the player1 color.

 

If you want to create a display where any pixel can be any one of 4 colors, you can't do it. The best you could do is create an 8-pixel wide area by stacking player0 on top of player1, which will let you get any one of 3 colors in any one of those 8 pixels-- the player0 color, or the player1 color, or the background color. If you turn on the playfield pixels, you can get a 4th color, but since each playfield pixel is 4 CCs wide, you can't make any of the 8 pixels be any of the 4 colors. Instead, you'd get any of 3 colors, where the 3rd color can be either the playfield color or the background color for a given 4 CC-wide area, like this:

 

pixel1 pixel2 pixel3 pixel4 pixel5 pixel6 pixel7 pixel8

pixels 1-4 can be any of COLUP0/COLUP1/COLUPF or COLUP0/COLUP1/COLUBK

pixels 5-8 can be any of COLUP0/COLUP1/COLUPF or COLUP0/COLUP1/COLUBK

 

If you use the ball, you can get COLUP0/COLUP1/COLUPF/COLUBK in a given 4-CC area, but you can't reposition the ball fast enough to get COLUPF/COLUBK for any pixel. And anyway, we're talking about a tiny fraction of the screen-- 8 CCs wide.

 

I see what you're saying, mid-line color changes are better accomplished through graphics object overlays. Interesting to see that a Playfield pixel can be divided finer in color if not actual pixel resolution. From what I see of this greater degrees of mid-line color change in the Playfield may be worth pursuing for an art slide but it seems horrible for actual gaming purposes.

 

If you want to create a "paint" program for the 2600, you can make some colorful pictures by changing colors from line to line, as well as mid-line, but the overall screen resolution will be lo res (40x192, which is the playfield resolution), with some hi-res areas (the players, missiles, and ball), although the hi-res areas will be limited in size and number. Still, if you're careful in planning the positioning of the sprites and the mid-line color changes, you should be able to draw some nice pictures if you work creatively within the limits of the 2600.

 

Oh I always knew careful planning would be part of art composition on the 2600 but I like to know the full potential of every object and its functions therein. As far as the lo res 40X192 and the hi-res object limits that has always been regarded in this concept. I made my peace with the fact that a 2600 paint program would be unlike any other paint program ever made. Actually much of what I'm trying for is not so much more color but a more elegant alignment of the objects using the standard amount of colors per scan line, I know it seems like I'm trying for more at times but in the long run tricks or rendering gimmicks aren't as good as art techniques that fit within standard practices.

[Tjoppen]

Here's a sneak peek of what this thread inspired me to cobble together:

[BladeJunker]

Here's a sneak peek of what this thread inspired me to cobble together:

Very cool I love it. Its very neat to see what it looks like.

[SeaGtGruff]

Let's ignore the graphics objects for a moment, and focus on changes to a single color register. For example, suppose you've disabled all the graphics objects (set all of their graphics bits to 0), so that the only thing "visible" on the screen is the background color (COLUBK). The absolute fastest color changes you could do would be if you loaded the accumulator, X register, and Y register with three color values ahead of time, then write them to the COLUBK register one after the other:

 

STA COLUBK

STX COLUBK

STY COLUBK

STA COLUBK

STX COLUBK

STY COLUBK

etc.

Don't forget SAX -> 4th color.

I can't forget it until I've learned about it. I wasn't aware of this particular illegal opcode until now, but I'll definitely keep it in mind in the future. I've never been a huge fan of getting a third color by ANDing two together, just because I prefer being able to have the freedom to pick any color. But if you pick two colors "wisely," I guess the ANDed color could be pretty useful. I'll have to experiment with this.

[SeaGtGruff]

Funny I've been using 800X600 as my test stretch resolution, had no idea it was ideal or most convenient when I decided upon it.

The only reason I picked 800x600 is because it works well in a Paint program if your desktop resolution is 800x600 or a bit larger-- which I think I was using back a few years ago when I first started doing mockups. And it also works well for the math. Now I typically use a much higher screen resolution for my desktop.

 

Okay you're basically saying the pursuit of more than one mid-line color change per line will result in even less Playfield resolution, weird widths where color changes actually occur, and a severe cycle and color clock costs. So what is the bad news. ^_^

No, the playfield resolution is always the same regardless of mid-line color changes. I was just comparing the size of a "pixel"-- or "pseudo pixel," if you prefer-- created by changing the color of the background to how big a playfield pixel is. When some people first learn about making color changes mid-line, they start thinking it might be a way to dramatically increase the number of colors being displayed per line-- and it *can* increase the number of colors per line (that's the whole point). *But* you have to remember that the 2600 doesn't have a really fast CPU clock rate, so if you're thinking you could create a more colorful "graphics mode" by just changing colors over and over on each line, you may end up being disappointed when you realize how far the scanning beams travel between each color change.

 

I see what you're saying, mid-line color changes are better accomplished through graphics object overlays. Interesting to see that a Playfield pixel can be divided finer in color if not actual pixel resolution. From what I see of this greater degrees of mid-line color change in the Playfield may be worth pursuing for an art slide but it seems horrible for actual gaming purposes.

I agree about the art slides-- if you design a screen carefully, you can use the graphics objects and mid-line color changes to create a nice picture. In a game, it's usually more feasible to just do color changes from line to line-- but some games *do* incorporate mid-line color changes as well. Two I can think of are "BMX Air Master" and "Robot Tank," but I imagine there must be others as well.

[SeaGtGruff]

Oh, yes-- "Stratogems Deluxe" uses mid-line color changes, too!

[Tjoppen]

Don't forget SAX -> 4th color.

I can't forget it until I've learned about it. I wasn't aware of this particular illegal opcode until now, but I'll definitely keep it in mind in the future. I've never been a huge fan of getting a third color by ANDing two together, just because I prefer being able to have the freedom to pick any color. But if you pick two colors "wisely," I guess the ANDed color could be pretty useful. I'll have to experiment with this.

.. or you can let your quantization algorithm choose like I do.

The simplest and most useful case is probably doing grayscale-ish things by having A = %xxxx0100, X = %xxxx1010, Y = xxxx1110 -> A&X = %xxxx0000 ==> four brightness levels.

Edited March 7, 2012 by Tjoppen

[BladeJunker]

Okay you're basically saying the pursuit of more than one mid-line color change per line will result in even less Playfield resolution, weird widths where color changes actually occur, and a severe cycle and color clock costs. So what is the bad news. ^_^

No, the playfield resolution is always the same regardless of mid-line color changes. I was just comparing the size of a "pixel"-- or "pseudo pixel," if you prefer-- created by changing the color of the background to how big a playfield pixel is. When some people first learn about making color changes mid-line, they start thinking it might be a way to dramatically increase the number of colors being displayed per line-- and it *can* increase the number of colors per line (that's the whole point). *But* you have to remember that the 2600 doesn't have a really fast CPU clock rate, so if you're thinking you could create a more colorful "graphics mode" by just changing colors over and over on each line, you may end up being disappointed when you realize how far the scanning beams travel between each color change.

 

Oh good, thank the creator since that would have been far less useful. Believe me I wasn't thinking of going for dramatic increases just moderate mid-line color change increases, 3 is plenty for me given the width of each Playfield column. My goal for the 2600 graphics standard is a moderate quality increase based on easily achievable kernels. Actually one of my "rules" for per scan line color changes is to actually not change them very much at all since the horizontal axis is so color challenged it creates too much contrast in most circumstances.

 

Thanks for the game examples, they were most helpful.

[BladeJunker]

It takes 3 machine cycles to write to COLUBK, and 1 machine cycle is equal to 3 color clocks, so 3 machine cycles are equal to 9 color clocks. If you think of each color change as creating a "pixel" of color on the screen, each pixel is 9 CCs wide, which is just slightly more than twice as "fat" as a playfield pixel. There are 160 CCs per line, and 160/9 = about 17.8, so that would be a screen resolution of less than 18x192-- extremely "lo res"! And since you have to load A, X, and Y ahead of time (which you could do during the horizontal blanks), this limits you to only 3 colors per line.

 

If you decide to load a different color before each color change, the fastest load instruction (using immediate mode) takes 2 machine cycles, so it takes a total of 5 cycles to load and store each color. That's 15 CCs per "pixel" of color, or a screen resolution of less than 11x192 (160/15 = about 10.7)-- even more "lo res"!

 

Most address modes take more than 2 cycles-- zero-page loads take 3 cycles, absolute loads take 4 cycles, and indexed modes can take 5 or 6 cycles. So if you add the 3 cycles for storing the color after you load it, that's a total of up to 9 cycles per color change, giving a "pixel" width of up to 27 CCs!

 

Okay how do you divide a Playfield by such irregular values like 17.8 or 10.7. If you round up the value does that mean one column of mid-line color change is less wide than the majority since within Tjoppen's screen capture it appears the first column starting on the left is narrower than the rest? Also if there is one narrow column does it matter where you put it in horizontal position?

[Tjoppen]

Okay how do you divide a Playfield by such irregular values like 17.8 or 10.7. If you round up the value does that mean one column of mid-line color change is less wide than the majority since within Tjoppen's screen capture it appears the first column starting on the left is narrower than the rest?

Also if there is one narrow column does it matter where you put it in horizontal position?

You're thinking too much - just experiment. But yeah, 18 columns is the maximum since you can't poke the TIA faster than that - ceil(160 / 9) = 18. You also only have three pixel precision due to the 6502 being slower than the TIA, so you can't position your writes perfectly.

Edited March 9, 2012 by Tjoppen

[SeaGtGruff]

You also only have three pixel precision due to the 6502 being slower than the TIA, so you can't position your writes perfectly.

I'd like to expound/expand on that.

 

What Tjoppen means is that even though you can do a color change during any machine cycle of a scan line, you're limited to making color changes at every third color clock, since 1 machine cycle equals 3 color clocks. For example:

 

A color change that occurs during machine cycle 30 would occur at color clock 90 (or 3 * 30).

 

A color change that occurs during machine cycle 31 would occur at color clock 93 (or 3 * 31).

 

So you can do a color change at color clock 90, or at color clock 93-- but not at color clocks 91 or 92, since they aren't evenly divisible by 3.

 

And note, when I say you can do a color change on any machine cycle, I'm referring to a single color change. If you do two color changes-- the second immediately after the first-- they'll be separated by 3 machine cycles, or 9 color clocks, since it takes 3 machine cycles to write to a TIA register using the zero-page address mode.

 

Furthermore, if you want to change the playfield color and you want it to coincide with a playfield pixel boundary, you're limited to every third playfield pixel, since 1 playfield pixel equals 4 color clocks, and it takes 3 playfield pixels to get a multiple of 3 color clocks:

 

1 playfield pixel = 4 color clocks (4 is not evenly divisible by 3)

2 playfield pixels = 8 color clocks (8 is not evenly divisible by 3)

3 playfield pixels = 12 color clocks (12 *is* evenly divisible by 3)

 

Of course, you can still do a playfield color change at any time-- it just might take effect partway through a playfield pixel, such that the first part of the playfield pixel is one color and the second part of the playfield pixel is a different color. That's fine if you *want* the playfield pixel to be two different colors. And even if you want each playfield pixel to be just one color, you could make sure that the playfield pixel where the mis-aligned color change occurs is always turned off, so the color change won't show up until the *next* playfield pixel.

[BladeJunker]

You also only have three pixel precision due to the 6502 being slower than the TIA, so you can't position your writes perfectly.

I'd like to expound/expand on that.

 

What Tjoppen means is that even though you can do a color change during any machine cycle of a scan line, you're limited to making color changes at every third color clock, since 1 machine cycle equals 3 color clocks. For example:

 

A color change that occurs during machine cycle 30 would occur at color clock 90 (or 3 * 30).

 

A color change that occurs during machine cycle 31 would occur at color clock 93 (or 3 * 31).

 

So you can do a color change at color clock 90, or at color clock 93-- but not at color clocks 91 or 92, since they aren't evenly divisible by 3.

 

And note, when I say you can do a color change on any machine cycle, I'm referring to a single color change. If you do two color changes-- the second immediately after the first-- they'll be separated by 3 machine cycles, or 9 color clocks, since it takes 3 machine cycles to write to a TIA register using the zero-page address mode.

 

Furthermore, if you want to change the playfield color and you want it to coincide with a playfield pixel boundary, you're limited to every third playfield pixel, since 1 playfield pixel equals 4 color clocks, and it takes 3 playfield pixels to get a multiple of 3 color clocks:

 

1 playfield pixel = 4 color clocks (4 is not evenly divisible by 3)

2 playfield pixels = 8 color clocks (8 is not evenly divisible by 3)

3 playfield pixels = 12 color clocks (12 *is* evenly divisible by 3)

 

Of course, you can still do a playfield color change at any time-- it just might take effect partway through a playfield pixel, such that the first part of the playfield pixel is one color and the second part of the playfield pixel is a different color. That's fine if you *want* the playfield pixel to be two different colors. And even if you want each playfield pixel to be just one color, you could make sure that the playfield pixel where the mis-aligned color change occurs is always turned off, so the color change won't show up until the *next* playfield pixel.

 

Thank you very much as this was what I was looking for as a "visually oriented" Atari enthusiasts. ^_^ This will help greatly in my pixel artist guide as us doodlers appreciate a good solid evenly defined pixel dimension.

[BladeJunker]

Just a few questions that I humbly request anybody answer.

 

-I can't remember where but I read the Ball object doesn't multiplex well, is that true?

 

-I assumed but I should confirm, can you split the Playfield vertically into 2 seperate regions of Playfield color and Background color. I just want to make sure what I'm seeing in 2600 games isn't being accomplished some other way.

 

-I'll post some examples but its mostly a question of what are the usual methods used to achieve instances of "Playfield cohesion" or appearances that defy the standard Playfield limits. Is it just heavy Missile object use, Playfield layer flicker, or vertical split screens?

[Tjoppen]

-I can't remember where but I read the Ball object doesn't multiplex well, is that true?

 

The ball works more or less like the missiles. You can't duplicate it horizontally though, so you can't do things like the RESPx trick to get even more copies of it.

 

-I assumed but I should confirm, can you split the Playfield vertically into 2 seperate regions of Playfield color and Background color. I just want to make sure what I'm seeing in 2600 games isn't being accomplished some other way.

 

Vertically? You can have as many "splits" as you have lines, and then some.

You can split the playfield horizontally using the SCORE bit in CTRLPF. This makes the left side of the playfield take its color from COLUP0 and the right from COLUP1. The background will still be COLUBK for both sides.

 

The screenshots shows fairly typical behaviour, like changing COLUPF/COLUBK every now and then or using some of the graphics objects to draw extra mountains (battlezone).

[+SpiceWare]

what are the usual methods used to achieve instances of "Playfield cohesion" or appearances that defy the standard Playfield limits. Is it just heavy Missile object use, Playfield layer flicker, or vertical split screens?

 

Use Stella's Debug Color mode (COMMAND-Comma on Mac, ALT-Comma on Linux/Windows) to see what's going on.

 

The hills in Battlezone are drawn using the playfield, and smoothed on both sides by using both players and both missiles. Likewise, the tank is drawn using the playfield, both players and both missiles.

 

Most of what you see in the initial Barnstorming screen is just changes to the background color.

[BladeJunker]

The ball works more or less like the missiles. You can't duplicate it horizontally though, so you can't do things like the RESPx trick to get even more copies of it.

Darn I thought might be the case, I think I was trying to will the Ball into doing more than it can lol. However "can't duplicate horizontally" is pretty definitive so I'll conk my head to stop myself from thinking of it as another Missile as its more of a lesser Missile type.

 

Vertically? You can have as many "splits" as you have lines, and then some.

You can split the playfield horizontally using the SCORE bit in CTRLPF. This makes the left side of the playfield take its color from COLUP0 and the right from COLUP1. The background will still be COLUBK for both sides.

 

The screenshots shows fairly typical behaviour, like changing COLUPF/COLUBK every now and then or using some of the graphics objects to draw extra mountains (battlezone).

I forgot about the SCORE bit which is dumb on my part since its a handy default hardware option. So you can't "split" or change the Background color vertically at all per scanline then, it can only be one color top to bottom?

[BladeJunker]

 

Use Stella's Debug Color mode (COMMAND-Comma on Mac, ALT-Comma on Linux/Windows) to see what's going on.

 

The hills in Battlezone are drawn using the playfield, and smoothed on both sides by using both players and both missiles. Likewise, the tank is drawn using the playfield, both players and both missiles.

Oh thanks for the Stella debug info, I only emulate Atari infrequently so I haven't gotten that familiar with all its options yet.

 

Okay I see what Battlezone does,very clever distribution.

 

Most of what you see in the initial Barnstorming screen is just changes to the background color.

Changes to the background color? Well I already delved deeper by asking Tjoppen already about the Background so its up to you if you want to field the question first lol.

 

Still its neat to see how the plane sprite is made, front made of Player but is the main hull Playfield or Missiles?

[+SpiceWare]

The main hull is the playfield(dark purple).

 

You can also use COMMAND/ALT along with Z, X, C, V, B, N or M^* to disable/enable the various objects. Using M to disable the HMOVE lines show that the birds are drawn, but that they are hidden by the HMOVE lines:

 

Edit: This is how the Barnstorming normally looks - your screenshot is cropped so the HMOVE lines aren't visible.

 

The HMOVE line is the black line you see on the left edge of a lot of games, it's really obvious in the later levels of Missile Command.

 

The HMOVE is a side effect of repositioning an object (players, missiles and/or ball) while drawing the screen. Activision didn't like the look, so they decided to do an HMOVE on every single scanline to make it not so noticeable. They give up 8 pixels (and 2 PF pixels) of screen in doing so, but as shown by the birds it can be used to simplify sprite logic by hiding sprites in the black bar instead of having logic in the kernel to decide if it's going to show/not show a sprite.

 

 

^*In Stella's Help system go to Keyboard Layout section to see the keys and what they toggle on/off. They're listed in the table titled Developer Keys in TIA mode.

Edited March 27, 2012 by SpiceWare

[+SpiceWare]

Also, you can change colors mid-screen, it is a bit tricky though. Video Cube changes the color of the playfield multiple times on each scanline:

 

 

I changed the color of the playfield (using the SCORE bit that Tjoppen mentioned) to draw the kings a different color than the castle walls in Medieval Mayhem. Likewise you can see that I changed the color of the sprites during the scanline to display each score in the proper color.

 

Edited March 27, 2012 by SpiceWare

[BladeJunker]

The main hull is the playfield(dark purple).

 

You can also use COMMAND/ALT along with Z, X, C, V, B, N or M^* to disable/enable the various objects. Using M to disable the HMOVE lines show that the birds are drawn, but that they are hidden by the HMOVE lines:

 

Edit: This is how the Barnstorming normally looks - your screenshot is cropped so the HMOVE lines aren't visible.

 

The HMOVE line is the black line you see on the left edge of a lot of games, it's really obvious in the later levels of Missile Command.

 

The HMOVE is a side effect of repositioning an object (players, missiles and/or ball) while drawing the screen. Activision didn't like the look, so they decided to do an HMOVE on every single scanline to make it not so noticeable. They give up 8 pixels (and 2 PF pixels) of screen in doing so, but as shown by the birds it can be used to simplify sprite logic by hiding sprites in the black bar instead of having logic in the kernel to decide if it's going to show/not show a sprite.

 

 

^*In Stella's Help system go to Keyboard Layout section to see the keys and what they toggle on/off. They're listed in the table titled Developer Keys in TIA mode.

 

I guess my Background question was already answered, didn't look close enough at the debug examples. Well I can find uses for that.

 

Boy the debug option is great at revealing what is doing what, saves me time asking and it saves others time from politely answering these kind of questions.

 

HMOVE, haven't really delved into it although I am aware of its existence and its visual byproducts. Not too sure what kind of stance I'll take on it yet, leave it, hide it, or completely cater to a code base that eliminates its on screen appearance.