39 replies to this topic

[nudicle]

reflected boobs! well, sort of.

[kamakazi]

Sorry...I know that I'm probably a bit off the subject here. But almost every 8-bit Atari console I've owned has done the change color screensaver thing (I forget the keyword for it...learned how to program it in Atari BASIC). Are we going to have to program it here as well if we want/need it or is that in control of the 6502?

Also...was still playing around a bit with the playfield (from previous lessons) and got some weird but cool results. I was trying to perform an old Atari trick with color cycling. For those of you not familiar with Atari system programming of any kind...color cycling is were you simply move the color number from a set address in memory and poke it into the previous or next address. The nice thing about Atari is that this feature has been built into it's processors (although I'm not sure about the 2600). Thus...you can get a cool effect without having to redraw everything. While I didn't succeed yet with the cycling...what I got is cool I think. How else am I going to learn?

And another thing...how important is all of the spacing in creating an assembly program? I tried to clean it up by doing away with all of the double spacing...but upon compiling it to a .bin file...i got an error message.

           processor 6502

           include "vcs.h"

           include "macro.h"

;---------------------------------------------------------------

PATTERN		= $80
TIMETOCHANGE	= 20

;----------------------------------------------------------------


           SEG

           ORG $F000



Reset

;Clear RAM and all TIA registers

	ldx #0
	lda #0
Clear	sta 0,x
	inx
	bne Clear

;----------------------------------------------------------------

; Once-only initialization

	lda #0
	sta PATTERN

	lda #$45
	sta COLUPF

	ldy #0

;----------------------------------------------------------------



StartOfFrame



  ; Start of vertical blank processing



           lda #0

           sta VBLANK



           lda #2

           sta VSYNC

           

               sta WSYNC

               sta WSYNC

               sta WSYNC	; 3 scanlines of VSYNC signal



           lda #0

           sta VSYNC           



              ; 37 scanlines of vertical blank...

	ldx #0

VerticalBlank	sta WSYNC

	inx

	cpx #37
	
	bne VerticalBlank

;--------------------------------------------------------------------

;Handle a change in the pattern once every 20 frames
;and write the pattern to the PF1 register

	iny

	cpy #TIMETOCHANGE
	
	bne notyet

	ldy #0

	inc PATTERN
	
notyet  
	
	lda PATTERN

	sta PF0
	sta PF1

;--------------------------------------------------------------------



;--------------------------------------------------------------------
    
           ; 192 scanlines of picture...



               ldx #$45
	stx COLUBK

	ldx #0


Picture stx COLUPF

	SLEEP 40

	lda #$45
	
	sta COLUPF
	
	sta WSYNC

	inx

	cpx #242

	bne Picture


;-------------------------------------------------------------------

           lda #%01000010

           sta VBLANK                     ; end of screen - enter blanking



              ; 30 scanlines of overscan...

	ldx #0

Overscan	sta WSYNC

	inx

	cpx #30

	bne Overscan



           jmp StartOfFrame





           ORG $FFFA



           .word Reset          ; NMI

           .word Reset          ; RESET

           .word Reset          ; IRQ



    END

Any help for a 2600 newbie would be appreciated. Also keep in mind...I've never assembled before...use to various BASIC techniques.

Attached Thumbnails

• 

[Wickeycolumbus]

kamakazi, on Wed Mar 26, 2008 8:53 PM, said:

Sorry...I know that I'm probably a bit off the subject here. But almost every 8-bit Atari console I've owned has done the change color screensaver thing (I forget the keyword for it...learned how to program it in Atari BASIC). Are we going to have to program it here as well if we want/need it or is that in control of the 6502?

Also...was still playing around a bit with the playfield (from previous lessons) and got some weird but cool results. I was trying to perform an old Atari trick with color cycling. For those of you not familiar with Atari system programming of any kind...color cycling is were you simply move the color number from a set address in memory and poke it into the previous or next address. The nice thing about Atari is that this feature has been built into it's processors (although I'm not sure about the 2600). Thus...you can get a cool effect without having to redraw everything. While I didn't succeed yet with the cycling...what I got is cool I think. How else am I going to learn?

And another thing...how important is all of the spacing in creating an assembly program? I tried to clean it up by doing away with all of the double spacing...but upon compiling it to a .bin file...i got an error message.

           processor 6502

           include "vcs.h"

           include "macro.h"

;---------------------------------------------------------------

PATTERN		= $80
TIMETOCHANGE	= 20

;----------------------------------------------------------------


           SEG

           ORG $F000



Reset

;Clear RAM and all TIA registers

	ldx #0
	lda #0
Clear	sta 0,x
	inx
	bne Clear

;----------------------------------------------------------------

; Once-only initialization

	lda #0
	sta PATTERN

	lda #$45
	sta COLUPF

	ldy #0

;----------------------------------------------------------------



StartOfFrame



  ; Start of vertical blank processing



           lda #0

           sta VBLANK



           lda #2

           sta VSYNC

           

               sta WSYNC

               sta WSYNC

               sta WSYNC	; 3 scanlines of VSYNC signal



           lda #0

           sta VSYNC           



              ; 37 scanlines of vertical blank...

	ldx #0

VerticalBlank	sta WSYNC

	inx

	cpx #37
	
	bne VerticalBlank

;--------------------------------------------------------------------

;Handle a change in the pattern once every 20 frames
;and write the pattern to the PF1 register

	iny

	cpy #TIMETOCHANGE
	
	bne notyet

	ldy #0

	inc PATTERN
	
notyet  
	
	lda PATTERN

	sta PF0
	sta PF1

;--------------------------------------------------------------------



;--------------------------------------------------------------------
    
           ; 192 scanlines of picture...



               ldx #$45
	stx COLUBK

	ldx #0


Picture stx COLUPF

	SLEEP 40

	lda #$45
	
	sta COLUPF
	
	sta WSYNC

	inx

	cpx #242

	bne Picture


;-------------------------------------------------------------------

           lda #%01000010

           sta VBLANK                     ; end of screen - enter blanking



              ; 30 scanlines of overscan...

	ldx #0

Overscan	sta WSYNC

	inx

	cpx #30

	bne Overscan



           jmp StartOfFrame





           ORG $FFFA



           .word Reset          ; NMI

           .word Reset          ; RESET

           .word Reset          ; IRQ



    END

Any help for a 2600 newbie would be appreciated. Also keep in mind...I've never assembled before...use to various BASIC techniques.

Examine this color cycling source code.

[Wickeycolumbus]

kamakazi, on Wed Mar 26, 2008 8:53 PM, said:

Sorry...I know that I'm probably a bit off the subject here. But almost every 8-bit Atari console I've owned has done the change color screensaver thing (I forget the keyword for it...learned how to program it in Atari BASIC). Are we going to have to program it here as well if we want/need it or is that in control of the 6502?

Also...was still playing around a bit with the playfield (from previous lessons) and got some weird but cool results. I was trying to perform an old Atari trick with color cycling. For those of you not familiar with Atari system programming of any kind...color cycling is were you simply move the color number from a set address in memory and poke it into the previous or next address. The nice thing about Atari is that this feature has been built into it's processors (although I'm not sure about the 2600). Thus...you can get a cool effect without having to redraw everything. While I didn't succeed yet with the cycling...what I got is cool I think. How else am I going to learn?

And another thing...how important is all of the spacing in creating an assembly program? I tried to clean it up by doing away with all of the double spacing...but upon compiling it to a .bin file...i got an error message.

           processor 6502

           include "vcs.h"

           include "macro.h"

;---------------------------------------------------------------

PATTERN		= $80
TIMETOCHANGE	= 20

;----------------------------------------------------------------


           SEG

           ORG $F000



Reset

;Clear RAM and all TIA registers

	ldx #0
	lda #0
Clear	sta 0,x
	inx
	bne Clear

;----------------------------------------------------------------

; Once-only initialization

	lda #0
	sta PATTERN

	lda #$45
	sta COLUPF

	ldy #0

;----------------------------------------------------------------



StartOfFrame



  ; Start of vertical blank processing



           lda #0

           sta VBLANK



           lda #2

           sta VSYNC

           

               sta WSYNC

               sta WSYNC

               sta WSYNC	; 3 scanlines of VSYNC signal



           lda #0

           sta VSYNC           



              ; 37 scanlines of vertical blank...

	ldx #0

VerticalBlank	sta WSYNC

	inx

	cpx #37
	
	bne VerticalBlank

;--------------------------------------------------------------------

;Handle a change in the pattern once every 20 frames
;and write the pattern to the PF1 register

	iny

	cpy #TIMETOCHANGE
	
	bne notyet

	ldy #0

	inc PATTERN
	
notyet  
	
	lda PATTERN

	sta PF0
	sta PF1

;--------------------------------------------------------------------



;--------------------------------------------------------------------
    
           ; 192 scanlines of picture...



               ldx #$45
	stx COLUBK

	ldx #0


Picture stx COLUPF

	SLEEP 40

	lda #$45
	
	sta COLUPF
	
	sta WSYNC

	inx

	cpx #242

	bne Picture


;-------------------------------------------------------------------

           lda #%01000010

           sta VBLANK                     ; end of screen - enter blanking



              ; 30 scanlines of overscan...

	ldx #0

Overscan	sta WSYNC

	inx

	cpx #30

	bne Overscan



           jmp StartOfFrame





           ORG $FFFA



           .word Reset          ; NMI

           .word Reset          ; RESET

           .word Reset          ; IRQ



    END

Any help for a 2600 newbie would be appreciated. Also keep in mind...I've never assembled before...use to various BASIC techniques.

Examine this color cycling source code.

Attached Files

•  colorcycle.zip   1.68K   67 downloads

[kamakazi]

Ok, without showing any code, how could I control the playfield to display a grid of 5x5 squares? I would like to see if it is possible to do so without too much modification to the original code presented by Andrew here.

[Nukey Shay]

Are the squares intended to be colored independantly? That would raise the complexity meter quite a bit. Otherwise, it's just redrawing the PF registers mid-scanline for an assymetrical display. Depending on how you have CTRLPF set, either PF2 (reflected) or PF0 (mirrored) should complete it's store exactly on cycle 48.

[SeaGtGruff]

kamakazi, on Tue Sep 14, 2010 6:16 PM, said:

Ok, without showing any code, how could I control the playfield to display a grid of 5x5 squares? I would like to see if it is possible to do so without too much modification to the original code presented by Andrew here.

I haven't tried the original code presented here, but by 5x5 squares, do you mean each square is 1 playfield pixel wide, or are you wanting to divide all 40 playfield pixels into 5 squares (i.e., each square is 8 playfield pixels wide)? Assuming you mean the latter, you'd need to divide up the playfield registers as follows:

|        Left side of the screen        |       Right side of the screen        |

|  PF0  |      PF1      |      PF2      |  PF0  |      PF1      |      PF2      | ("repeated" mode)
|4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7|4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7| (bit numbers)
|. . . . . . . .|. . . . . . . .|. . . . . . . .|. . . . . . . .|. . . . . . . .|
|   Square #1   |   Square #2   |   Square #3   |   Square #4   |   Square #5   |

or

|  PF0  |      PF1      |      PF2      |      PF2      |      PF1      |  PF0  | ("reflected" mode)
|4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7|7 6 5 4| (bit numbers)
|. . . . . . . .|. . . . . . . .|. . . . . . . .|. . . . . . . .|. . . . . . . .|
|   Square #1   |   Square #2   |   Square #3   |   Square #4   |   Square #5   |

"Repeated" mode is easier to do, because there's more leeway for updating the playfield registers midline between the left and right halves of the screen.

"Reflected" mode is more unforgiving when it comes to the timing-- but really only as far as updating the right copy of PF2.

If you use "repeated" mode, squares #4 and #5 would be a breeze to control, since they would each correspond to a full playfield register.

On the other hand, if you use "reflected" mode, the timing restrictions for updating PF2 between the left and right halves of the screen would be lessened, since square #3 would be formed by bits 4-7 of PF2, and you'd therefore have more leeway about when you have to update PF2 with a new value for the first half of square #4.

If you're talking about smaller squares, you can divide up the playfield registers in other assorted ways, such as

|        Left side of the screen        |       Right side of the screen        |

|  PF0  |      PF1      |      PF2      |  PF0  |      PF1      |      PF2      | ("repeated" mode)
|4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7|4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7| (bit numbers)
|. . . . . . . . . .|. . . .|. . . .|. . . .|. . . .|. . . .|. . . . . . . . . .|
|                   |Square1|Square2|Square3|Square4|Square5|                   |

or

|  PF0  |      PF1      |      PF2      |      PF2      |      PF1      |  PF0  | ("reflected" mode)
|4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7|7 6 5 4| (bit numbers)
|. . . . . . . . . .|. . . .|. . . .|. . . .|. . . .|. . . .|. . . . . . . . . .|
|                   |Square1|Square2|Square3|Square4|Square5|                   |

Perhaps the easiest way would be an off-center grid with a repeated playfield:

|        Left side of the screen        |       Right side of the screen        |

|  PF0  |      PF1      |      PF2      |  PF0  |      PF1      |      PF2      | ("repeated" mode)
|4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7|4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7| (bit numbers)
|. . . . . . . . . . . .|. . . .|. . . .|. . . .|. . . .|. . . .|. . . . . . . .|
|                       |Square1|Square2|Square3|Square4|Square5|               |

But my suggestions may be way off, because I don't have a clear picture of what you mean by a grid of 5x5 squares-- are you trying to have squares that can be turned on or off in a 5x5 array, or are you talking about drawing crosshatched lines to create a 5x5 board, like this:

+-----+-----+-----+-----+-----+
|     |     |     |     |     |
|     |     |     |     |     |
+-----+-----+-----+-----+-----+
|     |     |     |     |     |
|     |     |     |     |     |
+-----+-----+-----+-----+-----+
|     |     |     |     |     |
|     |     |     |     |     |
+-----+-----+-----+-----+-----+
|     |     |     |     |     |
|     |     |     |     |     |
+-----+-----+-----+-----+-----+
|     |     |     |     |     |
|     |     |     |     |     |
+-----+-----+-----+-----+-----+

where the squares are empty spaces and the lines of the grid are drawn with playfield pixels?

Michael

[kamakazi]

I guess I should of been more specific, but yes. The 5x5 grid is referring to your presentation of the 5x5 board. I have an idea I'd like to try while going through these tutorials.

[SeaGtGruff]

kamakazi, on Wed Sep 15, 2010 1:57 AM, said:

I guess I should of been more specific, but yes. The 5x5 grid is referring to your presentation of the 5x5 board. I have an idea I'd like to try while going through these tutorials.

Okay, that's easy. Here's how *I* would do it, but of course you can do it however you want. No code, just talk.

First, I'd want the grid to be as "square" as possible, so I'd figure out how big I'd have to make everything to get as close to a square as possible, as follows:

On the Atari 2600, the smallest pixel-- 1 color clock wide and 1 scan line tall-- has a pixel aspect ratio of approximately 5x3. (I'm assuming that interlacing is *not* being used.) That means for every 3 color clocks across, you need a vertical height of 5 scan lines to get a square. So if you want the grid to fill up as much of the screen as possible in the vertical direction, you can take 192 lines and divide by 5 to see what you get-- 192 / 5 = 38 (we'll round to the nearest whole number). Then multiply that number by 3 to see how wide to make the grid-- 38 * 3 = 114 color clocks. However, if you're drawing the grid with the playfield, each pixel is 4 color clocks wide, so divide that number by 4-- 114 / 4 = 28 playfield pixels wide (rounded down).

Next, you want each square to be the same size-- let's call it X-- and I assume you want the lines of the grid to be as thin as possible, so each line is 1 pixel wide. That means you want to solve for this equation:

1 + X + 1 + X + 1 + X + 1 + X + 1 + X + 1 = 28
5 * X + 6 = 28
5 * X = 22
X = 4 (rounded down)

So each square will be 4 playfield pixels wide, and each line will be 1 playfield pixel wide. The whole grid will be 5 * 4 + 6 = 26 pixels wide, or 26 * 4 = 104 color clocks wide.

Now let's work out the vertical dimensions. If a line is 1 pixel wide, and each pixel is 4 color clocks wide, each line is 4 color clocks wide. Multiply that by 5, then divide by 3, to get the height of each line-- 4 * 5 = 20, and 20 / 3 = 7 scan lines (remember, I'm rounding to the nearest whole number). So the vertical layout will be

7
Y
7
Y
7
Y
7
Y
7
Y
7

One way to solve for Y would be to say that each square is 4 pixels wide, or 4 * 4 = 16 color clocks wide, so multiply that by 5 and divide by 3-- 16 * 5 = 80, 80 / 3 = 27 scan lines tall. But I would include the lines, as follows:

1 + 4 + 1, so the horizontal distance from the beginning of one line to the beginning of the next line is 5 pixels, or 5 * 4 = 20 color clocks. 20 * 5 = 100, 100 / 3 = 33, so the vertical distance from the beginning of one line to the beginning of the next line is 33 scan lines. Then subtract 7 scan lines for the grid line-- 33 - 7 = 26 scan lines for the square (rather than 27 scan lines). So the vertical layout will be as follows:

7
26
7
26
7
26
7
26
7
26
7

The total width is 104 color clocks, and the total height is 6 * 7 + 5 * 26 = 42 + 130 = 172 scan lines. Note that 104 * 5 = 520, and 520 / 3 = 173 (rounding to the nearest whole number), so these numbers should produce a fairly decent square shape for the entire grid.

If you want the grid to be centered, then you'll want 13 pixels on the left side of the screen and 13 pixels on the right side of the screen. (It's lucky for us that we calculated the grid's ideal width to be an even number!) So if you use a reflected playfield, you'd want to draw the grid as follows:

|  PF0  |      PF1      |      PF2      |      PF2      |      PF1      |  PF0  |
|4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7|7 6 5 4|
|. . . . . . . X X X X X X X X X X X X X X X X X X X X X X X X X X . . . . . . .| --- 7 scan lines
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .| \
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .|  \ 26 scan lines
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .|  /
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .| /
|. . . . . . . X X X X X X X X X X X X X X X X X X X X X X X X X X . . . . . . .| --- 7 scan lines
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .| \
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .|  \ 26 scan lines
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .|  /
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .| /
|. . . . . . . X X X X X X X X X X X X X X X X X X X X X X X X X X . . . . . . .| --- 7 scan lines
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .| \
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .|  \ 26 scan lines
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .|  /
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .| /
|. . . . . . . X X X X X X X X X X X X X X X X X X X X X X X X X X . . . . . . .| --- 7 scan lines
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .| \
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .|  \ 26 scan lines
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .|  /
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .| /
|. . . . . . . X X X X X X X X X X X X X X X X X X X X X X X X X X . . . . . . .| --- 7 scan lines
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .| \
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .|  \ 26 scan lines
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .|  /
|. . . . . . . X . . . . X . . . . X . . . . X . . . . X . . . . X . . . . . . .| /
|. . . . . . . X X X X X X X X X X X X X X X X X X X X X X X X X X . . . . . . .| --- 7 scan lines

Reducing this down to the data bytes needed, it would be

playfield_data
   ;     PF1 data,  PF2 data
   BYTE % 00011111, % 11111111 ; for  7 scan lines
   BYTE % 00010000, % 00100001 ; for 26 scan lines
   BYTE % 00011111, % 11111111 ; for  7 scan lines
   BYTE % 00010000, % 00100001 ; for 26 scan lines
   BYTE % 00011111, % 11111111 ; for  7 scan lines
   BYTE % 00010000, % 00100001 ; for 26 scan lines
   BYTE % 00011111, % 11111111 ; for  7 scan lines
   BYTE % 00010000, % 00100001 ; for 26 scan lines
   BYTE % 00011111, % 11111111 ; for  7 scan lines
   BYTE % 00010000, % 00100001 ; for 26 scan lines
   BYTE % 00011111, % 11111111 ; for  7 scan lines

Note that you don't need to write anything to PF0-- just set it to 0 (or 000000) for the entire frame). And you don't need to change PF1 and PF2 midline, since the right side of the screen is a perfect reflection of the left side. However, you do have to remember to write the data "backwards" for PF2, since it's drawn "backwards."

Michael

Edit: Fixed my numbers at the beginning, as my math was off!

Edit again: Fixed the BYTE values for the % 00 forum bug.

Edited by SeaGtGruff, Wed Sep 15, 2010 10:47 PM.

[kamakazi]

Thanks Sea! I forgot that the first 4 binaries of PF0 are ignored. That's going to take me some time to get used to. I'm not used to certain registers ignoring data. I'll play around with what you showed me and see what I can come up with. I'm also new to assembly so this should be a good way to learn the language.

[Nukey Shay]

The 2600 ignores quite a lot...this might be of some use to you:
http://nocash.emubase.de/2k6specs.htm

The equates shown at the top include the relevent bit positions that stores or reads use. Bit positions not marked with 1's make no difference for that operation. If marked as <strobe>, the value itself is not important.

[kamakazi]

First, thanks to Nukey for that link. There's a lot of helpful information, especially for Assembly, on that site. It's odd that most of the 8-bit consoles and computers, including the NES, shared a similar processor.

Second, on getting the grid on the screen, I'm still working on the code. But I figured I would sort of post what I am understanding in hopes that others will tell me if I'm right of wrong. Using the example that SeaGTGruff posted, I am assuming that I will have to waste 7 scan lines before posting the first grid line. After that, I need to waste 26 scan lines. Assuming that this is correct, is this what I am needing to do:

TopScanLine
                sta WSYNC
		inx
		cpx #7
		bne TopScanLine
		ldx #0
		lda #%00011111
		sta PF0
		 
SecondScanLine
                sta WSYNC
                inx
                cpx #26
                bne SecondScanLine
                ldx #0
                lda #%11111111
                sta PF1
                

Is this right or am I missing something or doing something inaccurately?

Edited by kamakazi, Sun Sep 19, 2010 4:40 PM.

[Nukey Shay]

The data you are drawing needs to be relevant for the loop. Also, reversing the direction of X would eliminate the need for a CPX (counting down to zero instead of up). PF1 and PF2 data needs to be rewritten if the pattern itself is intended to change. This can happen outside of the display loop, if you wish (to save cycles for other stuff)...it happens after WSYNC's in the example below purely for simplicity's sake.
Because the display consists of 6 passes to display the 7-line band and 5 passes to display the 26-line band means that you can use a loop for the whole deal...with an unused register (Y) doing the counting.
The initial store to PF0 can be skipped if you have no data there to erase anyway (and if you do, the fact that Y contains no bits turned on in the upper nybble means that you can reuse that value to do the store).
In the second section of drawing a 26-scanline band, the bitpattern between PF2 and PF1 is nearly the same...just shifted to the right 1 pixel. So LSR can be used there to strip the low bit away before reusing it. Saves 1 byte not needing to load a new bitpattern
Finally, blank stores to PF1 and PF2 at the end clear off display data.

      ldy #6
      sty PF0 ;no pixels drawn
RepeatTopLine:
      ldx #7
TopScanLine:
      sta WSYNC
      lda #%11111
      sta PF1
      lda #%11111111
      sta PF2
      dex
      bne TopScanLine
      dey
      beq ScreenEnd
      ldx #26
SecondScanLine:
      sta WSYNC
      lda #%100001
      sta PF2
      lsr
      sta PF1
      dex
      bne SecondScanLine
      beq RepeatTopLine ;unconditional

ScreenEnd: ;x=0, y=0
      sta WSYNC
      sty PF1
      sty PF2

Edited by Nukey Shay, Sun Sep 19, 2010 5:23 PM.

[Nukey Shay]

BTW the above doesn't include CTRLPF...since this doesn't need to happen if you aren't alternating between display modes (reflected, mirrored, score mode) or ball widths. You could just set it to the appropriate value you need right after cold start's ramclear loop if it never changes.

[kamakazi]

Just to make it clear, the idea I have means the grid will not change. I don't want to give away my idea until I have something solid. So, the grid will be the same through the whole game idea I have. The only time it will change is if a title screen is added. I know I'm probably jumping the gun but I would like to be able to have a new game for 2600 players. I do enjoy playing the 2600 and I am enjoying learning the inner workings of this machine, even if I am having some road blocks along the way