nudicle Posted May 21, 2005 Share Posted May 21, 2005 reflected boobs! well, sort of. Link to comment Share on other sites More sharing options...
kamakazi Posted March 27, 2008 Share Posted March 27, 2008 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. Link to comment Share on other sites More sharing options...
Wickeycolumbus Posted March 27, 2008 Share Posted March 27, 2008 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. Link to comment Share on other sites More sharing options...
Wickeycolumbus Posted March 27, 2008 Share Posted March 27, 2008 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. colorcycle.zip Link to comment Share on other sites More sharing options...
kamakazi Posted September 15, 2010 Share Posted September 15, 2010 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. Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 15, 2010 Share Posted September 15, 2010 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. Link to comment Share on other sites More sharing options...
SeaGtGruff Posted September 15, 2010 Share Posted September 15, 2010 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 Link to comment Share on other sites More sharing options...
kamakazi Posted September 15, 2010 Share Posted September 15, 2010 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. Link to comment Share on other sites More sharing options...
SeaGtGruff Posted September 16, 2010 Share Posted September 16, 2010 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. Link to comment Share on other sites More sharing options...
kamakazi Posted September 16, 2010 Share Posted September 16, 2010 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. Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 16, 2010 Share Posted September 16, 2010 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. Link to comment Share on other sites More sharing options...
kamakazi Posted September 19, 2010 Share Posted September 19, 2010 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? Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 19, 2010 Share Posted September 19, 2010 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 Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 19, 2010 Share Posted September 19, 2010 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. Link to comment Share on other sites More sharing options...
kamakazi Posted September 20, 2010 Share Posted September 20, 2010 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 Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Archived
This topic is now archived and is closed to further replies.