Jump to content
IGNORED

bB Version 1.0 released!


batari

Recommended Posts

BTW, does anyone regularly use the IDE made by Atarius Maximus?

The bBEditor that Atarius Maximus wrote does have some cool features, but it lacks two things that would make it much more useful-- (1) the ability to invoke the compile batch to compile bB programs from inside the editor, and (2) the ability to invoke an emulator to run the bB program after it's compiled. It should be fairly easy to add those features, but I don't know if Atarius Maximus is still maintaining his bBEditor.

 

Michael

 

I stopped working on it due to an apparent lack of interest in the project. It was adapted from an older project I worked on several years back, so I didn't have to put too much time into it. You're right, it probably wouldn't be too difficult to add in those two features, I'll revisit the code and see what I can do in the coming weeks. I haven't been frequenting the bB forum quite as much the last 7-8 months because of my new job - I have much less time to sneak in web browsing and personal programming time during the work day. ;)

 

Can't wait to try out the new version of bB, it looks great! :cool:

 

Steve

Link to comment
Share on other sites

Atarius Maximus gave me the idea that I should make the latest changes more clear on my version of the bB page, so here is my first shot at it:

 

http://www.randomterrain.com/atari-2600-me...c-commands.html

 

I added an unofficial overview near the top of the page and you might also want to take a look at the Jump List on the right side of the page. I put a yellow background behind links to new sections, commands, directives and options.

 

If anyone has any other ideas to make the page better, please let me know.

 

 

Thanks.

Link to comment
Share on other sites

Congratulations! You have successfully implemented the most frequently-suggested, never-actually-done Atari 2600 thing ever. (:

 

(Um... this is a sincere compliment, in case that's kinda hard to infer! It's a major accomplishment.)

Edited by boutell
Link to comment
Share on other sites

Hey, who here does

http://www.atari2600land.com/basic/index.html ?

 

I have a thing or two I wouldn't mind seeing there... it looks like that site is what I intended to do at http://alienbill.com/2600/basic/home.html -- actually would you consider putting in screenshots? I think it would make the whole thing a lot more fun...

Hi! I just noticed this page being up today. I'm going to download the latest Batari Basic version and play with it a little. As for the site, sure, I'll put some screenshots in.

Check the Batari BASIC game page now. I'm slowly but surely working on a new one.

Link to comment
Share on other sites

  • 1 year later...
  • 2 years later...

The following Wikipedia page says batari Basic was released in 2007. It's true that version 1.0 was released in 2007, but batari Basic was originally released in 2005.

 

http://en.wikipedia.org/wiki/Atari_2600_homebrew#batari_Basic

Edited by Random Terrain
Link to comment
Share on other sites

The following Wikipedia page says batari Basic was released in 2007. It's true that version 1.0 was released in 2007, but batari Basic was originally released in 2005.

 

http://en.wikipedia.org/wiki/Atari_2600_homebrew#batari_Basic

Technically, I think 2007 is correct, as the earlier versions were considered beta builds.

Link to comment
Share on other sites

The following Wikipedia page says batari Basic was released in 2007. It's true that version 1.0 was released in 2007, but batari Basic was originally released in 2005.

 

http://en.wikipedia.org/wiki/Atari_2600_homebrew#batari_Basic

Technically, I think 2007 is correct, as the earlier versions were considered beta builds.

Maybe *you* considered them to be "beta builds," but that didn't stop a bunch of people from grabbing onto those "beta builds" with both hands and starting to create their own games. When was the first "completed" batari Basic game released (as opposed to a demo or a WIP), either on cart or just as a ROM image? Was it before 2007, or after? And considering that I was seeing enthusiastic announcements about batari Basic (or "2600 Basic") on various web sites back when version 0.1 was released in 2005-- not to mention the creation of a forum on AtariAge specifically devoted to it-- I have to vote for 2005. :)

 

Michael

  • Like 1
Link to comment
Share on other sites

  • 9 months later...

I'm wanting to accomplish code like this, however it refuses to compile when anything beside a literal number is in the curly braces:

 

dim direction = a
def North=8
def South=4
def East=2
def West=1

direction = North + West

if direction{West} then goto death
if direction{North} then goto allow_exit else goto refuse_exit

 

It refuses to compile giving error "Value in 'and #256' must be <$100.", however it compiles if I replace North and West with {8} and {1} respectively.

 

Why is this?

 

[edit]Note that what I posted isn't supposed to compile as is, this is just a snippet of the code I wish to use.

[edit2] Forgot to mention I've also tried it with Const, but this also causes compiler errors on the lines in which this test was used.

Edited by ScumSoft
Link to comment
Share on other sites

It's the way you're trying to use them. NORTH is defined as being 8, but then you're trying to use it as the number of a bit. Bit 8 has a value of 256, so that's why the assembler protests.

 

I think what you really want to do is something like this:

 

  dim direction = a

  def North=3
  def South=2
  def East=1
  def West=0

  direction{North} = 1
  direction{West} = 1

  if direction{West} then goto death
  if direction{North} then goto allow_exit else goto refuse_exit

Or you could initialize direction with direction = %1001 or direction = 9.

 

Michael

 

 

 

  • Like 1
Link to comment
Share on other sites

Oh darr!!! I totally overlooked that supposed to be obvious part :P

It compiles fine now.

 

My brain runs on Fuzzy logic, so my reasoning went a little something like this:

Bit 4 is value 8, so set direction value to 8 to check bit 4. :P

 

Thanks for clearing this up for me!

Link to comment
Share on other sites

In this case, either should work equally well, so it's mainly a matter of preference.

I guess I just have it stuck in my head that const is for numbers and def is for more complicated strings.

 

I also had some weird errors when I used a lot of defs, so I use const whenever I need a meaningful replacement for a number. ScumSoft probably isn't using as many defs as I did, so he has nothing to worry about.

 

 

 

Anyway, defs don't change.

Yeah, I worded that wrong. Instead of "if the defs aren't going to change," I should have said, "if he's only using numbers that aren't going to change."

Link to comment
Share on other sites

bB doesn't support using a variable for a bit position check, so when the parser sees non-numerics between the curly braces it throws an error.

 

Const works by defining an assembly symbol with a value, and using the symbol name where specified. If you use a const in curly braces, to the bB parser it looks the same as a variable.

 

Def works by literally substituting every occurrence of the keyword on the left of the "=" with whatever is on the right. This happens before the command parser, so if you use a def in a curly brace, the parser only sees whatever was on the right side of the "=".

 

For those familiar with C or Java, def works conceptually the same as #define.

  • Like 1
Link to comment
Share on other sites

This happens before the command parser, so if you use a def in a curly brace, the parser only sees whatever was on the right side of the "=".

Thanks. I imagined that const was handled in a similar way (everything changed to a number before bB could choke on it).

Edited by Random Terrain
Link to comment
Share on other sites

Speaking of this type of code, is the code that was already posted better:

 

  dim direction = a

  def North=3
  def South=2
  def East=1
  def West=0

  direction{North} = 1
  direction{West} = 1

  if direction{West} then goto death
  if direction{North} then goto allow_exit else goto refuse_exit

 

 

Or is this better:

 

  dim Direction = a

  def North=Direction{3}
  def South=Direction{2}
  def East=Direction{1}
  def West=Direction{0}

  North = 1
  West = 1

  if West then goto death
  if North then goto allow_exit else goto refuse_exit

 

Seems like this first version would make you remember that you're dealing with bits and not full variables.

Link to comment
Share on other sites

Thanks. I imagined that const was handled in a similar way (everything changed to a number before bB could choke on it).

No problem! You can see your "const" symbols being set alongside your "dim" symbols in the "2600basic_variable_redefs.h" file that gets automatically built when you compile your project. bB puts them there so dasm can figure out what those symbols mean when it encounters them in your compiled assembly code.

 

Personally, I think I'm going to start using def instead of const where the two are interchangeable. If you have a large game with a lot of symbols, dasm starts doing weird things with some of them - I personally had it screw up a bunch of constants in my game, and had to hardcode the values instead. Until I figured out what was going on, I wasted a lot of time chasing bugs that weren't there.

 

 

Speaking of this type of code, is the code that was already posted better...

I'd pick the form in the first example where the bits are related - as they are in the the example - but I'd pick the form of the second example when the bits weren't related to each other. If I was worried about forgetting I was dealing with bits, I'd preface the variable names with b_ or something like that.

  • Like 2
Link to comment
Share on other sites

Right, anytime I use a variable to represent multiple things I call it MultiVar, and then assign def Blah=MultiVar{7} and so forth. But when the byte is shared for a single purpose then def direction = a and then North=3 and so forth.

 

This way later on in my code I can do a semi complex check for allowed exits on the screen, and refuse to allow the player to move off the screen if not.

Link to comment
Share on other sites

  dim Direction = a

  def North=Direction{3}
  def South=Direction{2}
  def East=Direction{1}
  def West=Direction{0}

  North = 1
  West = 1

  if West then goto death
  if North then goto allow_exit else goto refuse_exit

I think this form is more consistent with languages that let you define a variable as a BIT or BOOLEAN type, so it's probably the better (i.e., easier to use) method. Of course, with this method you don't need to dim Direction at all, unless you want to be able to refer to the Direction variable in addition to its defined bits. So just use def North=a{3} and so on if you don't plan to refer to Direction by itself.

 

Michael

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

Loading...
  • Recently Browsing   0 members

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