what are the limitations of bBasic compared to assembler?

[Scorp.ius]

Hi!

 

I want to make a game on the atari (or better lern how to do that)

 

now i find this batari Basic... i remember on the c64 it was not possible to do fast games with much grafixs with basic an you had to do it in assembler. ok, that basic was an interpreter...

 

but i cant imagine that this basic can do all the things assembler can do, right?

 

so what are the limitations if there are any?

 

thanks for reply

[jbanes]

bBASIC is a compiled language, meaning that it has a similar performance profile to assembly code. Most of bBASIC's limitations are imposed by the limited capabilities of the 2600, combined with a very generic rendering engine, or "kernal" in 2600 programming terminology. Specifically:

• bBASIC uses 102 bytes of the 2600's RAM, leaving you with only 26 variables to work with
  
• The playfield only takes up a portion of the screen. The rest is either bordered with black bars, or is reserved for the 6 digit score.
  
• Using the standard "kernal", only 2 sprites can be shown at a given time. This is a limitation of the 2600 hardware that most custom kernals use tricks to work around. There is an alternate bBASIC kernal that can render many more sprites, but you have to give up the 6 digit score along with a few other features.
  
• The Playfield (the background area) is handled as a low resolution 32x10 grid rather than the high-res 40x192 grid the VCS is capable of.
  
• bBASIC's features cost nearly 2K of ROM space to use. That's nearly half of a standard 4K catridge. (Bankswitching can work around this, but there are limitations to bBASIC's bankswitching abilities.)
  

There are more, but those are probably the biggest limitations. The good news is that bBASIC can be customized with new ASM files and kernals, so you can modify it to meet your needs when you're ready. It also has some really great features that help make up for its limitations:

• Sprites can be absolutely positioned. This is useful, because the 2600 does not directly support absolute positioning.
  
• The playfield is dynamic. In most games, the playfield is pulled from ROM and is thus static.
  
• Various APIs make it easy to handle input, collision detection, and logic routines
  
• Fixed point math, multiplication, and division are fairly well supported
  
• 6 digit scores are difficult to do on the VCS, but come free with bBASIC
  
• Games can be created in very few lines of code
  
• bBASIC is the only useable high-level language supported by the 2600
  

If you want to get a feel for bBASIC's advantages/limitations, check out some of the games in the Homebrew Discussion forum. The bBASIC games are usually marked, and can easily be identified by their distinctive look.

 

Hope this helps!

[SeaGtGruff]

but i cant imagine that this basic can do all the things assembler can do, right?

 

so what are the limitations if there are any?

Some people may disagree with my answers, but here goes...

 

bB can do *all* the things that assembly language can do. How can that be, you may ask? bB is a compiled language, and it compiles into assembly language (which is then assembled into machine code). Furthermore, you could say there's not really that much difference between bB's high-level commands and assembly language "macros"-- i.e., each of bB's commands is sort of like a macro (or really a combination of a macro and a subroutine). And finally, bB uses "include" files that can be customized, or even replaced with entirely new files, plus you can easily incorporate "in-line assembly" directly into a bB program. So what all that means is, if you can do something in a "pure assembly" program, then you can do it in a bB program, too!

 

So what are bB's limitations? Well, in one sense, bB has *no* limitations-- or rather, it has the same limitations that assembly has (especially as dictated by the limitations of the Atari 2600 itself). But in another sense, bB *does* have limitations-- e.g., the "canned" kernels have limitations (although any kernel has limitations which are determined by its design, and bB's "canned" kernels can be replaced by custom kernels); bB program statements might not compile into the most optimized assembly code (although they can be replaced by more highly-optimized in-line assembly code); bB uses a large chunk of precious zero-page RAM for its own purposes (although you can use *all* of zero-page RAM if you don't use any bB commands which use zero-page RAM); and bB's own routines take up a big chunk of the 4K ROM space (although you can control which "include" files get included, thereby reducing the amount of ROM space that's taken up by bB's routines). So when you get down to it, bB's limitations are going to be dictated by whether you're using bB "straight out of the box" without customizing it at all, and by the degree to which you're capable of customizing bB, and also by the degree to which you're able to incorporate in-line assembly code into your bB programs. In short, bB's limitations are largely dependent upon what *your* limitations are as a programmer-- especially with regard to writing 6502 assembly code and exploiting the Atari 2600's capabilities.

 

Now, some people might argue that if you put a bunch of in-line assembly code into a bB program, then it isn't really a bB program, or else it's partly a bB program and partly an assembly program. However, I disagree with that argument, at least on certain levels. For example, bB's "include" files are written in-- you guessed it-- *assembly* language! So whenever you use a bB command, not only is the bB command compiled into assembly code, but part of that may (or may not) involve calling an "included" subroutine that's written in assembly code. So my argument is, what's *really* the difference between using in-line assembly code in a bB program, versus calling a bB "system" routine (like "drawscreen" or "pfpixel") that's written in assembly code? The only *real* difference is that, on the one hand, you can *see* the in-line assembly code inside the bB program listing; and on the other hand, the "included" assembly code is "hidden" from view if your program listing consists of only bB statements.

 

Despite having a number of projects on my plate already, today I decided to begin tinkering on an adventure game along the lines of "Sword of Fargoal," in which the dungeon map is revealed (and stays revealed) as you move through the dark. This may end up being an unfinished project-- more of a "proof of concept" demo, rather than a completed game-- but part of the reason why I decided to do it is to show other people *how* it can be done on the Atari 2600 (in the hopes that they'll write some games of this type so *I* can play them ). And I'm using bB to write it, although I'm having to create my own "include" files. So I'm writing the game in a mixture of bB and assembly, but the assembly code is "hidden" inside of the custom "include" files, and the "visible" program listing (i.e., the ".bas" file) is going to be in pure bB code.

 

I ask you, is this going to be a bB program, or an assembly program? Will it be 90% bB and 10% assembly, or 40% bB and 60% assembly, or what? Really, how can anyone accurately measure the percentage of each, since the custom "include" files will necessarily be written in 100% assembly code (just as bB's normal "include" files are), but the ".bas" program code will be written with 100% bB statements?

 

The "boundaries" between bB and assembly are much more blurred than many people realize! The reason I find bB to be so appealing is that it "hides" the assembly from you, which makes it easy for beginners to get into Atari 2600 programming, yet bB is also customizable and open-ended. If you know very little or nothing about programming the Atari 2600, bB lets you jump right in, and then makes it easy for you to gradually make the transition to pure 6502 assembly at your own pace. And even if you're already an expert at assembly programming on the 2600, you can design your own custom bB "include" files, and then use bB code to slap a game together rather quickly.

 

MR

[Scorp.ius]

aha, as i understand your posting bB is NO dead end as other Basic dialects often are.