kamakazi Posted April 27, 2014 Share Posted April 27, 2014 Thanks to Andrew's 2600 Programming Tutorials I have a better understanding of not only the 2600's mediocre but cool architecture but in Assembly as well (for the most part). And I have three game designs down on paper already that I am eager to bring to life on the console originally designed for pong-style games. I figure if others could make games for a console that wasn't intended to play those kinds of games then I should be able to as well. I am currently working on the basis for my game but have a playfield question. In one section (somewhere close to the beginning of the code) I have this: ;--------------------------------------- ; Playfield Data ;--------------------------------------- PF_Data1 = #%11111111 ;Top and Bottom Bar PF_Data2 = #%10000001 ;Side Bar PF_Data3 = #%10111101 ;Side Bar with Top Bottom Middle Box PF_Data4 = #%10100101 ;Side Bar with Middle Box Sides And then when I want to send the data to TIA, I have this: ;---------------------------------------- ; Draw Our Playfield ;---------------------------------------- Playfield lda BGDColor ;Get stored color sta COLUBK ;set the BG Color lda PFColor1 ;Get PF Color sta COLUPF ;set PF Color lda PF_Data1 ;Get PFDATA1 Set sta COLUPF ;Store it! lda PF_Data2 ;Get PFDATA2 Set sta COLUPF ;Store it! lda PF_Data3 ;Get PFDATA3 Set sta COLUPF ;Store it! lda PF_Data4 ;Get PFDATA4 Set sta COLUPF ;Store it! lda PF_Data5 ;Get PFDATA5 Set sta COLUPF ;Store it! What I am trying to achieve is a maze playfield similar to what might be seen in Maze Craze. Am I on the right track? I know I still need to count my cycles and I might need to place a few cycle "pauses" to have some sections repeated. I have not finished the code enough yet to try it out but I wanted make sure I'm doing it right. I plan to add at least 3 enemy sprites and one player sprite to the code once I get a working maze. Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 28, 2014 Share Posted April 28, 2014 You have to change the Playfield graphics every time you need them to change. That can even be twice per scanline if you're not wanting replicated or reflected mode. The colour setting - you'd probably not want to do that within the kernal loop unless you require different colours throughout. The sprite stuff - if reusing objects then you'd probably reposition when the playfield doesn't need updating. But if you have to do the PF changes twice per scanline then everything would become very tricky. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted April 28, 2014 Share Posted April 28, 2014 Your code is setting the playfield color register multiple times, whereas I assume you meant to use the playfield graphics registers-- PF0, PF1, and PF2. As Rybags mentioned, you need to update the playfield graphics registers whenever you want them to change. In rare cases you might be able to set them once, but that's only if they're going to keep the same graphics for the entire height of the screen-- such as if you want to draw only vertical walls on the screen from top to bottom, with no openings in the walls and no horizontal walls. The "best case scenario" is where you're going to use either a reflected or repeated playfield and the screen will be split into a certain number of vertical zones-- similar to the screens in Atari 2600 Adventure or Atari 2600 Superman-- such that you can update the playfield graphics once every so many scan lines. The "worst case scenario" is where you want the left and right halves of the playfield to be completely different (an "asymmetrical" playfield), because that means you'll need to update each playfield graphics register twice on each line, and the updates will have to be properly timed or the display won't come out the way you want. Quote Link to comment Share on other sites More sharing options...
kamakazi Posted April 28, 2014 Author Share Posted April 28, 2014 Well, what I was trying to accomplish, and obviously I misunderstood the playfield tutorials, was try to create a small symmetrical maze. So I plan on using the mirrored mode...I just hadn't come that far in my code yet. I still have a LOT to do as I am starting from scratch and learning as I go. I know I have to count the cycles to make sure everything works, I just haven't figured it out yet. The maze I am "hoping" for I assume is going to be more than I expected. I think I need to go back and read the playfield tutorials again. I just want a single maze design (reflected) similar to what one would expect from a game like Pac-Man or Ms. Pac-Man. That's it. I just wanted to see if it could be done with a fine line instead of a thick block. But, as Andrew has mentioned, the playfield registers are at a fixed size. Quote Link to comment Share on other sites More sharing options...
kamakazi Posted April 28, 2014 Author Share Posted April 28, 2014 What I am trying to accomplish is something like this. I know that I might not be able to get it this detailed as this is just a mock-up I'm using to go by. As I've said, I guess I need to go back and view Andrew's playfield tutorials. I know I have 192 cycles I can play around with. Just thought I would share my thoughts here and see if others could give some good advise. So far the advise I've received has helped me out a lot. Quote Link to comment Share on other sites More sharing options...
kamakazi Posted April 29, 2014 Author Share Posted April 29, 2014 OK...I've been playing around with the playfield a bit but I don't quite understand, yet, how to use code like: .byte $3C ; | XXXX | $FF48 .byte $46 ; | X XX | $FF49 .byte $06 ; | XX | $FF4A .byte $3E ; | XXXXX | $FF4B .byte $66 ; | XX XX | $FF4C .byte $66 ; | XX XX | $FF4D .byte $66 ; | XX XX | $FF4E .byte $3C ; | XXXX | $FF4F I know these are for numbers but I've seen playfield data done in a similar fashion. Do I put my "maze" in this format and then point TIA to where the information is and then point it to another memory location when I need to change it? Sorry if questions like mine come along often and I'm really not trying to be a pain. I'm new to Assembly and the 2600 but learning as I go. I am more familiar with various forms of BASIC so this is still all new to me. I am having fun learning though. I know I only need the playfield to be no more than 170 clocks as the bottom portion will be the HUD area. Quote Link to comment Share on other sites More sharing options...
kamakazi Posted April 29, 2014 Author Share Posted April 29, 2014 OK. I've cleaned up my code a lot to a format that I enjoy working with. However, I am trying to understand how to use the memory locations and variables. For example, so I don't have to key in my playfield data every time I want to change it I tried to setup variables with various settings like: ;************************************* ;** ** ;** Set Playfield Data ** ;************************************* PlayfieldData1 = #%11111111 ;Top and Bottom Borders (Solid) PlayfieldData2 = #%10010000 ;Side Borders (Left/Right) PlayfieldData3 = #%11100111 ; PlayfieldData4 = #%00100100 ; PlayfieldData5 = #%10111101 ; PlayfieldData6 = #%10100101 ; PlayfieldData7 = #%00000000 ;Used To Clear Playfield Registers When Needed However, when I've tried to access that information I get nothing on the screen. This is how I was trying to access that data: ;*************************************** ;** Draw Playfield ** ;*************************************** ;** We have 192 scanlines to use. ** ;** Let's track them! ** ;*************************************** ldx #192 ;Start at 192 in a memory location lda PlayfieldData1 ;Get Playfield Data sta PF0 ;Store it to PF0 sta PF1 ;PF1 and... sta PF2 ;PF2 Registers TopBD sta WSYNC dex cpx #190 bne TopBD lda PlayfieldData7 sta PF0 sta PF1 sta PF2 sta WSYNC ;************************************* ;** Finish Up Unused Cycles ** ;************************************* EndBD sta WSYNC dex cpx #0 bne EndBD It works if I replace "PlayfieldData1" with the data directly like "#%11111111". What did I do wrong that I can't use my variable? Thanks in advance. Quote Link to comment Share on other sites More sharing options...
Wickeycolumbus Posted April 30, 2014 Share Posted April 30, 2014 To make that work, you'll need to put a number sign in front of the constant, #PlayfieldData1 for example. Otherwise the assembler will think that PlayfieldData is an address and you will store garbage data. A better approach would be to store the data in ROM as you were referring to in your previous post. The idea is to load the data in your loop using indexed addressing. Something like this: ;.... other code here ldx #7 DisplayLoop sta WSYNC lda PFData,x sta PF0 dex bpl DisplayLoop ;.... more code here PFData .byte $3C ; | XXXX | $FF48 .byte $46 ; | X XX | $FF49 .byte $06 ; | XX | $FF4A .byte $3E ; | XXXXX | $FF4B .byte $66 ; | XX XX | $FF4C .byte $66 ; | XX XX | $FF4D ... .byte $66 ; | XX XX | $FF4E loaded second .byte $3C ; | XXXX | $FF4F loaded first The lda PFData,x line loads the value at the address PFData + the value of the x register to the accumulator, which is then stored to the PF0 data register. Then on the next line, x gets decreased by one and a different value is loaded. I'd recommend you read this book alongside Andrew Davie's tutorials, it's great for learning 6502 assembly: http://www.atariarchives.org/mlb/ Quote Link to comment Share on other sites More sharing options...
kamakazi Posted April 30, 2014 Author Share Posted April 30, 2014 Thank you very much! What you mentioned work and I will work on learning Assembly better so I can create games that are efficient and that people will want to play. That is my goal. Has been since I received an Atari 5200 for Christmas in 1982. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted April 30, 2014 Share Posted April 30, 2014 Regarding the mockup you posted, it looks more or less doable, but you'll need to adjust it a bit. The playfield has a horizontal resolution of 40 pixels, so your vertical walls and vertical halls need to add up to 40. When I count the number of wall columns I get 18, and when I count the number of hall columns I get 17, so in general the formula would be 18x + 17y = z, where x is the width of a wall column, y is the width of a hall column, and z is the width of the entire screen, which in this case is 40: 18x + 17y = 40 You'll want x to be 1, so 18 + 17y = 40 17y = 22 That means the halls will be 1 pixel wide, with 5 pixels left over that you could distribute among the halls (i.e., some halls could be 2 pixels wide). Or you could decrease the number of walls and halls so that all of the halls can be 2 pixels wide: 1x + 2y = 40 In this case x is the number of walls and y is the number of halls. Since there will always be 1 more wall than there are halls, this can be rewritten as 1(n + 1) + 2n = 40 where n is the number of halls, so n + 1 + 2n = 40 3n + 1 = 40 3n = 39 n = 13 So if you have 13 vertical halls, and 14 vertical walls, you could have the halls be twice as wide as the walls. Otherwise, if you want to get the maximum number of halls, they'd all be 1 pixel wide-- except for the central hall, which would be 2 pixels wide-- as follows: 1n + 1(n -1) + 1 = 40 2n = 40 n = 20 So the maximum would be 20 walls and 19 halls. Quote Link to comment Share on other sites More sharing options...
kamakazi Posted April 30, 2014 Author Share Posted April 30, 2014 One more quick question. I was viewing Andew's Playfield Wierdness image of the playfield registers. To make sure I understand the image, PF0 and PF2 are reversed and PF1 isn't, correct? Also only the first (or last since it is reversed) four bits are used for PF0. The remaining four are ignored? Thanks again to everyone who responded for all your help. Quote Link to comment Share on other sites More sharing options...
Kylearan Posted April 30, 2014 Share Posted April 30, 2014 Here's the order how PF bits get displayed (copied from http://nocash.emubase.de/2k6specs.htm which I use often for reference during development): Normal: PF0.4-7 PF1.7-0 PF2.0-7 PF0.4-7 PF1.7-0 PF2.0-7 Mirror: PF0.4-7 PF1.7-0 PF2.0-7 PF2.7-0 PF1.0-7 PF0.7-4 And yes, the other four bits of PF0 are ignored. Quote Link to comment Share on other sites More sharing options...
kamakazi Posted April 30, 2014 Author Share Posted April 30, 2014 Haha! I finally got it!! Well, the playfield anyway. And to make it easier to compare: It's not exactly how I wanted it but I'm happy with the outcome of the "maze" portion. I think I'm going to make this official that this is a WIP. I haven't been able find any jobs since I graduated college and I love to program no matter what it is I'm programming. So, I will make this project my job until something else comes along. I know I still have some things that need to be learned but I will do like the original 2600 developers did...learn as I go. I'm not going to learn otherwise. I could read the books and tutorials all day long for a year solid but I do best when I play around with some code and see the effects. I may need help again along the way but, hey, it's part of being a programmer. And...I did read the Machine Language for Beginners book a long time ago. I still have it, plus 98 other Atari 8-Bit programming books, on my computer. I've got plenty of knowledge in those but I have discovered the best knowledge comes from other people who can share their experiences. The 2600 is an interesting system. It's amazing that it works at all. I have gained a better appreciation for the console and for the ex-Atari employees that had to work with this system without the tools we have today. So, thank you to all those that have helped out already 3 Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted April 30, 2014 Share Posted April 30, 2014 Looking good! Quote Link to comment Share on other sites More sharing options...
kamakazi Posted May 1, 2014 Author Share Posted May 1, 2014 OK. More newbie questions. Is it possible to draw the sprite after the playfield has been drawn? Do any sprites have to be drawn while the playfield is being drawn? I'm only asking because of a few things. I was under the impression that once the playfield had been drawn it would stay there. I assume this is on a per scanline basis and not an entire screen, correct? I've been trying to understand the joystick registers. That is one area that Andrew's tutorial I don't believe talked about. How are those registers detected? Thanks again for the help! Quote Link to comment Share on other sites More sharing options...
kamakazi Posted May 11, 2014 Author Share Posted May 11, 2014 It's been a while since anyone has responded to my questions above so I will do an update. I was working on trying to add sprites to the playfield when I ran across an unexpected issue. And here is the code work (so far) if some one would kindly tell me where I went wrong. ;Flag Patrol - filename flagdemo.asm ;Atari 2600 Game Program ;by Michael Allard ;(C) 2014 Mike Allard Studios ;Use with Joystick Controllers ;1 Player ;************************************* ;** Start Up ** ;************************************* processor 6502 include "vcs.h" include "macro.h" ;************************************* ;** Point to starting RAM location ** ;************************************* seg org $F000 ;************************************* ;** Reset ALL RAM Locations ** ;************************************* Reset ldx #0 ;Set a counter lda #0 ;Set accumulator to zero Clear sta 0,x ;set memory location (x) to zero inx ;change to next memory location bne Clear ;if we haven't reached the last ;memory location then keep going ;************************************* ;** Initializations ** ;************************************* ;** ** ;** Set Player Positions Data ** ;************************************* Player1POS = 130 ; Set player 1 in top-left portion of maze ;************************************* ;** Set Background and ** ;** Playfield Colors ** ;************************************* BackgroundColor = #$80 ;Medium Blue PlayfieldColor1 = #$8B ;Light Blue Player0Color = #$1E ; Player 1 = Yellow Player1Color = #$44 ;Player 2 (Enemies) = Red ;************************************* ;** Turn on Background and ** ;** Playfield Colors ** ;************************************* lda #PlayfieldColor1 sta COLUPF lda #BackgroundColor sta COLUBK lda #%00000001 sta CTRLPF ; reflect playfield LDA #Player0Color ; Yellow STA COLUP0 ; Player 0 Color LDA #Player1Color ; Get Enemy Color STA COLUP1 ; Store it! (RED) ;************************************* ;** Start Of Frame ** ;************************************* StartOfFrame ;************************************* ;** Start Vertical Syncing ** ;************************************* lda #0 ;Set TIA to zero sta VBLANK ;Here we go! lda #2 ;Set accumulator to two sta VSYNC sta WSYNC sta WSYNC sta WSYNC ;3 scanlines of Vertical Sync lda #0 ;Set Accumulator to Zero sta VSYNC ;Turn On VSYNC ;************************************* ;** Top Vertical Blanking ** ;************************************* ldx #33 ;set x at 34 for out vertical blank timer NotDone sta WSYNC dex ;Did we hit 37 vertical blanks yet? bne NotDone ;NO - Keep going until we do lda #0 sta VBLANK ;************************************* ;** Draw Playfield ** ;************************************* ;** We have 192 scanlines to use. ** ;** Let's track them! ** ;************************************* LDX #192 ;192 Scanlines to display Draw_Playfield LDA Screen_PF0-1,X STA PF0 LDA Screen_PF1-1,X STA PF1 LDA Screen_PF2-1,X STA PF2 STA WSYNC CPX #Player1POS BEQ ResetPlayer1 DEX BNE Draw_Playfield LDA #%01000010 ; Disable TIA Output STA VBLANK ;************************************* ;** Finish Up Unused Cycles ** ;************************************* ;EndBD sta WSYNC ; dex ; cpx #50 ; bne EndBD ;************************************* ;** Bottom Vertical Blanking ** ;************************************* ldx #0 ;reset x to zero Overscan sta WSYNC ;start overscan trace inx ;increase x by 1 cpx #30 bne Overscan ;No we didn't ;return to Main Routine jmp StartOfFrame ;************************************* ; Place Player OnScreen ** ;************************************* ResetPlayer1 STA RESP0 ; Set Player 0 (X) PlacePlayer1 CPX #8 ; 14 Lines of Sprite Datas Drawn ? BEQ Draw_Playfield ; Yes = Continue Drawing Playfield LDA #Player0_Data,x STA GRP0 DEX JMP PlacePlayer1 ;************************************* ;** Player Sprite Data ** ;************************************* Player0_Data .byte #%00000000 .byte #%01011010 .byte #%01011010 .byte #%01111110 .byte #%00111100 .byte #%01111110 .byte #%11111111 .byte #%11111111 ;************************************* ;** Playfield Data (MAZE 1) ** ;************************************* Screen_PF0 .byte #%11110000 ; Scanline 191 .byte #%10010000 ; Scanline 190 .byte #%10010000 ; Scanline 189 .byte #%10010000 ; Scanline 188 .byte #%10010000 ; Scanline 187 .byte #%10010000 ; Scanline 186 .byte #%10010000 ; Scanline 185 .byte #%10010000 ; Scanline 184 .byte #%10010000 ; Scanline 183 .byte #%10010000 ; Scanline 182 .byte #%10010000 ; Scanline 181 .byte #%10010000 ; Scanline 180 .byte #%10010000 ; Scanline 179 .byte #%10010000 ; Scanline 178 .byte #%10010000 ; Scanline 177 .byte #%10010000 ; Scanline 176 .byte #%10010000 ; Scanline 175 .byte #%10010000 ; Scanline 174 .byte #%10010000 ; Scanline 173 .byte #%10010000 ; Scanline 172 .byte #%10010000 ; Scanline 171 .byte #%10010000 ; Scanline 170 .byte #%10010000 ; Scanline 169 .byte #%00010000 ; Scanline 168 .byte #%00010000 ; Scanline 167 .byte #%00010000 ; Scanline 166 .byte #%00010000 ; Scanline 165 .byte #%00010000 ; Scanline 164 .byte #%00010000 ; Scanline 163 .byte #%00010000 ; Scanline 162 .byte #%00010000 ; Scanline 161 .byte #%00010000 ; Scanline 160 .byte #%00010000 ; Scanline 159 .byte #%00010000 ; Scanline 158 .byte #%00010000 ; Scanline 157 .byte #%00010000 ; Scanline 156 .byte #%00010000 ; Scanline 155 .byte #%00010000 ; Scanline 154 .byte #%00010000 ; Scanline 153 .byte #%00010000 ; Scanline 152 .byte #%00010000 ; Scanline 151 .byte #%10010000 ; Scanline 150 .byte #%10010000 ; Scanline 149 .byte #%10010000 ; Scanline 148 .byte #%10010000 ; Scanline 147 .byte #%10010000 ; Scanline 146 .byte #%10010000 ; Scanline 145 .byte #%10010000 ; Scanline 144 .byte #%10010000 ; Scanline 143 .byte #%10010000 ; Scanline 142 .byte #%10010000 ; Scanline 141 .byte #%10010000 ; Scanline 140 .byte #%10010000 ; Scanline 139 .byte #%10010000 ; Scanline 138 .byte #%10010000 ; Scanline 137 .byte #%10010000 ; Scanline 136 .byte #%10010000 ; Scanline 135 .byte #%10010000 ; Scanline 134 .byte #%10010000 ; Scanline 133 .byte #%10010000 ; Scanline 132 .byte #%10010000 ; Scanline 131 .byte #%10010000 ; Scanline 130 .byte #%10010000 ; Scanline 129 .byte #%10010000 ; Scanline 128 .byte #%10010000 ; Scanline 127 .byte #%10010000 ; Scanline 126 .byte #%10010000 ; Scanline 125 .byte #%10010000 ; Scanline 124 .byte #%10010000 ; Scanline 123 .byte #%10010000 ; Scanline 122 .byte #%10010000 ; Scanline 121 .byte #%10010000 ; Scanline 120 .byte #%10010000 ; Scanline 119 .byte #%10010000 ; Scanline 118 .byte #%10010000 ; Scanline 117 .byte #%10010000 ; Scanline 116 .byte #%10010000 ; Scanline 115 .byte #%10010000 ; Scanline 114 .byte #%10010000 ; Scanline 113 .byte #%10010000 ; Scanline 112 .byte #%10010000 ; Scanline 111 .byte #%10010000 ; Scanline 110 .byte #%10010000 ; Scanline 109 .byte #%10010000 ; Scanline 108 .byte #%10010000 ; Scanline 107 .byte #%10010000 ; Scanline 106 .byte #%10010000 ; Scanline 105 .byte #%00010000 ; Scanline 104 .byte #%00010000 ; Scanline 103 .byte #%00010000 ; Scanline 102 .byte #%00010000 ; Scanline 101 .byte #%00010000 ; Scanline 100 .byte #%00010000 ; Scanline 99 .byte #%00010000 ; Scanline 98 .byte #%00010000 ; Scanline 97 .byte #%00010000 ; Scanline 96 .byte #%00010000 ; Scanline 95 .byte #%00010000 ; Scanline 94 .byte #%00010000 ; Scanline 93 .byte #%00010000 ; Scanline 92 .byte #%00010000 ; Scanline 91 .byte #%00010000 ; Scanline 90 .byte #%00010000 ; Scanline 89 .byte #%00010000 ; Scanline 88 .byte #%00010000 ; Scanline 87 .byte #%00010000 ; Scanline 86 .byte #%10010000 ; Scanline 85 .byte #%10010000 ; Scanline 84 .byte #%10010000 ; Scanline 83 .byte #%10010000 ; Scanline 82 .byte #%10010000 ; Scanline 81 .byte #%10010000 ; Scanline 80 .byte #%10010000 ; Scanline 79 .byte #%10010000 ; Scanline 78 .byte #%10010000 ; Scanline 77 .byte #%10010000 ; Scanline 76 .byte #%10010000 ; Scanline 75 .byte #%10010000 ; Scanline 74 .byte #%10010000 ; Scanline 73 .byte #%10010000 ; Scanline 72 .byte #%10010000 ; Scanline 71 .byte #%10010000 ; Scanline 70 .byte #%10010000 ; Scanline 69 .byte #%10010000 ; Scanline 68 .byte #%10010000 ; Scanline 67 .byte #%10010000 ; Scanline 66 .byte #%10010000 ; Scanline 65 .byte #%10010000 ; Scanline 64 .byte #%10010000 ; Scanline 63 .byte #%10010000 ; Scanline 62 .byte #%10010000 ; Scanline 61 .byte #%10010000 ; Scanline 60 .byte #%10010000 ; Scanline 59 .byte #%10010000 ; Scanline 58 .byte #%10010000 ; Scanline 57 .byte #%10010000 ; Scanline 56 .byte #%10010000 ; Scanline 55 .byte #%10010000 ; Scanline 54 .byte #%10010000 ; Scanline 53 .byte #%10010000 ; Scanline 52 .byte #%10010000 ; Scanline 51 .byte #%10010000 ; Scanline 50 .byte #%10010000 ; Scanline 49 .byte #%10010000 ; Scanline 48 .byte #%10010000 ; Scanline 47 .byte #%10010000 ; Scanline 46 .byte #%10010000 ; Scanline 45 .byte #%10010000 ; Scanline 44 .byte #%10010000 ; Scanline 43 .byte #%10010000 ; Scanline 42 .byte #%10010000 ; Scanline 41 .byte #%10010000 ; Scanline 40 .byte #%10010000 ; Scanline 39 .byte #%00010000 ; Scanline 38 .byte #%00010000 ; Scanline 37 .byte #%00010000 ; Scanline 36 .byte #%00010000 ; Scanline 35 .byte #%00010000 ; Scanline 34 .byte #%00010000 ; Scanline 33 .byte #%00010000 ; Scanline 32 .byte #%00010000 ; Scanline 31 .byte #%00010000 ; Scanline 30 .byte #%00010000 ; Scanline 29 .byte #%00010000 ; Scanline 28 .byte #%00010000 ; Scanline 27 .byte #%00010000 ; Scanline 26 .byte #%00010000 ; Scanline 25 .byte #%00010000 ; Scanline 24 .byte #%00010000 ; Scanline 23 .byte #%00010000 ; Scanline 22 .byte #%00010000 ; Scanline 21 .byte #%00010000 ; Scanline 20 .byte #%10010000 ; Scanline 19 .byte #%10010000 ; Scanline 18 .byte #%10010000 ; Scanline 17 .byte #%10010000 ; Scanline 16 .byte #%10010000 ; Scanline 15 .byte #%10010000 ; Scanline 14 .byte #%10010000 ; Scanline 13 .byte #%10010000 ; Scanline 12 .byte #%10010000 ; Scanline 11 .byte #%10010000 ; Scanline 10 .byte #%10010000 ; Scanline 9 .byte #%10010000 ; Scanline 8 .byte #%10010000 ; Scanline 7 .byte #%10010000 ; Scanline 6 .byte #%10010000 ; Scanline 5 .byte #%10010000 ; Scanline 4 .byte #%10010000 ; Scanline 3 .byte #%10010000 ; Scanline 2 .byte #%11111111 ; Scanline 1 .byte #%11110000 ; Scanline 0 Screen_PF1 .byte #%11111111 ; Scanline 191 .byte #%00000000 ; Scanline 190 .byte #%00000000 ; Scanline 189 .byte #%00000000 ; Scanline 188 .byte #%00000000 ; Scanline 187 .byte #%00000000 ; Scanline 186 .byte #%00000000 ; Scanline 185 .byte #%00000000 ; Scanline 184 .byte #%00000000 ; Scanline 183 .byte #%00000000 ; Scanline 182 .byte #%00000000 ; Scanline 181 .byte #%00000000 ; Scanline 180 .byte #%00000000 ; Scanline 179 .byte #%00000000 ; Scanline 178 .byte #%00000000 ; Scanline 177 .byte #%00000000 ; Scanline 176 .byte #%00111100 ; Scanline 175 .byte #%00100100 ; Scanline 174 .byte #%00100100 ; Scanline 173 .byte #%00100100 ; Scanline 172 .byte #%00100100 ; Scanline 171 .byte #%00100100 ; Scanline 170 .byte #%00100100 ; Scanline 169 .byte #%00100100 ; Scanline 168 .byte #%00100100 ; Scanline 167 .byte #%00100100 ; Scanline 166 .byte #%00100100 ; Scanline 165 .byte #%00100100 ; Scanline 164 .byte #%00100100 ; Scanline 163 .byte #%00100100 ; Scanline 162 .byte #%00100100 ; Scanline 161 .byte #%00100100 ; Scanline 160 .byte #%00100100 ; Scanline 159 .byte #%00100100 ; Scanline 158 .byte #%00100100 ; Scanline 157 .byte #%00100100 ; Scanline 156 .byte #%00100100 ; Scanline 155 .byte #%00100100 ; Scanline 154 .byte #%00100100 ; Scanline 153 .byte #%00100100 ; Scanline 152 .byte #%00100100 ; Scanline 151 .byte #%00100100 ; Scanline 150 .byte #%00100100 ; Scanline 149 .byte #%00100100 ; Scanline 148 .byte #%00100100 ; Scanline 147 .byte #%00100100 ; Scanline 146 .byte #%00100100 ; Scanline 145 .byte #%00100100 ; Scanline 144 .byte #%00100100 ; Scanline 143 .byte #%00100100 ; Scanline 142 .byte #%00100100 ; Scanline 141 .byte #%00100100 ; Scanline 140 .byte #%00000100 ; Scanline 139 .byte #%00000100 ; Scanline 138 .byte #%00000100 ; Scanline 137 .byte #%00000100 ; Scanline 136 .byte #%00000100 ; Scanline 135 .byte #%00000100 ; Scanline 134 .byte #%00000100 ; Scanline 133 .byte #%00000100 ; Scanline 132 .byte #%00000100 ; Scanline 131 .byte #%00000100 ; Scanline 130 .byte #%00000100 ; Scanline 129 .byte #%00000100 ; Scanline 128 .byte #%00000100 ; Scanline 127 .byte #%00000100 ; Scanline 126 .byte #%00000100 ; Scanline 125 .byte #%00000100 ; Scanline 124 .byte #%00000100 ; Scanline 123 .byte #%00100100 ; Scanline 122 .byte #%00100100 ; Scanline 121 .byte #%00100100 ; Scanline 120 .byte #%00100100 ; Scanline 119 .byte #%00100100 ; Scanline 118 .byte #%00100100 ; Scanline 117 .byte #%00100100 ; Scanline 116 .byte #%00100100 ; Scanline 115 .byte #%00100100 ; Scanline 114 .byte #%00100100 ; Scanline 113 .byte #%00100100 ; Scanline 112 .byte #%00100100 ; Scanline 111 .byte #%00100100 ; Scanline 110 .byte #%00100100 ; Scanline 109 .byte #%00100100 ; Scanline 108 .byte #%00100100 ; Scanline 107 .byte #%00100100 ; Scanline 106 .byte #%00100100 ; Scanline 105 .byte #%00100000 ; Scanline 104 .byte #%00100000 ; Scanline 103 .byte #%00100000 ; Scanline 102 .byte #%00100000 ; Scanline 101 .byte #%00100000 ; Scanline 100 .byte #%00100000 ; Scanline 99 .byte #%00100000 ; Scanline 98 .byte #%00100000 ; Scanline 97 .byte #%00100000 ; Scanline 96 .byte #%00100000 ; Scanline 95 .byte #%00100000 ; Scanline 94 .byte #%00100000 ; Scanline 93 .byte #%00100000 ; Scanline 92 .byte #%00100000 ; Scanline 91 .byte #%00100000 ; Scanline 90 .byte #%00100000 ; Scanline 89 .byte #%00100000 ; Scanline 88 .byte #%00100000 ; Scanline 87 .byte #%00100000 ; Scanline 86 .byte #%00100100 ; Scanline 85 .byte #%00100100 ; Scanline 84 .byte #%00100100 ; Scanline 83 .byte #%00100100 ; Scanline 82 .byte #%00100100 ; Scanline 81 .byte #%00100100 ; Scanline 80 .byte #%00100100 ; Scanline 79 .byte #%00100100 ; Scanline 78 .byte #%00100100 ; Scanline 77 .byte #%00100100 ; Scanline 76 .byte #%00100100 ; Scanline 75 .byte #%00100100 ; Scanline 74 .byte #%00100100 ; Scanline 73 .byte #%00000100 ; Scanline 72 .byte #%00000100 ; Scanline 71 .byte #%00000100 ; Scanline 70 .byte #%00000100 ; Scanline 69 .byte #%00000100 ; Scanline 68 .byte #%00000100 ; Scanline 67 .byte #%00000100 ; Scanline 66 .byte #%00000100 ; Scanline 65 .byte #%00000100 ; Scanline 64 .byte #%00000100 ; Scanline 63 .byte #%00000100 ; Scanline 62 .byte #%00000100 ; Scanline 61 .byte #%00000100 ; Scanline 60 .byte #%00000100 ; Scanline 59 .byte #%00000100 ; Scanline 58 .byte #%00000100 ; Scanline 57 .byte #%00000100 ; Scanline 56 .byte #%00000100 ; Scanline 55 .byte #%00100100 ; Scanline 54 .byte #%00100100 ; Scanline 53 .byte #%00100100 ; Scanline 52 .byte #%00100100 ; Scanline 51 .byte #%00100100 ; Scanline 50 .byte #%00100100 ; Scanline 49 .byte #%00100100 ; Scanline 48 .byte #%00100100 ; Scanline 47 .byte #%00100100 ; Scanline 46 .byte #%00100100 ; Scanline 45 .byte #%00100100 ; Scanline 44 .byte #%00100100 ; Scanline 43 .byte #%00100100 ; Scanline 42 .byte #%00100100 ; Scanline 41 .byte #%00100100 ; Scanline 40 .byte #%00100100 ; Scanline 39 .byte #%00100100 ; Scanline 38 .byte #%00100100 ; Scanline 37 .byte #%00100100 ; Scanline 36 .byte #%00100100 ; Scanline 35 .byte #%00100100 ; Scanline 34 .byte #%00100100 ; Scanline 33 .byte #%00100100 ; Scanline 32 .byte #%00100100 ; Scanline 31 .byte #%00100100 ; Scanline 30 .byte #%00100100 ; Scanline 29 .byte #%00100100 ; Scanline 28 .byte #%00100100 ; Scanline 27 .byte #%00100100 ; Scanline 26 .byte #%00100100 ; Scanline 25 .byte #%00100100 ; Scanline 24 .byte #%00100100 ; Scanline 23 .byte #%00100100 ; Scanline 22 .byte #%00100100 ; Scanline 21 .byte #%00100100 ; Scanline 20 .byte #%00100100 ; Scanline 19 .byte #%00100100 ; Scanline 18 .byte #%00100100 ; Scanline 17 .byte #%00100100 ; Scanline 16 .byte #%00100100 ; Scanline 15 .byte #%00111100 ; Scanline 14 .byte #%00000000 ; Scanline 13 .byte #%00000000 ; Scanline 12 .byte #%00000000 ; Scanline 11 .byte #%00000000 ; Scanline 10 .byte #%00000000 ; Scanline 9 .byte #%00000000 ; Scanline 8 .byte #%00000000 ; Scanline 7 .byte #%00000000 ; Scanline 6 .byte #%00000000 ; Scanline 5 .byte #%00000000 ; Scanline 4 .byte #%00000000 ; Scanline 3 .byte #%00000000 ; Scanline 2 .byte #%11111111 ; Scanline 1 .byte #%00000000 ; Scanline 0 Screen_PF2 .byte #%11111111 ; Scanline 191 .byte #%00000001 ; Scanline 190 .byte #%00000001 ; Scanline 189 .byte #%00000001 ; Scanline 188 .byte #%00000001 ; Scanline 187 .byte #%00000001 ; Scanline 186 .byte #%00000001 ; Scanline 185 .byte #%00000001 ; Scanline 184 .byte #%00000001 ; Scanline 183 .byte #%00000001 ; Scanline 182 .byte #%00000001 ; Scanline 181 .byte #%00000001 ; Scanline 180 .byte #%00000001 ; Scanline 179 .byte #%00000001 ; Scanline 178 .byte #%00000001 ; Scanline 177 .byte #%00000001 ; Scanline 176 .byte #%01111001 ; Scanline 175 .byte #%00001001 ; Scanline 174 .byte #%00001001 ; Scanline 173 .byte #%00001001 ; Scanline 172 .byte #%00001001 ; Scanline 171 .byte #%00001001 ; Scanline 170 .byte #%00001001 ; Scanline 169 .byte #%00001000 ; Scanline 168 .byte #%00001000 ; Scanline 167 .byte #%00001000 ; Scanline 166 .byte #%00001000 ; Scanline 165 .byte #%00001000 ; Scanline 164 .byte #%00001000 ; Scanline 163 .byte #%11001000 ; Scanline 162 .byte #%01001000 ; Scanline 161 .byte #%01001000 ; Scanline 160 .byte #%01001000 ; Scanline 159 .byte #%01001000 ; Scanline 158 .byte #%01001000 ; Scanline 157 .byte #%01001000 ; Scanline 156 .byte #%01001000 ; Scanline 155 .byte #%01001000 ; Scanline 154 .byte #%01001000 ; Scanline 153 .byte #%01001000 ; Scanline 152 .byte #%01001000 ; Scanline 151 .byte #%01001001 ; Scanline 150 .byte #%01001001 ; Scanline 149 .byte #%01001001 ; Scanline 148 .byte #%11001001 ; Scanline 147 .byte #%00001001 ; Scanline 146 .byte #%00001001 ; Scanline 145 .byte #%00001001 ; Scanline 144 .byte #%00001001 ; Scanline 143 .byte #%00001001 ; Scanline 142 .byte #%00001001 ; Scanline 141 .byte #%00001001 ; Scanline 140 .byte #%00001001 ; Scanline 139 .byte #%00001001 ; Scanline 138 .byte #%00001001 ; Scanline 137 .byte #%00001001 ; Scanline 136 .byte #%00111001 ; Scanline 135 .byte #%00001001 ; Scanline 134 .byte #%00001001 ; Scanline 133 .byte #%00001001 ; Scanline 132 .byte #%00001001 ; Scanline 131 .byte #%00001001 ; Scanline 130 .byte #%00001001 ; Scanline 129 .byte #%00001001 ; Scanline 128 .byte #%00001001 ; Scanline 127 .byte #%00001001 ; Scanline 126 .byte #%00001001 ; Scanline 125 .byte #%00001001 ; Scanline 124 .byte #%00001001 ; Scanline 123 .byte #%11001001 ; Scanline 122 .byte #%01001001 ; Scanline 121 .byte #%01001001 ; Scanline 120 .byte #%01001001 ; Scanline 119 .byte #%01001001 ; Scanline 118 .byte #%01001001 ; Scanline 117 .byte #%01001001 ; Scanline 116 .byte #%01001001 ; Scanline 115 .byte #%01001001 ; Scanline 114 .byte #%01001001 ; Scanline 113 .byte #%01001001 ; Scanline 112 .byte #%01001001 ; Scanline 111 .byte #%01001001 ; Scanline 110 .byte #%01001001 ; Scanline 109 .byte #%01001001 ; Scanline 108 .byte #%01001001 ; Scanline 107 .byte #%01001001 ; Scanline 106 .byte #%01001001 ; Scanline 105 .byte #%01000001 ; Scanline 104 .byte #%01000001 ; Scanline 103 .byte #%01000001 ; Scanline 102 .byte #%01000001 ; Scanline 101 .byte #%01000001 ; Scanline 100 .byte #%01000001 ; Scanline 99 .byte #%01000001 ; Scanline 98 .byte #%01000001 ; Scanline 97 .byte #%01000001 ; Scanline 96 .byte #%01000001 ; Scanline 95 .byte #%01000001 ; Scanline 94 .byte #%01000001 ; Scanline 93 .byte #%01000001 ; Scanline 92 .byte #%01000001 ; Scanline 91 .byte #%01000001 ; Scanline 90 .byte #%01000001 ; Scanline 89 .byte #%01000001 ; Scanline 88 .byte #%01000001 ; Scanline 87 .byte #%01000001 ; Scanline 86 .byte #%01000001 ; Scanline 85 .byte #%01001001 ; Scanline 84 .byte #%01001001 ; Scanline 83 .byte #%01001001 ; Scanline 82 .byte #%01001001 ; Scanline 81 .byte #%01001001 ; Scanline 80 .byte #%01001001 ; Scanline 79 .byte #%01001001 ; Scanline 78 .byte #%01001001 ; Scanline 77 .byte #%01001001 ; Scanline 76 .byte #%01001001 ; Scanline 75 .byte #%01001001 ; Scanline 74 .byte #%01001001 ; Scanline 73 .byte #%01001001 ; Scanline 72 .byte #%01001001 ; Scanline 71 .byte #%01001001 ; Scanline 70 .byte #%01001001 ; Scanline 69 .byte #%01001001 ; Scanline 68 .byte #%01001001 ; Scanline 67 .byte #%11001001 ; Scanline 66 .byte #%00001001 ; Scanline 65 .byte #%00001001 ; Scanline 64 .byte #%00001001 ; Scanline 63 .byte #%00001001 ; Scanline 62 .byte #%00001001 ; Scanline 61 .byte #%00001001 ; Scanline 60 .byte #%00001001 ; Scanline 59 .byte #%00001001 ; Scanline 58 .byte #%00001001 ; Scanline 57 .byte #%00001001 ; Scanline 56 .byte #%00001001 ; Scanline 55 .byte #%00001001 ; Scanline 54 .byte #%00111001 ; Scanline 53 .byte #%00001001 ; Scanline 52 .byte #%00001001 ; Scanline 51 .byte #%00001001 ; Scanline 50 .byte #%00001001 ; Scanline 49 .byte #%00001001 ; Scanline 48 .byte #%00001001 ; Scanline 47 .byte #%00001001 ; Scanline 46 .byte #%00001001 ; Scanline 45 .byte #%00001001 ; Scanline 44 .byte #%00001001 ; Scanline 43 .byte #%00001001 ; Scanline 42 .byte #%00001001 ; Scanline 41 .byte #%11001001 ; Scanline 40 .byte #%01001001 ; Scanline 39 .byte #%01001000 ; Scanline 38 .byte #%01001000 ; Scanline 37 .byte #%01001000 ; Scanline 36 .byte #%01001000 ; Scanline 35 .byte #%01001000 ; Scanline 34 .byte #%01001000 ; Scanline 33 .byte #%01001000 ; Scanline 32 .byte #%01001000 ; Scanline 31 .byte #%01001000 ; Scanline 30 .byte #%01001000 ; Scanline 29 .byte #%01001000 ; Scanline 28 .byte #%01001000 ; Scanline 27 .byte #%11001000 ; Scanline 26 .byte #%00001000 ; Scanline 25 .byte #%00001000 ; Scanline 24 .byte #%00001000 ; Scanline 23 .byte #%00001000 ; Scanline 22 .byte #%00001000 ; Scanline 21 .byte #%00001000 ; Scanline 20 .byte #%00001001 ; Scanline 19 .byte #%00001001 ; Scanline 18 .byte #%00001001 ; Scanline 17 .byte #%00001001 ; Scanline 16 .byte #%00001001 ; Scanline 15 .byte #%00001001 ; Scanline 14 .byte #%01111001 ; Scanline 13 .byte #%00000001 ; Scanline 12 .byte #%00000001 ; Scanline 11 .byte #%00000001 ; Scanline 10 .byte #%00000001 ; Scanline 9 .byte #%00000001 ; Scanline 8 .byte #%00000001 ; Scanline 7 .byte #%00000001 ; Scanline 6 .byte #%00000001 ; Scanline 5 .byte #%00000001 ; Scanline 4 .byte #%00000001 ; Scanline 3 .byte #%00000001 ; Scanline 2 .byte #%11111111 ; Scanline 1 .byte #%00000000 ; Scanline 0 ;************************************* ;** End of Coding ** ;************************************* ORG #$FFFA InterruptVectors .word Reset ;NMI .word Reset ;RESET .word Reset ;IRQ END I would appreciate any suggestions as to what I am doing wrong. I also noticed that joystick routines are missing from Andrew's tutorials. Are there any tutorials available that deal with reading the joystick ports? Thanks in advance! I would share the binary file I have but I can't remember how to share it on Atari Age. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted May 11, 2014 Share Posted May 11, 2014 You are setting X=192 for your 'Draw_Playfield' loop, and then branching out when X=Player1POS, which is hardcoded to 130. So you are only drawing ~ 62 lines there. Once in there you are getting stuck in 'PlacePlayer1' place player loop until X decreases to 8. The logic looks wrong there. You want to draw eight lines of a sprite, but you have never set up X. So maybe save X at that point and reload it with 8. After you are done that routine you car re-load X. Also you have no WSYNC's in you loop for drawing PlacePlayer1. You need to implement a better routine for repositioning P0 as you have to hit it at the correct cycle (depending on where you want it horizontally). Finally maybe look at how to use timers for delaying time after and before drawing the kernel. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted May 11, 2014 Share Posted May 11, 2014 It's been a while since anyone has responded to my questions above so I will do an update. I actually started to reply a couple of times, but my responses started getting way too complicated, so I never finished them. I'll see if I can answer simply. Is it possible to draw the sprite after the playfield has been drawn? Do any sprites have to be drawn while the playfield is being drawn? I'm only asking because of a few things. I was under the impression that once the playfield had been drawn it would stay there. I assume this is on a per scanline basis and not an entire screen, correct? Generally speaking, you can write to the playfield and sprite graphics registers (as well as their color registers) in any order, as long as you write the desired values to them sometime before the TIA needs to draw them. But the 2600 has no video memory per se, just the registers for the graphics and colors, so anything you write to those registers will be displayed over and over again on the subsequent scan lines until you write new values to them. In your case, you're using a mirrored playfield, which means you can write to the three playfield graphics registers once per line, and even leave them alone for several scan lines for the portions of the playfield that stay the same for several scan lines. In other words, if you design your loops correctly, you don't need 192 bytes of data for each playfield register, just the data for the unique lines. The following example is pseudo-code written in a hypothetical BASIC (not batari Basic) to illustrate what I mean: rem * suppose the first playfield row is 8 lines tall read PF0data, PF1data, PF2data PF0 = PF0data PF1 = PF1data PF2 = PF2data for x = 1 to 8 WSYNC = 0 : rem * strobe WSYNC so the playfield is drawn the same for 8 lines next x rem * suppose the next playfield row is 16 lines tall read PF0data, PF1data, PF2data PF0 = PF0data PF1 = PF1data PF2 = PF2data for x = 1 to 16 WSYNC = 0 : rem * strobe WSYNC so the playfield is drawn the same for 16 lines next x rem * etc. On the other hand, you'll want to draw the player-missile sprites anywhere, so the loop(s) will need to include code for that, too-- in which case, if ROM isn't an issue, you might as well just have 192 bytes of playfield data for each line, since it will be simpler to include the code for the player-missile graphics and colors. If you need to load and store too much data per line, such that you can't do it all during the HBLANK period, you'll need to count cycles and determine where on the scan line each instruction is getting executed, then if you need to you can rearrange some of the instructions. For instance, the TIA needs to draw PF0 first, so you'll want to load PF0's data and store it sometime before HBLANK ends, but you can write to PF1 a little bit after HBLANK ends, and you can write to PF2 a little bit after that, so if you need to you could write to PF0, then write to GRP0, then write to GRP1, then write to PF1, then write to PF2, or something like that, as long as each register gets written to by the time the TIA needs to draw from that register. I've been trying to understand the joystick registers. That is one area that Andrew's tutorial I don't believe talked about. How are those registers detected? The joystick registers are part of the RIOT chip-- SWCHA, or location $0280. You'll need to use SWACNT ($0281) to set the desired bits of SWCHA to the input mode-- if you want to read both joysticks, just set SWACNT to 0-- then you can read SWCHA at least once per screen to get the joysticks' values. There are two basic philosophies here-- one is to read SWCHA once per screen and store its value in RAM for future reference, and the other is to just read SWCHA as many times as needed per screen (you'll need to bit-mask the value to check each of the directions, hence the need to either store its value or reread it as needed). The upper nibble of SWCHA is the left joystick, and the lower nibble is the right joystick: D7 = left joystick pushed right D6 = left joystick pushed left D5 = left joystick pushed down D4 = left joystick pushed up D3 = right joystick pushed right D2 = right joystick pushed left D1 = right joystick pushed down D0 = right joystick pushed up If a given bit contains a 1, it means the joystick is *not* being pushed in that direction; but if the bit is 0, then the joystick *is* being pushed in that direction. Thus, if SWCHA contains 255 (all 8 bits set to 1), it means neither joystick is being pushed in any of the directions. But if, for example, SWCHA contains the value %10100000, then the left joystick is being pushed to the right and down simultaneously, whereas the right joystick isn't being pushed. The joystick buttons, on the other hand, are read from the TIA at INPT4 (address $0C, left joystick's button) and INPT5 (address $0D, right joystick's button). Quote Link to comment Share on other sites More sharing options...
kamakazi Posted May 11, 2014 Author Share Posted May 11, 2014 From the responses I'm getting it seems like I might ought to try and rework the code for optimization reasons. The code will need to be able to perform playfield, sprites, joystick detection, collision detection (four of these: one for collecting a flag, one for any missile hitting another player, one for any player running into a playfield boundary, and one for any player running into another one), scoring, lives, and a timer. Let's see...did I miss something. Oh, YEA! The AI of the enemy sprites. So I still have a LOT of work to do and if I try to optimize now the less issues I will have later. Hopefully. Thanks for the information. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted May 14, 2014 Share Posted May 14, 2014 (edited) From the responses I'm getting it seems like I might ought to try and rework the code for optimization reasons. The code will need to be able to perform playfield, sprites, joystick detection, collision detection (four of these: one for collecting a flag, one for any missile hitting another player, one for any player running into a playfield boundary, and one for any player running into another one), scoring, lives, and a timer. Let's see...did I miss something. Oh, YEA! The AI of the enemy sprites. So I still have a LOT of work to do and if I try to optimize now the less issues I will have later. Hopefully. Thanks for the information. If you modify your maze just a bit, you can have just 27 bytes of data for each playfield register, with 8 scan lines left over at the bottom for displaying a score bar, timer bar, or something like that. Attached is a mockup of what the modified maze would look like, plus a blank form that you can use for designing additional mazes. Edit: The silver lines represent the boundaries of the maze building blocks as it were, and the black lines represent the boundaries of the playfield registers, to help you with coding the data bytes. Edited May 15, 2014 by SeaGtGruff Quote Link to comment Share on other sites More sharing options...
kamakazi Posted May 16, 2014 Author Share Posted May 16, 2014 (edited) So I can convert my playfield data from #%10111101 to #$BD and then I would end up with something like: .byte #$00 .byte #$5A .byte #$FF .byte #$7E .byte #$3C .byte #$5A .byte #$5A .byte #$00 Then I can simplify the data further by doing something like: .byte #$00, $5A, $FF, $7E, $3C And then just load the playfield changes when needed? I am learning but this ol' dog is taking a while to get the hang of it. Assembly has a lot more hand-holding than BASIC or other forms of programming languages I've come across. In some ways it is almost like ActionScript (FLASH) in that you have to be very specific at specific times or nothing will be right. And one flaw can throw a monkey wrench in the whole thing. Edited May 16, 2014 by kamakazi Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted May 16, 2014 Share Posted May 16, 2014 So I can convert my playfield data from #%10111101 to #$BD and then I would end up with something like: .byte #$00 .byte #$5A .byte #$FF .byte #$7E .byte #$3C .byte #$5A .byte #$5A .byte #$00 Then I can simplify the data further by doing something like: .byte #$00, $5A, $FF, $7E, $3C And then just load the playfield changes when needed? I am learning but this ol' dog is taking a while to get the hang of it. Assembly has a lot more hand-holding than BASIC or other forms of programming languages I've come across. In some ways it is almost like ActionScript (FLASH) in that you have to be very specific at specific times or nothing will be right. And one flaw can throw a monkey wrench in the whole thing. That's a way to simplify the format of the data, but by itself it doesn't reduce the ROM space needed. If you want to know the most compact format you could use for the data within the source code, that would be with the HEX statement rather than the BYTE statement: HEX 005AFF7E3C ; no spaces or dollar signs needed, just nibbles of hex data HEX 00 5A FF 7E 3C ; although it's easier to read/understand if you space it out But with graphics data I think it makes more sense to put the data in binary form-- at least, if the graphics use 2 colors (foreground/background, or on/off)-- so I'd personally leave it in binary format. Quote Link to comment Share on other sites More sharing options...
kamakazi Posted May 17, 2014 Author Share Posted May 17, 2014 Without using bankswitching I am limited to 2K or 4K of ROM, correct? Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted May 17, 2014 Share Posted May 17, 2014 Without using bankswitching I am limited to 2K or 4K of ROM, correct? That's right-- anything over 4K would require bankswitching. Quote Link to comment Share on other sites More sharing options...
kamakazi Posted May 28, 2014 Author Share Posted May 28, 2014 It's been a while and progress on this 2600 program has been slow. To take a break I have been learning the Atari 8-bits as well (ML routines through BASIC). IF there is enough space on the 2600 the game is planned to have at least 4 different mazes that randomly appear. I have also thought about breaking the maze down into "parts" that can be randomly placed so that each maze would be unique. Still a work in progress though and there are plans in place to have it appear on ALL the Atari 8-bit consoles from the 2600 to the 7800 and computers. I've got a LOT of learning to do so if I don't respond in a while it's because I will be busy hammering out code for the game. I also have two more game ideas on paper that will follow this one. I'm following one of my childhood dreams of wanting to work for Atari, Inc and at 40 years old it's all I have besides my wife and doggie. For some reason, though, the learning process is going slow and I use to be able to pick up on programming languages fairly quick. I blame old age on this one LOL. Hang in there with me...I WILL get 'er done! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.