Atari 2600 BASIC compiler is here!

[+batari]

I've posted new source with a fixed makefile that should compile in Linux, and I think Solaris requires the changes I made too - just spaced that some compilers require you to link in the math library which is where pow() lives.

Edited July 16, 2005 by batari

[bliprob]

I've posted new source with a fixed makefile that should compile in Linux, and I think Solaris requires the changes I made too - just spaced that some compilers require you to link in the math library which is where pow() lives.

892865[/snapback]

Fred, I had to make a few minor fixes for Mac OS X - spaces instead of tabs, or the other way around, I can't recall.

 

Re whitespace -- another annoying thing, if you have vertical whitespace, the line can't have spaces. My editor of choice (BBEdit, until my own IDE is ready!) adds blank lines already indented with whitespace to match the above line.

 

Thanks for the tip on array index, I figured out the workaround myself and I've got my game working mostly! (Uses almost all of your new language features... why thanks!) One new thing I've run into:

 

.L025;  if x=2 goto moveworm

       LDA x
       CMP #2
Bus error

 

It doesn't matter what variable is on that line or what it's compared to. Pretty weird!

[+batari]

I've posted new source with a fixed makefile that should compile in Linux, and I think Solaris requires the changes I made too - just spaced that some compilers require you to link in the math library which is where pow() lives.

892865[/snapback]

Fred, I had to make a few minor fixes for Mac OS X - spaces instead of tabs, or the other way around, I can't recall.

 

Re whitespace -- another annoying thing, if you have vertical whitespace, the line can't have spaces. My editor of choice (BBEdit, until my own IDE is ready!) adds blank lines already indented with whitespace to match the above line.

 

Thanks for the tip on array index, I figured out the workaround myself and I've got my game working mostly! (Uses almost all of your new language features... why thanks!) One new thing I've run into:

 

.L025;  if x=2 goto moveworm

       LDA x
       CMP #2
Bus error

 

It doesn't matter what variable is on that line or what it's compared to. Pretty weird!

892907[/snapback]

The makefile had some spaces instead of tabs. I posted a new zip file with a corrected makefile that should build in Mac OSX without problems now.

 

Regarding your error, you should try if x=2 then moveworm... goto won't be recognized in place of then right now and apparently really bad things will happen if you don't put a then somewhere. Another thing to add to the list - bus errors are never good.

 

Also, clearly the way I chose to skip blank lines wasn't good... The todo list is stacking up already.

[kisrael]

[quote name=kisrael' date='Fri Jul 15, 2005 3:17 Maybe you're right - it might me good to at least wait until this is good enough to call it beta instead of alpha.

[/quote]

Slashdot wasn't enough publicity?

 

But yeah, probably would want to wait for the multiple kernels option... or a mad rush of new users will ask over and over about two scores.

The slashdot thing was cool, but I'd suggest waiting 'til you have at least a late beta before anyone tries another grab for the gusto.

 

I think the playfield commands are clear enough for instance: if you do pfhline 1 10 30 you will get a line on the bottom starting in the 1st column 10th row and 30 copies.

a more simple comparison is if you compre it to TI basic Playfield commands:

Call hchar ( row,column , char, rep) just have to reverse the row and column and

drop the char since batari basic doesn't use it.

Yeah, TI is <i>really</i> an odd duck with that...I can't remember *any* programming system I used that wasn't "X,Y" (mathematically speaking in quadrant 4, with 0,0 at the top left)

 

Batari, the parsing issues are going to drive you insane. I am speaking from personal experience. My advice is to set up a real parser now before you get too much kluged in there. It just gets worse as you go along. You need expression trees, BNF, etc. Yah, lex and yacc are good. Cryptic but they work.

I'm going to counter argue that you can and maybe should nip the parsing issue in the bud by NOT allowing fancy expressions. I'm of the school that Batari BASIC should keep a role as a cheap-n-cheerful (cheap in the development time sense) way of writing something that will go straight to 2600 ASM, rather than a version of BASIC that just happens to use the Atari 2600 for display.

 

Like, I'd rather have something that lets me say

 

IF x BETWEEN 0 AND z THEN INC X;

 

then

 

IF (X > 0) AND ((X < Z) OR P > 2) THEN X = X + 1

 

the latter implies full rich parsing which will generate ASM *no one* will want to look at. the former implies very atari- and programmer- focused thinking.

 

If there's every a trade off, say, between a few more kernals that can allow some cool new gaming ideas to be done or some new built in functions to do sound or whatever, or full rich parsing that lets me right complex statements in a single line, further removing me from the ASM being written, I'd strongly vote for the former.

 

So if this general kind of view wins out, there's no reason parsing needs to get much tougher than it is now. Parsing gets tough when it allows infinite nesting, you can say:

a = b

a = b + 10

a = b + (c / 2)

a = b + (21 * c + d) / 2)

and things get defined recursively. I think Batari need only go to the second level,

variable = (variable) (operator) (variable or constant)

 

That's pretty easy to parse, and it's nice that it kind of forces people to think about what variables they might accidentally be using.

 

PS, off to update the website now!

 

PPS no idea why my quotes aren't showing up as quotes

Edited July 16, 2005 by kisrael

[+batari]

PPS no idea why my quotes aren't showing up as quotes

892912[/snapback]

I think you have one missing /quote.

 

Oh, and I would like to agree in the complex if-thens to some degree, in that one boolean is probably enough, which is the way it is now. Though I think it wouldn't hurt to allow slightly more complicated assignments, but I may stop at parentheses - once you get this far, the compiler will have to start using internal registers/memory to store intermediate values, and the memory to do this is already scarce. I'd rather have the programmer figure out where to use intermediate variables.

 

Keeping it simple also makes is easier for me to program and maintain. But sticking with the original vision of batari basic, some things will actually make it harder on me...

 

... Namely, I want the generated asm to be easy to follow. Which brings up another issue - conditional compilation of individual modules. It would be easy to make one huge assembly file and selectively compile only portions of it by conditional compilation flags. However, doing so makes the asm hard to read, especially for a beginner. Therefore, although it's much harder for me to program, I'm leaning toward generation of a new, clean assembly file for every compile where only relevant portions (as kernels, routines) are inserted in a logical place.

[+batari]

(Uses almost all of your new language features... why thanks!)

892907[/snapback]

Damn Damn. I just tried data statements and they don't work... I'll see if I can whip up a fix.

Edited July 17, 2005 by batari

[potatohead]

I'll second the idea of keeping it simple and close to assembly. Forcing the programmer to think that way while keeping nasty details out of the picture is the way to go.

 

Will build Linux version later today and get back to testing / building game.

[danwinslow]

My advice about doing a real parser is not to allow for complex statements. Its to keep Batari from going crazy trying to allow for the 80 million different teeny little issues that will be cropping up dealing with things like spacing, tabs, and any combination of unlikely characters. Hand-jamming a parser as you go, even if the syntax is relatively simple, can be very painful towards the end of the development.

[+batari]

(Uses almost all of your new language features... why thanks!)

892907[/snapback]

Damn Damn. I just tried data statements and they don't work... I'll see if I can whip up a fix.

892953[/snapback]

Fixed data statements... easy fix. This is what I get for coding them in without any testing whatsoever get new version above.

[Chuck Gill]

Batari,

 

Thanks for your awesome contribution. Accessible 2600 programming, it's just incredible.

 

Chuck

[Tork110]

Stupid double post.

Edited July 17, 2005 by Tork110

[Tork110]

I have a question about the kernal. Is it suppose to be for the NTSC standard? Because my sprites seems to stretch the way it would when my old attempts at Atari 2600 programming went terribly wrong, (i.e., I used too many clock cycles for a scanline and the emulator or DASM thinks that I was trying to program for PAL.)

 

I also can't get the colors to work for the sprites. The sprites insist on being the same color as the score.

 

Note: This program isn't finished. It's based on an idea I had when I was trying to make a 2600 program by just assembly. It was sort of a reversed Kaboom! and based on popular web characters.

 

 

I guess my concerns might be moot since the next basic thing is out, but I'm still curious if I made a mistake.

Game2.zip

Edited July 17, 2005 by Tork110

[bliprob]

Damn Damn.  I just tried data statements and they don't work...  I'll see if I can whip up a fix.

892953[/snapback]

Fixed data statements... easy fix.  This is what I get for coding them in without any testing whatsoever get new version above.

892977[/snapback]

Fred, thanks, that was quick! Although that's the one new feature I'm not using.

 

A few more things I've learned through many code/compile/debug cycles:

 

- a label with no line content fails -- all my labels have a blank "rem" after them.

 

- the blank line with one space thing is a huge pain, but it's my own fault. BBEdit almost always adds this, so part of my coding cycle is to grep the \r \r to \r\r.

 

Also, here's a tip -- if you run your file through 2600bas directly with stdout to the console, you can see exactly what lines your compilation is barfing on.

 

So my game is almost really work. I'm out of variables... and I need one more temp var for a calculation. if I can find an unused byte somewhere, I'll finish it and post it.

Edited July 17, 2005 by bliprob

[bliprob]

Just realized something else. Sorry for the large number of posts.

 

if !collision(player0,playfield) then gosub hitself

 

It appears that, to detect a collision, I have to use the not operator. As in, if NOT a collision goto my collision code (as above).

 

This is pretty weird, and I'm chalking it to my inexperience, but in case it's some weird thing (i.e. I'm on a Mac, maybe it's endian-related?) I thought I'd mention it.

[s0c7]

It appears that, to detect a collision, I have to use the not operator. As in, if NOT a collision goto my collision code (as above).

 

 

Whew... glad I'm not the only one. I was poring over the docs trying to figure out what I was doing wrong.

 

I'll have to try the NOT operator (didn't think to try that). In my case it is detecting the collision immediately and the 2 objects aren't even remotely close to each other.

[potatohead]

Still have linux issues

 

Everything compiled but for this (in statements.c)

 

[in function let]

 

if (statement[4][0]=='0')

printf(" AND #%d\n",255 ^ pow(2,bit));

 

Got this:

 

cc -O2 -o 2600bas 2600bas.c statements.c keywords.c

statements.c: In function `let':

statements.c:775: error: invalid operands to binary ^

 

 

Let me know how I can help.

 

changed "^" to "*" just to see if that was the only problem.

 

Wasn't.

 

Linux still does not like the use of pow (int)pow(....)

Edited July 17, 2005 by potatohead

[+batari]

Still have linux issues

 

Everything compiled but for this (in statements.c)

 

[in function let]

 

if (statement[4][0]=='0')

      printf(" AND #%d\n",255 ^ pow(2,bit));

 

Got this:

 

cc -O2 -o 2600bas 2600bas.c statements.c keywords.c

statements.c: In function `let':

statements.c:775: error: invalid operands to binary ^

 

 

Let me know how I can help.

 

changed "^" to "*" just to see if that was the only problem.

 

Wasn't.

 

Linux still does not like the use of pow (int)pow(....)

893053[/snapback]

I have no idea what's happening there. I'll probably forgo the use of the pow function in the next release - I can live without it, it will just make my code a little longer.

 

In the meantime, I created a statically linked Linux binary - let me know if it works for you.

batari_basic_linux_binary.zip

Edited July 17, 2005 by batari

[+batari]

Just realized something else. Sorry for the large number of posts.

 

if !collision(player0,playfield) then gosub hitself

 

It appears that, to detect a collision, I have to use the not operator. As in, if NOT a collision goto my collision code (as above).

 

This is pretty weird, and I'm chalking it to my inexperience, but in case it's some weird thing (i.e. I'm on a Mac, maybe it's endian-related?) I thought I'd mention it.

893034[/snapback]

Could be a bug. I think I only tested player0,player1 collisions, and I think they worked but I could be wrong. Or maybe some work and some don't?

 

In any case, do whatever works for you right now, just be aware that if it's a bug and it's fixed, your program might need to be updated before it will work under a new release.

[potatohead]

Still have linux issues

 

Everything compiled but for this (in statements.c)

 

[in function let]

 

if (statement[4][0]=='0')

      printf(" AND #%d\n",255 ^ pow(2,bit));

 

Got this:

 

cc -O2 -o 2600bas 2600bas.c statements.c keywords.c

statements.c: In function `let':

statements.c:775: error: invalid operands to binary ^

 

 

Let me know how I can help.

 

changed "^" to "*" just to see if that was the only problem.

 

Wasn't.

 

Linux still does not like the use of pow (int)pow(....)

893053[/snapback]

I have no idea what's happening there. I'll probably forgo the use of the pow function in the next release - I can live without it, it will just make my code a little longer.

 

In the meantime, I created a statically linked Linux binary - let me know if it works for you.

893070[/snapback]

 

 

I'll give it a try. I have it working now. (uh, the one I patched up with it's own pow2 function) Think I am having lf/cr trouble because I'm getting syntax errors in dasm. Sure enough <cr> is present in those lines. You posted how to fix that however, so I'll do that and do some testing...

 

I'm running Mandrake 10 smp

 

I came to a similar conclusion about pow. I went ahead and wrote a little powers of two function that appeared to work nicely.

 

added to statements.h

 

int pow2 (int);

 

 

 

added to statements.c

int pow2 (int n)
{

auto int t;
auto int x = 2;

if (n < 0)
 {
n = -n;
}

while (n)
 {
if (n & 1) t *= x;
n >>= 1;
x *= x;
}

return t;
}

 

also in statements.c where pow appears, the following was substitued:

 

pow2 (xx);

Edited July 17, 2005 by potatohead

[+batari]

I have a question about the kernal.  Is it suppose to be for the NTSC standard? Because my sprites seems to stretch the way it would when my old attempts at Atari 2600 programming went terribly wrong, (i.e., I used too many clock cycles for a scanline and the emulator or DASM thinks that I was trying to program for PAL.)

It's NTSC. The sprites probably appear stretched because this is a 2-line kernel, which means that each pixel is 2 scanlines high.

I also can't get the colors to work for the sprites.  The sprites insist on being the same color as the score.

You need to set the sprite colors in the game loop.

Note:  This program isn't finished.  It's based on an idea I had when I was trying to make a 2600 program by just assembly.  It was sort of a reversed Kaboom! and based on popular web characters.

 

 

I guess my concerns might be moot since the next basic thing is out, but I'm still curious if I made a mistake.

893014[/snapback]

BTW, it wouldn't compile under Alpha 0.2 - the problem seems to be that some of the "then" statements are capitalized. Alpha 0.1 didn't care but the current version does. I've got case insensitivity for keywords on the to do list now.

[+batari]

Think I am having lf/cr trouble because I'm getting syntax errors in dasm.  Sure enough <cr> is present in those lines.  You posted how to fix that however, so I'll do that and do some testing...

I just ran into the same thing. I'll have to preprocess out all of the CR/LF chars before parsing the input. Apparently some are still getting through.

 

The Alpha-ness of this is really starting to reveal itself.

I came to a similar conclusion about pow.  I went ahead and wrote a little powers of two function that appeared to work nicely.

It could be even simpler, since bit can only be 0-7, so I could have used (1<<bit) in place of pow(2,bit)... Hindsight is 20/20.

[potatohead]

Think I am having lf/cr trouble because I'm getting syntax errors in dasm.  Sure enough <cr> is present in those lines.  You posted how to fix that however, so I'll do that and do some testing...

I just ran into the same thing. I'll have to preprocess out all of the CR/LF chars before parsing the input. Apparently some are still getting through.

 

The Alpha-ness of this is really starting to reveal itself.

I came to a similar conclusion about pow.  I went ahead and wrote a little powers of two function that appeared to work nicely.

It could be even simpler, since bit can only be 0-7, so I could have used (1<<bit) in place of pow(2,bit)... Hindsight is 20/20.

893081[/snapback]

 

LOL

 

This really shows the wisdom of keeping the function set down to a minimum. The set of keywords for this alpha will open a lot of doors. Adding to the set, from now on, probably should be only for things not easily possible otherwise, IMHO.

 

Are the temp vars still a part of things?

[+batari]

Are the temp vars still a part of things?

893094[/snapback]

The usage of temp vars has not changed. However, I think I will need to use one more for the playfield routines when I change them to allow indexed variables in their arguments. I should keep a detailed record of variable usage in various routines and put it in the help file so people know when the temp vars are going to be obliterated.

[Tom]

I just ran into the same thing.  I'll have to preprocess out all of the CR/LF chars before parsing the input.  Apparently some are still getting through.

 

Would have been a piece of cake to do with lex. You really should use lex/yacc or at least lex. Your grammar is probably simple enough to handcraft a parser without going mad. Personally I wouldn't have used C in the first place but Java and I'd written the scanner/parser stuff with JavaCC.

 

If you want I can help you autotoolize the code, so you don't have to worry that much about makefiles anymore.

[+batari]

Would have been a piece of cake to do with lex. You really should use lex/yacc or at least lex. Your grammar is probably simple enough to handcraft a parser without going mad.

I found a good tutorial on lex/yacc, and while yacc is still very mysterious to me, I think I've got a handle on lex and I can see how it would help. It would help immensely with outputing meaningful errors, if nothing else, which would add significant complexity if I didn't use lex. I hope to get lex to build some code for me before the next release or soon thereafter.

If you want I can help you autotoolize the code, so you don't have to worry that much about makefiles anymore.

893100[/snapback]

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