427 replies to this topic

[Tom]

batari said:

I found a good tutorial on lex/yacc

Probably you actually have flex/bison (the GNU implementations) installed on your system. I think the best tutorials about these are in their manuals. See
http://www.gnu.org/s...are/flex/manual and http://www.gnu.org/s...re/bison/manual

batari said:

That would be great!  The more help I get, the better...

Okay, but not before next weekend. I'm in the army at the moment.

[Cybergoth]

Hi there!

Tom, on Sun Jul 17, 2005 11:06 AM, said:

Okay, but not before next weekend. I'm in the army at the moment.

Uihjah! So did you get one of those:

http://www.victorinox.de/newsite/en/produk...swissmemory.htm

I already own this one:

http://www.victorinox.de/newsite/en/produk...-T/1-7725-T.htm

As soon as there's a merger between the two available, I need to upgrade

Greetings,
Manuel

[Tom]

Cybergoth, on Sun Jul 17, 2005 7:43 AM, said:

Uihjah! So did you get one of those:

No, of course not. These are not Swiss army knives, only what the rest of the world believes to be Swiss army knives. Also, "officer's" knives don't exist. Everybody has the same kind of knife, regardless of his rank.

That knife is, btw, pretty much useless. It has a blade which is too small to cut bread (we usually used the bajonet for that), a can opener (which you don't need, because you don't want to eat the canned meat they, fortunately only rarely, give you), something that can - maybe - be used to poke holes, and something that looks like a large screwdriver and which I used to clean the pipe's head (I don't smoke pipe anymore).

The only positive thing about the real Swiss army knive is that it doesn't come in that cheesy red but is chrome colored.

Personally I own a Cybertool aswell. It was a gift, I wouldn't have bought one myself. I mostly use it for its screwdrivers, but real screwdrivers with round handles are just better.

[bliprob]

I am having trouble with reverse loops. The code below is a loop that DIDN'T work, and (I think) the logic is fine, but it doesn't work. (Note: the initial value of z is 4.)

 for x = z to 1 step -1
    y = x + 1
    a[y] = a[x]
    v = x + 10
    y = v + 1
    a[y] = a[v]
 next

I later wrote the same loop as an if/then version of the same thing, and it does work:

 x = z + 1
loopstart rem 
 x = x - 1
 y = x + 1
 a[y] = a[x]
 v = x + 10
 y = v + 1
 a[y] = a[v]
 if x > 1 then goto loopstart

At some point I'll check out the assembly and see what's up, but for now, I'm just glad it's finally working. I was banging my head against that wall for hours yesterday.

[s0c7]

Ok... well.... gotta say this is very cool. Kudos to batari for a fine job. For a alpha release this thing is very usable.

Here's my first attempt at a game. It's not done yet, but it's playable. It may be a while before I can pick it back up, so I thought I'd share. I commented it as best I could and time would allow. Hopefully it may help somebody just starting. I tried to keep it simple.

It's loosely based on the old arcade game Phantom II (check it out in Mame if you've never played it).

One question - is there any way to tell it to only scroll a certain portion of the screen without resorting to inline asm? Remove the REM on line 80 to see what I'm talking about. It scrolls down into the score.

** update 7/19 ** - go to post 320 to get the latest version.

Attached Thumbnails

• 

Edited by s0c7, Tue Jul 19, 2005 9:12 PM.

[batari]

bliprob, on Sun Jul 17, 2005 12:28 PM, said:

I am having trouble with reverse loops. The code below is a loop that DIDN'T work, and (I think) the logic is fine, but it doesn't work. (Note: the initial value of z is 4.)

 for x = z to 1 step -1
 next

I later wrote the same loop as an if/then version of the same thing, and it does work:

 x = z + 1
loopstart rem 
 x = x - 1
 if x > 1 then goto loopstart

The two loops aren't exactly the same, in that if x>1 at the end would work the same as for x=z to 2 step -1.

But reverse loops stepping by -1 and ending at 1 is a special case for the compiler, since I thought if a way these could be optimized by saving several bytes. There could be a problem with the optimization. I'll look into this.

[batari]

s0c7, on Sun Jul 17, 2005 1:27 PM, said:

Ok... well.... gotta say this is very cool.  Kudos to batari for a fine job.  For a alpha release this thing is very usable.

Here's my first attempt at a game.  It's not done yet, but it's playable.  It may be a while before I can pick it back up, so I thought I'd share.  I commented it as best I could and time would allow.  Hopefully it may help somebody just starting.  I tried to keep it simple.

It's loosely based on the old arcade game Phantom II (check it out in Mame if you've never played it).

One question - is there any way to tell it to only scroll a certain portion of the screen without resorting to inline asm?  Remove the REM on line 80 to see what I'm talking about.  It scrolls down into the score.

I could allow scrolling of part of the screen fairly easily in the next release. pfscroll left, for instance would work the same but pfscroll left 4 7 could scroll just lines 4-7. It might take a week or two to get Alpha 0.3 out since I plan to use lex/flex to help with parsing/error detection.

[bliprob]

Fred -- Thanks for Batari basic! I never would have done any of this if not for your basic.

Here's a screenshot of my game in progress. It uses:

- an array for the worm segment coordinates
- for... next loops to iterate the array and erase/draw the segments with PF blocks
- of course, labels instead of line numbers

I've got to spend some time on collision detection and figuring out why my PF blocks sometimes turn off without warning... but overall it's coming along nicely. It's already kind of fun to play.

[vdub_bobby]

bliprob, on Mon Jul 18, 2005 1:50 PM, said:

Here's a screenshot of my game in progress. It uses:

- an array for the worm segment coordinates
- for... next loops to iterate the array and erase/draw the segments with PF blocks
- of course, labels instead of line numbers

I've got to spend some time on collision detection and figuring out why my PF blocks sometimes turn off without warning... but overall it's coming along nicely. It's already kind of fun to play.

Nice mushroom sprite.

[kisrael]

Heh. Once Batari BASIC settles down, I think a total revamp of 2600101 is in order. Or maybe just making 2600101: bB edition

Actually I wouldn't be surprised if there might be a "compeition" for making the best documentation and tutorials. It's an easy way of getting a bit of glory, riding Batari's coattails :-)

[potatohead]

kisrael, on Mon Jul 18, 2005 5:46 PM, said:

Heh. Once Batari BASIC settles down, I think a total revamp of 2600101 is in order. Or maybe just making 2600101: bB edition

Actually I wouldn't be surprised if there might be a "compeition" for making the best documentation and tutorials.  It's an easy way of getting a bit of glory, riding Batari's coattails :-)

Hehe, I'm up for that (in a few more days that is.)

Quick note on the revamp. I think a Bb version is the right thing to do, one can transition from pure basic to inline assembly to assembly tweaks. At that point, they are teed up for the 2600 101 course as presented.

[bluetriforce]

I am looking for a beginner tutorial for this Atari 2600 Basic compiler.

[batari]

bluetriforce, on Tue Jul 19, 2005 12:46 AM, said:

I am looking for a beginner tutorial for this Atari 2600 Basic compiler. 

No beginner tutorial exists, but the documentation available at the home page is accumulating. Sooner or later someone will write one, I'm sure

[batari]

s0c7, on Sun Jul 17, 2005 1:27 PM, said:

Ok... well.... gotta say this is very cool.  Kudos to batari for a fine job.  For a alpha release this thing is very usable.

Here's my first attempt at a game.  It's not done yet, but it's playable.  It may be a while before I can pick it back up, so I thought I'd share.  I commented it as best I could and time would allow.  Hopefully it may help somebody just starting.  I tried to keep it simple.

It's loosely based on the old arcade game Phantom II (check it out in Mame if you've never played it).

One question - is there any way to tell it to only scroll a certain portion of the screen without resorting to inline asm?  Remove the REM on line 80 to see what I'm talking about.  It scrolls down into the score.

Just got a chance to look at your code... I think I answered the wrong question before, as the scrolling into the score was a bug in Alpha 0.1. This has been fixed in Alpha 0.2, so removing the rem in line 80 scrolls properly. The code needed to be fixed up a bit to compile in Alpha 0.2, since inline asm needs to be indented now.

[Jess Ragan]

This is pretty sweet stuff! Here's to hoping the language becomes more complex with time.

JR

[attendo]

Hey Batari,

I think most people are downloading the old version of Batari, 2600basic.zip, because it is posted above the new version: batari_basic_alpha2.zip

Could you perhaps change it? also a little bit because my ide doesnt work with the files in 2600basic.zip and needs the latest version..

2600basic.zip ( 110.9k ) Number of downloads: 173 <---
batari_basic_alpha2.zip ( 148.74k ) Number of downloads: 10

greets

[Jess Ragan]

All rightie... what am I doing wrong with this? I'm trying to create a simple program with perpetual movement for the character... in other words, pressing the joystick in one direction causes the character to continue to move in that direction even after the joystick is released. It's very closely based on the sample.bas program included with the compiler, yet I can't get it to compile at all.

1 rem smartbranching on
10 x = 40 : y = 40 : v = 0 : w= -1
30 COLUPF = 40
40 COLUP0 = 80 : player0x = x : player0y = y
50 scorecolor = 20
60 player0:
 %00011000
 %00011000
 %00011000
 %10111101
 %11111111
 %11011011
 %10011001
 %10000001
end
70 if joy0up then v = 0 : w = -1
80 if joy0down then v = 0 : w = 1
90 if joy0left then v = -1 : w = 0
100 if joy0right then v = 1 : w = 0
110 x = x + v : y = y + w
120 player0x = x : player0y = y
130 drawscreen
140 goto 40

Must a second player be defined, even if you're not using one? I tried creating a second player, but it didn't help at all.

While I'm here, I may as well ask... is it possible to create conditional shapes for the players, thereby creating animation? For instance, could this be done?

30 if a = 0 then player0:
%00111100
%01000010
%10000001
%10000001
%10000001
%10000001
%01000010
%00111100

40 if a = 1 then player0:
%00111100
%01000010
%10011001
%10111101
%10111101
%10011001
%01000010
%00111100

JR

[potatohead]

Try this:

1 rem smartbranching on

Init section of code to be executed one time

10 x = 40 : y = 40 : v = 0 : w= -1

Display loop -- set up variables for use each time the screen is drawn 60x / second NTSC
Keep things to a minimum here, only those things that matter for the screen display.

30 COLUPF = 40
40 COLUP0 = 80 : player0x = x : player0y = y
50 scorecolor = 20
60 player0:
 %00011000
 %00011000
 %00011000
 %10111101
 %11111111
 %11011011
 %10011001
 %10000001
end
65 drawscreen

Game logic.  This is where you have the most time to get other things done.

70 if joy0up then v = 0 : w = -1
80 if joy0down then v = 0 : w = 1
90 if joy0left then v = -1 : w = 0
100 if joy0right then v = 1 : w = 0
110 x = x + v : y = y + w
140 goto 30 

Quote

Must a second player be defined, even if you're not using one?  I tried creating a second player, but it didn't help at all.

Have not tried this. If the above does not work, throw in a second player definition and let us know if that changed things.

Quote

While I'm here, I may as well ask... is it possible to create conditional shapes for the players, thereby creating animation?  For instance, could this be done?

See my animation demo earlier in this thread. I didn't try it this way, but the way I did it worked great.

I found negative numbers to be a little goofy. Because all the variables are unsigned 8 bit numbers, adding 255 is just like subtracting 1. eg:

v = -1 <--- Might need a space between the "-" and the 1?

a = a + v

is the same as:

v = 255
a = a + v

Edited by potatohead, Tue Jul 19, 2005 7:52 AM.

[kisrael]

potatohead, on Mon Jul 18, 2005 9:16 PM, said:

kisrael, on Mon Jul 18, 2005 5:46 PM, said:

Heh. Once Batari BASIC settles down, I think a total revamp of 2600101 is in order. Or maybe just making 2600101: bB edition

Actually I wouldn't be surprised if there might be a "compeition" for making the best documentation and tutorials.  It's an easy way of getting a bit of glory, riding Batari's coattails :-)

Hehe, I'm up for that (in a few more days that is.)

Quick note on the revamp. I think a Bb version is the right thing to do, one can transition from pure basic to inline assembly to assembly tweaks. At that point, they are teed up for the 2600 101 course as presented.

Well, I dunno. I'd like a bB (btw, I like "bB" because batari sometimes has his first initial lowercase while BASIC is often capitalized, it doesn't look like the music note "B-flat". Though it does look a bit like a Scion car name) version to build up a theoretical knowledge. It has too many seemingly-arbitrary restrictions that won't make sense unless you understand some of the theoreticals...at least stuff like having 2 players, 2 missiles, etc.

You know, since most of this stuff is Creative Commons liscenced (even where it's not explicitly said that seems to be the underlying assumption) I wonder if something collaborative would make sense. I know some people are big fans of Wikis for this kind of thing, though personally I don't trust 'em, both because of possible future mean spirited tampering, and then just because I think people like to point to things and say "I Did That!" , and that ego-boost is a bit of a spur-on.

On the other hand, one thing is bB might be going some major changes. I wouldn't want to teach line numbers (or show useful workarounds for 'em) if they might become optional...

I wonder how big this thread would have to get and how mature bB would have to be before we could make a pitch to Al that it should have its own forum. (Actually, Al mentioned to me that this thread kind of isn't in the wrong place, the Newbie Forum was more meant to be for Davie's tutorials and discussion about that, not about Newbies in general. He doesn't mind it being here or anything, though personally it seems like a lot of clicks to get here sometimes...)

Edited by kisrael, Tue Jul 19, 2005 10:03 AM.

[potatohead]

kisrael, on Tue Jul 19, 2005 10:34 AM, said:

potatohead, on Mon Jul 18, 2005 9:16 PM, said:

kisrael, on Mon Jul 18, 2005 5:46 PM, said:

Heh. Once Batari BASIC settles down, I think a total revamp of 2600101 is in order. Or maybe just making 2600101: bB edition

Actually I wouldn't be surprised if there might be a "compeition" for making the best documentation and tutorials.  It's an easy way of getting a bit of glory, riding Batari's coattails :-)

Hehe, I'm up for that (in a few more days that is.)

Quick note on the revamp. I think a Bb version is the right thing to do, one can transition from pure basic to inline assembly to assembly tweaks. At that point, they are teed up for the 2600 101 course as presented.

Well, I dunno. I'd like a bB (btw, I like "bB" because batari sometimes has his first initial lowercase while BASIC is often capitalized, it doesn't look like the music note "B-flat". Though it does look a bit like a Scion car name) version to build up a theoretical knowledge. It has too many seemingly-arbitrary restrictions that won't make sense unless you understand some of the theoreticals...at least stuff like having 2 players, 2 missiles, etc.

You know, since most of this stuff is Creative Commons liscenced (even where it's not explicitly said that seems to be the underlying assumption) I wonder if something collaborative would make sense. I know some people are big fans of Wikis for this kind of thing, though personally I don't trust 'em, both because of possible future mean spirited tampering, and then just because I think people like to point to things and say "I Did That!" , and that ego-boost is a bit of a spur-on.

On the other hand, one thing is bB might be going some major changes. I wouldn't want to teach line numbers (or show useful workarounds for 'em) if they might become optional...

I wonder how big this thread would have to get and how mature bB would have to be before we could make a pitch to Al that it should have its own forum. (Actually, Al mentioned to me that this thread kind of isn't in the wrong place, the Newbie Forum was more meant to be for Davie's tutorials and discussion about that, not about Newbies in general. He doesn't mind it being here or anything, though personally it seems like a lot of clicks to get here sometimes...)

I'm not worried about number of clicks at this point. Though you are right, others are. In a way, the out of the way nature of this thread is appropriate. We've got a few folks plugging away on enough projects to catch the bugs that really matter and keep proposed changes to a minimum. That's one fear of mine --people will want too much. Much better to have the commands necessary to take full advantage of the kernel, but not so many that things get away from the simple combinations of logic and timing that will be important later on...

Of course, that last bit is a guess on my part but I think I'm right about it.

Once we get through this next alpha, I'm going to throw a link or two on my home blog and spread the word a little bit more.

....it's own forum....

I like this idea. The stuff people will need can be put into stickys and Atariage is a fine community otherwise. I hope bigger things will happen and we see lots of game concepts tossed about here. That part of things will be fun for everyone involved, particularly if the habit of code sharing continues!

Someday, when 7800 development is farther along and the emulator issues are more precisely ironed out, I think this language would shine brightly there. Still have the 2600 feel, but enough capability and colors to make very interesting games accessable to a greater number of folks. Having something so simple, yet with a lot of speed really is unique in this age of huge API's and complex machines. Sometimes the game gets lost in all of that, IMHO.

I like the forum interface actually. I'm having to setup a community site, for something completely unrelated. This forum, combined with a nice blog really does the community thing right. Much more accessable than the usual combination of wiki, mailing list, cvs, web pages, etc... (I'm perfectly happy with those things, but somehow they seem wrong for something like this.)

From a documentation standpoint, the forum has the advantage of being able to quickly format bits and pieces, then tie them together later on as was done with the 2600 101 stuff. The disadvantage is the same formatting makes hard copies & packages difficult in the duplication necessary to package it all up.



Guess it all comes down to what people gravitate to. It will be interesting to see how that unfolds.

[kisrael]

Personally I find it challenging to extract the latest and greatest of everything from a forum (hence my request for email) -- even using that "paperclip view" back on the forumlist page.

[potatohead]

kisrael, on Tue Jul 19, 2005 11:55 AM, said:

Personally I find it challenging to extract the latest and greatest of everything from a forum (hence my request for email) -- even using that "paperclip view" back on the forumlist page.

When I get a chance to do some stuff again, I'll be sure and shoot you e-mail. That *is* tough, if you don't have a lot of time...

[s0c7]

batari, on Tue Jul 19, 2005 3:29 AM, said:

Just got a chance to look at your code... I think I answered the wrong question before, as the scrolling into the score was a bug in Alpha 0.1.  This has been fixed in Alpha 0.2, so removing the rem in line 80 scrolls properly.  The code needed to be fixed up a bit to compile in Alpha 0.2, since inline asm needs to be indented now.

Ok, thanks for looking at it. Just d/l'd the latest, greatest and yes that did fix my scrolling issue. Was going to stick in another couple of quick changes and post a new source, but I've run into another issue. I can't get score to decrement properly. score = score - 1 yields 67.

Just to see if it was my program, I changed the following lines in your sample.bas

60 if joy0up then score = score + 1
80 if joy0down then score = score - 1

Hit up a couple of times, then hit down.

[batari]

Jess Ragan, on Tue Jul 19, 2005 7:40 AM, said:

All rightie... what am I doing wrong with this?  I'm trying to create a simple program with perpetual movement for the character... in other words, pressing the joystick in one direction causes the character to continue to move in that direction even after the joystick is released.  It's very closely based on the sample.bas program included with the compiler, yet I can't get it to compile at all.

1 rem smartbranching on
10 x = 40 : y = 40 : v = 0 : w= -1
...
70 if joy0up then v = 0 : w = -1
...
90 if joy0left then v = -1 : w = 0

Yep, Potatohead is right - the compiler currently doesn't like -1. Just replace -1 with 255, and it will compile and work how you want it to. No need to define player 1.

Edited by batari, Tue Jul 19, 2005 2:04 PM.

[batari]

attendo, on Tue Jul 19, 2005 6:50 AM, said:

Could you perhaps change it? also a little bit because my ide doesnt work with the files in 2600basic.zip and needs the latest version..

2600basic.zip ( 110.9k ) Number of downloads: 173 <---
batari_basic_alpha2.zip ( 148.74k ) Number of downloads: 10

Yeah, it doesn't make much sense to continue to have Alpha 0.1 there, so I removed the file.