New build: Improved if-then

[+batari]

Part of the motivation to improve if-then statements was from this thread where some tried various suggestions to find something that would build properly in bB and nothing worked.

 

So... I'm happy to say that this new build will take just about any condition (including those in the above thread that didn't work before) in an if-then and compile it. Examples that should work:

 

 if !(a & 3) then 40
 if blockread(a,b)=3 then a=a+1
 if (a+b)>(c&127) && !(a-y) then f=2

 

Please note that this hasn't been tested enough so please do so and report any issues (and successes!)

 

One limitation I'm aware of is you can't use logical OR (||) with complex conditions, only simple conditions.

bB_conditions.zip

[Pioneer4x4]

Looks promising, thanks! I haven't used it much lately, but I'll give it a shot.

[SeaGtGruff]

Wow, this 2600basic.exe is a lot smaller than the ones from 05/26/2007 and 10/25/2008. Did something get taken out, or is the code just a lot cleaner and more compact?

 

Anyway, thanks for the new build. I'll be using it from now on, unless I run into any major issues and have to go back to the 10/25/2008 build. If I do run into anything, I'll let you know.

 

Michael

[+batari]

Most likely, the smaller size is due to the new C compiler. The old compiler used some 16-bit system calls that don't work with 64-bit Windows. However, it's actually not Microsoft's fault this time It's a hardware issue: 64-bit CPUs, when running a 64-bit OS, cannot use the "Vitrual86" mode that is necessary for 16-bit system calls.

 

Anyway, the new compiler also means bB will no longer run in a pure DOS environment but I'm sure nobody cares about that.

[SeaGtGruff]

Anyway, the new compiler also means bB will no longer run in a pure DOS environment but I'm sure nobody cares about that.

As long as you still have "roll your own"-- er, "compile your own"-- versions for the Linux and Mac crowds, I don't think the Microsoft crowd will care about whether or not the Windows version runs in pure DOS.

 

Michael

[+Gemintronic]

This seemed to fix using def'ed binary values in IF statements but I still wonder why dim'ing COLUPF doesn't compile..

 

As a side dim background_color=COLUBK compiles just fine.

 

Does work now:

 

 dim counter = a
def march = counter{4}
if march then pfscroll down : REFP0 = 8

 

 

 

Never worked:

 rem Can't foreground_color=COLUPF for some reason..

rem Declare constants
const c_aqua = $B8
const c_black = $00

dim background_color=COLUBK
dim foreground_color=COLUPF

rem Init variables

foreground_color = c_aqua
background_color = c_black

Edited August 23, 2010 by theloon

[+batari]

This seemed to fix using def'ed binary values in IF statements but I still wonder why dim'ing COLUPF doesn't compile..

 

As a side dim background_color=COLUBK compiles just fine.

 

Does work now:

 

 dim counter = a
def march = counter{4}
if march then pfscroll down : REFP0 = 8

 

 

 

Never worked:

 rem Can't foreground_color=COLUPF for some reason..

rem Declare constants
const c_aqua = $B8
const c_black = $00

dim background_color=COLUBK
dim foreground_color=COLUPF

rem Init variables

foreground_color = c_aqua
background_color = c_black

The problem is "foreground_color" has the "for" keyword so bB is attempting to parse it as for-next loop, which fails.

[+Gemintronic]

The problem is "foreground_color" has the "for" keyword so bB is attempting to parse it as for-next loop, which fails.

 

 

For some reason I always suspected my variable and constant names stepping on eachothers toes. Thanks for clarifying!

 

By extension does this mean any program label, variable or constants need to watch out for this gotcha? If so, maybe I need to print out a keyword list and double check my code..

[SeaGtGruff]

The problem is "foreground_color" has the "for" keyword so bB is attempting to parse it as for-next loop, which fails.

 

 

For some reason I always suspected my variable and constant names stepping on eachothers toes. Thanks for clarifying!

 

By extension does this mean any program label, variable or constants need to watch out for this gotcha? If so, maybe I need to print out a keyword list and double check my code..

From what I've seen in the past, the compiler is sensitive about using the word "score" at the beginning of a variable name.

 

Michael

[+batari]

I looked into the parsing issues and I think I can have fixed them, so for, score, and other keywords won't conflict with variables. Turns out it wasn't very hard to do. Probably not worth posting a new version just for this, though.

Edited August 24, 2010 by batari

[Pioneer4x4]

so for, score, and other keywords

How about seven?

[SeaGtGruff]

It would be nice if you could improve the parser to allow adding comments after "dim" statements. I thought the semicolon might work, but it breaks the compile:

 

  dim lives_1 = a ; number of spare lives remaining for player 1
  dim lives_2 = b ; number of spare lives remaining for player 2
  dim whatzit = c ; blah blah something blah blah something

Michael

[jbs30000]

I use Windows 7 64-bit and I couldn't compile a program at all. If anyone else has the same OS I'd be interested to know if works on your computer.

[jwierer]

I use Windows 7 64-bit and I couldn't compile a program at all. If anyone else has the same OS I'd be interested to know if works on your computer.

You have to make sure you're using the other latest 32 bit binaries. If you're using the original 16-bit versions it won't work. You can grab copy of my working Win7 64-bit bB folder here.

 

-Jeff

[jbs30000]

Thanks, but you did that for me a few weeks ago. The preprocessor and postprocessor in your folder wouldn't run so I had to use my versions, and everything I have right now works for me.

 

I'll try your files again and see what happens.

[jwierer]

Thanks, but you did that for me a few weeks ago. The preprocessor and postprocessor in your folder wouldn't run so I had to use my versions, and everything I have right now works for me.

 

I'll try your files again and see what happens.

I updated those last week.

 

-Jeff

[jbs30000]

Sorry, still doesn't work.

 

Maybe it's my include div_mul.asm line. Try putting that in a program and see what happens.

 

Hmmm, this is weird. VisualbB says

2600 Basic compilation failed!
LINE -->Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

D:\bB Projects\Undecided2>preprocess <default.bas >e30c01cc-3480-4827-961e-79f295a3444f.tmp

D:\bB Projects\Undecided2>2600basic -i <e30c01cc-3480-4827-961e-79f295a3444f.tmp %bB%
game

And then spits out the asm for my program.

 

Meanwhile using Crimson Editor gives

---------- Capture Output ----------
> "C:\Atari2600\bB\2600bas.bat" D:\bB Projects\Undecided2\default.bas
The system cannot find the file specified.

> Terminated with exit code 255.

 

Yet building one of the sample programs worked just fine. Bizarre.

[GroovyBee]

Try removing the space in your directory name (between bB and Projects) and try it again.

[jbs30000]

Try removing the space in your directory name (between bB and Projects) and try it again.

---------- Capture Output ----------

> "C:\Atari2600\bB\2600bas.bat" D:\bBProjects\Undecided2\default.bas

batari Basic v1.01 ©2005-2007

(134): Error: Unknown keyword: B

 

Compilation failed.

 

> Terminated with exit code 0.

[GroovyBee]

At least its found your file now. What is on line 134?

[jwierer]

Try removing the space in your directory name (between bB and Projects) and try it again.

---------- Capture Output ----------

> "C:\Atari2600\bB\2600bas.bat" D:\bBProjects\Undecided2\default.bas

batari Basic v1.01 ©2005-2007

(134): Error: Unknown keyword: B

 

Compilation failed.

 

> Terminated with exit code 0.

In testing with other codes that use include div_mul.asm, the latest 2600basic.exe seems to occasionally fail on my machine? When I revert to the compiler dated 12.6.2009 it works just fine. I tested this outside of VisualbB to make sure it was't an issue of something I was doing there. I would PM Batari your source so he can debug it during compilation.

 

EDIT: In testing more sometimes 2600basic.exe simply crashes, other times is displays the following:

 

batari Basic v1.01 (C)2005-2007
(586): extraneous end statement found
(595): Error: Unknown keyword: 2☺

-Jeff

[jbs30000]

At least its found your file now. What is on line 134?

I figured it out. It doesn't like my data statements. I eliminate all of the data statements and everything is fine.

[+batari]

If jbs30000 and jwierer can send me any source that fails, that would be appreciated.

[jbs30000]

default.bas

 

This simple file that only contains

rem Generated 8/27/2010 8:35:10 PM by Visual bB Version 1.0.0.550
rem **********************************
rem *<filename>                      *
rem *<description>                   *
rem *<author>                        *
rem *<contact info>                  *
rem *<license>                       *
rem **********************************


data Test
0, 1, 2, 3, 4
end

Gives this output in the message windows of VisualbB

Compile started at 8/27/2010 8:36:54 PM
Compiling D:\bB Projects\Test Project\default.bas
2600 Basic compilation failed!
LINE -->Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

D:\bB Projects\Test Project>preprocess <default.bas >f3140bdf-3565-4f97-83b0-610017e63cc2.tmp

D:\bB Projects\Test Project>2600basic -i <f3140bdf-3565-4f97-83b0-610017e63cc2.tmp %bB%
game
.L00 ;  rem Generated 8/27/2010 8:35:10 PM by Visual bB Version 1.0.0.550

.L01 ;  rem **********************************

.L02 ;  rem *<filename>                      *

.L03 ;  rem *<description>                   *

.L04 ;  rem *<author>                        *

.L05 ;  rem *<contact info>                  *

.L06 ;  rem *<license>                       *

.L07 ;  rem **********************************

.
; 

.
; 

.L08 ;  data Test

JMP .skipL08
Test
.byte  0, 1, 2, 3, 4

.skipL08

D:\bB Projects\Test Project>@exit

Post compilation files deleted

Crimson editor gives this

---------- Capture Output ----------
> "C:\Atari2600\bB\2600bas.bat" C:\Atari2600\bB\samples\default.bas
batari Basic v1.01 (C)2005-2007
(13): Error: Unknown keyword: B

Compilation failed.

> Terminated with exit code 0.

If line numbers start with 1, and blank spaces are counted, then line 13 is the "end" statement.

Edited August 28, 2010 by jbs30000

[+batari]

Both the default.bas and the file jwierer sent to me build just fine. The extraneous end is a warning, not an error, and it's correct.

 

The problem with both does seem to be data statements. The errors: (13): Error: Unknown keyword: B and this error: (595): Error: Unknown keyword: 2☺ are both right after data statements.

 

I looked at the code and there is some uninitialized memory during data statements, and I didn't think the memory was used, but just in case I have cleared it all before use. Let me know if this fixes those weird errors.

 

Also, this build fixes some variables that previously conflicted with keywords (like "foreground") and improves keyword detection overall. This version also spots a previously undetected error in the file jwierer sent to me (and I expect this to happen again, but these are truly errors anyway.)

2600basic_datafix.zip