batari Basic Commands

Game Design Theory

Game Standards and Procedures

BASIC (Wikipedia)

The Basics: How Programming Works

Atari Basic - A Self-Teaching Guide

WHAT IS ATARI BASIC?

bB Programming Tutorial by CurtisP

Code Snippets & Samples for bB Beginners

Quotes from Famous Game Designers and Others

The Motivation and Creativity Page

Video Game Genres (Wikipedia)

Posting Tips for New bB Users

How to Attach Files and Images

Indent!

Indenting in batari Basic means putting at least one space at the beginning of a line that contains certain types of code. There is no need to indent blank lines. [Note from RT: I always indent with 3 spaces so it's easier to tell that it is indented.] All program statements, data, and sprite/playfield pixel data must be indented by at least one space. (Labels, line numbers, and end must not be indented.)

Example:

   if _Agenda = _Depopulation then goto __Georgia_Guidestones

   if _Cabal > 42 then _Cabal = 0

   player0:
   %00111100
   %01111110
   %11000011
   %10111101
   %11111111
   %11011011
   %01111110
   %00111100
end

__Georgia_Guidestones

See Labels and Line Numbers, asm, and Compiler Errors for more information.

You Don't Have to Use Line Numbers

Line numbers were mandatory when using old style BASIC languages, but batari Basic is more like later versions of BASIC, so line numbers are no longer necessary. You can use line numbers if you want, but remember to use them like labels instead of putting them at the beginning of every line of code.

See Labels and Line Numbers for more information.

Memory

The Atari 2600's microprocessor can only address 4K of ROM at a time, and the console only has 128 bytes of RAM. Of this RAM, 26 bytes are available for general use in your programs, as variables a-z. It may not sound like much, and it isn't, but many great games have been written despite these limitations.

Some ways to mitigateReduce, lessen, or decrease. the above limitations are to use bankswitching and/or Superchip RAM. Bankswitching allows programs up to 64K in size, and the Superchip gives us another 128 bytes of RAM. There are drawbacks to both, however. See Bankswitching and/or Superchip for more information.

Compilation Completed: ____ Bytes of ROM Space Left

Text from RevEng (adapted by Random Terrain)

Short story: Sometimes bB manages to stick your code into wasted space, and the reported number doesn't change.

Long story: There's graphics data that needs to be aligned on memory page boundaries, so sometimes bB will waste space by sticking empty ROM before the boundary, to ensure correct alignment.

If you're adding code prior to one of these, the code will take up that blank ROM space and not report any extra usage. But eventually you'll add enough code to push the graphics data past its required alignment and you'll lose a bunch of reported space at once.

[Moral of the story: If you want to compare little chunks of code to see which style uses more space, do it in a small test program so you can see the actual bytes that are being saved or wasted. You might want to try using the test code that RevEng posted at AtariAge. Below is a template version of it.]

Timing

Text by batari and updated by RevEng (adapted by Random Terrain)

Timing is crucial in batari Basic, in that you only have about 2 milliseconds between successive calls to drawsceen.

Trivia: There are 2380 cycles in 2 milliseconds.

(1190000 cycles/second * 0.002 seconds = 2380 cycles.)

Normally, bB code runs in overscan. This is the portion of the television screen, roughly 2 milliseconds long, after the visible screen but before the synchronization signals are sent to the television. After this is an area called vertical blank, where the picture is blanked for a couple of milliseconds before the display kernel renders the visible screen. As of March of 2016, the standard kernel has 2710 cycles available in overscan and 1675 cycles available in vblank, but those numbers may change if a new version of the kernel is released.

Although bB has a useful debug directive, there are 4 ways you can use Stella (the Atari 2600 emulator) to make sure your program isn't taking too long and has a steady scanline count:

Keeping Track of the Scanline Count with Stella

See drawscreen, vblank and debug for more information.

White Space

It is recommended that you include white space in your program. Blank lines can help to create a physical separation of some code, and some space between commands and tokens can help readability. Earlier versions of bB had trouble with white space, but this problem should be resolved now.

Some of us (myself included) do not leave much, if any, white space between commands, and bB can still parse most code correctly, regardless. For example, the statement:

  for l=1 to 10:t=t+4:next

is acceptable. Also, the following would be parsed the same way:

  for l = 1 to 10 : t = t + 4 : next
  for   l   =1   to 10:t=t  +4: next
  for l=1  to 10 : t= t+4 :next

The following would not:

  forl=1to10:t=t+4:next
  forl=1 to 10:t=t+4:next
  for l=1 to10 :t=t+4:next

In other words, any keywords or commands must be spaced properly or batari Basic will think they are variables and compilation will fail, but anything else is fair game. As long as there is a recognizable separator, such as +, -, =, :, *, /, &, &&, |, ||, ^ and possibly others, you can space however you want (or not at all).

Warning: Although batari said there are few limitation when it comes to white space, people have had various problems when they didn't have a space before and after each colon that is used to separate commands on a line.

Multiple Statements on One Line

Text added by Random Terrain

As it says here, multiple statements on one line are separated by a colon.

Below are a few examples:

   AUDV0 = 0 : AUDV1 = 0
   
   if temp5 > 128 then player1x = (rand&7) + 5 : goto __Skip_Enemy_Setup
   
   player0x = 77 : player0y = 53 : missile0x = 200 : missile0y = 220
   
   COLUPF = $FC : COLUBK = 0 : _Bit0_Reset_Restrainer{0} = 1
   
   pfscore2 = %11111111 : pfscorecolor = _C8 : ballheight = 3 : CTRLPF = $31

Warning: People have had various problems when they didn't have a space before and after each colon that is used to separate commands on a line, so you might want to put a space before and after each colon just to be safe.

Line Length and Other Limitations

Text from bogax and RevEng (adapted by Random Terrain)

It seems bB doesn't like lines over 190 characters. There seems to be a limit of around 45 labels on a single line when using on…goto or on…gosub, but you'll probably want to use fewer labels than that for the sake of readability using this tip for on…goto or this tip for on…gosub.

Testing shows that 46 parameters can be passed to a macro. That makes sense, as statements are limited to 50 strings, and the command, macroname, and newline chars use up 4 strings.

DOS Compatibility

Although batari Basic is a command-line program, you are expected to run it under Windows 95 or later because it requires a DPMI (DOS protected mode interface) and uses long filenames. If you wish to run under pure DOS, however, you can, but you will need to:

• obtain a DPMI program, such as cwsdpmi.exe, and run this before running batari Basic.
• rename all filenames to 8.3 format
• edit includes files to point to renamed files above
• use the command-line parameter -r to specify an alternate variable redefinition file that conforms to 8.3.

Comments (rem, semicolons, and C-style)

The rem statement is used for in-program comments. These comments are very helpful, not only to other programmers trying to make sense of your code, but to yourself if your memory is anything like mine. :)

Note that, unlike old interpreted BasicsRun line by line, directly from the source code without compiling first., you can use rem as much as you want and it will not affect the length or speed of your compiled program.

Example:

   rem  **************************************************************
   rem  *
   rem  *  Name: Space Nuggets
   rem  *  Version: 2016y_03m_21d_0225t
   rem  *
   rem  **************************************************************
   rem  *
   rem  *  Programmer: Scadoobie Floinkenburger
   rem  *  Language: batari Basic v1.0
   rem  *  System: Atari 2600 VCS
   rem  *
   rem  **************************************************************

Notice how each rem has at least one space after it. If you don't have at least one space between the rem and your comment, your program may not compile.

Semicolons and C-style multi-line comments are also supported.

Here are a few examples using semicolons:

   dim _Monkey_Brains = a ; Keeps track of brains eaten.

   a = 5 ; I Like Pizza

   ;***************************************************************
   ;
   ;  Name: Space Nuggets
   ;  Version: 2023y_01m_09d_1431t
   ;
   ;***************************************************************
   ;
   ;  Programmer: Scadoobie Floinkenburger
   ;  Language: batari Basic v1.7
   ;  System: Atari 2600 VCS
   ;
   ;***************************************************************

Semicolons can also be used with data and sdata. Remember, rem is not used. No colon, no rem, just put a semicolon and your comment.

Example:

   data _Music_Data
   5,7,18
   0,0,0
   9
   2,7,18 ; Mango knee bone butter
   0,0,0
   3
   7,6,12 ; Elusive fractal salve
   0,0,0
   9
   2,6,12
   0,0,0
   3
   255 ; End of data
end

Here's an example using C-style comments:

   /* comment #1 */


   /* comment #2
   */


   /*
   comment #3
   and some more of #3
   */

Note: There's a subtle difference between the two commenting styles. When you use ";" and "/* */" comments, the comments don't show up in the generated assembly code. When you use "rem" they do.

reboot [do not use this if you use rand]

This command will warm bootRestart a computer under software control. your game, but you should probably never use it. Everything is cleared by reboot, similar to turning the Atari 2600 off and back on again, so do not use it if you need to store things such as the highest level reached, high score, current game selections and so on.

Example:

  if switchreset then reboot

It seems that reboot can also mess up random numbers, so you might want to have a Start/Restart section that you can jump to that clears and sets up variables, sprite positions, colors, and so on. Below is an example inspired by RevEng that will clear all normal variables:

   ;***************************************************************
   ;
   ;  Clears all normal variables.
   ;
   for temp5 = 0 to 25 : a[temp5] = 0 : next

This seems to be faster than the example above:

   ;***************************************************************
   ;
   ;  Clears all normal variables (faster way).
   ;
   a = 0 : b = 0 : c = 0 : d = 0 : e = 0 : f = 0 : g = 0 : h = 0 : i = 0
   j = 0 : k = 0 : l = 0 : m = 0 : n = 0 : o = 0 : p = 0 : q = 0 : r = 0
   s = 0 : t = 0 : u = 0 : v = 0 : w = 0 : x = 0 : y = 0 : z = 0

And iesposta pointed out that using assembly language is even faster:

   ;***************************************************************
   ;
   ;  Clears all normal variables (fastest way using asm).
   ;
   asm
   LDA #0
   STA a
   STA b
   STA c
   STA d
   STA e
   STA f
   STA g
   STA h
   STA i
   STA j
   STA k
   STA l
   STA m
   STA n
   STA o
   STA p
   STA q
   STA r
   STA s
   STA t
   STA u
   STA v
   STA w
   STA x
   STA y
   STA z
end

If you are using Superchip RAM, you can use the example below to clear normal variables and the old playfield variables:

   ;***************************************************************
   ;
   ;  Clears all normal variables and old playfield variables.
   ;
   for temp5 = 0 to 25 : a[temp5] = 0 : next

   for temp5 = 0 to 47 : var0[temp5] = 0 : next

This seems to be faster than the Superchip example above:

   ;***************************************************************
   ;
   ;  Clears all normal variables and old playfield variables
   ;  (faster way).
   ;
   a = 0 : b = 0 : c = 0 : d = 0 : e = 0 : f = 0 : g = 0 : h = 0 : i = 0
   j = 0 : k = 0 : l = 0 : m = 0 : n = 0 : o = 0 : p = 0 : q = 0 : r = 0
   s = 0 : t = 0 : u = 0 : v = 0 : w = 0 : x = 0 : y = 0 : z = 0

   var0 = 0 : var1 = 0 : var2 = 0 : var3 = 0 : var4 = 0 : var5 = 0
   var6 = 0 : var7 = 0 : var8 = 0 : var9 = 0 : var10 = 0 : var11 = 0
   var12 = 0 : var13 = 0 : var14 = 0 : var15 = 0 : var16 = 0 : var17 = 0
   var18 = 0 : var19 = 0 : var20 = 0 : var21 = 0 : var22 = 0 : var23 = 0
   var24 = 0 : var25 = 0 : var26 = 0 : var27 = 0 : var28 = 0 : var29 = 0
   var30 = 0 : var31 = 0 : var32 = 0 : var33 = 0 : var34 = 0 : var35 = 0
   var36 = 0 : var37 = 0 : var38 = 0 : var39 = 0 : var40 = 0 : var41 = 0
   var42 = 0 : var43 = 0 : var44 = 0 :  var45 = 0 : var46 = 0 : var47 = 0

And iesposta pointed out that using asm is even faster than the Superchip example above:

   ;***************************************************************
   ;
   ;  Clears all normal variables and old playfield variables
   ;  (fastest way using asm).
   ;
   asm
   LDA #0
   STA a
   STA b
   STA c
   STA d
   STA e
   STA f
   STA g
   STA h
   STA i
   STA j
   STA k
   STA l
   STA m
   STA n
   STA o
   STA p
   STA q
   STA r
   STA s
   STA t
   STA u
   STA v
   STA w
   STA x
   STA y
   STA z
   STA var0
   STA var1
   STA var2
   STA var3
   STA var4
   STA var5
   STA var6
   STA var7
   STA var8
   STA var9
   STA var10
   STA var11
   STA var12
   STA var13
   STA var14
   STA var15
   STA var16
   STA var17
   STA var18
   STA var19
   STA var20
   STA var21
   STA var22
   STA var23
   STA var24
   STA var25
   STA var26
   STA var27
   STA var28
   STA var29
   STA var30
   STA var31
   STA var32
   STA var33
   STA var34
   STA var35
   STA var36
   STA var37
   STA var38
   STA var39
   STA var40
   STA var41
   STA var42
   STA var43
   STA var44
   STA var45
   STA var46
   STA var47
end

Here is the faster way to clear DPC+ variables:

   ;***************************************************************
   ;
   ;  Clears all normal variables and the extra 9 (fastest way).
   ;
   a = 0 : b = 0 : c = 0 : d = 0 : e = 0 : f = 0 : g = 0 : h = 0 : i = 0
   j = 0 : k = 0 : l = 0 : m = 0 : n = 0 : o = 0 : p = 0 : q = 0 : r = 0
   s = 0 : t = 0 : u = 0 : v = 0 : w = 0 : x = 0 : y = 0 : z = 0
   var0 = 0 : var1 = 0 : var2 = 0 : var3 = 0 : var4 = 0
   var5 = 0 : var6 = 0 : var7 = 0 : var8 = 0

And iesposta pointed out that using asm is even faster than the DPC+ example above:

   ;***************************************************************
   ;
   ;  Clears all normal variables and the extra 9
   ;  (fastest way using asm).
   ;
   asm
   LDA #0
   STA a
   STA b
   STA c
   STA d
   STA e
   STA f
   STA g
   STA h
   STA i
   STA j
   STA k
   STA l
   STA m
   STA n
   STA o
   STA p
   STA q
   STA r
   STA s
   STA t
   STA u
   STA v
   STA w
   STA x
   STA y
   STA z
   STA var0
   STA var1
   STA var2
   STA var3
   STA var4
   STA var5
   STA var6
   STA var7
   STA var8
end

If you're doing your best to make a professional-looking game that remembers the high score and other things from one game to the next, you'll want to use a modified version of the examples above so your important variables won't be cleared. You can safely use one of the examples above outside of your game, near the beginning of your code, after your dims and defs and so on, but before the Start/Restart section to make sure all of your variables have been cleared when the game first starts.

See switchreset for more information.

Warning: It seems that reboot causes random numbers to be not so random anymore, so if randomness is important to you, do not use reboot.

end

This is a unique command, as it is never indented. It is used to tell the compiler that you are finished with your data entry, graphics definition or inline assembly. That is, the data, sdata and asm commands, and any data-related command normally ending with a colon (such as playfield:, player0:, lives:, and others).

Examples:

   playfield:
   X.X...X..XX..X.XX.X....XX..X.X..
   X.X....XX..X.X..X.X...X..XX..X.X
end



   player0:
   %00100010
   %01110111
   %01111111
end



   data _My_Data
   200, 43, 33, 93, 255, 54, 22
end



   asm
minikernel
   sta WSYNC
   lda _SC_Back
   sta COLUBK
   rts
end

Warning: Some new users of batari Basic want to put random ends everywhere for some strange reason. Some new bB users will put end before every return when there is no data that goes with it. You'll get errors if you randomly sprinkle your programs with the end command, so please use it the way it's supposed to be used.

Variable Testing

If you'd like to know the value of a variable or coordinates of a sprite/missile/ball when testing your game, you can use the score to display it. The following is an adapted example by bogax that will display two values using the score:

   ;***************************************************************
   ;
   ;  Variable aliases go here (DIMs).
   ;
   ;```````````````````````````````````````````````````````````````
   ;  Converts 6 digit score to 3 sets of two digits.
   ;
   ;  The 100 thousands and 10 thousands digits are held by _sc1.
   ;  The thousands and hundreds digits are held by _sc2.
   ;  The tens and ones digits are held by _sc3.
   ;
   dim _sc1 = score
   dim _sc2 = score+1
   dim _sc3 = score+2



__Main_Loop



   ;,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
   ;```````````````````````````````````````````````````````````````
   ;
   ;  Your code to test goes here.
   ;
   ;,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
   ;```````````````````````````````````````````````````````````````



   ;***************************************************************
   ;
   ;  Sets color of the score.
   ;
   scorecolor = $9C



   ;***************************************************************
   ;
   ;  Puts temp4 in the three score digits on the left side.
   ;
   ;```````````````````````````````````````````````````````````````
   ;  Replace "player0x" with whatever you need to check.
   ;
   temp4 = player0x

   _sc1 = 0 : _sc2 = _sc2 & 15
   if temp4 >= 100 then _sc1 = _sc1 + 16 : temp4 = temp4 - 100
   if temp4 >= 100 then _sc1 = _sc1 + 16 : temp4 = temp4 - 100
   if temp4 >= 50 then _sc1 = _sc1 + 5 : temp4 = temp4 - 50
   if temp4 >= 30 then _sc1 = _sc1 + 3 : temp4 = temp4 - 30
   if temp4 >= 20 then _sc1 = _sc1 + 2 : temp4 = temp4 - 20
   if temp4 >= 10 then _sc1 = _sc1 + 1 : temp4 = temp4 - 10
   _sc2 = (temp4 * 4 * 4) | _sc2



   ;***************************************************************
   ;
   ;  Puts temp4 in the three score digits on the right side.
   ;
   ;```````````````````````````````````````````````````````````````
   ;  Replace "player0y" with whatever you need to check.
   ;
   temp4 = player0y

   _sc2 = _sc2 & 240 : _sc3 = 0
   if temp4 >= 100 then _sc2 = _sc2 + 1 : temp4 = temp4 - 100
   if temp4 >= 100 then _sc2 = _sc2 + 1 : temp4 = temp4 - 100
   if temp4 >= 50 then _sc3 = _sc3 + 80 : temp4 = temp4 - 50
   if temp4 >= 30 then _sc3 = _sc3 + 48 : temp4 = temp4 - 30
   if temp4 >= 20 then _sc3 = _sc3 + 32 : temp4 = temp4 - 20
   if temp4 >= 10 then _sc3 = _sc3 + 16 : temp4 = temp4 - 10
   _sc3 = _sc3 | temp4



   ;***************************************************************
   ;
   ;  Displays the screen.
   ;
   drawscreen



   goto __Main_Loop

Below is an example program that uses the code above to display object coordinates using the score.

let (optional)

The let statement is optional, and is used for variable assignment. It was left in because an early unreleased version of batari Basic required it. If you wish to use it, it will not affect program length—it will simply be ignored by the compiler.

Example:

   let x = x + 1

const

If you haven't used constants before, see Glossary: Constants, Variables, and Values before you dive in.

A constant is a special type of variable that cannot be changed while a program is running. To declare a constant in batari Basic, use the const command. const declares a constant value for use within a program. This improves readability in a program in the case where a value is used several times but will not change, or you want to try different values in a program but don't want to change your code in several places first.

For example, you might have the following near the beginning of your program:

   const _c_MyConst = 200
   const _c_Monster_Height = $12

After that, any time _c_MyConst or _c_Monster_Height is used, the compiler will substitute 200 or $12 respectively. [Note from Random Terrain: I add a little c to let me know that it's a constant and not a normal variable.]

See NTSC Color Constants and Instant PAL-60 Conversion if you want an easy way to make NTSC and PAL-60 versions of the same game.

Older versions of batari Basic had a limit of 50 constants, but that limit was later increased to 500.

See Glossary: Constants, Variables, and Values for more information.

dim

If you haven't used dim before, see What is an alias? before you dive in.

The dim statement is used to create more descriptive names for variables, or to create a fixed-point type and assign it to some of these variables.

   dim _Monster_xpos = a
   dim _Monster_ypos = b
   dim _Corbomite_Maneuver_Data = c
   dim _Tranya_Supply = d
   dim _Space_Dentist = e
   dim _Flying_Pickle = f

def  (by SeaGtGruff)

The def statement is similar to the dim statement, but it lets you define an entire string and assign it to a logical name. So if you use def to assign 'a{0}' to 'MyVar,' then everywhere batari Basic sees 'MyVar' in your program, it will replace it with 'a{0}.'

You may already know that dim won't let you assign a specific alias that only works for a certain bit, but the good news is that def will. Of course, the other restrictions and rules still apply, so you have to check it with 'if MyVar then,' or 'if !MyVar then,' instead of using 'if MyVar=0 then,' or 'if MyVar=1 then.'

The def statement also works with math, such as 'def MyVar=a + b - c.' Everywhere batari Basic sees 'MyVar,' it will replace it with 'a + b - c.' But def shouldn't be confused with a function, because it's just doing a "search and replace" in the code, not calling a function. So def can help make your code more readable and concise, but it doesn't save any bytes or cycles.

Although def and dim are totally separate, you can use them in combination if you want:

   dim _Game_Flags = a

   def _Game_Level=_Game_Flags & $0F
   def _Show_Title=_Game_Flags{4}
   def _Game_in_Play=_Game_Flags{5}
   def _Game_Over=_Game_Flags{6}
   def _Show_Hi_Scores=_Game_Flags{7}

Gemintronic discovered that there is a limit of 50 defs (defines).

Note: For def to work properly, do not use a space before or after the equals sign. Strings used with def must be different from each other or you will get strange errors. For example, if you used _PullMyLeg, you couldn't use Pull or My or Leg as def strings. [Note from Random Terrain: I had all kinds of mysterious problems when using def. It may work correctly for you, but I stopped using it.]

Bit Operations

On modern systems, you may not think twice about using an entire variable for every on/off condition. For example, to determine whether a game is in progress or it is over, often an entire variable is used even though its only value is 0 or 1.

Since the Atari 2600 only has 128 bytes of RAM, and batari Basic only has 26 bytes available for variables (depending on the kernel you are using), it is very likely that you will need to use individual bits for game state information. For example, a common use of a bit is to determine whether a game is over or still in progress.

The 8 bits of a byte are numbered 0 through 7, starting from right to left, with 0 being the least significant bit (LSB) or smallest.

For example, to access the LSB in a variable or register:

   a{0} = 1
   a{0} = 0
   if a{0} then gosub __Moose_Gizzard
   if !a{0} then goto __Game_Over

Notice that bit operations do not use an equal sign in if…then statements. And remember that curly brackets {} are used, not round brackets or parentheses (). Also remember that a variable cannot be used inside of the curly brackets. A number must be used (0 through 7) unless special code is used.

The example below shows how you can flip a bit:

   a{2} = !a{2}

The bit is toggled from 0 to 1 or 1 to 0. Below is another example that also shows alternative ways to do the same thing:

The XOR examples produce more compact assembly (thanks to RevEng).

   ;***************************************************************
   ;
   ;  Random number for a{0}.
   ;
   temp5 = (rand & %00000001)
   a = a ^ temp5

   ;***************************************************************
   ;
   ;  Random number for a{7}
   ;
   temp5 = (rand & %10000000)
   a = a ^ temp5

You may also assign one bit to another bit. For example:

   d{3} = r{4}
   f{5} = !f{5}

A Bit of a Reminder

Accessing the bits of a variable is almost like turning it into 8 separate variables. Instead of having only 26 variables, you potentially have 208. You just have to remember that these itty-bitty variables can only hold 0 or 1.

Remember that when you use the individual bits of a variable to do simple on/off jobs, you can no longer use the whole variable for other jobs. For example, if you use one of the bits of the variable a, you can't use something like a = 48 or a = a + 1 in your program somewhere else. If you do, the bit you are trying to use in the variable a will end up getting overwritten.

Using Aliases

You can use dim to create a normal descriptive variable name and access the individual bits later.

Example:

   dim _my_variable = a

   _my_variable{0} = 0
   _my_variable{1} = 0
   _my_variable{2} = 1
   _my_variable{3} = 0
   _my_variable{4} = 0
   _my_variable{5} = 0
   _my_variable{6} = 0
   _my_variable{7} = 0

   rem  *  That will set _my_variable to 4, or %00000100.

Here's the same example with a different alias for each bit:

   dim _Hero_Shot = a
   dim _Hero_Thrust = a
   dim _Hero_Crash = a
   dim _Hero_Shield = a
   dim _Enemy_Shot = a
   dim _Enemy_Thrust = a
   dim _Enemy_Crash = a
   dim _Enemy_Shield = a

   _Hero_Shot{0} = 0
   _Hero_Thrust{1} = 0
   _Hero_Crash{2} = 1
   _Hero_Shield{3} = 0
   _Enemy_Shot{4} = 0
   _Enemy_Thrust{5} = 0
   _Enemy_Crash{6} = 0
   _Enemy_Shield{7} = 0

   rem  *  That will set "a" or any alias for "a" to 4, or %00000100.

Here's the same example with the bit number added to each alias so it will be easier to remember and work with:

   dim _Bit0_Hero_Shot = a
   dim _Bit1_Hero_Thrust = a
   dim _Bit2_Hero_Crash = a
   dim _Bit3_Hero_Shield = a
   dim _Bit4_Enemy_Shot = a
   dim _Bit5_Enemy_Thrust = a
   dim _Bit6_Enemy_Crash = a
   dim _Bit7_Enemy_Shield = a

   _Bit0_Hero_Shot{0} = 0
   _Bit1_Hero_Thrust{1} = 0
   _Bit2_Hero_Crash{2} = 1
   _Bit3_Hero_Shield{3} = 0
   _Bit4_Enemy_Shot{4} = 0
   _Bit5_Enemy_Thrust{5} = 0
   _Bit6_Enemy_Crash{6} = 0
   _Bit7_Enemy_Shield{7} = 0

   rem  *  That will set "a" or any alias for "a" to 4, or %00000100.

If you use dim to create descriptive variable names, don't try to 'dim' single bits as shown in the bad examples below.

Bad examples:

   dim _my_variable = a{1}
   dim _my_variable{1} = a
   dim _my_variable{1} = a{1}

Instead, use the example showing the bit number added to each alias, or you can attempt to use def.

Example:

   def _Hero_Shot=a{0}
   def _Hero_Thrust=a{1}
   def _Hero_Crash=a{2}
   def _Hero_Shield=a{3}
   def _Enemy_Shot=a{4}
   def _Enemy_Thrust=a{5}
   def _Enemy_Crash=a{6}
   def _Enemy_Shield=a{7}

   _Hero_Shot = 0
   _Hero_Thrust = 0
   _Hero_Crash = 1
   _Hero_Shield = 0
   _Enemy_Shot = 0
   _Enemy_Thrust = 0
   _Enemy_Crash = 0
   _Enemy_Shield = 0

   rem  *  That will set a or any alias for a to 4, or %00000100.

See def for more information. [Note from Random Terrain: I had all kinds of mysterious problems when using def. It may work correctly for you, but I stopped using it.]

   if a{0} then if !a{5} then goto __Pause_Game

   if !a{0} then if a{5} then goto __Pause_Game

   temp5 = (_PEEK_Game_Level) + 1
   _POKE_Game_Level temp5

   a = a & $0F
   a = b ^ %00110000
   a = a | 1

Fixed Point Variables

Fixed point variables can be assigned to fractional values, similar to floating point variables in other languages. bB provides two fixed point types:

• a two-byte variable, with one byte as the integersNumbers without a decimal (positive, negative or zero). Whole numbers. portion and one as the fractional portion. This is referred to as an 8.8 type. These can range from 0 to 255, with a fractional portion that is accurate to within 1/256 or 0.00390625. This type can also be considered as signed in the same way an integer variable is.
• a one-byte variable, with four bits as the integer and four bits as the fraction. This is referred to as a 4.4 type. This type ranges from -8 to 7.9375, and is accurate to within 1/16 or 0.0625. In other words, this type is always signed.

To declare these special types, you must use the dim statement. To declare an 8.8 type, you must specify the integer and fractional portion by the following:

   dim _My_Var = a.b
   dim _Monster_x = d.r

The first will use the variable a as the integer and b as the fraction, the second will use d as the integer and r as the fraction. Then any time you use _My_Var or _Monster_x in a variable assignment, the compiler will know to use the 8.8 fixed point type.

To declare a 4.4 type, you use a similar syntax as the above, but you use the same variable name for the integer and fraction:

   dim _xvelocity = c.c
   dim _yvelocity = d.d

After this dim, using _xvelocity will tell the compiler to use the 4.4 type.

You may use some fixed-point operations without any changes to your program, but some will require you to include the fixed point module. If you need to include the fixed point module, place this somewhere near the beginning of your program:

   include fixed_point_math.asm

Alternatively, you may modify the includes file to include it automatically. See include or includes file for more information.

In a 2600 game, the 8.8 types are particularly useful for specifying coordinates. The 4.4 types are useful for specifying velocity without using the extra bytes needed in 8.8 types.

This subpixel movement, or movement of a non-integer number of pixels for each frame, allows more flexibility in gameplay mechanics than ordinary integer variables provide, or at least it simplifies the calculations that would otherwise be required using only integers. Here's an example using player0 and player1:

   dim _P0_L_R = player0x.a
   dim _P0_U_D = player0y.b

   dim _P1_L_R = player1x.c
   dim _P1_U_D = player1y.d

And here are a few examples of how you could move player0 to the left:

   _P0_L_R = _P0_L_R - 0.85

   _P0_L_R = _P0_L_R - 2.0

   _P0_L_R = _P0_L_R - 1.052

The 8.8 type can be used interchangeably anywhere an integer would normally be used. If this is done, for example by assigning an 8.8 to player0x, the fractional portion of the number will be ignored, just like the int() function in other BASIC dialects. The 4.4 types, however, cannot be used anywhere—they can only be added, subtracted or assigned to/from themselves, integers or 8.8 types. Well, that's not totally true. If you use a 4.4 type in some way other than an assignment, addition or subtraction, its value will be multiplied by 16.

Also, note that fixed point types are subject to the same limitations in if…then statements. Although you may compare two 4.4 types in an if…then, if you compare a 4.4 with a number or another type, the 4.4 will be multiplied by 16. If you use an 8.8 type in an if…then, the fractional portion will be ignored.

If you want to use just the fractional portion in an if…then, this can be done by accessing the variable assigned to the fraction. . . In the first example above, this would be b or r. Note that if you access b or r directly, the fractional portion will be multiplied by 256.

Multiplication and division of fixed point types is subject to the same limitations above.

Some valid operations using fixed point types, that is, ones that are not subject to limitations are listed below. This is not a complete list. Those denoted with a (*) require that the fixed_point_math.asm module is included, those without a (*) do not.

Note: assume that my44 is a 4.4 type, myint is an integer, and my88 is an 8.8:

   my88 = 12.662
   my44 = 4.67
   my88 = -12.662
   my44 = -4.67
   my88 = myint
   my44 = myint
   myint = my44
   myint = my88
   my88 = my44 (*)
   my44 = my88 (*)
   my88 = my88+1.45
   my44 = my44+2.55
   my88 = my88-1.45 
   my44 = my44-2.55
   my88 = my44+6.45 (*)
   my44 = my88+3.45 (*)
   my88 = my44-6.45 (*)
   my44 = my88-3.45 (*)
   my88 = my88+my88
   my44 = my44+my44
   my88 = my88-my88
   my44 = my44-my44
   my88 = my44+my88 (*)
   my44 = my88+my44 (*)
   my88 = my44-my88 (*)
   my44 = my88-my44 (*)

In other words, if you mix 4.4 and 8.8 types in a statement, you need to include the fixed_point_math.asm module.

Ephemeral Variables and Registers (short-lived)

By ephemeralLasting for only a short time., we mean variables or TIA registersTelevision Interface Adaptor Registers
Locations that hold temporary data similar to variables. that are routinely obliteratedDestroyed, erased. through normal functioning of bB. Note that this section is not yet complete.

The temporary variables, temp1-temp6, are always obliterated by the kernel. Also, some bB internal functions use them, such as those for playfield plotting or scrolling. User functions also pass values by way of these variables. Other than that, the temp variables are safe to use for all of your intermediate calculations.

Some early versions of bB obliterated certain system variables such as the x and y positions of sprites. Although this is no longer true, this old requirement seems to have rubbed off on newer games, and in turn, programmers are wasting valuable variables to mirror system variables.

Again, all player, missile and ball x, y and height variables will keep their values unless changed by the programmer.

In addition, the standard kernel will maintain sprite definitions and so these can be placed outside of the game loop. The multisprite kernel, however, will not maintain definitions for player 0, so this needs to be defined within the game loop.

TIA registers may be ephemeral, in that the TIA is constantly updated throughout the visible screen so you need to stay on top of most of them. But some TIA registers are persistent, meaning that you can set them once and they will remain in effect throughout your game. Some are obliterated every frame and therefore must be set before each drawscreen. Knowing which are safe to set and once or which need to be redefined every frame will help you write more efficient programs.

The following are persistent:

AUDV0
AUDV1
AUDC0
AUDC1
AUDF0
AUDF1
COLUBK (unless background kernel option set)
COLUPF (unless pfscorecolor variables used and/or pfcolors kernel option set)
CTRLPF

The following are obliterated, but values are predictable and don't necessarily need resetting. The TIA register and its value after a drawscreen are noted below:

Note that the multisprite kernel uses special variables for its virtual sprites 1-5 that resemble TIA regs, but are not TIA regs themselves (they point to 2600's RAM.) Therefore the values _COLUP1, COLUP2-COLUP5, _NUSIZ1, and NUSIZ2-NUSIZ5 are all persistent. Also note that bit 3 of _NUSIZ1 and NUSIZ2-NUSIZ5 contains the REFP value.

goto

The goto statement is used to jump to a line number or label anywhere in your program.

Examples:

   goto 100
   goto __My_Subroutine

In bankswitched games, if you are jumping to a routine in another bank, you must specify the bank.

Example:

   goto __Move_Monster bank2

[Note from Random Terrain: I put one underscore at the beginning of variable aliases and two underscores at the beginning of labels. Then I don't have to worry if I'm using a bB keyword by mistake and I'll never have to worry if my new variable alias has the same name as a label.]

on…goto

This works similar to a case statement in other languages. It is useful for replacing multiple if…then statements when conditions happen in an ordinalIn order. For example, first, second, third, and so on. fashion.

For example:

   on _Walk_Up goto __P0U0 __P0U1 __P0U2 __P0U3

is the same as:

   if _Walk_Up = 0 then goto __P0U0
   if _Walk_Up = 1 then goto __P0U1
   if _Walk_Up = 2 then goto __P0U2
   if _Walk_Up = 3 then goto __P0U3

The variable alias _Walk_Up used in the examples above can safely have a value from 0 to 3 and that value can be in any order. The value of _Walk_Up could be 3, then 0, then 1, then 0 again. The value doesn't have to be from 0 to 3 in order, but you'll probably end up increasing the value by 1 when using on…goto for displaying sprite animation frames.

You cannot use expressions in an on…goto statement.

For example:

   on _Walk_Up-8 goto __P0U0 __P0U1 __P0U2 __P0U3

would need to be replaced with something like this:

   _My_Temp = _Walk_Up - 8 : on _My_Temp goto __P0U0 __P0U1 __P0U2 __P0U3

[Note from Random Terrain: I put one underscore at the beginning of variable aliases and two underscores at the beginning of labels. Then I don't have to worry if I'm using a bB keyword by mistake and I'll never have to worry if my new variable alias has the same name as a label.]

Bankswitching Workaround

The on…goto statement can only jump within the current bank. If you are writing a bankswitched game and want to jump to labels in another bank using on…goto, the example below is one good way to do it.

Example:

   goto __Color_Fun bank2
   ...
   ...
   ...
   ...
   bank 2

__Color_Fun
   on _Walk_Up goto __Red __Green __Blue __Purple

Warning: There is no automatic checking to see if your variable's value coincides with a label in the list. In the above example, there is no label in the list to jump to if _Walk_Up is equal to 4 or more, but the statement will try to find a label for it anyway, which almost always means that your program will crash. You can check your variable before the on…goto to prevent this.

Example:

   if _Walk_Up < 4 then on _Walk_Up goto __P0U0 __P0U1 __P0U2 __P0U3

Too Many Labels

There seems to be a limit of around 45 labels on a single line when using on…goto. If you have too many jumps to put comfortably in a single on…goto statement, you can break it up into multiple on…goto statements. Example:

   if _Walk_Up < 4 then on _Walk_Up goto __P0U0 __P0U1 __P0U2 __P0U3
   _My_Temp = _Walk_Up - 4
   if _My_Temp < 4 then on _My_Temp goto __P0U4 __P0U5 __P0U6 __P0U7
   _My_Temp = _Walk_Up - 8
   if _My_Temp < 4 then on _My_Temp goto __P0U8 __P0U9 __P0U10 __P0U11

gosub

The gosub statement is often used for a subroutine that is called by multiple locations throughout your program.

Examples:

   gosub 100
   gosub __My_Subroutine
   if x > 10 then gosub __Sink_Ship

To return control back to the main program, issue a return in your subroutine. Example:

__My_Subroutine
   a = a - 1
   x = x + 10
   return

[Note from Random Terrain: I put one underscore at the beginning of variable aliases and two underscores at the beginning of labels. Then I don't have to worry if I'm using a bB keyword by mistake and I'll never have to worry if my new variable alias has the same name as a label.]

Note that each gosub will use two bytes of stack space, which will be recovered after a return. Only 6 bytes of stack space are reserved for this, so do not use too many nested subroutines, especially since this may be changed in later versions. Using too many nested subroutines will overwrite variables and strange hair-pulling problems will pop up, so try to avoid nested subroutines.

In bankswitched games, if you are jumping to a subroutine in another bank, you must specify the bank.

Example:

   gosub __Move_Monster bank2

If you're going to use gosub with bankswitched games, be sure to see the section about return thisbank and return otherbank.

See Glossary: Subroutines for more information.

on…gosub

This works very much like on…goto, and has similar restrictions, but control returns back to the statement following the on…gosub list when a return is encountered.

For example:

   on _Walk_Up gosub __P0U0 __P0U1 __P0U2 __P0U3
   drawscreen

The above example will return control to the drawscreen statement following the on…gosub list when a return is encountered.

You cannot use expressions in an on…gosub statement.

For example:

   on _Walk_Up-8 gosub __P0U0 __P0U1 __P0U2 __P0U3

would need to be replaced with something like this:

   _My_Temp = _Walk_Up - 8 : on _My_Temp gosub __P0U0 __P0U1 __P0U2 __P0U3

[Note from Random Terrain: I put one underscore at the beginning of variable aliases and two underscores at the beginning of labels. Then I don't have to worry if I'm using a bB keyword by mistake and I'll never have to worry if my new variable alias has the same name as a label.]

Bankswitching Workaround

The on…gosub statement can only jump within the current bank. If you are writing a bankswitched game and want to jump to labels in another bank using on…gosub, the example below is one good way to do it.

Example:

   goto __Color_Fun bank2
   ...
   ...
   ...
   ...
   bank 2

__Color_Fun
   on _Walk_Up gosub __Red __Green __Blue __Purple

Warning: There is no automatic checking to see if your variable's value coincides with a label in the list. In the above example, there is no label in the list to jump to if _Walk_Up is equal to 4 or more, but the statement will try to find a label for it anyway, which almost always means that your program will crash. You can check your variable before the on…gosub to prevent this.

Example:

   if _Walk_Up < 4 then on _Walk_Up gosub __P0U0 __P0U1 __P0U2 __P0U3

Too Many Labels

There seems to be a limit of around 45 labels on a single line when using on…gosub. If you have too many jumps to put comfortably in a single on…gosub statement, you can break it up into multiple on…gosub statements. Example:

   if _Walk_Up < 4 then on _Walk_Up gosub __P0U0 __P0U1 __P0U2 __P0U3
   _My_Temp = _Walk_Up - 4
   if _My_Temp < 4 then on _My_Temp gosub __P0U4 __P0U5 __P0U6 __P0U7
   _My_Temp = _Walk_Up - 8
   if y < 4 then on _My_Temp gosub __P0U8 __P0U9 __P0U10 __P0U11

if…then

Perhaps the most important statement is the if…then statement (also called the if-then statement). These can divert the flow of your program based on a condition.

The basic syntax is:

if condition then action

action can be a statement, label or line number if you prefer. If the condition is true, then the statement will be executed. Specifying a line number or label will jump there if the condition is true. Put into numerical terms, the result of any comparison that equals a zero is false, with all other numbers being true.

Note that in specific cases, assembly of if…then statements with a line number or label as the target will fail. If this happens, the assembler will report a "branch out of range." One way to fix this is to change the offending if…then statement to if…then goto, or you can let the compiler fix the problem for you by turning on smart branching.

To do this, use the following:

   set smartbranching on

Place it near the beginning of your program. Be aware that turning on smartbranching will slightly obfuscateConfuse, darken, make unclear. the generated assembly file, so do not use it if you plan to examine the assembly later to see how it works. Smartbranching will not slow down your program, so you don't have to be afraid to use it. See smartbranching for more information.

There are three types of if…then statements.

#1 Simple True/False Evaluation

The first type is a simple check where the condition is a single statement.

The following example diverts program flow to the label __Fried_Fish if a is anything except zero:

   if a then goto __Fried_Fish

This type of if…then statement is more often used for checking the state of various read registers. For example, the joysticks, console switches, single bits and hardware collisions are all checked this way.

Example:

   if joy0up then x = x + 1

That will add 1 to x if the left joystick is pushed up.

   if switchreset then goto __Mucus_Membrane

Jumps to __Mucus_Membrane if the reset switch on the console is set.

   if collision(player1,playfield) then t = 1

Sets t to 1 if player1 collides with the playfield.

   if !a{3} then a{4} = 1

Sets bit 4 of a if bit 3 of a is zero. See Bit Operations for more information about using single bits.

#2 Simple Comparison

A second type of statement includes a simple comparison. Valid comparisons are = , < , >, <=, >=, and <>.

Examples:

   if a < 2 then goto __Doggy_Dip
   if f = g then f = f + 1
   if r <> e then r = e

Note: Assembly Language programmers might want to know that batari Basic always uses one comparison and one branch no matter if you use <, <=, >, or >=, so there are no size/speed optimizations to be had by choosing one over the other. (Adapted from a post by GroovyBee.)

#3 Compound Statement

The third type of if…then is a complex or compound statement, that is, one containing a boolean AND (&&) operator or a boolean OR (||) operator. You are allowed only one OR (||) for each if…then statement. You can use more than one AND (&&) in a line, but you cannot mix AND (&&) and OR (||).

For example:

   if x < 10 && x > 2 then b = b - 1
   if !joy0up && _Game_Over = 0 then goto __Pig_Knuckle
   if x = 5 || x = 6 then x = x - 4

Warning: Using multiple if…thens in a single line might not work correctly if you are using boolean operators.

Relief for ENDIF Addicts

For those who are accustomed to using endif in other programming languages, you don't have to resort to using subroutines to deal with many lines of code. All you have to do is reverse the condition and add a label.

So instead of endif, which you cannot use in batari Basic:

   if x = 4 then

   x = t - 2 : _mosterheight = (_monsterheight&7) + 1

   pfhline 3 4 x off : a = (rand&127) + 16 : r{0} = 1

endif

or gosub:

   if x = 4 then gosub __Monster_Kill

   . . .

   . . .

   . . .

__Monster_Kill

   x = t - 2 : _mosterheight = (_monsterheight&7) + 1

   pfhline 3 4 x off : a = (rand&127) + 16 : r{0} = 1

   return

You'd use this instead:

   if x <> 4 then goto __Skip_Monster_Kill

   x = t - 2 : _mosterheight = (_monsterheight&7) + 1

   pfhline 3 4 x off : a = (rand&127) + 16 : r{0} = 1

__Skip_Monster_Kill

If you're using boolean operators, just invert each individual condition and change && to || or vice-versa. So this:

   if x = 4 && y = 2 then r = 4

becomes this:

   if x <> 4 || y <> 2 then goto __Skip_Ninja_Stab

   r = 4

__Skip_Ninja_Stab

And this:

   if r < 4 then e = e + 1

becomes this:

   if r >= 4 then goto __Skip_Fish_Jump

   e = e + 1

__Skip_Fish_Jump

   if a < 31 && a > 0 then goto __64_Tetrahedron

   if a = 2 || a = 4 then a = a + 1

   if !joy0up then goto __Vesica_Piscis

for…next

For-next loops work similar to the way they work in other Basics.

The syntax is:

for variable = value1 to value2 [step value3]

variable is any variable, and value1, 2, and 3 can be variables or numbers. You may also specify a negative step for value3.

The step keyword is optional. Omitting it will default the step to 1.

Examples:

   for x = 1 to 10
   for a = b to c step d
   for l = player0y to 0 step -1

It might be tempting to use a for…next loop with drawscreen in it to slow down a game, but it's better to use a counter since you can slow down specific things while letting other things run at full speed.

   for x = 1 to 10 : a[x] = x : next

   for x = 1 to 20
   goto __Zero_Point_Energy
   for g = 2 to 49
__Zero_Point_Energy
   next

rand

rand is a special variable that will implicitly call an 8-bit random number generator when used.

The rand function returns a pseudo-random number between 1 and 255 every time it is called (a number between 0 and 255 is called when using rand16 or the DPC+ kernel). You typically call this function by something like this:

   a = rand

However, you can also use it in an if…then statement:

   if rand < 32 then r = r + 1

You can also assign the value of rand to something else, at least until it is accessed again. The only reason you would ever want to do this is to seed the randomizer. If you do this, pay careful attention to the value you store there, since storing a zero in rand will "break" it such that all subsequent reads will also be zero!

The standard random number generator is not random enough for most games. It's better to use the optional 16-bit random number generator. This requires that you set aside one variable. You cannot use this variable for other purposes and you should never clear the variable or it will ruin your random numbers. To use the improved routine, place the following near the beginning of your program:

   dim rand16 = <var>

<var> is one of your 26 variables (a-z) or one of your 48 extra variables (var0-var47) when using Superchip RAM. Do not use “rand16” in your code; use rand as you normally would. The only place “rand16” is used is when you set it up with “dim rand16 = <var>”. The DPC+ kernel has an ARM-based 32-bit LFSR for random numbers, so “dim rand16 = <var>” should not be used when making games with the DPC+ kernel.

In bankswitched games, rand may slow down your game if you use it often, as it is typically necessary to switch banks every time it is called. You can get around this limitation using one of the optimization options (see inlinerand for more information).

Below is an imperfect, but close enough list of percentages in case you ever need to limit the chance of something happening:

  5%   temp5 = rand : if temp5 < 13 then

 10%   temp5 = rand : if temp5 < 26 then

 15%   temp5 = rand : if temp5 < 38 then

 20%   temp5 = rand : if temp5 < 51 then

 25%   temp5 = rand : if temp5 < 64 then

 30%   temp5 = rand : if temp5 < 77 then

 35%   temp5 = rand : if temp5 < 90 then

 40%   temp5 = rand : if temp5 < 102 then

 45%   temp5 = rand : if temp5 < 115 then

 50%   temp5 = rand : if temp5 < 128 then

 55%   temp5 = rand : if temp5 < 141 then

 60%   temp5 = rand : if temp5 < 154 then

 65%   temp5 = rand : if temp5 < 166 then

 70%   temp5 = rand : if temp5 < 179 then

 75%   temp5 = rand : if temp5 < 192 then

 80%   temp5 = rand : if temp5 < 205 then

 85%   temp5 = rand : if temp5 < 218 then

 90%   temp5 = rand : if temp5 < 230 then

 95%   temp5 = rand : if temp5 < 243 then

.bin file (use with your favorite emulator).

.bas file (bB code).

Related Link

Sequential Data (or large data)

The sdata statement will define a set of data that is accessed more like the data in other Basics. The 256-byte limitation is also removed—the effective length is only limited by the size of each bank (4K). SequentialIn a row or in order without gaps. data is useful for things like music or a large set of scrolled playfield data. There is also no need to specify a pointer into the data.

One drawback, however, is each sequential data statement requires two adjacent variables from normal 2600's RAM (not Superchip) be set aside.

To define the set of data, use:

sdata <name>=<variable>

<name> is the name you wish to call it when it is read, and <variable> is the first variable name you are setting aside. Although you just specify one variable, the next variable in sequence will also be used.

Example:

   sdata _My_Music=a
   1,2,3,4,5,6,7,255
end

The above will set up a sequential data table called _My_Music that uses variables a and b to remember the element at which it is currently pointing.

Unlike regular data statements, the program must actually run over the sdata statement for it to be properly initialized to the beginning of the data table. Also, it must typically be defined outside the game loop because each time the program runs over the statement, it will be reinitialized to the beginning of the table.

To read the data, use the sread function. It works somewhat similar to a regular bB function. Example:

   t = sread(_My_Music)

This will get the next value in the data table _My_Music and place it in t.

Note that unlike other Basics, there is no error or other indication when reaching the end of data. Since there is no data length variable defined with sequential data, it's usually necessary to place a terminal value at the end of your data. In the above example, 255 was used. In the above example you would then check t for 255.

There is no restore function like other basics. However, if you allow your program to run over the sdata statement again, it will be initialized to the beginning of data just like the restore function.

Note that all data tables, sequential or otherwise, must be located in the same bank where they are read. If you try to access data that lives in another bank, there will be no errors, but the data you get will certainly be incorrect. Check out the example program called Sound With Background “Music” to see how sdata can be used for music.

COLUBK  (Color-Luminosity Background)

Sets the background color. Example: COLUBK = $80.

For a multicolored background using the standard kernel, see kernel_options: background or the kernel_options chart. You can also have a multicolored background using the DPC+ kernel.

Write-Only: COLUBK cannot be read. For example, a = COLUBK will not work properly.

COLUPF  (Color-Luminosity Playfield, Ball)

Sets the playfield color and ball color. Example: COLUPF = $CE. If you use pfscore bars, you'll need to have COLUPF in your main loop or the playfield will become the color of the pfscore bars.

For a multicolored playfield using the standard kernel, see pfcolors or the kernel_options chart. You can also have a multicolored playfield using the DPC+ kernel.

Write-Only: COLUPF cannot be read. For example, a = COLUPF will not work properly.

COLUP0  (Color-Luminosity Player0, Missile0)   Inside Game Loop

Sets the color for player0 sprite and missile0. Example: COLUP0 = $0A. See Ephemeral Variables & Registers for more information.

For a multicolored sprite using the standard kernel, see player1colors and playercolors or the kernel_options chart. You can also have multicolored sprites using the DPC+ kernel.

Write-Only: COLUP0 cannot be read. For example, a = COLUP0 will not work properly.

COLUP1  (Color-Luminosity Player1, Missile1)   Inside Game Loop

Sets the color for player1 sprite and missile1. Example: COLUP1 = $FE. See Ephemeral Variables & Registers for more information.

For a multicolored sprite using the standard kernel, see player1colors and playercolors or the kernel_options chart. You can also have multicolored sprites using the DPC+ kernel.

Write-Only: COLUP1 cannot be read. For example, a = COLUP1 will not work properly.

scorecolor

Sets the score color so it will be visible. Example: scorecolor = $68. See score for more information.

pfscorecolor

Sets the color of the pfscore bars if they are enabled. Example: pfscorecolor = $84. See pfscore bars for more information.

Atari 2600 TIA Color Charts

The color charts below are interactive. Click on a color in one of the charts and the hexadecimal color value will be displayed above it. Visit the TIA Color Charts and Tools page for an NTSC/PAL color conversion tool and Atari 2600 color compatibility tools. You might also want to check out the Color Compatibility Tool that works on a real Atari 2600.

Player Graphics (Sprites)

The standard kernel can display two player sprites, which are 8 pixels wide and any height (up to 256). You access these sprites by using various reserved values and commands. To define a sprite, you use player0: and player1:

Example:

   player0:
   %00100010
   %01110111
   %01111111
end

This will define a player0 sprite which is 3 blocks in height.

Note: You don't need to have your sprite data in the main loop. Whatever you tell your sprites to look like before the main loop starts is what they will look like forever until you tell them to look differently.

Note that the bytes that make up a sprite are upside down in your code. Sprites will be flipped in the game. If you want to edit sprite data right there in your code instead of using a sprite editor, you can use Visual batari Basic to temporarily flip the sprite data right-side-up. Then you can flip the sprite data back upside down when you're done.

To display the objects, you must first set the colors with COLUP0 and COLUP1. They are black by default, which will not display against a black background. For multicolored sprites, see the kernel_options chart and player1colors/playercolors.

To set the coordinates, you set player0x, player0y, player1x, or player1y. On the screen, player0x and player1x values between 0 and 159 are useful, as they represent the extreme left and right edges of the screen. You can specify numbers larger than 159 but you may see some jumping at the edges of the screen. Values of player0y and player1y between 0 and about 88 are useful. Others will simply cause the player to move off of the screen.

   player0:
   %00000000
   %00111100
   %01111110
   %11000011
   %10111101
   %11111111
   %11011011
   %01111110
   %00111100
end

   COLUBK = 0

   player0x = 77
   player0y = 53

__Main_Loop

   COLUP0 = $9C

   if !joy0up then goto __Skip_Up
   if player0height < 8 then player0height = player0height + 1
__Skip_Up

   if !joy0down then goto __Skip_Down
   if player0height > 0 then player0height = player0height - 1
__Skip_Down

   drawscreen

   goto __Main_Loop

   ;***************************************************************
   ;
   ;  Constants for number graphics.
   ;  [The c stands for constant.]
   ;
    const _c_score_table_high = >scoretable
    const _c_score_table_low = <scoretable

   ;```````````````````````````````````````````````````````````````
   ;  Grabs number graphic for player0 sprite.
   ;
   temp5 = _DisplayNumber
   player0pointerhi = _c_score_table_high
   temp5 = temp5 * 8
   player0pointerlo = temp5 + _c_score_table_low

   ;```````````````````````````````````````````````````````````````
   ;  Number graphic variable.
   ;
   dim _DisplayNumber = q

Missiles

Two missiles can be displayed on the screen at coordinates that you specify. The missiles are just solid rectangles. Only the width, height, and color can be changed. A missile can be as tall as the screen, but a missile can only be 1 pixel wide, 2 pixels wide, 4 pixels wide, or 8 pixels wide. See NUSIZx for more information about missile width. Sprite data cannot be applied to the missiles. The missiles share the same colors with their respective players.

To access missiles, you can set missile0x, missile0y, and missile0height for missile0, and missile1x, missile1y, and missile1height for missile1.

Example:

   missile0x = 64
   missile0y = 64
   missile0height = 8

   missile1x = 64
   missile1y = 80
   missile1height = 8


__Main_Loop

   COLUP0 = 140
   COLUP1 = 28 

   NUSIZ0 = $30
   NUSIZ1 = $30

   drawscreen

   goto __Main_Loop

The smallest height that can be used for missile0height and missile1height in the standard kernel is zero. When set to zero, a missile appears to be around two scanlines high.

In the multisprite kernel, the missiles are fixed at one unit high, and the missile height variables do not exist. Also remember that one or both of the missiles can become unavailable depending on the kernel options you select. See kernel options for more information.

When using the DPC+ kernel, the smallest height that can be used with missile0height and missile1height is two. A missile will seem to disappear when its height is set to zero. And setting the height to one will cause the missile to appear on even rows and disappear on odd rows.

There are more things you can do with missiles by modifying the NUSIZx TIA registers. See NUSIZ0, NUSIZ1 for more information.

Ball

The ball is one of the objects that the Atari 2600 can display in the screen.

The ball is the same color as the playfield. If a multicolored playfield is used, the ball will use the color of whatever row it is on. The ball is accessed by ballx, bally, and ballheight, much like accessing the missiles.

Example:

   ballx = 64
   bally = 64

   ballheight = 4 : rem * Ball 4 pixels high.

   CTRLPF = $21 : rem * Ball 4 pixels wide.

   COLUPF = $1E : rem * Ball/playfield color.

__Main_Loop
 
   drawscreen

   goto __Main_Loop

In the multisprite kernel, the ball is fixed at one unit high, and the ballheight variable does not exist.

You can do a few more things with the ball by changing the CTRLPF TIA register. See CTRLPF for more information.

drawscreen

The drawscreen command displays the screen. Any objects with changed colors, positions or height will be updated. Internally, this command runs the display kernel.

Normally, drawscreen is called once within the normal game loop, but it can be called anywhere. The drawscreen operation takes about 12 milliseconds to complete, since it needs to render the entire television display, one scanline at a time. Control will be returned to batari Basic once the visible portion of the screen has been rendered.

It is important to note that the drawscreen command must be run at least 60 times a second. Aside from rendering the visible screen, drawscreen also sends synchronization signals to the television. Failure to run drawscreen quickly enough will result in a display that shakes, jitters, or at worst, rolls.

Therefore, it is possible that your game loop will take up too much time and cause the television to lose sync. Note that your game loop cannot execute for more than around 2 milliseconds, so you should keep the number of loops and calls to playfield scrolling routines to a minimum. This works out to about 2,700 machine cycles, which can get used up pretty fast if you are doing many complicated operations.

If your screen rolls, jitters or shakes, the only solution is to simplify your operations or to try and spread your operations across two or more television frames by calling drawscreen at strategic times. Note also that doing so may slow your game down if you do not also move your sprites or other objects between calls to drawscreen.

Note that emulators are very forgiving about timing, and real hardware will exhibit display problems well before an emulator will. To help troubleshoot timing problems, bB has two debug modes, described elsewhere in this document.

If you do run out of time, you will need to optimize your code and/or spread it across multiple frames, which could slow down the game.

One alternative is to place some code in the vertical blank area. See vblank command for more information about placing code here.

   vblank
   pfscroll left
   return

__Main_Loop

   COLUBK = $C4 : rem  *  Green

   drawscreen

   goto __Main_Loop


   vblank

   COLUBK = $44 : rem  *  Red

   return

pfclear (playfield clear)

Clears the playfield in the standard kernel or can optionally be used with an argument to fill playfield RAM with the specified value.

Example:

   pfclear

The following example will completely fill the playfield RAM with binary value 10101010:

   pfclear %10101010

If you are using the standard kernel and are not scrolling the screen, you can clear the screen without clearing the four playfield variables on the bottom hidden row, and that means you get four extra variables. Here's an example:

   ;***************************************************************
   ;
   ;  Clears screen without clearing var44, var45, var46, or var47.
   ;
   playfield:
   ................................
   ................................
   ................................
   ................................
   ................................
   ................................
   ................................
   ................................
   ................................
   ................................
   ................................
end

This seems to be even faster than the example above:

   ;***************************************************************
   ;
   ;  Clears screen without clearing var44 through var47.
   ;
   var0 = 0 : var1 = 2 : var2 = 0 : var3 = 0 : var4 = 0 : var5 = 0
   var6 = 0 : var7 = 0 : var8 = 0 : var9 = 0 : var10 = 0 : var11 = 0
   var12 = 0 : var13 = 0 : var14 = 0 : var15 = 0 : var16 = 0 : var17 = 0
   var18 = 0 : var19 = 0 : var20 = 0 : var21 = 0 : var22 = 0 : var23 = 0
   var24 = 0 : var25 = 0 : var26 = 0 : var27 = 0 : var28 = 0 : var29 = 0
   var30 = 0 : var31 = 0 : var32 = 0 : var33 = 0 : var34 = 0 : var35 = 0
   var36 = 0 : var37 = 0 : var38 = 0 : var39 = 0 : var40 = 0 : var41 = 0
   var42 = 0 : var43 = 0

And iesposta pointed out that using asm is even faster than the example above:

   ;***************************************************************
   ;
   ;  Clears screen without clearing var44 through var47
   ;  (fastest way using asm).
   ;
   asm
   LDA #0
   STA var0
   STA var1
   STA var2
   STA var3
   STA var4
   STA var5
   STA var6
   STA var7
   STA var8
   STA var9
   STA var10
   STA var11
   STA var12
   STA var13
   STA var14
   STA var15
   STA var16
   STA var17
   STA var18
   STA var19
   STA var20
   STA var21
   STA var22
   STA var23
   STA var24
   STA var25
   STA var26
   STA var27
   STA var28
   STA var29
   STA var30
   STA var31
   STA var32
   STA var33
   STA var34
   STA var35
   STA var36
   STA var37
   STA var38
   STA var39
   STA var40
   STA var41
   STA var42
   STA var43
end

Warning: pfclear does not work with the multisprite kernel.

pfpixel (playfield pixel) •

This draws a single pixel with playfield blocks. Uses 80 processor cycles every frame. The syntax is:

pfpixel xpos ypos function   ( | )

xpos can be 0-31 and ypos can be 0-11 (11 is hidden off of the screen and only seen if scrolled). If you use Superchip RAM with pfres or the multisprite kernel or the DPC+ kernel, you can have more than 11 rows.

function is any of on, off, or flip. on turns the block on, off turns it off, and flip turns it off if it was on or on if it was off.

Examples:

   pfpixel 16 2 on
   pfpixel 8 4 off
   pfpixel 24 8 flip

Note that there is no checking if the bounds of the function are exceeded. If you do so, strange things may happen, including crashing your program.

pfhline (playfield horizontal line)  

This draws a horizontal
Left and Right line with playfield blocks. Uses 250 to 1500 processor cycles every frame depending on length (Approx 210+42*length). The syntax is:

pfhline xpos ypos endxpos function   ( | )

xpos can be 0-31 and ypos can be 0-11 (11 is hidden off of the screen and only seen if scrolled). If you use Superchip RAM with pfres or the multisprite kernel or the DPC+ kernel, you can have more than 11 rows.

endxpos should be greater than xpos or the command will not work properly, and strange things may happen.

function is any of on, off, or flip. on turns the block on, off turns it off, and flip turns it off if it was on or on if it was off.

Examples:

   pfhline 0 0 31 on
   pfhline 4 2 8 off
   pfhline 2 8 24 flip

Note that there is no checking if the bounds of the function are exceeded. If you do so, strange things may happen, including crashing your program.

pfvline (playfield vertical line)  

This draws a vertical
Up and Down line with playfield blocks. Uses 230 to 600 processor cycles every frame depending on length (Approx 200+34*length). The syntax is:

pfvline xpos ypos endxpos function   ( | )

xpos can be 0-31 and ypos can be 0-11 (11 is hidden off of the screen and only seen if scrolled). If you use Superchip RAM with pfres or the multisprite kernel or the DPC+ kernel, you can have more than 11 rows.

endxpos should be greater than xpos or the command will not work properly, and strange things may happen.

function is any of on, off, or flip. on turns the block on, off turns it off, and flip turns it off if it was on or on if it was off.

Examples:

   pfvline 0 0 10 on
   pfvline 31 4 8 off
   pfvline 8 2 4 flip

Note that there is no checking if the bounds of the function are exceeded. If you do so, strange things may happen, including crashing your program.

pfscroll (playfield scroll)

This command scrolls the playfield. It is useful for a moving background or other purposes. For scrolling with the DPC+ kernel, see pfscroll (DPC+).

Valid values are:

Simple example:

   pfhline 8 5 23 on

   scorecolor = $C4
   COLUBK = $C4
   COLUPF = $CE

__Main_Loop

   pfscroll down

   drawscreen

   goto __Main_Loop

More advanced scrolling example:

   scorecolor = $C4
   COLUBK = $C4
   COLUPF = $CE


   playfield:
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   X..............................X
   X...XXXXXXXXXX....XXXXXXXXXX...X
   X...X......................X...X
   X...X......................X...X
   X...X......................X...X
   X..............................X
   X..............................X
   X...XXXX....XXXXXXXX....XXXX...X
   X..............................X
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   ................................
end


__Main_Loop

   if joy0up then pfscroll up
   if joy0down then pfscroll down
   if joy0left then pfscroll left
   if joy0right then pfscroll right

   drawscreen

   goto __Main_Loop

Using pfscroll left or right will use quite a few processor cycles every frame (500 cycles), so use it sparingly. Using pfscroll up or down uses 650 cycles every 8th time it's called, 30 cycles otherwise.

When using pfscroll up or down, the hidden blocks at y position 11 are useful. Although these blocks are never seen, they are "scrolled in" to the visible screen by the commands. This invisible area can therefore be used to simulate a changing background, instead of showing the same background over and over again.

upup and downdown will scroll two lines at a time without the need for calling the routine twice.

Playfield plotting and scrolling commands do not work with the multisprite kernel. If you try to use them, chances are the program will not compile, or if it does, your program may crash.

pfread function

Use pfread to determine whether an existing playfield pixel is on or off. It can only be used in an if…then statement at this time. You may use numbers, variables or arrays as arguments. The syntax is:

if pfread(xpos,ypos) then    ( | )

xpos can be 0-31 and ypos can be 0-11 (11 is hidden off of the screen and only seen if scrolled). If you use Superchip RAM with pfres or the multisprite kernel or the DPC+ kernel, you can have more than 11 rows.

You access it as follows:

   if pfread(10,8) then goto __Star_Doink
   if !pfread(a[x], b) then goto __Higher_Frequency_Manifesting

If you are using the multisprite kernel, you can use a special pfread module, called pfread_msk.asm, made just for this kernel. It is not enabled by default. To enable it, you can use the include or inline command in a 2K or 4K game. For a bankswitched game, only the inline command will work, and the command must be placed in the last bank. For example:

   inline pfread_msk.asm

The command will work in a similar manner to the standard kernel except that y-values are reversed. See inline for more information about this command and its proper use. Alternatively, you can create a custom includes file with this module placed such that it will live in the last bank.

score

The score keyword is used to change the score. The score is fixed at 6 digits, and it currently resides permanently at the bottom of the screen. Unlike other variables, batari Basic accepts values from 0-999999 when dealing with the score.

   const scorefade = 1

   scorecolor = $9C

__Main_Loop

   drawscreen

   goto __Main_Loop

   const scorefade = 1

__Main_Loop

   x = x + 1

   scorecolor = x

   drawscreen

   goto __Main_Loop

   dim _Bit2_FireB_Restrainer = d
   dim _Points_Roll_Up = z

   ;```````````````````````````````````````````````````````````````
   ;  Converts 6 digit score to 3 sets of two digits.
   ;
   ;  The 100 thousands and 10 thousands digits are held by _sc1.
   ;  The thousands and hundreds digits are held by _sc2.
   ;  The tens and ones digits are held by _sc3.
   ;
   dim _sc1 = score
   dim _sc2 = score+1
   dim _sc3 = score+2


__Main_Loop

   scorecolor = $1A


   if !joy0fire then _Bit2_FireB_Restrainer{2} = 0 : goto __Skip_Fire

   if _Bit2_FireB_Restrainer{2} then goto __Skip_Fire

   _Bit2_FireB_Restrainer{2} = 1

   a = a + 5

   if a > 30 then a = 100

   _Points_Roll_Up = _Points_Roll_Up + a

__Skip_Fire


   ;***************************************************************
   ;
   ;  Points roll up code from Nukey Shay.
   ;
   asm
   lda  _Points_Roll_Up
   beq  No_Points_To_Add
   dec  _Points_Roll_Up
   sed
   clc
   lda  _sc3
   adc  #1
   sta  _sc3
   lda  _sc2
   adc  #0
   sta  _sc2
   lda  _sc1
   adc  #0
   sta  _sc1
   cld
No_Points_To_Add:
end

   drawscreen

   goto __Main_Loop

   asm
minikernel
   sta WSYNC
   lda _SC_Back
   sta COLUBK
   rts
end

   ;***************************************************************
   ;
   ;  Assign a variable to the score background.
   ;
   dim _SC_Back = x


   ;***************************************************************
   ;
   ;  Use _SC_Back whenever you need to change the score background.
   ;
   _SC_Back = $C4

   set kernel DPC+

   goto __Start_Restart bank2

   asm
minikernel
   ldx _Score_Background
   stx COLUBK
   rts
end

   bank 2
   temp1=temp1

   dim _Score_Background = y ; Used by asm code to set score bg color.

__Start_Restart

   set kernel DPC+

   goto __Start_Restart bank2

   asm
minikernel
   ldx #$84
   stx COLUBK
   rts
end

   bank 2
   temp1=temp1

__Start_Restart

To change the score, some examples of valid operations are:

   score = 1000
   score = score + 2000
   score = score - 10
   score = score + a

Be careful when using the last one. It will compile, but upon execution, a must always be a BCD compliant number. If a non-BCD number is in a, part of your score may end up garbled.

Conditional statements don't work properly with the score. For example, "if score<10" will compile correctly but will not check if the score is less than 10. This is because the score is a special object: a 24-bit BCD number.

If you plan to check the score, you will need to break out its 6 digits into 3 sets of two digits and check each one. One way to pull out the score digits is:

   ;```````````````````````````````````````````````````````````````
   ;  Converts 6 digit score to 3 sets of two digits.
   ;
   ;  The 100 thousands and 10 thousands digits are held by _sc1.
   ;  The thousands and hundreds digits are held by _sc2.
   ;  The tens and ones digits are held by _sc3.
   ;
   dim _sc1 = score
   dim _sc2 = score+1
   dim _sc3 = score+2

The example above does not use up any of your variables. Starting from left to right, _sc1 holds the 100 thousands and 10 thousands digits, _sc2 holds the thousands and hundreds, and _sc3 holds the tens and ones. Since these are all BCD numbers, you need to place a "$" in front of any values you check. For example, to check if the score is less than 10:

   if _sc1 = $00 && _sc2 = $00 && _sc3 < $10 then ...

To check if the score is greater than 123456:

  if _sc1 > = $12 && _sc2 > = $34 && _sc3 > $56 then ...

The example below increases the score when the fire button is pressed and changes the color of the background each time the thousands digit changes:

   ;***************************************************************
   ;  Converts 6 digit score to 3 sets of two digits.
   ;  _sc1 holds the 100 thousands and 10 thousands
   ;  digits of the score. _sc2 holds the thousands and
   ;  hundreds digits of the score. _sc3 holds the tens
   ;  and ones digits of the score.
   ;
   dim _sc1 = score
   dim _sc2 = score+1
   dim _sc3 = score+2


   ;***************************************************************
   ;  How to check the digits:
   ;
   ;  100 thousands digit .. _sc1 & $F0 (X0 00 00)
   ;  10 thousands digit ... _sc1 & $0F (0X 00 00)
   ;
   ;  Thousands digit ...... _sc2 & $F0 (00 X0 00)
   ;  Hundreds digit ....... _sc2 & $0F (00 0X 00)
   ;
   ;  Tens digit ........... _sc3 & $F0 (00 00 X0)
   ;  Ones digit ........... _sc3 & $0F (00 00 0X)


   scorecolor = $FA


__Main_Loop


   ;***************************************************************
   ;
   ;  Fire button check.
   ;
   ;
   if !joy0fire then goto __Skip_FireB

   ;```````````````````````````````````````````````````````````````
   ;  Remembers the thousands digit.
   ;
   temp5 = _sc2 & $F0

   ;```````````````````````````````````````````````````````````````
   ;  Add points to score.
   ;
   score = score + 10

   ;```````````````````````````````````````````````````````````````
   ;  Grabs the thousands digit.
   ;
   temp6 = _sc2 & $F0

   ;```````````````````````````````````````````````````````````````
   ;  Skips this part if thousands digit has NOT changed.
   ;  
   if temp5 = temp6 then goto __Skip_FireB

   COLUBK = $B4 : c = 45

__Skip_FireB


   if c then c = c - 1 : if !c then COLUBK = 0


   drawscreen


   goto __Main_Loop

   ;***************************************************************
   ;
   ;  High score check.
   ;
   ;  Checks for a new high score.
   ;
   ;```````````````````````````````````````````````````````````````
   ;  Checks first byte.
   ;
   if _sc1 > _High_Score1 then goto __New_High_Score
   if _sc1 < _High_Score1 then goto __Skip_High_Score

   ;```````````````````````````````````````````````````````````````
   ;  First byte equal. Checks second byte.
   ;
   if _sc2 > _High_Score2 then goto __New_High_Score
   if _sc2 < _High_Score2 then goto __Skip_High_Score

   ;```````````````````````````````````````````````````````````````
   ;  Second byte equal. Checks third byte.
   ;
   if _sc3 > _High_Score3 then goto __New_High_Score
   if _sc3 < _High_Score3 then goto __Skip_High_Score

   ;```````````````````````````````````````````````````````````````
   ;  All bytes equal. Skips high score.
   ;
   goto __Skip_High_Score

   ;```````````````````````````````````````````````````````````````
   ;  All bytes not equal. New high score!
   ;
__New_High_Score

   _High_Score1 = _sc1 : _High_Score2 = _sc2 : _High_Score3 = _sc3

__Skip_High_Score

   ;***************************************************************
   ;
   ;  High score check using asm.
   ;
   ;  The original supercat code was adapted by Karl G with input
   ;  from bogax.
   ;
   asm
   sed                    ; Set the Decimal Mode Flag
   lda _High_Score3       ; Load the Accumulator
   cmp _sc3               ; Compare Memory and the Accumulator
   lda _High_Score2       ; Load the Accumulator
   sbc _sc2               ; Subtract With Carry
   lda _High_Score1       ; Load the Accumulator
   sbc _sc1               ; Subtract With Carry
   cld                    ; Clear the Decimal Flag
   bcs .__Skip_High_Score ; Branch if Carry Set
                          ; (goto label if carry is set)
end

   ;```````````````````````````````````````````````````````````````
   ;  New high score!
   ;
   _High_Score1 = _sc1 : _High_Score2 = _sc2 : _High_Score3 = _sc3

__Skip_High_Score

Breaking out score digits is also useful for setting the score to display special values or custom graphics. You can modify score_graphics.asm to include definitions for digits "A-F" and set the score digits manually. How to do this is beyond the scope of this document, but it has been discussed in detail in the batari Basic forum at AtariAge.

   const font = .21stcentury
   const font = alarmclock
   const font = handwritten
   const font = interrupted
   const font = retroputer
   const font = whimsey
   const font = tiny

   const noscore = 1

   ;***************************************************************
   ;
   ;  Enables pfscore bars.
   ;
   const pfscore = 1

   pfscore1 = 21
   pfscore2 = 255

   pfscore1 = %00010101
   pfscore2 = %11111111

   pfscore1 = pfscore1/4 ; If using a lives bar on left side.
   pfscore2 = pfscore2/4 ; If using a lives bar on right side.

   pfscore1 = pfscore1*4|2 ; If using a lives bar on left side.
   pfscore2 = pfscore2*4|2 ; If using a lives bar on right side.

   pfscore1 = pfscore1*4|1 ; If using a lives bar on left side.
   pfscore2 = pfscore2*4|1 ; If using a lives bar on right side.

   pfscore1 = pfscore1/2 ; If using a health bar on left side.
   pfscore2 = pfscore2/2 ; If using a health bar on right side.

   pfscore1 = pfscore1*2|1 ; If using a health bar on left side.
   pfscore2 = pfscore2*2|1 ; If using a health bar on right side.

   if s{0} then dec a = a + $02
   if s{1} then dec a = a + $05
   if s{2} then dec a = a + $10
   if s{3} then dec a = a + $20

   score = score + a

   asm
   sed ; set decimal mode
end

   a = a + $05

   asm
   cld ; clear decimal mode
end

   score = score + a

NUSIZ0, NUSIZ1   Inside Game Loop

This section was updated with the style of SpiceWare's update to the CTRLPF section.

Changes the size and/or other properties of player0/1 and missile0/1.

Use value $mp where m is the missile setting and p is the player setting.

Left click on the m value row and the p value row that you want in the chart below and the code will appear above the chart. You can then copy the code and paste it into your program.

   NUSIZ0 = $  

   rem  *     

Value	Effect
m = 0	1 pixel wide missile.
m = 1	2 pixel wide missile.
m = 2	4 pixel wide missile.
m = 3	8 pixel wide missile.
p = 0	1 copy of player and missile.
p = 1	2 close-spaced copies of player and missile.
p = 2	2 medium-spaced copies of player and missile.
p = 3	3 close-spaced copies of player and missile.
p = 4	2 wide-spaced copies of player and missile.
p = 5	Double-sized player.
p = 6	3 medium-spaced copies of player and missile.
p = 7	Quad-sized player.

Example: NUSIZ0=$33 will make missile0 8 pixels wide, plus make three close copies of player0 and missile0. If you are using the DPC+ kernel, things are a little different. See NUSIZx and REFPx (DPC+) for more information. Also check out the Shooting NUSIZ Copies (DPC+) example program.

Write-Only: NUSIZ0 and NUSIZ1 cannot be read. For example, a = NUSIZ0 will not work properly.

CTRLPF

This section was updated by SpiceWare (adapted by Random Terrain).

Changes properties of the ball and the playfield.

Use value $bp where b is the ball setting and p is the playfield setting.

Left click on the b value row and the p value row that you want in the chart below and the code will appear above the chart. You can then copy the code and paste it into your program.

   CTRLPF = $  

   rem  *     

For example, CTRLPF = $25 will set a 4 pixel wide ball and make the players move behind the playfield.

Note that ball and playfield properties are both set with a single write.

Write-Only: CTRLPF cannot be read. For example, a = CTRLPF will not work properly.

REFP0, REFP1   Inside Game Loop

Reflects player sprites (flips them horizontally
Left and Right). If you are using the DPC+ kernel, things are a little different. See NUSIZx and REFPx (DPC+) for more information.

This is useful for asymmetric spritesSprites that are irregular or lopsided. Not a perfect mirror image on both sides. so that they can give the appearance of changing direction without needing to redefine their graphics.

REFP0 and REFP1 are also used by batari Basic to display the score properly, so they revert back to zero every time drawscreen is used. You can take advantage of that to save a little ROM since you won't have to write code that changes REFP0 or REFP1 to zero when you want to keep the sprite from flipping.

Example:

   dim _Bit6_Flip_P0 = y
   dim _Bit7_Flip_P1 = y

   player0:
   %01111110
   %11111111
   %00011111
   %00000111
   %00011111
   %11111111
   %01111110
end

   player1:
   %10101010
   %11111111
   %10000011
   %10101011
   %11111111
   %10010011
   %11011011
   %10010011
   %01111110
end

   COLUBK = 0

   player0x = 68 : player1x = player0x + 20

   player0y = 55 : player1y = 55



__Main_Loop


   COLUP0 = $1E : COLUP1 = $AE


   if joy0left then _Bit6_Flip_P0{6} = 0 : _Bit7_Flip_P1{7} = 0
   if joy0right then _Bit6_Flip_P0{6} = 1 : _Bit7_Flip_P1{7} = 1


   ;****************************************************************
   ;
   ;  Flips player0 sprite when necessary.
   ;
   if _Bit6_Flip_P0{6} then REFP0 = 8


   ;****************************************************************
   ;
   ;  Flips player1 sprite when necessary.
   ;
   if _Bit7_Flip_P1{7} then REFP1 = 8


   drawscreen


   goto __Main_Loop

Write-Only: REFP0 and REFP1 cannot be read. For example, a = REFP0 will not work properly.

PF0   Inside Game Loop

Set or clear the left and right 10% of the playfield. PF0 must be inside of your game loop.

PF0 is useful for creating a border in batari Basic. In other kernels or in assembly, it has other uses.

Write-Only: PF0 cannot be read. For example, a = PF0 will not work properly.

More About PF0:

The side areas are mirrored and each side can have up to four columns. PF0 is easier to deal with if you use a binary number. The first four digits in the number are the ones that matter. For example, PF0 = %11110000 will give you a thick side border (made of four columns) and PF0 = %10000000 will give you a thin side border right next to the playfield (made of one column).

Example with one column next to playfield:

   COLUBK = 132 
   COLUPF = 30

   playfield:
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   ................................
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   ................................
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   ................................
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   ................................
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   ................................
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

__Main_Loop

   PF0 = %10000000

   drawscreen

   goto __Main_Loop

PF0 = %10000000 in the example above can be replaced with other combinations. Below are two examples.

Column farthest away from the playfield:

   PF0 = %00010000

Four columns:

   PF0 = %11110000

AUDV0, AUDC0, AUDF0, AUDV1, AUDC1, AUDF1

See sound for more information about these.

if collision (object,object)

This function is used for checking if two objects have collided on the screen. Valid arguments are playfield, ball, player0, player1, missile0, missile1. The two objects can be specified in any order.

The collision() function is only valid when used in an if…then statement.

Note that the collision detection is hardware-based and is pixel-perfect. The collision detection may or may not be suitable for your game.

Note that in the multisprite kernel, you can define objects player2 through player5. However, these are not valid arguments in the collision statement because the Atari 2600 cannot actually display 5 completely independent player objects. Player2-5 are virtual sprites, drawn by repositioning player1 several times during the visible screen. Therefore, a collision with player1 in the multisprite kernel means that you have hit one or more virtual players, and you must do further checks, for example, the y-positions, to determine which one.

Examples:

   if collision(playfield,player0) then a = a + 1

   if !collision(player0,missile1) then goto __Polly_Tricks

DPC+ Kernel

Text by RevEng, batari, iesposta, Atarius Maximus, SpiceWare, ScumSoft, and possibly others (adapted by Random Terrain)

The DPC+ kernel is similar to the multisprite kernel, but it has an asymmetric (non-mirrored) multicolored playfield with simultaneous single line background and foreground colors. It also has 10 multicolored single-height sprites instead of 6 mono-colored double-height sprites. For a quick overview, check out the DPC+ section of the Table of Contents.

Before the DPC+ kernel was added, all bB sprites had double-thick rows, so they weren't as pretty as the sprites that assembly language programmers could make. Thanks to the DPC+ kernel, bB users can create single-height sprites that are as detailed as the ones made by Imagic and Activision.

To use the DPC+ kernel, put this at the beginning of your code:

   set kernel DPC+

Kernel options for the standard kernel are not used with the DPC+ kernel.

The romsize for the DPC+ kernel is 32k and cannot be changed. Do not declare set romsize 32k when using the DPC+ kernel as the ROM size is automatically set to 32k for you. The DPC+ kernel has a 4k graphics bank where your sprite and playfield data automatically go. You cannot place your own code in the graphics bank. There's another 4k bank that you cannot use that holds the ARM code. Most of bank 1 is used up, but banks 2, 3, 4, 5, and 6 are completely free for normal use. So that's 4K bB system, 20K of your basic code, 4K graphics data, and 4K ARM code = 32K binary.

The DPC+ kernel goes in bank 1, so there's very little free room there. It's a good idea to put a goto statement in bank 1 to a label in bank 2 and start your code there.

Example:

   goto __Bank_2 bank2

   bank 2

   temp1=temp1

__Bank_2

There are less than 100 bytes free to use in bank 1 and that will shrink over time as improvements are made. To make sure your games will always compile with the latest version of bB, about the only code you should have in bank 1 is a goto that jumps to bank 2.

Make sure that you have downloaded the latest version of bB. You might also want to see if you have the latest version of Visual batari Basic, the bB IDE.

   ;****************************************************************
   ;
   ;  This program uses the DPC+ kernel.
   ;
   set kernel DPC+


   ;****************************************************************
   ;
   ;  Standard used in North America and most of South America.
   ;
   set tv ntsc


   ;****************************************************************
   ;
   ;  Helps player1 sprites register a collision with the playfield.
   ;
   set kernel_options collision(player1,playfield)


   ;***************************************************************
   ;
   ;  Variable aliases go here (DIMs).
   ;
   ;***************************************************************
   ;
   ;  (You can have more than one alias for each variable.)
   ;
   ;```````````````````````````````````````````````````````````````
   ;  Scroll counter.
   ;
   dim _Scroll_Counter = a

   ;```````````````````````````````````````````````````````````````
   ;  Bits for various jobs.
   ;
   dim _Bit0_Reset_Restrainer = y
   dim _Bit7_Flip_Scroll = y



   goto __Bank_2 bank2



   bank 2
   temp1=temp1



__Bank_2



   ;***************************************************************
   ;***************************************************************
   ;
   ;  Program Start/Restart
   ;
__Start_Restart


   ;***************************************************************
   ;
   ;  Displays the screen to avoid going over 262 when reset.
   ;
   drawscreen


   ;***************************************************************
   ;
   ;  Clears the playfield.
   ;
   pfclear


   ;***************************************************************
   ;
   ;  Mutes volume of both sound channels.
   ;
   AUDV0 = 0 : AUDV1 = 0


   ;***************************************************************
   ;
   ;  Clears all normal variables and the extra 9.
   ;
   a = 0 : b = 0 : c = 0 : d = 0 : e = 0 : f = 0 : g = 0 : h = 0 : i = 0
   j = 0 : k = 0 : l = 0 : m = 0 : n = 0 : o = 0 : p = 0 : q = 0 : r = 0
   s = 0 : t = 0 : u = 0 : v = 0 : w = 0 : x = 0 : y = 0 : z = 0
   var0 = 0 : var1 = 0 : var2 = 0 : var3 = 0 : var4 = 0
   var5 = 0 : var6 = 0 : var7 = 0 : var8 = 0


   ;***************************************************************
   ;
   ;  Playfield data.
   ;
   playfield:
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .X....X..X....X..X....X..X....X.
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
end


   ;***************************************************************
   ;
   ;  Playfield colors.
   ;
   pfcolors:
   $0E
   $0C
   $0A
   $08
   $06
   $1E
   $1C
   $1A
   $18
   $16
   $2E
   $2C
   $2A
   $28
   $26
   $3E
   $3C
   $3A
   $38
   $36
   $4E
   $4C
   $4A
   $48
   $46
   $5E
   $5C
   $5A
   $58
   $56
   $6E
   $6C
   $6A
   $68
   $66
   $7E
   $7C
   $7A
   $78
   $76
   $9E
   $9C
   $9A
   $98
   $96
   $AE
   $AC
   $AA
   $A8
   $A6
   $BE
   $BC
   $BA
   $B8
   $B6
   $CE
   $CC
   $CA
   $C8
   $C6
   $DE
   $DC
   $DA
   $D8
   $D6
   $EE
   $EC
   $EA
   $E8
   $E6
   $3E
   $3C
   $3A
   $38
   $36
   $4E
   $4C
   $4A
   $48
   $46
   $5E
   $5C
   $5A
   $58
   $56
   $6E
   $6C
   $6A
   $68
   $66
   $7E
   $7C
   $7A
   $78
   $76
   $8E
   $8C
   $8A
   $88
   $86
   $9E
   $9C
   $9A
   $98
   $96
   $BE
   $BC
   $BA
   $B8
   $B6
   $CE
   $CC
   $CA
   $C8
   $C6
   $FE
   $FC
   $FA
   $F8
   $F6
end


   ;***************************************************************
   ;
   ;  Background colors.
   ;
   bkcolors:
   $80
   $82
   $84
   $86
   $88
   $8A
   $8C
   $8E
   $80
   $82
   $84
   $86
   $88
   $8A
   $8C
   $8E
   $80
   $82
   $84
   $86
   $88
   $8A
   $8C
   $8E
   $80
   $82
   $84
   $86
   $88
   $8A
   $8C
   $8E
   $80
   $82
   $84
   $86
   $88
   $8A
   $8C
   $8E
   $80
   $82
   $84
   $86
   $88
   $8A
   $8C
   $8E
   $80
   $82
   $84
   $86
   $88
   $8A
   $8C
   $8E
   $80
   $82
   $84
   $86
   $88
   $8A
   $8C
   $8E
   $80
   $82
   $84
   $86
   $88
   $8A
   $8C
   $8E
   $80
   $82
   $84
   $86
   $88
   $8A
   $8C
   $8E
   $80
   $82
   $84
   $86
   $88
   $8A
   $8C
   $80
end


   ;***************************************************************
   ;
   ;  Score colors.
   ;
   scorecolors:
   $1E
   $1C
   $1A
   $1A
   $18
   $18
   $16
   $16
end


   ;***************************************************************
   ;
   ;  Restrains the reset switch for the main loop.
   ;
   ;  This bit fixes it so the reset switch becomes inactive if
   ;  it hasn't been released after being pressed once.
   ;
   _Bit0_Reset_Restrainer{0} = 1




   ;***************************************************************
   ;***************************************************************
   ;
   ;  Main Loop
   ;
__Main_Loop



   ;,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
   ;```````````````````````````````````````````````````````````````
   ;
   ;  Gameplay logic goes here.
   ;
   ;,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
   ;```````````````````````````````````````````````````````````````



   ;***************************************************************
   ;
   ;  Scrolls the foreground color up and down.
   ;
   _Scroll_Counter = _Scroll_Counter + 1

   if _Bit7_Flip_Scroll{7} then pfscroll 255 4 4

   if !_Bit7_Flip_Scroll{7} then pfscroll 1 4 4

   if _Scroll_Counter < 32 then goto __Skip_Scroll

   _Scroll_Counter = 0

   _Bit7_Flip_Scroll{7} = !_Bit7_Flip_Scroll{7}

__Skip_Scroll



   ;***************************************************************
   ;
   ;  88 rows that are 2 scanlines high.
   ;
   DF6FRACINC = 255 ; Background colors.
   DF4FRACINC = 255 ; Playfield colors.

   DF0FRACINC = 128 ; Column 0.
   DF1FRACINC = 128 ; Column 1.
   DF2FRACINC = 128 ; Column 2.
   DF3FRACINC = 128 ; Column 3.



   ;***************************************************************
   ;
   ;  Displays the screen.
   ;
   drawscreen



   ;***************************************************************
   ;
   ;  Reset switch check and end of main loop.
   ;
   ;  Any Atari 2600 program should restart when the reset  
   ;  switch is pressed. It is part of the usual standards
   ;  and procedures.
   ;
   ;```````````````````````````````````````````````````````````````
   ;  Turns off reset restrainer bit and jumps to beginning of
   ;  main loop if the reset switch is not pressed.
   ;
   if !switchreset then _Bit0_Reset_Restrainer{0} = 0 : goto __Main_Loop

   ;```````````````````````````````````````````````````````````````
   ;  Jumps to beginning of main loop if the reset switch hasn't
   ;  been released after being pressed.
   ;
   if _Bit0_Reset_Restrainer{0} then goto __Main_Loop

   ;```````````````````````````````````````````````````````````````
   ;  Restarts the program.
   ;
   goto __Start_Restart



   bank 3
   temp1=temp1


   bank 4
   temp1=temp1


   bank 5
   temp1=temp1


   bank 6
   temp1=temp1

   ; Position stack at location 200 and push the value stored in player0x.
   ;
   stack 200

   push player0x


   ; [Code that reuses player0x can go here.]


   ; Position stack above location 200 and pull off the item below.
   ;
   stack 199

   pull player0x

   scorecolors:
   $3E
   $3C
   $3A
   $38
   $36
   $36
   $34
   $32
end

   player0:
   %00001111
   %00000110
   %00000111
   %00011111
   %11111111
   %00111110
   %11111111
   %00011111
   %00000111
   %00000110
   %00001111
end

   player1:
   %00000011
   %00000110
   %00011111
   %11111111
   %11111110
   %11111110
   %11111110
   %11111111
   %00011111
   %00000110
   %00000011
end

   player2:
   %00001111
   %00000110
   %11111111
   %11111111
   %00000111
   %00001110
   %00000111
   %11111111
   %11111111
   %00000110
   %00001111
end

   player3:
   %00111111
   %00111110
   %00000111
   %00011111
   %00111111
   %11111110
   %00111111
   %00011111
   %00000111
   %00111110
   %00111111
end

   player4:
   %00001111
   %00000110
   %00000110
   %00011110
   %11111111
   %11111111
   %11111111
   %00011110
   %00000110
   %00000110
   %00001111
end

   player1-9:
   %00001111
   %00000110
   %00000111
   %00011111
   %11111111
   %00111110
   %11111111
   %00011111
   %00000111
   %00000110
   %00001111
end

   player2-3:
   %00111111
   %00111110
   %00000111
   %00011111
   %00111111
   %11111110
   %00111111
   %00011111
   %00000111
   %00111110
   %00111111
end

   player1-4:
   %00001111
   %00000110
   %00000111
   %00011111
   %11111111
   %00111110
   %11111111
   %00011111
   %00000111
   %00000110
   %00001111
end

   player5-7:
   %00000011
   %00000110
   %00011111
   %11111111
   %11111110
   %11111110
   %11111110
   %11111111
   %00011111
   %00000110
   %00000011
end

   player8-9:
   %00001111
   %00000110
   %11111111
   %11111111
   %00000111
   %00001110
   %00000111
   %11111111
   %11111111
   %00000110
   %00001111
end

Collisions with the playfield can be tricky when using virtual sprites. For sprites 1 through 9, the one that touches a playfield pixel higher on the screen gets its y-coordinate placed in temp4. Other sprites touching a playfield pixel lower on the screen don't register as long as the sprite is still touching the higher playfield pixel. In other words, the sprite with the highest playfield pixel collision is the only one that gets reported, even if a lower collision is the latest one to happen. When it happens doesn't matter. The highest virtual sprite always wins.

 

Below is an adapted version of the 13 Objects with Coordinates example program to help us learn more about DPC+ collisions.

 

 

 

13 Objects With Coordinates and Collision (DPC+)

There are 10 sprites (player0 at the top, down to player9 at the bottom), 2 missiles (missile0 above missile1) and 1 ball on the screen. Hold down the fire button and press the joystick up or down to select an object. Hold down the fire button and move the joystick left or right to change the size of the currently selected object.

 

To move the currently selected object, release the fire button and press the joystick in any direction.

 

When you move the player0 sprite over the other sprites, a playfield pixel is turned on next to the starting position of the touched sprite.

 

When a sprite touches the green column on the screen, a playfield pixel is turned on across from the starting position of the sprite on the other side of the column.

 

.bin file (use with your favorite emulator).

.bas file (bB code).

 

 

 

 

The Playfield (DPC+)

You can specify an entire playfield at once by using the playfield: command. The syntax of the command is:

 

  playfield:
  (pixels)
end

 

Example:

   playfield:
   ..XXXX....XXXX....XXXX....XXXX..
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   ..XXXX....XXXX....XXXX....XXXX..
   ................................
   ................................
   ....X.......X.......X.......X...
   ...XX......XX......XX......XX...
   ..XXX.....XXX.....XXX.....XXX...
   ...XX......XX......XX......XX...
   ...XX......XX......XX......XX...
   ...XX......XX......XX......XX...
   ...XX......XX......XX......XX...
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   ................................
   ................................
   ..XXXX....XXXX....XXXX....XXXX..
   .X...XX..X...XX..X...XX..X...XX.
   .....XX......XX......XX......XX.
   .....XX......XX......XX......XX.
   ..XXXX....XXXX....XXXX....XXXX..
   .XX......XX......XX......XX.....
   .XX......XX......XX......XX.....
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   ................................
   ................................
   ..XXXX....XXXX....XXXX....XXXX..
   .X...XX..X...XX..X...XX..X...XX.
   .....XX......XX......XX......XX.
   ...XXX.....XXX.....XXX.....XXX..
   .....XX......XX......XX......XX.
   .....XX......XX......XX......XX.
   .X...XX..X...XX..X...XX..X...XX.
   ..XXXX....XXXX....XXXX....XXXX..
   ................................
   ................................
   ....XX......XX......XX......XX..
   ...XXX.....XXX.....XXX.....XXX..
   ..X.XX....X.XX....X.XX....X.XX..
   .X..XX...X..XX...X..XX...X..XX..
   .X..XX...X..XX...X..XX...X..XX..
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   ....XX......XX......XX......XX..
   ....XX......XX......XX......XX..
   ................................
   ................................
   .XXXXXX..XXXXXX..XXXXXX..XXXXXX.
   .XX......XX......XX......XX.....
   .XX......XX......XX......XX.....
   ..XXXX....XXXX....XXXX....XXXX..
   .....XX......XX......XX......XX.
   .....XX......XX......XX......XX.
   .X...XX..X...XX..X...XX..X...XX.
   ..XXXX....XXXX....XXXX....XXXX..
   ................................
   ................................
   ..XXXX....XXXX....XXXX....XXXX..
   .XX...X..XX...X..XX...X..XX...X.
   .XX......XX......XX......XX.....
   .XXXXX...XXXXX...XXXXX...XXXXX..
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   ..XXXX....XXXX....XXXX....XXXX..
   ................................
   ................................
   ..XXXXX...XXXXX...XXXXX...XXXXX.
   .X....X..X....X..X....X..X....X.
   .....XX......XX......XX......XX.
   ....XX......XX......XX......XX..
   ...XX......XX......XX......XX...
   ..XX......XX......XX......XX....
   ..XX......XX......XX......XX....
   ..XX......XX......XX......XX....
   ................................
   ................................
   ..XXXX....XXXX....XXXX....XXXX..
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   ..XXXX....XXXX....XXXX....XXXX..
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   .XX..XX..XX..XX..XX..XX..XX..XX.
   ..XXXX....XXXX....XXXX....XXXX..
end

 

 

 

 

pfclear (DPC+)

This is faster than regular pfclear in the standard kernel because the ARM CPU is faster than a 6507 at clearing its memory.

 

 

 

 

DFxFRACINC (DPC+)

The DPC+ kernel uses DFxFRACINC registers for certain jobs. No, it doesn't have anything to do with evil hydrofracking; it stands for Data Fetcher Fractional Increment. Normal data fetchers are 32 bit integers and automatically increment by 1 every time you read from them. Fractional data fetchers use the same idea as fixed point variables. Since 32 bit values are used in the ARM processor, the value is divided up as 24.8 instead of 8.8. Instead of incrementing by 1, they increment by 0.y where y is whatever you assigned DFxFRACINC.

 

Note: DFxFRACINC must be placed in the main loop before/with drawscreen.

 

 

 

 

Playfield Resolution (DPC+)

Horizontal resolution is 32 playfield pixels across (same as the standard kernel). Vertical resolution with the DPC+ kernel is a little more complicated. The playfield is divided into 4 columns and each column can have a different resolution (pixel height). Column resolution is controlled using 4 registers: DF0FRACINC, DF1FRACINC, DF2FRACINC, and DF3FRACINC.

 

Under the image below is an example program by RevEng:

 

.bin file (use with your favorite emulator).

.bas file (bB code).

 

The value stored to the DF0FRACINC-DF3FRACINC registers determines how many scanlines it takes to change a playfield row.  When using these registers, you shouldn't be thinking about the number of rows in the playfield but rather approximately how many scanlines tall each playfield row is. Currently the kernel displays 176 scanlines, but this is subject to change.

 

The value in DF4FRACINC determines how many times playfield pixels can change color from top to bottom.

 

The value in DF6FRACINC determines how many times the background color can be changed from top to bottom.

 

Below is a table of some playfield values that should work in the DPC+ kernel. These aren't the only values that work, or the only combination of values that work, so I encourage experimentation if you're doing something different (such as not aligning color changes to playfield rows.)

 

The first column in the table below is the number of scanlines in each row. The next is the approximate resolution (rounded up, and may change.)  Next is DF(0-3)FRACINC, which control the number of scanlines in each row of each playfield column. Last is the playfield color value (DF4FRACINC). Complicating matters somewhat is that color updates occur half as often, so not all playfield values can have colors that work nicely with them.  If this is the case, a dash is shown in place of the DF4FRACINC value. The values for DF4FRACINC may also be stored to DF6FRACINC if you wish to match the background colors with the playfield rows.

Scanlines       Resolution      DF(0-3)FRACINC          DF4FRACINC
1               176             255                     -
2               88              128                     255 
3               59 *            86                      -
4               44              64                      128
5               36 *            52                      -
6               30 *            43                      86
7               26 *            37                      -
8               22              32                      64
9               20 *            29                      -
10              18 *            26                      52
11              16              24                      -
12              15 *            22                      44
13              14 *            20                      -
14              13 *            19                      38
15              12 *            18                      -
16              11              16                      32
18              10 *            15                      30
19              10 *            14                      -
20              9 *             13                      26
22              8               12                      24
24              8 *             11                      22
26              7 *             10                      20
29              7 *             9                       -
32              6 *             8                       16
37              5 *             7                       -
44              4               6                       12
52              4 *             5                       10
64              3 *             4                       8
86              3 *             3                       6
128             2 *             2                       4
176             1               1 or 0                  1 or 0

Note: A "*" in the resolution column means that the bottom row isn't full height.

 

 

A few examples:

   ;***************************************************************
   ;
   ;  176 rows that are 1 scanline high except the top and bottom
   ;  rows (which seem to be 2 scanlines high). All of the colors
   ;  seem to be 2 scanlines high.
   ;
   DF6FRACINC = 255 ; Background colors.
   DF4FRACINC = 255 ; Playfield colors.

   DF0FRACINC = 255 ; Column 0.
   DF1FRACINC = 255 ; Column 1.
   DF2FRACINC = 255 ; Column 2.
   DF3FRACINC = 255 ; Column 3.


   ;***************************************************************
   ;
   ;  Simple fix for the top and bottom rows (only for 176 rows).
   ;
   asm
   lda DF6FRACDATA
   lda DF4FRACDATA
   lda DF0FRACDATA
   lda DF1FRACDATA
   lda DF2FRACDATA
   lda DF3FRACDATA
end


   ;***************************************************************
   ;
   ;  88 rows that are 2 scanlines high.
   ;
   DF6FRACINC = 255 ; Background colors.
   DF4FRACINC = 255 ; Playfield colors.

   DF0FRACINC = 128 ; Column 0.
   DF1FRACINC = 128 ; Column 1.
   DF2FRACINC = 128 ; Column 2.
   DF3FRACINC = 128 ; Column 3.


   ;***************************************************************
   ;
   ;  Simple fix for top two lines of 88 rows having same color.
   ;
   asm
   lda DF6FRACDATA
   lda DF4FRACDATA
end


   ;***************************************************************
   ;
   ;  44 rows that are 4 scanlines high.
   ;
   DF6FRACINC = 128 ; Background colors.
   DF4FRACINC = 128 ; Playfield colors.

   DF0FRACINC = 64 ; Column 0.
   DF1FRACINC = 64 ; Column 1.
   DF2FRACINC = 64 ; Column 2.
   DF3FRACINC = 64 ; Column 3.


   ;***************************************************************
   ;
   ;  22 rows that are 8 scanlines high.
   ;
   DF6FRACINC = 64 ; Background colors.
   DF4FRACINC = 64 ; Playfield colors.

   DF0FRACINC = 32 ; Column 0.
   DF1FRACINC = 32 ; Column 1.
   DF2FRACINC = 32 ; Column 2.
   DF3FRACINC = 32 ; Column 3.


   ;***************************************************************
   ;
   ;  11 rows that are 16 scanlines high.
   ;
   DF6FRACINC = 32 ; Background colors.
   DF4FRACINC = 32 ; Playfield colors.

   DF0FRACINC = 16 ; Column 0.
   DF1FRACINC = 16 ; Column 1.
   DF2FRACINC = 16 ; Column 2.
   DF3FRACINC = 16 ; Column 3.


   ;***************************************************************
   ;
   ;  6 rows that are 32 scanlines high.
   ;
   DF6FRACINC = 16 ; Background colors.
   DF4FRACINC = 16 ; Playfield colors.

   DF0FRACINC = 8 ; Column 0.
   DF1FRACINC = 8 ; Column 1.
   DF2FRACINC = 8 ; Column 2.
   DF3FRACINC = 8 ; Column 3.

 

DPC+ 176 rows and DPC+ 88 rows will not display properly without tricks developed by Lillapojkenpåön at AtariAge. Problem is that a DPC+ driver update made a change that caused the tricks to stop working using Stella 6.0 through 6.7 and the Harmony cart. Thanks to SpiceWare, if you go to AtariAge, download DPCplus.arm, and put it in your batari Basic includes folder, the tricks will work again using the latest version of Stella and the Harmony cart:

 

Download DPCplus.arm from AtariAge

 

 

 

DFxFRACINC Tool (DPC+)

Press the joystick left or right to select DF6FRACINC, DF0FRACINC, DF1FRACINC, DF2FRACINC, DF3FRACINC or DF4FRACINC. Press the joystick up or down to increase or decrease the selected register. Press the fire button to slow things down when you get near a number that you'd like to stop on. Press the select switch for presets. Press the reset switch to go back to the default settings.

 

.bin file (use with your favorite emulator).

.bas file (bB code).

 

 

 

 

pfscroll (DPC+)

RevEng added coarse vertical scrolling to the DPC+ kernel back when he was working on batari Basic for a while. There is no horizontal DPC+ scrolling at this time. Someone might come along and start working on batari Basic again and give us all kinds of goodies. Until then, we're lucky that we have vertical scrolling.

 

Unlike pfscroll for the other kernels, the syntax is "pfscroll [value]" or "pfscroll [variable]". It does a coarse scroll, 1 PF line at a time, so if you want smooth scrolling, you need a fine DF#FRACINC resolution. The playfield strips are 256 bytes in size, so if you want to scroll down, use "pfscroll 255" to scroll down by 1, "pfscroll 254" to scroll down by 2, and so on.

 

The DPC+ pfscroll command also has 2 optional queue values to indicate the starting column and ending column that you want to scroll. Right now variables won't work for the queue numbers, but you can still use a variable for the scrolling value, even if you add queue values.

 

The syntax is:

pfscroll [value or variable] [queue value] [queue value

 

0 = DF0FRACINC Playfield Data

1 = DF1FRACINC Playfield Data

2 = DF2FRACINC Playfield Data

3 = DF3FRACINC Playfield Data

4 = Playfield Color Data

6 = Background Color Data

 

 

Examples:

   pfscroll 1 ; Scrolls the DPC+ playfield one line.
   pfscroll 1 0 1 ; Scrolls DFO and DF1 one line.
   pfscroll 1 2 3 ; Scrolls DF2 and DF3 one line.
   pfscroll 1 1 3 ; Scrolls DF1 through DF3 one line.
   pfscroll 1 0 4 ; Scrolls whole playfield and PF colors one line.
   pfscroll 1 4 4 ; Scrolls only the PF colors one line.

A note on the last 2 examples. Due to the way the kernel updates PF colors, to keep colors lock-step with the PF graphics you should either set DF4FRACINC to twice the number of DF[0-3]FRACINC fetchers, or scroll the PF queues twice as much as the 4th (color) queue. The same also applies to DF6FRACINC:

   pfscroll 1 0 6 ; Scrolls playfield and background colors one line.
   pfscroll 1 6 6 ; Scrolls only the background colors one line.

 

 

 

Playfield Color & Background Color Scrolling With Changeable Score Background Color (DPC+)

Press fire button to change score background color. Hold to change colors slowly. Quickly press and release repeatedly to change colors faster. You can also press the fire button while holding the joystick in any direction to rapidly change the colors.

 

.bin file (use with your favorite emulator).

.bas file (bB code).

 

 

 

 

Playfield Colors (DPC+)

Specifies colors of each playfield row and must be followed by end. You can specify this as many times as you want.

 

Example:

   pfcolors:
   $0E
   $0C
   $0A
   $08
   $06
   $1E
   $1C
   $1A
   $18
   $16
   $2E
   $2C
   $2A
   $28
   $26
   $3E
   $3C
   $3A
   $38
   $36
   $4E
   $4C
   $4A
   $48
   $46
   $5E
   $5C
   $5A
   $58
   $56
   $6E
   $6C
   $6A
   $68
   $66
   $7E
   $7C
   $7A
   $78
   $76
   $9E
   $9C
   $9A
   $98
   $96
   $AE
   $AC
   $AA
   $A8
   $A6
   $BE
   $BC
   $BA
   $B8
   $B6
   $CE
   $CC
   $CA
   $C8
   $C6
   $DE
   $DC
   $DA
   $D8
   $D6
   $EE
   $EC
   $EA
   $E8
   $E6
   $3E
   $3C
   $3A
   $38
   $36
   $4E
   $4C
   $4A
   $48
   $46
   $5E
   $5C
   $5A
   $58
   $56
   $6E
   $6C
   $6A
   $68
   $66
end

Remember, the value in DF4FRACINC determines how many times playfield pixels can change color from top to bottom.

 

The code below will make all of the playfield pixels blue:

   DF4FRACINC = 0

   pfcolors:
   $86
end

 

 

 

Change Playfield Row Colors (DPC+)

This example program is by Lillapojkenpåön (adapted by Random Terrain).

 

Push joystick up or down to select any row. Push joystick right to change color of the selected row. Push joystick left while pushing up or down to paint playfield with the last color that was selected. Push joystick right while pushing up or down to paint with multiple colors. Holding down the fire button slows down row selection and color selection.

 

.bin file (use with your favorite emulator).

.bas file (bB code).

 

 

 

 

Background Colors (DPC+)

Lets you pick a color for each scanline in the background and must be followed by end. You can specify this as many times as you want.

 

Example:

   bkcolors:
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $80
   $82
   $82
   $82
   $82
   $82
   $82
   $82
   $82
   $84
   $84
   $84
   $84
   $84
   $84
   $84
   $86
   $86
   $86
   $86
   $86
   $86
   $88
   $88
   $88
   $88
   $88
   $8A
   $8A
   $8A
   $8A
   $8C
   $8C
   $8C
   $8E
   $8E
   $00
   $F0
   $F2
   $F2
   $F4
   $F4
   $F4
   $F6
   $F6
   $F6
   $F6
   $F8
   $F8
   $F8
   $F8
   $F8
   $F8
   $F8
   $F8
   $00
end

Remember, the value in DF6FRACINC determines how many times the background color can be changed from top to bottom.

 

The code below will make the background all red:

   DF6FRACINC = 0

   bkcolors:
   $44
end

If you'd like to have a good way to control the background color behind the score, check out the DPC+ Score Background Color asm code by RevEng or the Lillapojkenpåön example program that doesn't use a minikernel.

 

 

 

Change Background Row Colors (DPC+)

This example program is by Lillapojkenpåön (adapted by Random Terrain).

 

Push joystick up or down to select any row. Push joystick right to change color of the selected row. Push joystick left while pushing up or down to paint background with the last color that was selected. Push joystick right while pushing up or down to paint with multiple colors. Holding down the fire button slows down row selection and color selection.

 

.bin file (use with your favorite emulator).

.bas file (bB code).

 

 

 

 

 

 

vblank (DPC+)

The DPC+ kernel itself uses vblank to do its own setup, so there would only be a few free cycles left in vblank for your program. In the the DPC+ kernel, vblank would need to go in bank 1, but improvements to the DPC+ kernel have used up almost all available space in the first bank, so there is virtually no room for vblank code. As of March of 2016, the DPC+ kernel has 524 cycles available in vblank, but that could shrink significantly as more changes are made to the kernel. In other words, if you are using the DPC+ kernel, avoid vblank.

Back to Top

Multisprite Kernel

This is an entirely new kernel written from scratch that provides significant features that should be suitable for a wide variety of games. The multisprite kernel was created years before the DPC+ kernel. Many people choose to use the DPC+ kernel instead since it has 10 multicolored single-height sprites instead of 6 mono-colored double-height sprites. Thanks to the DPC+ kernel, bB users can create single-height sprites that are as detailed as the ones made by Imagic and Activision.

Instead of two player sprites, you get six. Five of the six sprites are subject to certain limitations, however. These limitations are because the 2600's hardware can only display two sprites on any given horizontal
Left and Right line (or y-value).

The player0 sprite works much how it did in the standard kernel. Player1-player5 sprites are 'virtual' sprites, and are displayed by repositioning the 2600's second hardware sprite several times during the visible screen.

One limitation is that the virtual sprites may flicker if one or more of them share the same vertical
Up and Down region or don't have enough vertical separation between them. Most people don't mind the flicker, and on a real television, it isn't always terribly noticeable if used sparingly. If you prefer to write a game with no flicker, just ensure that there is sufficient vertical separation between sprites. The kernel will automatically detect if two or more sprites are overlapping and will automatically flicker them, so you don't need to do this yourself. It should be noted that the flicker algorithm isn't perfected yet. Under certain conditions, some sprites might not display correctly. This is a known bug and it's being looked at.

Note that in the multisprite kernel, you can define objects player2 through player5. However, these are not valid arguments in the collision statement because the Atari 2600 cannot actually display 5 completely independent player objects. Player2-5 are virtual sprites, drawn by repositioning player1 several times during the visible screen. Therefore, a collision with player1 in the multisprite kernel means that you have hit one or more virtual players, and you must do further checks, for example, the y-positions, to determine which one.

The virtual sprites also are given their own virtual color and NUSIZ registers. COLUP2-COLUP5 and NUSIZ2-NUSIZ5 correspond to sprites 2-5. For sprite 1, use _COLUP1 and _NUSIZ1. Although these look like TIA registers, they are not; they point to the 2600's RAM. The actual TIA registers COLUP1 and NUSIZ1 can be set but they will probably have no effect in the multisprite kernel.

Also, although the multisprite kernel doesn't have special variables for REFPx, you can set the reflection bit for each individual sprite by using bit 3 of _NUSIZ1 or NUSIZ2-NUSIZ5, as this bit is unused by the TIA register NUSIZx.

Note that missile 1 may be affected by any of sprite 1-5's NUSIZx and COLUPx values depending on where it is located.

Some versions of the bB multisprite kernel require player0 to be defined each time you go through the loop, so try defining player0 outside the loop first, and if that doesn't work then move it inside the loop.

If you'd like to use more than 4k with the multisprite kernel, the first line of your program should be "includesfile multisprite_bankswitch.inc". Here's an example of the proper order that you should use:

   includesfile multisprite_bankswitch.inc
   set kernel multisprite
   set romsize 8k

If you'd like to use Superchip RAM with the multisprite kernel, the first line of your program should be "includesfile multisprite_superchip.inc". Here's an example of the proper order that you should use:

   includesfile multisprite_superchip.inc
   set kernel multisprite
   set romsize 32kSC

   const screenheight = 80

Minikernels/HUDs

Minikernels are a new feature of bB that allows for further customization of your game. Minikernels are intended for use as a HUD (Heads-up Display), which is the part of the game that shows lives, health, status, time, etc.

The HUDs go just below the bB screen but above the score. The minikernels that display the HUDs are totally modular, can be used in most any bB program, and will not take anything away from the visible screen (unless you choose to.)

   inline 6lives.asm

   inline 6lives_statusbar.asm

   lives:
   %01000100
   %11111110
   %11111110
   %01111100
   %00111000
   %00010000
   %00010000
   %00010000
end

   dim lives_centered = 1
   dim lives_compact = 1

   if lives < 32 then ....

   if lives > 223 then ...

   dim statusbarcolor = t

   statusbarcolor = $1C

   if ((<*+(code_length-minikernel)) > (<*))
   align 256
   endif
minikernel
   ... your code ...
code_length

Additional Kernels, Minikernels, Modules and Enhancements

This section has links to useful kernels, minikernels. modules and enhancements. Use them at your own risk. If you know about other helpful additions to bB that are not listed here, please contact Random Terrain at AtariAge. Thanks.

smartbranching

tv

romsize

optimization

kernel

kernel_options

debug

legacy

smartbranching

The smartbranching directive tells the compiler to generate optimal assembly code when it encounters an if…then statement with a line number or label after the then. Smartbranching is set to off by default, because this makes the generated assembly code easier for a human to read and understand.

Normally, an if…then statement with a line number or label after the then can only jump forward 127 bytes or backwards 128 bytes, so you'd need to use then goto for longer jumps. Thanks to smartbranching, you usually won't have to worry about that. If you set smartbranching on and just use then, the compiler will figure out whether to use then or then goto for you. The drawback to doing this is that the generated assembly file will be much harder for a human to read. If you don't care to see the assembly language that bB generates, however, you should set smartbranching on. Smartbranching will not slow down your program, so you don't have to be afraid to use it.

You can also use then goto all of the time and not have to worry about smartbranching at all, but then goto uses more code space than just then so you should take this into consideration as well. See Branches out of Range for more information. [Note from Random Terrain: I had all kinds of mysterious problems when using smartbranching with a very long program. Switching to then goto fixed all of the weird problems, so I dropped smartbranching. I use then goto instead.]

Warning: Smartbranching will sometimes cause the compilation to fail. In this case, you will need to use then goto instead of just then for the if…then statement that caused the problem.

tv

Specifies the tv format. Valid options are ntsc or pal. ntsc is the default and is unnecessary.

set tv pal will build a game that will run on a PAL television. This format is standard in Europe and Australia, among other places. [This is not recommended. Use PAL-60 instead so your NTSC and PAL game will run at the same speed. ]

Note that the PAL setting only changes the timing and synchronization signals and not the colors. PAL has a different palette than NTSC and some NTSC colors do not have a PAL counterpart, so you will have to select the colors carefully for each format if you intend to create a game for both formats.

It has been discovered that PAL televisions will play NTSC binaries without any problems except different colors. Optionally, you may prefer to create a PAL-60 binary, which uses the NTSC timing but PAL colors. To do so, use the NTSC TV format but specify the colors from the PAL palette.