How to Draw A Playfield
by Nick Bensema (6:35 P.M. 9/10/98)
(Adapted by Duane Alan Hahn)
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.
Since the CPU must hold the TIA's hand through all graphical operations, the flow ought to go like this:
Clear memory and registers
Set up variables
Loop:
Do the vertical blank
Do game calculations
Draw screen
Do more calculations during overscan
Wait for next vertical blank
End Loop
What I will do is create an outline, and explain everything I can. This program will display "HELLO" and scroll it down the screen.
In writing this program, I will take the opportunity to show you how a few simple modifications can completely change a program's appearance or behavior. I will invite you to comment out a few lines of code, and alter others, so that you can observe the results.
I will be using DASM for now. Conversion to A65 should be trivial.
processor 6502
include vcs.h
org $F000
Temp = $80
PlayfieldY = $90
Start
Let's Clear Things Up
The 2600 powers up in a completely random state, except for the PC which is set to the location at $FFC. Therefore the first thing we must do is to set everything up inside the 6502.
SEI ; Disable interrupts, if there are any.
CLD ; Clear BCD math bit.
You may feel the need to use the stack, in which case:
LDX #$FF
TXS ; Set stack to beginning.
Clear Memory and TIA Registers
Now the memory and TIA registers must be cleared. You may feel the need to write a subroutine that only clears out a certain section of memory, but for now a simple loop will suffice.
Since X is already loaded to 0xFF, our task becomes simply to count everything off.
LDA #0
B1 STA 0,X
DEX
BNE B1
The above routine does not clear location 0, which is VSYNC. We will take care of that later.
Set Up Joysticks and Such
At this point in the code we would set up things like the data direction registers for the joysticks and such.
JSR GameInit
Program Flow
Here is a representation of our program flow.
MainLoop
JSR VerticalBlank ;Execute the vertical blank.
JSR CheckSwitches ;Check console switches.
JSR GameCalc ;Do calculations during Vblank
JSR DrawScreen ;Draw the screen
JSR OverScan ;Do more calculations during overscan
JMP MainLoop ;Continue forever.
VSYNC
It is important to maintain a stable screen, and this routine does some important and mysterious things. Actually, the only mysterious part is VSYNC. All VBLANK does is blank the TIA's output so that no graphics are drawn otherwise the screen scans normally. It is VSYNC which tells the TV to pack its bags and move to the other corner of the screen.
Fortunately, my program sets VBLANK at the beginning of the overscan period, which usually precedes this subroutine, so it is not changed here.
VerticalBlank ;*********************** VERTICAL BLANK HANDLER
LDX #0
LDA #2
STA WSYNC
STA WSYNC
STA WSYNC
STA VSYNC ;Begin vertical sync.
STA WSYNC ; First line of VSYNC
STA WSYNC ; Second line of VSYNC.
But before we finish off the third line of VSYNC, why don't we use this time to set the timer? This will save us a few cycles which would be more useful in the overscan area.
To insure that we begin to draw the screen at the proper time, we must set the timer to go off just slightly before the end of the vertical blank space, so that we can WSYNC up to the ACTUAL end of the vertical blank space. Of course, the scanline we're going to omit is the same scanline we were about to waste VSYNCing, so it all evens out.
Cycle Count
Atari says we have to have 37 scanlines of VBLANK time. Since each scanline uses 76 cycles, that makes 37*76=2888 cycles. We must also subtract the five cycles it will take to set the timer, and the three cycles it will take to STA WSYNC to the next line. Plus the checking loop is only accurate to six cycles, making a total of fourteen cycles we have to waste. 2888-14=2876.
We almost always use TIM64T for this, since the math just won't work out with the other intervals. 2880/64=44. something. It doesn't matter what that something is, we have to round DOWN.
LDA #44
STA TIM64T
Clear Collision Latches
And now's as good a time as any to clear the collision latches.
LDA #0
STA CXCLR
End VSYNC Period
Now we can end the VSYNC period.
STA WSYNC ; Third line of VSYNC.
STA VSYNC ; (0)
At this point in time the screen is scanning normally, but the TIA's output is suppressed. It will begin again once 0 is written back into VBLANK.
RTS
Game Switch Switcheroo
Checking the game switches is relatively simple.
It just so happens that I'm not going to check any game switches here. I'm just going to set up the colors, without even checking the B&W switch! HA!
CheckSwitches ;*************************** CONSOLE SWITCH HANDLER
LDA #0
STA COLUBK ; Background will be black.
RTS
Game Calculations
Minimal game calculations, just to get the ball rolling.
GameCalc ;******************************* GAME CALCULATION ROUTINES
INC PlayfieldY ;Inch up the playfield
RTS
Screen Drawing Routines
This is the scariest thing I've done all month.
DrawScreen ;**************************** SCREEN DRAWING ROUTINES
LDA INTIM
BNE DrawScreen ; Whew!
STA WSYNC
STA VBLANK ;End the VBLANK period with a zero.
Now we can do what we need to do. What sort of playfield do we want to show? A doubled playfield will work better than anything if we either want a side scroller (which involves some tricky bit shifting, usually) or an asymmetrical playfield (which we're not doing yet). A mirrored playfield is usually best for vertical scrollers. With some creativity, you can use both in your game.
Score
The "score" bit is useful for drawing scores with playfield graphics as Combat and other early games do. It can also create a neat effect if you know how to be creative with it. One useful application of score mode would be always having player 1 on the left side, and player 0 on the right side. Each player would be surrounded in the opposite color, and the ball graphic could be used to stand out against either one. On my 2600jr, color from the right side bleeds about one pixel into the left side, so don't think it's perfect. It's really far from perfect because PC Atari does not implement it at all both sides appear as Player 0's color. A26 does, though.
To accommodate this, my routine puts color values into COLUP0 for the left side, and COLUP1 for the right side. Change the LDA operand to 0 or 1 to use the normal system. The code in the scanning loop accounts for both systems.
LDA #2
STA CTRLPF
Initialize Display Variables
There aren't any display variables!
Counting Scanlines with Y Register
I'm going to use the Y register to count scanlines this time. Realize that I am forfeiting the use of the Y register for this purpose, but DEC Zero Page takes five cycles as opposed to DEY's two, and LDA Zero Page takes three cycles as opposed to TYA's two.
I'm using all 191 remaining scanlines after the WSYNC. If you want less, or more, change the LDY line.
This is a decremental loop, that is, Y starts at 191 and continues down to 0, as do all functions of Y such as memory locations, which is why the graphics at the end of this file are stored "bottom-up". In a way, one could say that's how the screen is drawn. To turn this into an incremental loop, change the number to 65 (255-191) and change the DEY at the end of the scanning loop to INY.
LDY #191
A Clean Routine
Okay, now THIS is scary. I decided to put the bulk of my comments BEFORE the code, rather than inside it, so that you can look at the code all at once.
This routine came out surprisingly clean. There are no branches, and most updates are made even before PF0 becomes visible at cycle 23, even though PF1 and PF2 don't become visible until, by my estimate, cycles 29 and 40, respectively. We could use this time to get player shape and colors from temp variables and sneak them in, but that's another file. I put less-than signs in there to demonstrate that each register is changed before the "deadline cycle" at which point the changes would not completely appear on the current scanline.
The playfield will only be moved up every 4 scanlines, so it doesn't look squished. I could have updated it every 2 scanlines, and that would have saved two cycles. I could have saved another two cycles by having it change EVERY scanline. Comment out one or both of the ASL's to see what this would look like. I realize that it updates the PF registers whether it needs it or not, but it would be pointless to branch around these updates. Better to know you're wasting cycles and have them counted than to get unlucky and have your code spill into the next scanline every time too many things get updated.
Moving Playfield
This is going to be a moving playfield. For a stationary playfield, comment out the SEC and SBC lines. That's probably what most of you all are going to want, anyway. And for a really good moving playfield, like in River Raid or Vanguard, you'll need slightly more interesting code than I'm prepared to provide.
I also could have made the playfield graphic 16 bytes high, or 32, or 64, by changing only my data and the AND line. AND can serve as a modulus for any power of two (2^n) up to 128, by ANDing a byte with that number minus one ( (2^n)-1 ). 8 bytes * every 4 scanlines == 32, which is a power of two, which is why this works. Try commenting out the AND line and see how the program interprets it. Remember that PlayfieldY goes up to 255.
But you won't need to worry about that if you're drawing a stationary playfield where the graphics data is so large, it doesn't need to repeat. In that case, you don't need the AND line and you don't need to make sure your graphics are 2^n bytes tall. Comment out the AND, SEC and SBC lines, and add a third LSR to the block of two. It indexes a bit too far at the top of the screen, which explains the garbage. You can fix that problem either by adding more data to the end of each array, or by decreasing the resolution by adding a fourth or fifth LSR.
And who's to say you'll need all three playfield registers? Perhaps you have a rather narrow playfield, or one that's always clear in the middle. Either choice will save you five cycles per scanline.
As you can see, it can be trimmed down quite a bit, and I still have a lot of cycles left over. The maximum, if you recall, is 73 if you plan to use STA WSYNC, and I pity the fool who doesn't.
ScanLoop ; ================================== SCANNING LOOP
; Result of the following math is:
; X = ( (Y-PlayfieldY) /4 ) mod 7
TYA
SEC
SBC PlayfieldY
LSR ;Divide by 4
LSR
AND #7 ;modulo 8
TAX
LDA PFData0,X ;Load ahead of time.
; WSYNC is placed BEFORE all of this action takes place.
STA WSYNC
STA PF0 ;[0] +3 = *3* < 23
LDA PFLColor,X ;[3] +4
;In a real game, I wouldn't be this redundant.
STA COLUP0 ;[7] +3 = *10* < 23
STA COLUPF ;[10]+3 = *13* < 23
LDA PFData1,X ;[13]+4
STA PF1 ;[17]+3 = *20* < 29
LDA PFRColor,X ;[20]+4
STA COLUP1 ;[24]+3 = *27* < 49
LDA PFData2,X ;[27]+4
STA PF2 ;[31]+3 = *34* < 40
DEY
BNE ScanLoop
Prevent Bleeding
Clear all registers here to prevent any possible bleeding.
LDA #2
STA WSYNC ;Finish this scanline.
STA VBLANK ; Make TIA output invisible,
; Now we need to worry about it bleeding when we turn
; the TIA output back on.
; Y is still zero.
STY PF0
STY PF1
STY PF1
STY GRP0
STY GRP1
STY ENAM0
STY ENAM1
STY ENABL
RTS
Overscan Calculations
For the Overscan routine, one might take the time to process such things as collisions. I, however, would rather waste a bunch of scanlines, since I haven't drawn any players yet.
OverScan ;***************************** OVERSCAN CALCULATIONS
LDX #30
KillLines
STA WSYNC
DEX
BNE KillLines
RTS
GameInit
GameInit could conceivably be called when the Select key is pressed, or some other event.
GameInit
LDA #0
STA PlayfieldY
RTS
Graphics Data
Graphics are placed so that the extra cycle in the PFData, X indexes is NEVER taken, by making sure it never has to index across a page boundary. This way our cycle count holds true.
org $FF00 ; *********************** GRAPHICS DATA
PFData0 ;H 4 5 6 7
.byte $00,$f0,$00,$A0,$A0,$E0,$A0,$A0
PFData1 ;EL 7 6 5 4 3 2 1 0
.byte $00,$FF,$00,$77,$44,$64,$44,$74
PFData2 ;LO 0 1 2 3 4 5 6 7
.byte $00,$FF,$00,$EE,$A2,$A2,$A2,$E2
PFLColor ; Left side of screen
.byte $00,$FF,$00,$22,$26,$2A,$2C,$2E
PFRColor ; Right side of screen
.byte $00,$1F,$00,$6E,$6C,$6A,$66,$62
org $FFFC
.word Start
.word Start
Reversed Bit Order
This is the tricky part of drawing a playfield: actually drawing it. Well, the display routine and all that binary math was a bit tricky, too, but still, listen up.
Playfield data isn't stored the way most bitmaps are, even one-dimensional bitmaps. We will use the left side of the screen only, knowing that the right side is either repeated or reflected from it.
In PF0 and PF2, the most significant bit (bit 7) is on the RIGHT side. In PF1, the most significant bit is on the LEFT side. This means that relative to PF0 and PF2, PF1 has a reversed bit order. It's just really weird.
