By Darrell Spice, Jr. (adapted by Duane Alan Hahn, a.k.a. Random Terrain)
As an Amazon Associate I earn from qualifying purchases. (I get commissions for purchases made through certain links on this page.)
Original Blog Entry
As anybody involved in writing software can tell you, project specifications will often change when new information becomes available.
When I started working on Collect, my plan was to use it for my presentation at Classic Game Fest. As I've progressed I've come to the realization that a full blown game is going to be just too much information for a one hour presentation. I decided that I'm going to leave the existing example in place and just add a few slides about Collect with a link to these blog entries for anybody who is interested.
Since I'm no longer planning to fit this project into a presentation, I've decided on a few changes:
Mockup of two player game with new timer bar:
Timer has decreased:
One player variation will hide right player's score and use player1 as an additional box:
The Ball Object has a vertical delay feature. When used, the ball should be updated on the same scanline as player0. Due to this, I've revised the 2LK to be like this:
This was done to plan ahead for when the playfield is no longer updated on every scanline. Updating the playfield and ball will make the 2LK look something like this:
I'll also need to add in updates for the missiles. Ideally we want to update them on every scanline like this:
It's possible the timing won't work out for that. If it doesn't, then a change like this should work:
That would make it so that the missile objects can only start on every-other-scanline, but that's an OK compromise for our game.
In this build I've revised the Arena to be a little bit shorter to make room for the new timer display. The timer currently "ticks" once every 64 frames. Whenever it ticks, a bunch of byte rotations are done to shorten the length of the timer bar.
DecrementTimer: lsr TimerPF+5 ; PF2 right side, reversed bits so shift right rol TimerPF+4 ; PF1 right side, normal bits so shift left ror TimerPF+3 ; PF0 right side, reversed bits so shift right lda TimerPF+3 ; only upper nybble used, so we need to put bit 3 into C lsr lsr lsr lsr ror TimerPF+2 ; PF2 left side, reversed bits so shift right rol TimerPF+1 ; PF1 left side, normal bits so shift left ror TimerPF ; PF0 left side, reversed bits so shift right rts
Since there are 40 playfield pixels, the total playtime would be 40*64/60 = 42.7 seconds. We might decide that's too short of a play time. If so, we'll just change the tick to occur every 128 frames for 40*128/60 = 85.3 seconds of game time, or maybe even once very 256 frames for 40*256/60 = 170.7 seconds.
SetObjectColors has been modified to add a color for the timer bar. The Timer Bar and the Arena are both drawn using the playfield, so to make the Arena a different color than the Timer Bar I store the current Arena color in a RAM location.
SetObjectColors: ldx #4 ; we're going to set 5 colors (0-4) ldy #4 ; default to the color entries in the table (0-4) lda SWCHB ; read the state of the console switches and #%00001000 ; test state of D3, the TV Type switch bne SOCloop ; if D3=1 then use color ldy #9 ; else use the b&w entries in the table (5-9) SOCloop: lda Colors,y ; get the color or b&w value sta COLUP0-1,x ; and set it dey ; decrease Y dex ; decrease X bne SOCloop ; Branch Not Equal to Zero lda Colors,y ; get the Arena color sta ArenaColor ; save in RAM for Kernal Usage rts ; ReTurn from Subroutine Colors: .byte $46 ; red - goes into COLUPF, color for Arena (after Timer is drawn) .byte $86 ; blue - goes into COLUP0, color for player0 and missile0 .byte $C6 ; green - goes into COLUP1, color for player1 and missile1 .byte $64 ; purple - goes into COLUPF, color for Timer .byte $00 ; black - goes into COLUBK, color for background .byte $0A ; light grey - goes into COLUPF, color for Arena (after Timer is drawn) .byte $0E ; white - goes into COLUP0, color for player0 and missile0 .byte $06 ; dark grey - goes into COLUP1, color for player1 and missile1 .byte $04 ; dark grey - goes into COLUPF, color for Timer .byte $00 ; black - goes into COLUBK, color for background
For testing, I've set it up so the Right Difficulty switch is used to determine if the game is a one or two player game for which graphics to use for player1:
ldx #0 bit SWCHB bpl TwoPlayer ldx #1 TwoPlayer: ; 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 <(HumanGfx + HUMAN_HEIGHT - 1) .byte <(BoxGfx + HUMAN_HEIGHT - 1) ShapePtrHi: .byte >(HumanGfx + HUMAN_HEIGHT - 1) .byte >(BoxGfx + HUMAN_HEIGHT - 1)
Right Difficulty = B:
Right Difficulty = A:
The ROM and the source are at the bottom of my blog entry.
Other Assembly Language Tutorials
Step 6: Spec Change
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.
Some people appear to have a mental illness because they have a vitamin B deficiency. For example, the wife of a guy I used to chat with online had severe mood swings which seemed to be caused by food allergies or intolerances. She would became irrational, obnoxious, throw tantrums, and generally act like she had a mental illness. The horrid behavior stopped after she started taking a vitamin B complex. I’ve been taking #ad Jarrow B-Right for many years. It makes me much easier to live with.
Unfermented soy is bad! “When she stopped eating soy, the mental problems went away.” Fermented soy doesn’t bother me, but the various versions of unfermented soy (soy flour, soybean oil, and so on) that are used in all kinds of products these days causes a negative mental health reaction in me that a vitamin B complex can’t tame. The sinister encroachment of soy has made the careful reading of ingredients a necessity.
If you are overweight, have type II diabetes, or are worried about the condition of your heart, check out the videos by William Davis and Ivor Cummins. It seems that most people should avoid wheat, not just those who have a wheat allergy or celiac disease. Check out these books: #ad Undoctored, #ad Wheat Belly, and #ad Eat Rich, Live Long.
Negative ions are good for us. You might want to avoid positive ion generators and ozone generators. Whenever I need a new air cleaner (with negative ion generator), I buy it from surroundair.com. A plain old air cleaner is better than nothing, but one that produces negative ions makes the air in a room fresher and easier for me to breathe. It also helps to brighten my mood.
Never litter. Toss it in the trash or take it home. Do not throw it on the ground. Also remember that good people clean up after themselves at home, out in public, at a campsite and so on. Leave it better than you found it.
Seems like more people than ever finally care about water, land, and air pollution, but the climate change cash grab scam is designed to put more of your money into the bank accounts of greedy politicians. Those power-hungry schemers try to trick us with bad data and lies about overpopulation while pretending to be caring do-gooders. Trying to eliminate pollution is a good thing, but the carbon footprint of the average law-abiding human right now is actually making the planet greener instead of killing it.
Watch these two YouTube videos for more information:
Take a look at my page called The H Word and Beyond.
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.
Use any example programs at your own risk. I am not responsible if they blow up your computer or melt your Atari 2600. Use assembly language at your own risk. I am not responsible if assembly language makes you cry or gives you brain damage.