This tutorial assumes that you already have bAtari Basic setup on your system, and that you are able to compile and run a program. If not, then you can find instructions for doing this at http://bataribasic.com.
The 2600 has been called one of the most difficult consoles to program. This is because of the simplicity of the hardware. Now one might think that simple hardware means simple programming, but the 2600 is almost too simple. The chips that draw the television screen only hold enough information to draw one line at a time. This means that the CPU must reload new information every time a line is different from the one before it. Many times, the information new information is loaded into the middle of a line for special effects. Not only that, but this must be done every time a screen is drawn, sixty times a second.
It is this almost constant handling of the hardware, which requires that instructions be timed to the microsecond, so that the CPU is synchronized to the electron beam in the television, that caused many to believe that a Basic Compiler for the 2600 was impossible.
What makes bAtari Basic possible is the kernel, a dedicated piece of machine language code, included in the compiled program, that runs once every sixtieth of a second, and draws the screen based on parameters set by the Basic code. The compiled Basic code, on the other hand, is executed during the time that a picture is not being drawn on the television.
bAtari Basic divides the screen into two sections: the playfield and the score.
|....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX....| <- Playfield
|.................999999.................| <- Score
The playfield is made up of 11 eight-pixel high lines, each of which is 32 pixels across, with a four pixel wide space on each side.
There are five objects which may be displayed in the playfield area: two players, two missiles, and a ball. These objects will be covered later.
Your First Program
Many programming tutorials begin with a Hello World program. This will no exception. Since the 2600 doesn't have a character display, we will need to draw the words hello world on the playfield.
In bAtari Basic, all lines other than labels and the "end" statement must begin with at least one space. Labels and "end", on the other hand, may not have any leading spaces. Because the forum likes to strip space, I will be using an underscore where this space should be. The leading underscores will need to be replaced with spaces before the program will compile.
The program will start with a comment, which identifies the program. Comments begin with the command "rem", which is short for remark.
rem Hello World
Next, the playfield is defined using the playfield command. The playfield consists of 12 lines, each composed of 32 pixels. Only the first 11 lines are displayed, the 12th is used for vertical scrolling. Within each line, a period reperesents a blank pixel, an X represents a filled pixel.
playfield: ................................ ......X.X.XXX.X...X...XXX....... ......X.X.X...X...X...X.X....... ......XXX.XX..X...X...X.X....... ......X.X.X...X...X...X.X....... ......X.X.XXX.XXX.XXX.XXX....... ................................ .....X...X.XXX.XX..X...XX....... .....X...X.X.X.X.X.X...X.X...... .....X.X.X.X.X.XX..X...X.X...... .....XX.XX.XXX.X.X.XXX.XX....... end
When the program first starts, all variables and registers are set to 0, which happens to be the color black. This means that the background will be black. Unfortunately, the playfield will also be black, rendering it invisible. So, the color is set to white, by setting the appropriate TIA register with the desired color value.
COLUPF = 14Finally, we must tell the kernel to draw the screen. This must be done over and over, 60 times a second, forever (actually until the 2600 is turned off). So we have a label, "mainloop", the "drawscreen" command, which activates the kernel, and a "goto" back to the label, which causes the program to repeat the drawscreen command.
mainloop drawscreen goto mainloop
Compile the program, then load the resulting .bin file in an emulator, and you will be greeted by the words "HELLO WORLD".
The Rest of the Screen
Now let's replace the playfield in the Hello World with the following, which one might expect to draw two horizontal lines, one at the top of the screen, and one at the bottom, stretching from the far left to the far right.
playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end
When you compile and run it, however, you will see blank areas on the right and left edges of the screen and another blank area at the bottom of the screen.
The bottom of the screen is taken up by the 6 digit score. It's invisible now because the scorecolor system variable defaults to 0, which is black. So, right below the COLUPF statement, add the line
scorecolor = 14
Compile and run the program, and you will see the score below th
In addition, the playfield is actually 48 pixels wide, not 32. But, for various technical reasons, only 32 pixels of each line can be stored in memory. You can still draw in those those four left over pixels, but there are some limitations.
- Both borders will contain the same pixel patterns: You define the right border and it will be mirrored (horizontally flipped) on the left border.
- The border can only be defined once, and will be repeated on every single line.
PF0 = %10000000
Compile and run and, wait a minute, the borders are still blank. Actually they weren't blank the first time draw screen was called, but that lasted only a sixtieth of a second. The kernel blanks the borders while drawing the score, so we need to reset it ever time we do a drawscreen. Move the above line to just below the mainloop label and compile and run again.
The 2600 has two player graphics, numbered 0 and 1. The graphics are 8 pixels wide and can be any height.
They can be positioned anywhere in the playfield area, including the borders.
The player graphics are defined using the statement player#:where # is either 0 or 1. This is followed by the player data, in reverse order, and finally and end statement.
As an example, we will use the venerable smiley face, which would look something like this.
The easiest way to enter the data is as binary numbers, with a 0 representing a blank pixel, and 1 representing a drawn pixel, as follows:
player0: %01111110 %10000001 %10011001 %10100101 %10000001 %10100101 %10000001 %01111110 endWe also need to position the player. This is done using the player#x and player#y system variables (where # is 0 or 1). The player#x variables control the horizontal position of the left-most pixel of the players, while the player#y variables control the vertical position of the bottom-most line of the players. The horizontal positions range from 1 (at the left edge of the screen) to 160 (at the right edge of the screen), and the vertical positions range from 1 (at the top of the screen) to 88 (at the bottom of the playfield).
To position player0 in the center of the screen, use the following lines.
player0x = 76 player0y = 40The last thing we need to do is set the color of the player, since, like all settings, it defaults to 0 (black). There is no system variable for the player color so the TIA register COLUP0 will need to be set. There is one catch to using the COLUP0 and COLUP1 registers, however. Because the score routine uses the both players, it will reset both colors every frame. Therefore, you must set the player colors before every drawscreen.
So, the final code we need to make this program work is
mainloop COLUP0 = 14 drawscreen goto mainloop
Compile and run the program, and a white smiley face should appear in the center of the playfield area.
Along with the two player graphics, there are two missile graphics, one for each player. Each missile is consists of one pixel, but may be of any height. Missile0 has the same color as player0, and missile1 has the same color as player0.
Each missile is controlled by three variables: missile#height, which sets the height of the missile, missile#x, which controls the horizontal position of the missile, and missile#y, which controls the vertical position of the bottom most line of the missile. The missile height value is 1 less than the actual height of the missile, in lines. The horizontal positions range from 2, at the very left of the screen to 161 at the very right of the screen. This means that for any given horizontal location, the missile#x value is one more than the player#x value. The vertical positions range from 1 to 89 and are half a line above the equivalent player vertical positions.
As an example, take the previous example program and add the following lines before the mainloop label:
missile0height = 0 missile0x = 75 missile0y = 40Compile and run, and a single pixel will appear to left of the smiley face.
Player and Missile Options
The appearance of the Players and Missiles may be changed using the NUSIZ0, NUSIZ1, REFP0, and REFP1 registers. TIA registers. NUSIZ0 affects Player 1 and Missile 0, while NUSIZ1 affects Player 1 and Missile 1. Otherwise the two registers are identical.
As noted previously, the screen is 160 clocks (or pixels) wide. Each pixel of the playfield is four clocks wide, while each missile and player pixel is one clock wide.
Each NUSIZ register is divided into two nybbles (groups of 4 bits). The high nybble (bits 4-7) control the width of the missile, while the low nybble (bits 0-3) control the player. The easiest way to write to the NUSIZ register is to use hexadecimal, since each hex digit refers to a nybble. Thus, in the number $12, the high nybble contains 1, while the low nybble contains 2.
Valid values for the high nybble (first hex digit) are:
- 0 Missile is 1 clock wide (default)
2 Missile is 2 clocks wide
3 Missile is 4 clocks wide
4 Missile is 8 clocks wide
Valid values for the low nybble are:
- 0 Player pixels are 1 clock wide (default)
1 Player and Missile are drawn twice with 16 clocks apart
2 Player and Missile are drawn twice with 32 clocks apart
3 Player and Missile are drawn three times 16 clocks apart
4 Player and Missile are drawn twice with 64 clocks apart
5 Player pixels are 2 clocks wide
6 Player and Missile are drawn three times, 32 clocks apart
7 Player pixels are 4 clocks wide
The distances above are from leftmost pixel to leftmost pixel, so there will be that number minus eight clocks in between each player.
The REFP0 registers are used to reflect (horizontally flip) the players. Normally the players are displayed high bit to low bit. Setting bit 3 of this register (setting the value to causes the player to be displayed from low bit to high bit.
Since the players are used by the kernal to display the score, the NUSIZ and REFP registers (along with the
COLUP registers) are reset each time draswcreen is called. NUSIZ0, NUSIZ1, REFP0, and REFP1 are all set to 0, so if you are using the defaults you won't need to do anything. Otherwisem, the registers will need to be written to before each drawscreen.
Now to put this to use. Modifying our exisitng program, we will put player 0 at horizontal position 64.
player0x = 64 player0y = 40Then position the missiles 8 clocks to the right
missile0height = 1 missile0x = 73 missile0y = 40Finally, we will set Missile 0 to 8 clocks wide and Player and Missile 0 to be drawn three times, 16 clocks apart.
mainloop COLUP0 = 14 NUSIZ0 = $33 drawscreen goto mainloopCompile and run the program, and you will see three smiley faces with horizontal lines between them.
Next: Reading the Joystick
Edited by CurtisP, Mon Aug 10, 2009 3:55 PM.