427 replies to this topic

[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 by batari, Sat Jul 16, 2005 2:16 PM.

[bliprob]

batari, on Sat Jul 16, 2005 4:06 PM, said:

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.

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]

bliprob, on Sat Jul 16, 2005 5:15 PM, said:

batari, on Sat Jul 16, 2005 4:06 PM, said:

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.

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!

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]

bliprob, on Fri Jul 15, 2005 3:19 PM, said:

batari, on Fri Jul 15, 2005 6:11 PM, said:

Dan Iacovelli, on Fri Jul 15, 2005 3:35 PM, said:

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)

danwinslow, on Fri Jul 15, 2005 4:23 PM, said:

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 by kisrael, Sat Jul 16, 2005 4:46 PM.

• Back to top

---

#255 batari  

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

• 
• 
• 6,193 posts
Joined: 20-September 04

• begin 644 contest

Posted Sat Jul 16, 2005 5:33 PM

Quote

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

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.

• Back to top

---

#256 batari  

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

• 
• 
• 6,193 posts
Joined: 20-September 04

• begin 644 contest

Posted Sat Jul 16, 2005 6:10 PM

bliprob, on Sat Jul 16, 2005 5:15 PM, said:

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

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

Edited by batari, Sat Jul 16, 2005 6:39 PM.

• Back to top

---

#257 potatohead  

River Patroller

• 
• 
• 3,443 posts
Joined: 22-February 04

• Location:Portland, Oregon

Posted Sat Jul 16, 2005 6:50 PM

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.

• Back to top

---

#258 danwinslow  

Stargunner

• 
• 
• 1,748 posts
Joined: 09-March 05

Posted Sat Jul 16, 2005 6:59 PM

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.

• Back to top

---

#259 batari  

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

• 
• 
• 6,193 posts
Joined: 20-September 04

• begin 644 contest

Posted Sat Jul 16, 2005 7:09 PM

batari, on Sat Jul 16, 2005 7:10 PM, said:

bliprob, on Sat Jul 16, 2005 5:15 PM, said:

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

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

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

• Back to top

---

#260 Chuck Gill  

Moonsweeper

• 
• 
• 315 posts
Joined: 25-August 01

• Location:Chicago (rat-a-tat-tat)

Posted Sat Jul 16, 2005 8:36 PM

Batari,

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

Chuck

• Back to top

---

#261 Tork110  

Space Invader

• 
• 
• 15 posts
Joined: 12-July 05

• Location:Maryland

Posted Sat Jul 16, 2005 9:18 PM

Stupid double post.

Edited by Tork110, Sat Jul 16, 2005 9:20 PM.

• Back to top

---

#262 Tork110  

Space Invader

• 
• 
• 15 posts
Joined: 12-July 05

• Location:Maryland

Posted Sat Jul 16, 2005 9:18 PM

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.

Attached Files

•  Game2.zip   1.95K   46 downloads

Edited by Tork110, Sat Jul 16, 2005 9:34 PM.

• Back to top

---

#263 bliprob  

Space Invader

• 
• 
• 14 posts
Joined: 12-July 05

Posted Sat Jul 16, 2005 9:33 PM

batari, on Sat Jul 16, 2005 9:09 PM, said:

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

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

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 by bliprob, Sat Jul 16, 2005 9:33 PM.

• Back to top

---

#264 bliprob  

Space Invader

• 
• 
• 14 posts
Joined: 12-July 05

Posted Sat Jul 16, 2005 9:51 PM

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.

• Back to top

---

#265 s0c7  

Dragonstomper

• 
• 
• 555 posts
Joined: 01-March 05

Posted Sat Jul 16, 2005 10:07 PM

bliprob, on Sat Jul 16, 2005 10:51 PM, said:

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.

• Back to top

---

#266 potatohead  

River Patroller

• 
• 
• 3,443 posts
Joined: 22-February 04

• Location:Portland, Oregon

Posted Sat Jul 16, 2005 10:23 PM

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 by potatohead, Sat Jul 16, 2005 10:55 PM.

• Back to top

---

#267 batari  

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

• 
• 
• 6,193 posts
Joined: 20-September 04

• begin 644 contest

Posted Sat Jul 16, 2005 11:14 PM

potatohead, on Sat Jul 16, 2005 11:23 PM, said:

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(....)

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.

Attached Files

•  batari_basic_linux_binary.zip   221.26K   29 downloads

Edited by batari, Sat Jul 16, 2005 11:19 PM.

• Back to top

---

#268 batari  

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

• 
• 
• 6,193 posts
Joined: 20-September 04

• begin 644 contest

Posted Sat Jul 16, 2005 11:25 PM

bliprob, on Sat Jul 16, 2005 10:51 PM, said:

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.

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.

• Back to top

---

#269 potatohead  

River Patroller

• 
• 
• 3,443 posts
Joined: 22-February 04

• Location:Portland, Oregon

Posted Sat Jul 16, 2005 11:38 PM

batari, on Sun Jul 17, 2005 12:14 AM, said:

potatohead, on Sat Jul 16, 2005 11:23 PM, said:

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(....)

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.

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 by potatohead, Sat Jul 16, 2005 11:41 PM.

• Back to top

---

#270 batari  

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

• 
• 
• 6,193 posts
Joined: 20-September 04

• begin 644 contest

Posted Sat Jul 16, 2005 11:46 PM

Tork110, on Sat Jul 16, 2005 10:18 PM, said:

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.

Quote

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.

Quote

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.

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.

• Back to top

---

#271 batari  

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

• 
• 
• 6,193 posts
Joined: 20-September 04

• begin 644 contest

Posted Sun Jul 17, 2005 12:00 AM

Quote

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.

Quote

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.

• Back to top

---

#272 potatohead  

River Patroller

• 
• 
• 3,443 posts
Joined: 22-February 04

• Location:Portland, Oregon

Posted Sun Jul 17, 2005 12:41 AM

batari, on Sun Jul 17, 2005 1:00 AM, said:

Quote

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.

Quote

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.

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?

• Back to top

---

#273 batari  

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

• 
• 
• 6,193 posts
Joined: 20-September 04

• begin 644 contest

Posted Sun Jul 17, 2005 1:15 AM

potatohead, on Sun Jul 17, 2005 1:41 AM, said:

Are the temp vars still a part of things?

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.

• Back to top

---

#274 Tom  

Moonsweeper

• 
• 
• 449 posts
Joined: 10-October 03

• Location:Switzerland

Posted Sun Jul 17, 2005 1:21 AM

batari, on Sun Jul 17, 2005 1:00 AM, said:

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.

• Back to top

---

#275 batari  

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

• 
• 
• 6,193 posts
Joined: 20-September 04

• begin 644 contest

Posted Sun Jul 17, 2005 1:43 AM

Tom, on Sun Jul 17, 2005 2:21 AM, said:

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.

Quote

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

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

• Back to top

---

[batari]

Quote

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

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]

bliprob, on Sat Jul 16, 2005 5:15 PM, said:

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

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

Edited by batari, Sat Jul 16, 2005 6:39 PM.

[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]

batari, on Sat Jul 16, 2005 7:10 PM, said:

bliprob, on Sat Jul 16, 2005 5:15 PM, said:

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

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

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 by Tork110, Sat Jul 16, 2005 9:20 PM.

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

Attached Files

•  Game2.zip   1.95K   46 downloads

Edited by Tork110, Sat Jul 16, 2005 9:34 PM.

[bliprob]

batari, on Sat Jul 16, 2005 9:09 PM, said:

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

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

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 by bliprob, Sat Jul 16, 2005 9:33 PM.

[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]

bliprob, on Sat Jul 16, 2005 10:51 PM, said:

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 by potatohead, Sat Jul 16, 2005 10:55 PM.

[batari]

potatohead, on Sat Jul 16, 2005 11:23 PM, said:

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(....)

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.

Attached Files

•  batari_basic_linux_binary.zip   221.26K   29 downloads

Edited by batari, Sat Jul 16, 2005 11:19 PM.

[batari]

bliprob, on Sat Jul 16, 2005 10:51 PM, said:

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.

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]

batari, on Sun Jul 17, 2005 12:14 AM, said:

potatohead, on Sat Jul 16, 2005 11:23 PM, said:

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(....)

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.

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 by potatohead, Sat Jul 16, 2005 11:41 PM.

[batari]

Tork110, on Sat Jul 16, 2005 10:18 PM, said:

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.

Quote

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.

Quote

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.

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]

Quote

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.

Quote

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]

batari, on Sun Jul 17, 2005 1:00 AM, said:

Quote

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.

Quote

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.

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]

potatohead, on Sun Jul 17, 2005 1:41 AM, said:

Are the temp vars still a part of things?

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]

batari, on Sun Jul 17, 2005 1:00 AM, said:

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]

Tom, on Sun Jul 17, 2005 2:21 AM, said:

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.

Quote

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

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