Atari 2600 BASIC compiler is here!

[+batari]

batari,

hope you're cool with the new forum layout, and me writing the "sticky" intro message.

 

Would you like a single (possibly sticky) bug report and/or feature request thread? 

 

I do have a minor bug to report, I didn't yet put together a code sample (but I could), but it seems like on .... goto doesn't work with alphanumeric labels.  Does that seem possible?

895458[/snapback]

No problem with a sticky intro message - It's a great place for a link to your web page where people new to the forum can get the latest version of the software.

 

A separate bug report and feature request thread would be great too, as it will help me improve bB.

 

As for on...goto - I looked into this, and yes, it's a bug. It's an artifact of alpha 0.1 that didn't get updated properly. Well, it actually only checks the first character of a linenumber, so you could use anything as long as the first char was a digit.

 

Another addition to the todo list.

[+Random Terrain]

Is it safe for me to try this yet or are there a lot of new changes around the corner?

[+batari]

Is it safe for me to try this yet or are there a lot of new changes around the corner?

897315[/snapback]

A few improvements and bugfixes are coming soon, but people are making fun games with it now. It doesn't hurt to try it out, since whatever you learn will still be relevant in later versions.

[+Random Terrain]

A few improvements and bugfixes are coming soon, but people are making fun games with it now.  It doesn't hurt to try it out, since whatever you learn will still be relevant in later versions.

897324[/snapback]

OK, thanks. I'm in the mood for trying this, so I'll go ahead and see what happens.

[+Random Terrain]

I haven't read every post in this thread or the other threads in this forum, so I hope this hasn't been asked before.

 

When a program is compiled, does it matter where the game loop is? When I used to make BASIC programs on the VIC-20 and the Commodore 64, it was best to put the game loop at the beginning of the program (the game would run faster). The only thing before the game loop was a jump to a subroutine that was near the end of the program where everything was set up like variables and so on. Since bAtari BASIC is compiled, does it matter where the game loop is?

[kisrael]

I haven't read every post in this thread or the other threads in this forum, so I hope this hasn't been asked before.

 

When a program is compiled, does it matter where the game loop is? When I used to make BASIC programs on the VIC-20 and the Commodore 64, it was best to put the game loop at the beginning of the program (the game would run faster). The only thing before the game loop was a jump to a subroutine that was near the end of the program where everything was set up like variables and so on. Since bAtari BASIC is compiled, does it matter where the game loop is?

I hadn't heard about that "put game loop at the top" trick for the old 8bits. Did it have to do some kind of search thorugh memory for each line or something?

 

Anyway, I don't think the location of the gameloop matters at all. Like most Atari games, it's locked to the tv framerate, so it's very easy to get things to run at a constant 60 fps on an NTSC tv, just so long as you're not doing a HUGE amount of calculation and things are getting messy.

[vdub_bobby]

Does bB support constants? I've looked through the docs and nothing jumped out at me.

 

Something like:

  10 CONSTANT_1 = 40
...
 100 x = CONSTANT_1

 

EDIT: Also, does bB support GOTOing a variable line? (I would imagine not, but thought I'd ask.) As in:

  100 goto h

Edited July 26, 2005 by vdub_bobby

[+Random Terrain]

I hadn't heard about that "put game loop at the top" trick for the old 8bits.  Did it have to do some kind of search through memory for each line or something?

898769[/snapback]

Yeah, the computer has to go through each line, so the closer your game loop was to the beginning, the faster it ran. I think I read that tip in things like Run magazine. I used a stopwatch back then and it really did work.

 

 

 

Anyway, I don't think the location of the gameloop matters at all. Like most Atari games, it's locked to the tv framerate, so it's very easy to get things to run at a constant 60 fps on an NTSC tv, just so long as you're not doing a HUGE amount of calculation and things are getting messy.

898769[/snapback]

Thanks. That's good to know. I can do things in order then.

Edited July 27, 2005 by Random Terrain

[+batari]

Does bB support constants?  I've looked through the docs and nothing jumped out at me.

 

Something like:

  10 CONSTANT_1 = 40
...
 100 x = CONSTANT_1

 

EDIT: Also, does bB support GOTOing a variable line? (I would imagine not, but thought I'd ask.)  As in:

  100 goto h

899078[/snapback]

I tried it with the current build, and constants seem to work if you do this:

10 dim CONSTANT_1=40
100 x=#CONSTANT_1

 

You need the # or it will use memory location 40 instead. This should work in Alpha 0.2 as well, but I have not tested it.

 

goto h will compile, but will jump to the zero page memory location where variable h lives, not the line number that is in h. You should use on...goto instead.

[kisrael]

Does bB support constants?  I've looked through the docs and nothing jumped out at me.

 

Something like:

  10 CONSTANT_1 = 40
...
 100 x = CONSTANT_1

I tried it with the current build, and constants seem to work if you do this:

10 dim CONSTANT_1=40
100 x=#CONSTANT_1

You need the # or it will use memory location 40 instead. This should work in Alpha 0.2 as well, but I have not tested it.

 

Huge feature request...remove the need for the #. Forgetting the # is the cause of SO MANY compiler bugs in "regular" ASM coding, that in something as noob friendly as bB, it will be no end of heartache and grief... and constants can GREATLY improve code readability...

[+Random Terrain]

Labels

 

How long can a label be? What is the limit? I didn't see that in the documentation.

 

 

Thanks.

[+batari]

Huge feature request...remove the need for the #.  Forgetting the # is the cause of SO MANY compiler bugs in "regular" ASM coding, that in something as noob friendly as bB, it will be no end of heartache and grief... and constants can GREATLY improve code readability...

899241[/snapback]

Well, I'VE never forgotten a #... j/k

 

Anyway... if not a #, there needs to be another way to declare constants, since stating dim value=$FF should also have the ability to map to a real address if desired, and this is how an equate works in DASM.

 

A compromise would be to not require it in the statement but require it in the dim instead:

10 dim constant=#40
100 x=constant

Making constants the default over addresses is a bad idea I think, since it will just cause confusion for those moving on to ASM when they find it's really the other way around.

[+batari]

Labels

 

How long can a label be? What is the limit? I didn't see that in the documentation.

 

 

Thanks.

899278[/snapback]

It's 20 chars, I think. If you think this isn't enough, I can easily change this.

[+Random Terrain]

Labels

 

How long can a label be? What is the limit? I didn't see that in the documentation.

 

 

Thanks.

899278[/snapback]

It's 20 chars, I think. If you think this isn't enough, I can easily change this.

899289[/snapback]

You can increase it if you want, if it won't create any problems. It's just nice to know what the limit is.

 

 

Thanks.

[supercat]

A compromise would be to not require it in the statement but require it in the dim instead:

899288[/snapback]

 

How about creating a "const" statement to set up constants?

[+batari]

A compromise would be to not require it in the statement but require it in the dim instead:

899288[/snapback]

 

How about creating a "const" statement to set up constants?

899313[/snapback]

That would work.

[potatohead]

I'm back for a bit.

 

(Nasty work project got out of hand.)

 

Anyway, just compiled the latest source on Linux. Worked great. Just wanted to confirm the pow issue was all taken care of.

 

It seems a number of things have changed. The ooze game, written for Alpha 0.1 has lots of little issues now.

 

I'm going to rewrite it with all the new features, so that's no big deal.

 

The jet fighter thing is pretty damn cool!

[potatohead]

Arrgh!!!

 

New version sometimes very difficult to understand why something won't compile.

 

Here is a chunk of code that worked before I inserted a gosub for a title screen routine. Decided to take it out, and whammo!

 

 rem smartbranching on

COLUPF = 90 : COLUP0 = 120 : COLUP1 = 47
x = 50 : y = 89 : w = 60 : v = 60

gameloop

COLUPF = 90 : COLUP0 = 120 : scorecolor = 10 : COLUP1 = 47

player1x = w : player1y = v : player0x = x : player0y = y

player0:
%01000010
%11100111
%11111111
%01111110
%00111100
%00011000
%00011000
%00011000
end

player1:
%00011000
%00010000
%00001000
%00010000
%00001000
end

drawscreen


gosub moveship

gosub moveshot

goto gameloop


moveshot

return

moveship
if joy0left then x = x - 1
if joy0right then x = x + 1
if x < 35 then x = 35
if x > 147 then x = 147
return

 

[dougd@feona batari_basic]$ ./run

Error: cannot parse line L01

DASM V2.20.09, Macro Assembler ©1988-2003

Complete.

 

I've removed half the program and get this no matter what. Tried inserting blank lines before the first one, adding dummy statements in various places....

 

Just found it. A line with one blank space in it. (Think this came up before.)

 

Well, ok. Back to having fun now.

 

 

I'm liking the labels a lot. Didn't realize how much of a pain in the arse line numbers really are.

[potatohead]

Just learned something handy. I have not checked to see if it's in the docs yet, but the error numbers do not equate to actual source text line numbers.

 

They are all about source text statement lines.

 

So, the following:

yyy
rem smartbranching on

COLUPF = 90 : COLUP0 = 120 : COLUP1 = 47
x = 50 : y = 89 : w = 60 : v = 60

gameloop
zzz
COLUPF = 90 : COLUP0 = 120 : scorecolor = 10 : COLUP1 = 47
xxx
player1x = w : player1y = v : player0x = x : player0y = y

player0:
%01000010
%11100111
%11111111
%01111110
%00111100
%00011000
%00011000
%00011000
end

player1:
%00011000
%00010000
%00001000
%00010000
%00001000
end

drawscreen

 

Contains 7 code lines, numbered from L00 to L07. Labels don't count and the L00 indicates problems before any actual program statements occur. Knowing this can really help locate lines with blank spaces or other goofy problems.

 

Eg:

 

A line with only a space, where you see xxx, would output the line:

 

Error: cannot parse line L04

 

yyy would be:

 

Error: cannot parse line L00

 

zzz would be:

 

Error: cannot parse line L03

 

...etc. Happy hunting!

[potatohead]

Error: cannot parse line (null)DASM V2.20.09

 

Arrrgh!

 

Added one line, removed it and

 

Recoding game going well so far, have title screen done and currently working on the logic. Time spent getting code to compile much higher than before.

 

I know this is being worked on, and all will be good. Just venting a bit more frustration this time around.

[potatohead]

Error: cannot parse line (null)DASM V2.20.09

899412[/snapback]

 

 

The above appears to mean a line has a space after the last valid character.

 

(goes looking for an editor that will display whitespace)

[+batari]

Error: cannot parse line (null)DASM V2.20.09

 

Arrrgh!

 

Added one line, removed it and 

 

Recoding game going well so far, have title screen done and currently working on the logic.  Time spent getting code to compile much higher than before.

 

I know this is being worked on, and all will be good.  Just venting a bit more frustration this time around.

899412[/snapback]

The errors are cryptic in part because the error routine was written to echo the line number, but the line numbers aren't there And the preprocessor/tokenizer is buggy. I've got lex working in the current build now, and the "line" that is reported is now the line in the file, not the linenumber, so I hope these things will go away (and the changes don't create new problems.)

[potatohead]

Error: cannot parse line (null)DASM V2.20.09

899412[/snapback]

 

 

The above appears to mean a line has a space after the last valid character.

 

(goes looking for an editor that will display whitespace)

899413[/snapback]

 

Got one. Kedit (on Linux) allows you to set the background color of a character seperate from the overall editor window background. ---Perfect!

 

I've got it a nice Atari blue on white now.

[potatohead]

Error: cannot parse line (null)DASM V2.20.09

 

Arrrgh!

 

Added one line, removed it and 

 

Recoding game going well so far, have title screen done and currently working on the logic.  Time spent getting code to compile much higher than before.

 

I know this is being worked on, and all will be good.  Just venting a bit more frustration this time around.

899412[/snapback]

The errors are cryptic in part because the error routine was written to echo the line number, but the line numbers aren't there And the preprocessor/tokenizer is buggy. I've got lex working in the current build now, and the "line" that is reported is now the line in the file, not the linenumber, so I hope these things will go away (and the changes don't create new problems.)

899422[/snapback]

 

That all sounds like good stuff! Don't take my posts the wrong way. I figured it was better to post what I learned for the next guy, that's all.

 

Now that I have an editor configured the right way, things are much better. You don't really notice how and where you put spaces into things for the heck of it. My style happened to be a particularly bad match for the current state of Batari Basic.

 

Just used the data statements for drawing title screen and working on music. ---Very nice implementation. These are going to be handy.

[+batari]

Just curious if you think that all I need to include is the input file to lex in the source, or if the generated lex.yy.c file should be in there too for those who don't have lex? I.e. what's the "normal" thing to do?