Atari 2600 BASIC compiler is here!

[Thomas Jentzsch]

The dot is used for local labels. A new local area is started with the keyword SUBROUTINE.

If you use the dot for a label name, you can reuse the same label in a different local area.

If you define a label with a dot, you must use the dot when refering to that label.

 

BTW: I still don't understand why you use line numbers. Only ancient languages but no modern language use them. Because they are unflexible and/or mostly superfluous. Labels are much better and the code is much more readable, because you immediately see the jump targets.

[+batari]

BTW: I still don't understand why you use line numbers. Only ancient languages but no modern language use them. Because they are unflexible and/or mostly superfluous. Labels are much better and the code is much more readable, because you immediately see the jump targets.

890825[/snapback]

It was easier to code. In alpha 0.2 (should be done in a few days) the line numbers are optional, but you still need to use numbers instead of alphanumeric labels. Sooner or later I'll fix this too, but it probably won't happen until the parser can tell a keyword from a label.

[Thomas Jentzsch]

Sooner or later I'll fix this too, but it probably won't happen until the parser can tell a keyword from a label.

Easy. Everything that starts at column 0 is a label (unless it's a comment).

[attendo]

Ok, the Batari BASIC homepage has been updated:

 

* replaced working_game with ooze (at some point I'll probably stop including so much source inline)

* addeded 2600IDE and description

* added link to this forum

* added Potatohead's Batari User's Guide, plus an HTML port ofit

890753[/snapback]

 

Really great!

 

Could you perhaps also tell new users to put 2600IDE in the same directory as 2600bas.exe? I know that should be obvious but just in case. thanks.

[+batari]

Sooner or later I'll fix this too, but it probably won't happen until the parser can tell a keyword from a label.

Easy. Everything that starts at column 0 is a label (unless it's a comment).

890840[/snapback]

The problem is not what happens at the beginning of the line, but after a "then."

 

e.g.:

if x=4 then 200

if x=4 then player0x=20

 

Right now it looks for a number after a then and assumes it's a branch, otherwise it evaluates the statement.

 

But if we allow alphanumeric labels, we might get:

 

if x=4 then myroutine

 

It's quite a bit harder to know whether player0x or myroutine is a label or a statement, so I'm going to need a formal parser that recognizes valid tokens and assumes anything not found is a label. it also requires that I keep track of any new variables that are defined in the current program and maybe make multiple passes.

 

I could solve the problem by requiring something like this:

 

if x=4 then .myroutine

 

that is, allowing numbers, or if not a number, then a "." before the label. I'll probably end up doing something like this.

[Thomas Jentzsch]

The problem is not what happens at the beginning of the line, but after a "then."

How about "if then" and "if (then) goto"?

[kisrael]

Ok, the Batari BASIC homepage has been updated:

 

* replaced working_game with ooze (at some point I'll probably stop including so much source inline)

* addeded 2600IDE and description

* added link to this forum

* added Potatohead's Batari User's Guide, plus an HTML port ofit

 

Doug "Potatohead" Dingus. Hehe, guess I asked for that! I've used potatohead all over the place because it's almost never taken. Not to worry, I think it's funny! Once 'Dingus' becomes a factor, the name mangling can easily get far worse !! Nice update. If people come wandering by, it looks a lot more like something realistic than it did at first. --thanks!

Hehe. Well, betwee Fred "Mayor" Quimby, the lovely alliteration of Doug Dingus, and Kirk "not jewish, not that it matters" Israel, we're firing on all cylinders on the name front. (And I myself tend to heads of pumpkin-proportions, rather than potato)

 

ANYWAY. Thanks for the comment on the website. Actually, the most stinging remark was from one of my buddies from New England Classic Gamers who said "dude, it looks like a damn man page". That's when I started adding screenshots...

[+batari]

The problem is not what happens at the beginning of the line, but after a "then."

How about "if then" and "if (then) goto"?

890856[/snapback]

The goto is not a problem - there's currently no checking needed after a goto to see if it's a linenumber or not.

 

Perhaps there's a better way to solve the problem, like do a first pass that just grabs all of the labels and records them in a buffer. Then after a "then" it searches for these labels and if there is no match, then it's a statement. This should be easy enough to do. Maybe I'll go ahead and add this and see if it works.

[kisrael]

]The problem is not what happens at the beginning of the line, but after a "then."

 

e.g.:

if x=4 then 200

if x=4 then player0x=20

 

Right now it looks for a number after a then and assumes it's a branch, otherwise it evaluates the statement.

 

But if we allow alphanumeric labels, we might get:

 

if x=4 then myroutine

 

It's quite a bit harder to know whether player0x or myroutine is a label or a statement, so I'm going to need a formal parser that recognizes valid tokens and assumes anything not found is a label.  it also requires that I keep track of any new variables that are defined in the current program and maybe make multiple passes.

 

I could solve the problem by requiring something like this:

 

if x=4 then .myroutine

 

that is, allowing numbers, or if not a number, then a "." before the label.  I'll probably end up doing something like this.

I'd MUCH rather have a rule saying "you must include goto" than "you must include a dot"

 

ALso, In terms of variables, it's not uncommon to insist that all variables be predeclared before any "real" program code head. I think that's a reasonable restriction, and nicer than adding a new syntax element w/ the dot, and means you dont have to do multiple passes.

 

I'd really personally prefer the dot be a last resort and other options tried first.

Edited July 13, 2005 by kisrael

[kisrael]

Really great!

 

Could you perhaps also tell new users to put 2600IDE in the same directory as 2600bas.exe? I know that should be obvious but just in case. thanks.

890847[/snapback]

Ok, done.

 

Actually isn't it supposed to work with z26, or not? I pointed it it to z26, but I always get "file not found...untitled.bin"

 

also, sometimes programs like this open up the last edited program, that's often useful

 

and you really shouldn't have a "clear clipboard" option...no other program does it so it's a little confusion, and who cares about a bit of text stuck in the clipboard anyway?

[+batari]

ALso, In terms of variables, it's not uncommon to insist that all variables be predeclared before any "real" program code head.  I think that's a reasonable restriction, and nicer than adding a new syntax element w/ the dot, and means you dont have to do multiple passes.

 

I'd really personally prefer the dot be a last resort and other options tried first.

890868[/snapback]

OK, I won't bother with the dot, then. You'll know soon enough if my plan above works. Requires 2 passes, but the first pass only grabs the first column, and only if something is there...

[JLsoft]

Erm...am I doing something totally wrong, or is using 'off' with PFPIXEL not working, and instead doing the same thing as the 'flip' action?

 

10 rem smartbranching on
20 COLUPF = 200
30 x = rand
40 if x > 250 then pfpixel 0 5 on
50 pfscroll right
60 pfpixel 15 5 off
70 drawscreen
80 goto 30

 

This is just plotting a playfield pixel, scrolling the screen to the right, and attempting to turn off any playfield pixels as they reach halfway across the screen, but what that line 60 is actually doing is reversing the status of the playfield pixel there, not setting them to 'off' no matter what...

[Dan Iacovelli]

Really great!

 

Could you perhaps also tell new users to put 2600IDE in the same directory as 2600bas.exe? I know that should be obvious but just in case. thanks.

890847[/snapback]

Ok, done.

 

Actually isn't it supposed to work with z26, or not? I pointed it it to z26, but I always get "file not found...untitled.bin"

 

also, sometimes programs like this open up the last edited program, that's often useful

 

and you really shouldn't have a "clear clipboard" option...no other program does it so it's a little confusion, and who cares about a bit of text stuck in the clipboard anyway?

890870[/snapback]

 

I got it working with Z26

(I caved in and got my copy of z26 from my other computer)

[vdub_bobby]

To do this in assembly:

1400 if a > 8 then a = 8
1410 if b > 8 then b = 8
1420 if c > 8 then c = 8
1430 if d > 8 then d = 8
1440 if e > 8 then e = 8

Try this:

   ldx #4
Loop
  lda a,X
  cmp #9
  bcc NoChange
  lda #8
  sta a,X
NoChange
  dex
  bpl Loop

Though the assembly you posted will work, also.

[potatohead]

Erm...am I doing something totally wrong, or is using 'off' with PFPIXEL not working, and instead doing the same thing as the 'flip' action?

 

10 rem smartbranching on
20 COLUPF = 200
30 x = rand
40 if x > 250 then pfpixel 0 5 on
50 pfscroll right
60 pfpixel 15 5 off
70 drawscreen
80 goto 30

 

This is just plotting a playfield pixel, scrolling the screen to the right, and attempting to turn off any playfield pixels as they reach halfway across the screen, but what that line 60 is actually doing is reversing the status of the playfield pixel there, not setting them to 'off' no matter what...

890873[/snapback]

 

That's known behavior and I think it's on the todo list. I had the same problem...

 

I don't have a good work around, but for some assembly that would zero the 40 playfield ram bytes. If Batari can let us know which 40, a little chunk of asm code will get you through until the pixel fix is in.

[vdub_bobby]

I don't have a good work around, but for some assembly that would zero the 40 playfield ram bytes.  If Batari can let us know which 40, a little chunk of asm code will get you through until the pixel fix is in.

890945[/snapback]

If you look in 2600basic.h you can see where all the variables are assigned.

 

For the playfield:

playfield = $A4 ; $A4-$D3 = 48 bytes

EDIT: And regardless of where they are, notice that the RAM bytes are helpfully labelled, "playfield."

 

So a little asm like this would clear the entire PF:

   ldx #47
  lda #0
Loop
  sta playfield,X
  dex
  bpl Loop

Edited July 13, 2005 by vdub_bobby

[bliprob]

This may not interest most of you, but I've made a Mac OS X compilation of 2600bas and written a shell script (like the bat file) that performs the necessary compiling/concatenating/assmbling for a final output.

 

You may need to "chmod a+x 2600basic.sh" to make the shell script execute.

2600basic_mac.zip

[Thomas Jentzsch]

The goto is not a problem - there's currently no checking needed after a goto to see if it's a linenumber or not.

But after a 'goto' there can only be a label, never a statement. I still don't see the problem.

 

Perhaps there's a better way to solve the problem, like do a first pass that just grabs all of the labels and records them in a buffer.  Then after a "then" it searches for these labels and if there is no match, then it's a statement.  This should be easy enough to do.  Maybe I'll go ahead and add this and see if it works.

Sure, that's a good way anyway.

 

Regarding complex expressions: One way to define those expressions, is using BNF. And the implementation is done by using a state machine. Pretty straightforward, flexibel and robust once you got the idea.

[potatohead]

I'd MUCH rather have a rule saying "you must include goto" than "you must include a dot"

 

ALso, In terms of variables, it's not uncommon to insist that all variables be predeclared before any "real" program code head.  I think that's a reasonable restriction, and nicer than adding a new syntax element w/ the dot, and means you dont have to do multiple passes.

 

I'd really personally prefer the dot be a last resort and other options tried first.

890868[/snapback]

 

I'll second that.

 

Being able to write this sans line numbers will be nice, particularly for the cut ' paste lines required sometimes.

 

One other comment along these lines, we should keep language tweaks and discussions limited in scope as to preserve existing syntax with an eye on scaling for other platforms in the future. (Someday I many seriously want to put this on a 7800 --but will have to write a kernel. I'm sure others will start kicking around the same things, once a real project or two gets done on this thing.) I really don't have major preferences (and it's not my basic!) for little things one way or the other, but just want to keep an eye on scaling. If it scales, it's the right way to get it done, IMHO.

 

Most of it, as it currently is, will do just fine in larger environments. Some worries:

 

the a[x] syntax to index vars is good for the var names we have now, but won't scale to more loosely defined ones. I read on the Stella list (very big and interesting time sink, BTW) last night about keeping the letters internally while allowing users to come up with their own names. If possible, I think somehow keeping this structure, while allowing for more than 26 vars, will be considered extra effort at this point, but effort that will pay off nicely down the road because of the ability to index and the inline assembly advantages.

 

Being able to just call out the variables used is huge where new assembly programmers is concerned. As most of the messy details, normally associated with assembly are kept off the table, the first time (or returning in my case) assembly language programmer can focus on the logic problem to be solved with few other worries. Not having to preserve registers, but the stack, is a big plus too.

 

That does raise some other questions / choices though.

 

(How code might look with the proposed rule changes.)

 

if something then goto jump_over_assembly
a = a + 2
asm 
lda a
cmp #$04
bne somewhere
sta b
somewhere
end
jump_over_assembly
pfpixel a 4 on

 

This is a lot less readable to newcomers, IMHO, than this might be:

 

10 if something then 40
20 a = a + 2
30 asm 
lda a
cmp #$04
bne somewhere
sta b
somewhere
end
40 pfpixel a 4 on 

 

One suggestion that comes to mind is to allow blank lines as well without having to declare them a comment. With or without line numbers, this really helps to break things into nice little chunks.

 

; this is the first chunk of code
if something then goto jump_over_assembly
a = a + 2

; inline assembly for doing magic 
asm 
lda a
cmp #$04
bne somewhere
sta b
somewhere
end

; this is the third chunk of code
jump_over_assembly
pfpixel a 4 on

 

I like the last example best for readability. Thoughts?

Edited July 13, 2005 by potatohead

[potatohead]

I don't have a good work around, but for some assembly that would zero the 40 playfield ram bytes.  If Batari can let us know which 40, a little chunk of asm code will get you through until the pixel fix is in.

890945[/snapback]

If you look in 2600basic.h you can see where all the variables are assigned.

 

For the playfield:

playfield = $A4 ; $A4-$D3 = 48 bytes

EDIT: And regardless of where they are, notice that the RAM bytes are helpfully labelled, "playfield."

 

So a little asm like this would clear the entire PF:

   ldx #47
  lda #0
Loop
  sta playfield,X
  dex
  bpl Loop

890952[/snapback]

 

 

Nice! Of course that all makes perfect sense. I'm a little loopy this morning. Thanks for nudging me in the right direction for those kinds of questions. Still thinking way inside the box...

[Serguei2]

Will the next 2600 basic support score1(player 1), score2(player2) and a ball and put the scores everywhere on the screen?

[+batari]

Regarding complex expressions: One way to define those expressions, is using BNF. And the implementation is done by using a state machine. Pretty straightforward, flexibel and robust once you got the idea.

890982[/snapback]

Yeah, I'm currently working on mapping out a parse tree for everything which is going to just be a huge state machine, or DFA to CS geeks. Not in the next release though - maybe in a few months. But a DFA should make it easier to make further optimizations too.

[+batari]

Will the next 2600 basic support score1(player 1), score2(player2) and a ball and put the scores everywhere on the screen?

890995[/snapback]

Alpha 0.2 won't have the ball... It should be there by Alpha 0.3. Two 6-digit scores can't be done with this kernel because each one requires 15 bytes of RAM that's not available. It might be possible if the scores are 3 digits each. I could allow moving the score too, but it would have to be either at the top or bottom. I'll look into this part... but it probably won't happen in Alpha 0.2 since I hope to get that out really soon.

[vdub_bobby]

Will the next 2600 basic support score1(player 1), score2(player2) and a ball and put the scores everywhere on the screen?

890995[/snapback]

Alpha 0.2 won't have the ball... It should be there by Alpha 0.3. Two 6-digit scores can't be done with this kernel because each one requires 15 bytes of RAM that's not available. It might be possible if the scores are 3 digits each. I could allow moving the score too, but it would have to be either at the top or bottom. I'll look into this part... but it probably won't happen in Alpha 0.2 since I hope to get that out really soon.

891159[/snapback]

A nice compromise might be to support two 6-digit scores in memory and the programmer can choose which one to display. Then it will just cost you 3 bytes of RAM. This could be used for two players or could be used for displaying the current score and displaying the high score (on a title screen, for example). Course, I guess the intrepid programmer could do this already; just reserving 3 of "his" variables for another score and swapping them with the "score" variables as needed.

 

And you could reuse the score 1 graphic pointers for the score 2 graphic pointers. Probably just take a few blank scanlines to recalc the pointers midscreen. You could also reuse the player graphic pointers for the same purpose and save a few bytes.

[yuppicide]

Maybe we could have a 2 player mode where one player controls the ooze somehow.

 

Know what would be awesome?! Once you get this program more polished?!

 

Let's have some source code for a complete game and get one of the classic magazines to put it in their magazine. Sort of like the old Compute! magazines where you typed in C64 games. The article would list what programs you need, where to get them, and have a full source code with documentation.

 

That's not a bad idea! I'm sure a lot of us miss those.

 

That Ooze game has some errors too.. one would be when the ooze gets to the bottom most spot it can goto you cannot shoot it away, yet you can shoot the parts behind it. Pretty cool game. Spice it up a little with some sort of increased difficulty.. or maybe the ooze moving back and fourth or something. Maybe different levels. Slap on an intro screen and slap it into a cartridge and I'll buy one heh.

 

Aw man, now you have my hopes up

 

Well now that I know I've only used 1/3 of the code space avaliable to me, good things can happen. The tough part is getting the order and timing of things right.

 

The problem, you wrote about, happens when a bullet collides with the ooze and the ooze grows at the same time. A left over pixel gets drawn and that stops the bullet from hitting the real ooze pixels higher up on the screen. If you let the ooze come all the way down, you can then knock it back a high percentage of the time. --Things work so *fast*. I'm quickly remembering just why I spent so much time hacking on the old A800.

 

Still working on that one. That's part of why the ooze does not get to the bottom right now.

 

One variation I want to try is the paddle. We are not there yet (I think.) but probably will be. At that point, the ooze can move really fast and in wicked ways, really stressing the player control of the paddle.

 

More ooze is needed too. 5 rows is not enough. That one I know I can fix.

 

Addressing the "it could not be done comments above". Yeah, I was one of those naysayers when I saw this announed on /. My first thought was not enough code space, too few options to make games, slow, buggy, etc...

 

I hopped on here thinking the worst, but decided to give it a try. At first I said, "ok, this is a cool tech demo". But then after futzing around with it for a bit, the real power began to shine. Interestingly, everything I tried worked! The only real downside are the graphical limitations, but those can be powered through with creativitiy, IMHO. I am being honest when I say the issues really are my own. Programming with this is simple, but subtle --just like the 2600, only nicely abstracted.

 

The lack of dual comparisons and case, on goto statements makes some things tough, on the other hand, the compiled code is frugal enough to keep things possible. All in all, it's a lot of fun.

 

Re: updates, where do I send them to? (Use the forum e-mail address?)

890361[/snapback]