By Darrell Spice, Jr. (adapted by Duane Alan Hahn)
Support this site with PayPal.
Original Blog Entry
It's common for Atari games to have a number of game variations. To simplify the logic, the variations are usually driven by individual bits and/or groups of bits within a single byte that holds the game variation. A good example of that would be Space Invaders—check out the game matrix from the manual:
A byte is comprised of 8 bits, usually numbered 0-7 where 7 is the leftmost bit as in 76543210.
For Space Invaders, the bits in the game variation are used in this fashion:
Humans start counting at 1, but computers start at 0, so if you select game variation 12, internally it's really 11. 11 in binary is %00001011, which means bits 0, 1 and 3 are all turned on so the game variation has Invisible Invaders, ZigZagging Bombs and Moving Shields. You can confirm that by looking at column 12 of the Game Matrix above.
With this update to Collect, we're using bits 1 and 0 to give us 4 game variations:
If we have space at the end of the project, I plan to add some additional arenas. If we can add 2 more we'd just start using bit 2 and let the game Variation go from 1-8:
If we can add 6 more we'd add bit 3 and let the game variation go from 1-16
The ProcessSwitches routine has been modified so that hitting Select will increment the new variable Variation. It will also limit Variation to only the values 0-3. After changing Variation, the left score will be set to show Variation+1 as Humans prefer to see 1-4 instead of 0-3. The Right Score will be used to show the # of players, either 1 or 2.
NotReset: lsr ; D1 is now in C bcs NotSelect ; if D1 was on, the SELECT switch was not held lda #0 sta GameState ; clear D7 to signify Game Over ldx Variation ; Get the Game Variation inx ; and increase it txa ; transfer it to A and #%00000011 ; limit Variation to 0-3 sta Variation ; save it tax ; transfer it to X inx ; and increase it by 1 for the human readable varation 1-4 stx Score ; save in Score so it shows on left side ldy #1 ; default to showing 1 player variation lsr ; D0 of Variation, # of players, now in Carry flag bcc Not2 ; if Carry is clear, then show 1 player iny ; else set Y to 2 to show 2 players Not2: ror Players ; put Carry into D7 for BIT testing of # of players sty Score+1 ; show the human readable # of players on right side NotSelect: rts
The routine works, but when Select is pressed the game variation will rapidly change making it difficult to select a specific game variation. You can see that in the build in my blog entry.
To fix that, we'll add a SelectDelay variable so that holding down SELECT will only result in Variation changing at the rate of once per second. However, if the user rapidly presses/releases SELECT then Variation will also rapidly change.
ProcessSwitches: lda SWCHB ; load in the state of the switches lsr ; D0 is now in C bcs NotReset ; if D0 was on, the RESET switch was not held jsr InitPos ; Prep for new game lda #%10000000 sta GameState ; set D7 on to signify Game Active bne NotSelect ; clear SelectDelay NotReset: lsr ; D1 is now in C bcs NotSelect ; if D1 was on, the SELECT switch was not held lda #0 sta GameState ; clear D7 to signify Game Over lda SelectDelay ; do we need to delay the Select switch? beq SelectOK ; if delay is 0 then no dec SelectDelay ; else decrement the delay rts ; and exit the subroutine SelectOK: lda #60 ; Set the Select Delay to 1 second sta SelectDelay ; ldx Variation ; Get the Game Variation inx ; and increase it txa ; transfer it to A and #%00000011 ; limit Variation to 0-3 sta Variation ; save it tax ; transfer it to X inx ; and increase it by 1 for the human readable varation 1-4 stx Score ; save in Score so it shows on left side ldy #1 ; default to showing 1 player variation lsr ; D0 of Variation, # of players, now in Carry flag bcc Not2 ; if Carry is clear, then show 1 player iny ; else set Y to 2 to show 2 players Not2: ror Players ; put Carry into D7 for BIT testing of # of players sty Score+1 ; show the human readable # of players on right side rts NotSelect: lda #0 ; clears SelectDelay if SELECT not held sta SelectDelay rts
The routine PositionObjects has been modified to use a Box Graphic for player1 if a 1 player game has been selected:
PositionObjects: ... lda Variation ; get the game variation and #1 ; and find out if we're 1 or 2 player tax ; Player1Ptr = BoxGfx + HUMAN_HEIGHT - 1 - Y position lda ShapePtrLow,x sec sbc Temp sta Player1Ptr lda ShapePtrHi,x sbc #0 sta Player1Ptr+1 rts ShapePtrLow: .byte <(BoxGfx + HUMAN_HEIGHT - 1) .byte <(HumanGfx + HUMAN_HEIGHT - 1) ShapePtrHi: .byte >(BoxGfx + HUMAN_HEIGHT - 1) .byte >(HumanGfx + HUMAN_HEIGHT - 1)
The Kernel has also been modified so that the correct Arena will be drawn. A little bit after TimerBar: you'll find this:
TimerBar: ... lda Variation ; 3 20 lsr ; 2 22 - which Arena to show tay ; 2 24 - set for index ldx ArenaOffset,y ; 4 28 - set X for which arena to draw lda ArenaPF0,x ; 4 32 - reflect and priority for playfield and #%00000111 ; 2 34 - get the lower 3 bits for CTRLPF ora #%00110000 ; 2 36 - set ball to display as 8x pixel sta CTRLPF ; 3 39 ... ArenaOffset: .byte 0 ; Arena 1 .byte 22 ; Arena 2
The lsr command shifts bit 1 down to bit 0 so that we end up with 0 or 1 for the Arena number. That's used to set X to either 0 or 22 via the command ldx ArenaOffset,y.
I also added code to update CTRLPF based on the first PF0 data byte for the selected Arena. CTRLPF uses its bits like this:
Since PF0 only uses bits 7654, also known as the upper nybble of the byte, we can use the lower nybble to hold extra information to specify whether or not the selected Arena uses Playfield Priority (as opposed to Player Priority) or has a Reflected Playfield(as opposed to Repeated Playfield). We could even specify Score Mode which would just color the two sides of the playfield to match the colors of the players (like in the score display).
ArenaPF0: ; PF0 is drawn in reverse order, and only the upper nybble .byte %11110001 ; Arena 1 lower nybble controls playfield, set for REFLECT .byte %00010000 .byte %00010000 .byte %00010000 ... .byte %11110100 ; Arena 2 - lower nybble controls playfield, set for PLAYFIELD PRIORITY .byte %00010000 .byte %00010000 .byte %00010000
Game Variation 2, Arena 1 with 2 players. Arena 1 features Reflected Playfield and Player Priority:
Game Variation 3, Arena 2 with 1 player. Arena 2 features Repeated Playfield and Playfield Priority:
Look at the left Humanoid's head in each screenshot to see the difference that setting Playfield Priority makes. You might remember this being used in some games like Combat where the planes go behind the clouds.
Just for fun, here's Arena 2 with SCORE mode set (I've moved the players to the side of the screen they didn't start on):
The code change for that is:
.byte %11110010 ; Arena 2 - lower nybble controls playfield, set for SCORE
The ROM and the source are at the bottom of my blog entry.
Goals for this tutorial.
On other systems, the video chip generates the display; on the 2600, your program generates the display.
Improve the display generation by using the built-in timer.
Using the playfield to display information.
Draw the player objects (sprites) on screen (X & Y location).
Finish the Y positioning of the player objects (sprites).
Revise our goals.
Display an arena (like the mazes in Combat).
Using the Game Select and Game Reset console switches.
Step 9: Game Variations
How to implement game variations (number of players, different mazes).
How to randomize your game.
Draw the ball on screen (X & Y location).
Draw the missiles on screen (X & Y location)
Let’s make some noise!
Make the humans run instead of glide.
This book was written in English, not computerese. It's written for Atari users, not for professional programmers (though they might find it useful).
This book only assumes a working knowledge of BASIC. It was designed to speak directly to the amateur programmer, the part-time computerist. It should help you make the transition from BASIC to machine language with relative ease.
The 6502 Instruction Set broken down into 6 groups.
Nice, simple instruction set in little boxes (not made out of ticky-tacky).
This book shows how to put together a large machine language program. All of the fundamentals were covered in Machine Language for Beginners. What remains is to put the rules to use by constructing a working program, to take the theory into the field and show how machine language is done.
An easy-to-read page from The Second Book Of Machine Language.
A useful page from Assembly Language Programming for the Atari Computers.
Continually strives to remain the largest and most complete source for 6502-related information in the world.
By John Pickens. Updated by Bruce Clark.
Below are direct links to the most important pages.
Goes over each of the internal registers and their use.
Gives a summary of whole instruction set.
Describes each of the 6502 memory addressing modes.
Describes the complete instruction set in detail.
Cycle counting is an important aspect of Atari 2600 programming. It makes possible the positioning of sprites, the drawing of six-digit scores, non-mirrored playfield graphics and many other cool TIA tricks that keep every game from looking like Combat.
Atari 2600 programming is different from any other kind of programming in many ways. Just one of these ways is the flow of the program.
The "bankswitching bible." Also check out the Atari 2600 Fun Facts and Information Guide and this post about bankswitching by SeaGtGruff at AtariAge.
Atari 2600 programming specs (HTML version).
Links to useful information, tools, source code, and documentation.
Atari 2600 programming site based on Garon's "The Dig," which is now dead.
Includes interactive color charts, an NTSC/PAL color conversion tool, and Atari 2600 color compatibility tools that can help you quickly find colors that go great together.
Adapted information and charts related to Atari 2600 music and sound.
A guide and a check list for finished carts.
A multi-platform Atari 2600 VCS emulator. It has a built-in debugger to help you with your works in progress or you can use it to study classic games.
A very good emulator that can also be embedded on your own web site so people can play the games you make online. It's much better than JStella.
If assembly language seems a little too hard, don't worry. You can always try to make Atari 2600 games the faster, easier way with batari Basic.
View this page and any external web sites at your own risk. I am not responsible for any possible spiritual, emotional, physical, financial or any other damage to you, your friends, family, ancestors, or descendants in the past, present, or future, living or dead, in this dimension or any other.