Compiler stopped working all of a sudden

[jbs30000]

Hello. I'm brand new to Batari Basic. Last night I downloaded the bB package, installed everything, added the path to the Environment Variables (I'm running Windows XP) as well as setting the bB variable, and used the sample programs to test everything out. I got everything working, either by going to a DOS box and running 2600bas directly, and by using a couple of IDE's (Crimson Editor and 2600IDE). I was able to create .bin files no problem.

 

So, today I decide to write a test program. It doesn't do anything yet, other than change player 0 sprite depending on which way the joystick is being pressed. I try to compile it. At the beginning of the program is set kernel_options no_blank_lines. I get an error message that it doesn't recognize kernel_options. Strange, it recognized it before, so I tried to compile one of the sample programs that compiled before. Hey, it's not compiling now . I rebooted and even re downloaded Batari Basic, but nothing. Each time I put a rem in front of something, the next line isn't recognized. It doesn't recognize set smartbranching on, and when I define my first sprite, it doesn't recognize the first line (%00111100).

 

So, anybody have an idea of what's going on? And also, sorry if this was kind of long, but I wanted to give all the information I could. Thank you.

[+atari2600land]

If you post the code (the .bas file), I might be able to find what the problem is. And, just so you know, there's a subforum for batari Basic here. Oh, and welcome to the forums, and to the wonderful world of bB.

Edited February 26, 2007 by atari2600land

[jbs30000]

If you post the code (the .bas file), I might be able to find what the problem is. And, just so you know, there's a subforum for batari Basic here. Oh, and welcome to the forums, and to the wonderful world of bB.

Whoops, sorry about posting in the wrong forum. I don't think it's my code since the sample files that compiled last night won't do so today, but I'll link it if you like, just don't laugh at my coding, that's all I ask

TestBas.bas

[jbs30000]

If you post the code (the .bas file), I might be able to find what the problem is. And, just so you know, there's a subforum for batari Basic here. Oh, and welcome to the forums, and to the wonderful world of bB.

I think I'm figuring it out. I compiled sample.bas successfully, looked at the program, and saw that set smartbranching on had a space in front, where my code didn't. added spaces and now I'm getting an error about my first sprite definition. I'll tab those over and see if that helps also.

[+Random Terrain]

I might be misunderstanding since I'm watching TV as I type this, but I wanted to make sure you understand about indenting (adding a space at the beginning of a line). batari made it even clearer in his latest version:

 

http://www.randomterrain.com/atari-2600-me...nds.html#labels

Labels, line numbers, and end must not be indented, while all program statements must be. You may use labels with or without program statements after them. A label can have any combination of letters, numbers, or underscores, even as the first character. A label must not match or begin with a known keyword or any labels internal to bB (like end, kernel, and so on). For example, you cannot name a label next or pfpixel and although you could not use 'scorechange' you could use 'changescore'.

[jbs30000]

I might be misunderstanding since I'm watching TV as I type this, but I wanted to make sure you understand about indenting (adding a space at the beginning of a line). batari made it even clearer in his latest version:

 

http://www.randomterrain.com/atari-2600-me...nds.html#labels

Labels, line numbers, and end must not be indented, while all program statements must be. You may use labels with or without program statements after them. A label can have any combination of letters, numbers, or underscores, even as the first character. A label must not match or begin with a known keyword or any labels internal to bB (like end, kernel, and so on). For example, you cannot name a label next or pfpixel and although you could not use 'scorechange' you could use 'changescore'.

Yes, I understand. I've been going through my code and indenting what needs to be indented and making sure that end and my labels aren't indented. I think I'm getting the hang of it now. I'm making progress anyway.

[+atari2600land]

I see a problem: If you're just going to use one color for the player (in this case player0,) you don't define every sprite line, you just type COLUP0=34. If you want to make a sprite different horizontal colors, then you would put near the top of the code "set kernel_options player0color", and that would allow you to pick different colors. The problem with this is that you didn't put said line in. For example:

 

player0color:
 34
 64
 128
 196
end

 

 

would end up with a sprite that's yellow on the first pixel line, then red, then blue then green.

Edited February 26, 2007 by atari2600land

[jbs30000]

I see a problem: If you're just going to use one color for the player (in this case player0,) you don't define every sprite line, you just type COLUP0=34. If you want to make a sprite different horizontal colors, then you would put near the top of the code "set kernel_options player0color", and that would allow you to pick different colors. The problem with this is that you didn't put said line in. For example:

 

player0color:
 34
 64
 128
 196
end

 

 

would end up with a sprite that's yellow on the first pixel line, then red, then blue then green.

Yeah, I did that. I also put in the spaces where needed and now I get a program that displays my tank, but won't move it. I'm in the middle of putting the sprite images after labels and after the if then going to the label, change the sprite, draw the new screen, and return to the loop.

[SeaGtGruff]

I'm in the middle of putting the sprite images after labels and after the if then going to the label, change the sprite, draw the new screen, and return to the loop.

The code you originally posted looks pretty good except for a few problems, some of which it sounds like you've already figured out or been told:

 

(1) You need to put at least one space in front of your bB program statements.

 

(2) You can't put a "rem" after a "dim" on a line. I wish you could, but the bB compiler doesn't like it. Move each "rem" statement to the line after the "dim" statement.

 

(3) If you're going to use the "player0color:" statement, then you need to use "set kernel_options player1colors playercolors" (both are required). That means you'll lose both missile0 and missile1. But in your case, player0 is a single solid color, so unless you plan to eventually add some multicolor sprites to your program, it would be better to leave out the "set kernel_options player1colors playercolors," and replace the "player0colors:" statement with "COLUP0=34."

 

(4) You need to set the player colors within the loop so they will always get set (or reset) before or after each "drawscreen" statement, otherwise the player colors that you've specified will get wiped out, and the players will end up using the "scorecolor" color. I would move "COLUP0=34" to just after the "AdjustLoop" label, then move the first "drawscreen" statement to the line after that, and then take out the "drawscreen" statement that's at the end of the program (because it would not be needed anymore).

 

(5) Bit operations use the set brackets-- {}-- not the square brackets-- []. At the beginning of your "AdjustLoop" routine, change the "JoyStickAngle[0]" through "JoyStickAngle[3]" statements to "JoyStickAngle{0}" through "JoyStickAngle{3}."

 

Make those changes, and everything will work as you had expected. It sounds like maybe you've already figured out and fixed everything except for the kind of brackets used for bit operations.

 

Michael

TestBas.bas

[jbs30000]

I'm in the middle of putting the sprite images after labels and after the if then going to the label, change the sprite, draw the new screen, and return to the loop.

The code you originally posted looks pretty good except for a few problems, some of which it sounds like you've already figured out or been told:

 

(1) You need to put at least one space in front of your bB program statements.

 

(2) You can't put a "rem" after a "dim" on a line. I wish you could, but the bB compiler doesn't like it. Move each "rem" statement to the line after the "dim" statement.

 

(3) If you're going to use the "player0color:" statement, then you need to use "set kernel_options player1colors playercolors" (both are required). That means you'll lose both missile0 and missile1. But in your case, player0 is a single solid color, so unless you plan to eventually add some multicolor sprites to your program, it would be better to leave out the "set kernel_options player1colors playercolors," and replace the "player0colors:" statement with "COLUP0=34."

 

(4) You need to set the player colors within the loop so they will always get set (or reset) before or after each "drawscreen" statement, otherwise the player colors that you've specified will get wiped out, and the players will end up using the "scorecolor" color. I would move "COLUP0=34" to just after the "AdjustLoop" label, then move the first "drawscreen" statement to the line after that, and then take out the "drawscreen" statement that's at the end of the program (because it would not be needed anymore).

 

(5) Bit operations use the set brackets-- {}-- not the square brackets-- []. At the beginning of your "AdjustLoop" routine, change the "JoyStickAngle[0]" through "JoyStickAngle[3]" statements to "JoyStickAngle{0}" through "JoyStickAngle{3}."

 

Make those changes, and everything will work as you had expected. It sounds like maybe you've already figured out and fixed everything except for the kind of brackets used for bit operations.

 

Michael

Actually, I fixed my routine and it seems to be working fine now. As for the Bit Operations, I thought I was using {} Oh well. Anyway, I did away with those and used | and & instead (if joy0up then JStickAngle = JStickAngle | 1 else JStickAngle = JStickAngle & 14 for example).

One question remains. Everything compiles and runs OK, but I get this message "Possible duplicate label: Lo23 f520"

Any idea what it could be talking about?

TestBas.bas

[+Random Terrain]

One question remains. Everything compiles and runs OK, but I get this message "Possible duplicate label: Lo23 f520"

Any idea what it could be talking about?

Did you get a chance to read the part about Duplicate Labels under Troubleshooting/Assembler Errors:

 

http://www.randomterrain.com/atari-2600-me...troubleshooting

[SeaGtGruff]

Everything compiles and runs OK, but I get this message "Possible duplicate label: Lo23 f520"

Any idea what it could be talking about?

I compiled with the -l option to get a full compile listing, but I don't see any problem-- although the L023 line label is ending up at address $F523, not $F520, so it may just be a "bogus" error message (or warning) from DASM that isn't getting removed by the sed program. Since I'm not familiar with the sed program, I'll leave it for batari to figure that one out!

 

What's line label L023, you may ask? When the bB compiler converts your bB statements into 6502 assembly code, it creates line labels as needed for the 6502 assembly code that corresponds to your bB code, and L023 (or actually .L023) is one of the line labels that it created. Each program line with bB statements on it gets numbered from 0 to whatever, as follows: .L00, .L01, .L02, .L03, etc. That doesn't include any blank lines, lines that have line labels but no actual statements, or lines that are part of a single statement. Thus, the line that says "imageLoop" doesn't get counted as a statement, and everything from "player0:" through "end" gets counted as a single statement. So line .L023 is the line that says "if JStickAngle = 8 then tankright."

 

By the way, I liked your original code better-- it looked cleaner and easier to understand (at least to me). If you look at the changed version that I posted, you'll see that I didn't have to change very much to get it working.

 

Michael

[SeaGtGruff]

Did you get a chance to read the part about Duplicate Labels under Troubleshooting/Assembler Errors:

 

http://www.randomterrain.com/atari-2600-me...troubleshooting

I believe this is the relevant part:

 

"Note that the assembler sometimes reports bogus duplicate labels, but usually assembly is successful anyway. This is considered an assembler bug. Sometimes, the assembler generates literally hundreds of them. For this reason, all but the first one have been suppressed from the output. Ignore duplicate labels if your game builds successfully, or if the game doesn't build but has a non-empty unresolved symbol list (see next topic)."

 

So in other words, it's just an annoying warning, not an actual error. I think it might have occurred because while making the first pass DASM thought that label ".L023" was going to end up at address $F520, but it actually ended up at address $F523, so DASM thought perhaps there are two .L023 labels in the code, and was reporting it as a possible error ("*POSSIBLE* duplicate label"). And the explanation in the bB reference documentation is saying that the bB compile batch will remove all of the "possible duplicate label" messages except for the first one.

 

Michael

[jbs30000]

One question remains. Everything compiles and runs OK, but I get this message "Possible duplicate label: Lo23 f520"

Any idea what it could be talking about?

Did you get a chance to read the part about Duplicate Labels under Troubleshooting/Assembler Errors:

 

http://www.randomterrain.com/atari-2600-me...troubleshooting

Oops, no, but I will. Thanks.

[jbs30000]

Everything compiles and runs OK, but I get this message "Possible duplicate label: Lo23 f520"

Any idea what it could be talking about?

I compiled with the -l option to get a full compile listing, but I don't see any problem-- although the L023 line label is ending up at address $F523, not $F520, so it may just be a "bogus" error message (or warning) from DASM that isn't getting removed by the sed program. Since I'm not familiar with the sed program, I'll leave it for batari to figure that one out!

 

What's line label L023, you may ask? When the bB compiler converts your bB statements into 6502 assembly code, it creates line labels as needed for the 6502 assembly code that corresponds to your bB code, and L023 (or actually .L023) is one of the line labels that it created. Each program line with bB statements on it gets numbered from 0 to whatever, as follows: .L00, .L01, .L02, .L03, etc. That doesn't include any blank lines, lines that have line labels but no actual statements, or lines that are part of a single statement. Thus, the line that says "imageLoop" doesn't get counted as a statement, and everything from "player0:" through "end" gets counted as a single statement. So line .L023 is the line that says "if JStickAngle = 8 then tankright."

 

By the way, I liked your original code better-- it looked cleaner and easier to understand (at least to me). If you look at the changed version that I posted, you'll see that I didn't have to change very much to get it working.

 

Michael

Thank you very much for all your help. This dialect of Basic is different from others I've used, but I'm getting the hang of it. With the help already provided, and better reading of the documentation, I think I'll get this down in no time. Thanks again.

[+batari]

DASM thought perhaps there are two .L023 labels in the code, and was reporting it as a possible error ("*POSSIBLE* duplicate label").

The general issue is that batari Basic is starting to give DASM a good stress-test.

 

The label thing seems to be a DASM bug, and while it is annoying, it's somewhat innocuous. However, I've recently found a serious bug in DASM that has a similar root cause. It seems that in some cases, there is enough of a discrepancy between successive passes that a forward branch may resolve to an address more than -128 bytes away and this generates a bogus error, but this one aborts assembly entirely instead of just generating warnings.

 

This particular bug does not seem to be something I can easily work around, so I've built a modified version of DASM to address this and I will include this special version with bB. I will also eventually eliminate the need for sed, which I think is kind of a hack anyway. I won't change DASM enough so that the special version couldn't be used with other asm files.