Jump to content
IGNORED

Programming Tutorial


CurtisP

Recommended Posts

If someone could pin this, that would be great. I plan to add to this every few days. Comments are welcome.

 

Note

 

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.

 

Introduction

 

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.

 

The Kernel

 

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.

 

The Screen

 

bAtari Basic divides the screen into two sections: the playfield and the score.

 

 

+----------------------------------------+

|....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX....|

|....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX....|

|....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX....|

|....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX....|

|....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX....|

|....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX....| <- Playfield

|....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX....|

|....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX....|

|....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX....|

|....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX....|

|....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX....|

|.................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 = 14

Finally, 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.

To define the border, you set a TIA register with a binary value (of which only the first four bits will be used). Enter the following line, directly below the scorecolor 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.

 

Player Graphics

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.

.XXXXXX.

X......X

X.X..X.X

X......X

X.X..X.X

X..XX..X

X......X

.XXXXXX.

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
end

We 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 = 40

The 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.

 

Missile Graphics

 

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 = 40

Compile 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 8) 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 = 40

Then position the missiles 8 clocks to the right

  missile0height = 1
 missile0x = 73
 missile0y = 40

Finally, 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 mainloop

Compile and run the program, and you will see three smiley faces with horizontal lines between them.

 

Next: Reading the Joystick

Edited by CurtisP
  • Like 2
Link to comment
Share on other sites

Here is the Hello World program.

 

So how is the tutorial. Should I keep working on it?

Yes, every little bit helps. :) People will want to jump in and do a lot of fancy stuff right off the bat, so they might want you to go faster. But if you start small, and lay your foundation one block at a time, you'll have a more solid framework in which to keep adding as you go. The playfield is a good place to start. You'll want to show how to set the background and playfield colors, how to use playfield drawing commands, how to scroll the playfield, how to get multicolor playfields or backgrounds with the kernel options, how to get different playfield pixel sizes using the Superchip option, etc. You don't need to (and probably shouldn't) try to explain all of that at once-- just cover a little bit each time, and let it grow and develop.

 

You may even want to save some of the more advanced playfield stuff until later-- i.e., cover just the simplest basics of the playfield first, then the simplest basics of the other things (players, missiles, ball, audio), one by one. The you can go back through each topic again, but at a little more advanced level. And then you can go through them again, but at a still more advanced level. It will be like an upward spiral, going over each topic again and again, one after the other, but always building higher.

 

As you do this, not only will you help other people learn batari Basic, but you'll be learning more about it yourself. :) That's one of the rewarding things about helping others learn-- as you go about trying to answer their questions, you'll end up learning new things, too.

 

Michael

Link to comment
Share on other sites

Thanks Michael. I assume you'll keep an eye on it and point out any errors.

Well, one suggestion I have after reading your first installment is to put your snippets of sample code in code boxes. :) It helps preserve the leading spaces and general formatting, which in turn makes it easier to read, as well as easier to use copy-and-paste to copy your code samples into an editor and compile them. :)

 

Other than that, my main advice is to avoid the trap I always seem to fall into-- namely, making things longer and more complicated than they need to be, because that just makes it harder to get something finished. It's better to tackle things a little step at a time, so you can get it out there, get feedback, build on it, etc.

 

Michael

Link to comment
Share on other sites

Thanks for the tutorial, keep 'em coming!!!

 

Thanks to this, I made a nice display for my wife, with a color-rotated playfield that said her name (she's a sucker for that stuff :) ). I also added a few new effects tonight, pulled from other tutorials.

 

I'd never thought I'd do an Atari 2600 program. Always a dream of mine (sniff!)

 

-Don

Link to comment
Share on other sites

  • 2 weeks later...

I also think any tutorial anyone makes is appreciated. I don't mind you start slow as long as you keep working up to more and more. I would appreciated advanced tutorials in the future as well.

 

I think a good idea for us to get some more "attention" is to get with one of the retro gaming magazines and post code in there for a complete game ala like old Commodore 64 magazines used to do. Along with that give people locations and instructions on compiling it. People won't totally know what the game will be like until they type it in.

Link to comment
Share on other sites

I like that you've kept it all in the first post, and it's coming along nicely. Thanks for taking the time to do this! Maybe now we'll even see some teams forming. I for one don't really like to work alone.

 

Anyone who wants to learn bBASIC, but thinks they don't really have the time and/or patience will be surprised how fast and easy a tutorial like this makes the process.

Link to comment
Share on other sites

  • 2 weeks later...

Also note that Michael was working on a wiki and potentially could keep a copy of it there that everyone could edit. In a different thread we were talking with the AtariAge webmaster about having AtariAge host a wiki, but their concern is that they would want it to integrate with the existing forum, and unfortunately there are many mainstream wikis out there that can do it the way that they want it I think. So for now we have the forum and Michael's wiki.

Link to comment
Share on other sites

  • 1 month later...

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...