Jump to content

Photo

bB Version 1.0 released!


57 replies to this topic

#26 Atarius Maximus OFFLINE  

Atarius Maximus

    Stargunner

  • 1,798 posts
  • Load "Atari2600",8,1: SYS32777
  • Location:St. Louis, Missouri USA

Posted Tue Feb 20, 2007 4:13 PM

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

#27 Gregory DG OFFLINE  

Gregory DG

    TAT IS BACK!

  • 11,209 posts
  • Go Cardinals!
  • Location:Winter Haven, FL

Posted Wed Feb 21, 2007 9:45 AM

Cool. Glad to see it reach a 1.0 stage! I might start designing my Super Bagboy game! :D

#28 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 27,902 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Thu Feb 22, 2007 4:58 PM

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

#29 boutell OFFLINE  

boutell

    Space Invader

  • 17 posts
  • Location:Philadelphia

Posted Mon Feb 26, 2007 1:31 PM

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, Mon Feb 26, 2007 1:33 PM.


#30 atari2600land ONLINE  

atari2600land

    In the name of lvoe.

  • 10,527 posts
  • Shwam.
  • Location:Salem, Oregon

Posted Tue Feb 27, 2007 3:34 PM

Hey, who here does
http://www.atari2600...asic/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...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.

#31 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Sat Mar 29, 2008 11:10 AM

Note that there were some updates to version 1.0 that batari posted in these forums. I think the zipped file that's attached to the following post includes all or most of them...

http://www.atariage....s...t&p=1490744

Michael

#32 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 27,902 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Wed Sep 8, 2010 2:24 AM

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....ew#batari_Basic

Edited by Random Terrain, Wed Sep 8, 2010 2:25 AM.


#33 batari OFFLINE  

batari

    )66]U('=I;B$*

  • Topic Starter
  • 6,645 posts
  • begin 644 contest

Posted Tue Sep 14, 2010 1:33 PM

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....ew#batari_Basic

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

#34 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 27,902 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Sep 14, 2010 4:51 PM

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

OK, thanks.

#35 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Tue Sep 14, 2010 7:27 PM

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....ew#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

#36 esplonky OFFLINE  

esplonky

    Moonsweeper

  • 440 posts
  • Kinetic, Not synthetic.
  • Location:Canyon Lake, TX

Posted Sun Jun 19, 2011 11:32 AM

there should be a BASIC compiler that you can make NES games with, something called "Bintendo BASIC" or something. that would be cool.

#37 ScumSoft OFFLINE  

ScumSoft

    Moonsweeper

  • 373 posts
  • Location:Polysorbate 60

Posted Sun Jun 26, 2011 9:46 PM

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, Sun Jun 26, 2011 9:58 PM.


#38 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 27,902 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sun Jun 26, 2011 9:52 PM

Are you confusing def with const?

#39 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Sun Jun 26, 2011 11:00 PM

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




#40 ScumSoft OFFLINE  

ScumSoft

    Moonsweeper

  • 373 posts
  • Location:Polysorbate 60

Posted Sun Jun 26, 2011 11:07 PM

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!

#41 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 27,902 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Mon Jun 27, 2011 1:11 AM

After having the numbers fixed, if the defs aren't going to change, shouldn't const be used instead? or am I reading the code wrong?

#42 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Mon Jun 27, 2011 1:34 AM

After having the numbers fixed, if the defs aren't going to change, shouldn't const be used instead? or am I reading the code wrong?

In this case, either should work equally well, so it's mainly a matter of preference. Anyway, defs don't change.

Michael

#43 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 27,902 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Mon Jun 27, 2011 2:11 AM

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

#44 ScumSoft OFFLINE  

ScumSoft

    Moonsweeper

  • 373 posts
  • Location:Polysorbate 60

Posted Mon Jun 27, 2011 3:38 AM

Setting them as const actually causes an unknown compiler error, however defs work fine for some unknown reason.

-End of Line

#45 RevEng ONLINE  

RevEng

    River Patroller

  • 4,497 posts
  • Bitnik
  • Location:Canada

Posted Mon Jun 27, 2011 5:41 AM

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.

#46 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 27,902 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Mon Jun 27, 2011 7:35 AM

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, Mon Jun 27, 2011 7:35 AM.


#47 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 27,902 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Mon Jun 27, 2011 3:00 PM

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.

#48 RevEng ONLINE  

RevEng

    River Patroller

  • 4,497 posts
  • Bitnik
  • Location:Canada

Posted Mon Jun 27, 2011 3:50 PM

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.

#49 ScumSoft OFFLINE  

ScumSoft

    Moonsweeper

  • 373 posts
  • Location:Polysorbate 60

Posted Mon Jun 27, 2011 4:07 PM

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.

#50 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Mon Jun 27, 2011 4:17 PM

   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




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users