10-25-08 bAtari Basic build?

[yuppicide]

Does anyone have a list of changes in the latest 10-25-08 bB build?

[SeaGtGruff]

Does anyone have a list of changes in the latest 10-25-08 bB build?

batari didn't post a list, but in his posts he's mentioned the following changes:

 

(1) def can be used to assign a name to a bit variable, e.g.: def GAMEFLAG = a{1}

 

(2) def lets you replace a string with another string, so it can do more than just define bit variables

 

(3) macro command lets you define macros

 

(4) callmacro command lets you call macros

 

(5) const increased from a maximum of about 50 to a maximum of 500

 

Too bad he didn't post the source files, because we could have looked at them to see what keywords the compiler looks for when it's parsing statements.

 

Michael

[yuppicide]

Wonder if there is anything in the latest build that will make my works in progress not work so well.

[+batari]

Aside from what's listed above, there is on..gosub, the number of redefined variables increased from 100 to 500, the postprocessor will let you know if a user-defined header or asm file is used instead of the default, a version message is displayed, bugfixes to multicolored playfields, optimizations to joystick and console switch reading code, support for 0840 banking (use romsize 8kEB), a warning if any includes are ignored due to improper placement, pfscrolling in multisprite kernel (needs asm support to work), optimized storage of some sprite data, optimized complex math, optimized bit access, optimized score addition, bugfix to allow fixed-point number without needing a decimal in it, peephole optimizer (-O switch) improved.

 

There is also an obscure command called "extra" whose sole purpose is to place data or inline asm in the otherwise wasted space caused by placement of sprite data to prevent page wraps. For some reason it does not work with code (I can't remember why.) If you are writing a game using the multisprite kernel and the last bank is full, using extra might help you recover some of that space (which could be several hundred bytes.)

 

The syntax is:

 

extraN:

 

Where N is a number. End the extra block with "end," not indented, just like data statements, sprite definitions, etc. 0 will attempt to place your data or inline asm in the first block of wasted space, if it exists. 1 will place it in the second, 2 in the third, and so on. I can't remember what happens if the block doesn't exist.

 

A code example for extra might look like this:

 

 extra0: 
data getsound
2,4,15,8
end

asm
lda #1
...
end

end

[+Random Terrain]

Is this an experimental buggy build that should be used at your own risk or should I update the bB pages with this info?

[SeaGtGruff]

Is this an experimental buggy build that should be used at your own risk or should I update the bB pages with this info?

Well, when batari posted it, he said to use it at our own risk. The thing is, we need to use it, test it, and report any bugs we might run into, so batari can fix them.

 

Michael

[+batari]

Potentially buggy, and I can't remember how macros work. I wouldn't worry about documenting things yet. I'd recommend using it, however, as it does fix some bugs and your code will almost certainly compile to a shorter length, especially if you use the peephole optimizer (-O switch.)

[+Random Terrain]

Is this an experimental buggy build that should be used at your own risk or should I update the bB pages with this info?

Well, when batari posted it, he said to use it at our own risk. The thing is, we need to use it, test it, and report any bugs we might run into, so batari can fix them.

Potentially buggy, and I can't remember how macros work. I wouldn't worry about documenting things yet. I'd recommend using it, however, as it does fix some bugs and your code will almost certainly compile to a shorter length, especially if you use the peephole optimizer (-O switch.)

Thanks. So can one of you create an official thread for this (with latest build to download) and copy the useful info from this thread and paste it into the new thread? If so, I'll link to it from my version of the bB page. That way everything about this latest build will be in one spot.

[+batari]

Is this an experimental buggy build that should be used at your own risk or should I update the bB pages with this info?

Well, when batari posted it, he said to use it at our own risk. The thing is, we need to use it, test it, and report any bugs we might run into, so batari can fix them.

Potentially buggy, and I can't remember how macros work. I wouldn't worry about documenting things yet. I'd recommend using it, however, as it does fix some bugs and your code will almost certainly compile to a shorter length, especially if you use the peephole optimizer (-O switch.)

Thanks. So can one of you create an official thread for this (with latest build to download) and copy the useful info from this thread and paste it into the new thread? If so, I'll link to it from my version of the bB page. That way everything about this latest build will be in one spot.

I should probably post an update to the course web page. I suppose I should also check the asm files to see if there are any changes worth posting.

[jwierer]

Potentially buggy, and I can't remember how macros work. I wouldn't worry about documenting things yet. I'd recommend using it, however, as it does fix some bugs and your code will almost certainly compile to a shorter length, especially if you use the peephole optimizer (-O switch.)

ok maybe this is a stupid question, but which executable would I use the peephole optimizer (-O) with?

 

Thanks,

Jeff

[+batari]

Potentially buggy, and I can't remember how macros work. I wouldn't worry about documenting things yet. I'd recommend using it, however, as it does fix some bugs and your code will almost certainly compile to a shorter length, especially if you use the peephole optimizer (-O switch.)

ok maybe this is a stupid question, but which executable would I use the peephole optimizer (-O) with?

 

Thanks,

Jeff

Use it with the batch file.

[jrok]

Aside from what's listed above, there is on..gosub, the number of redefined variables increased from 100 to 500, the postprocessor will let you know if a user-defined header or asm file is used instead of the default, a version message is displayed, bugfixes to multicolored playfields, optimizations to joystick and console switch reading code, support for 0840 banking (use romsize 8kEB), a warning if any includes are ignored due to improper placement, pfscrolling in multisprite kernel (needs asm support to work), optimized storage of some sprite data, optimized complex math, optimized bit access, optimized score addition, bugfix to allow fixed-point number without needing a decimal in it, peephole optimizer (-O switch) improved.

 

There is also an obscure command called "extra" whose sole purpose is to place data or inline asm in the otherwise wasted space caused by placement of sprite data to prevent page wraps. For some reason it does not work with code (I can't remember why.) If you are writing a game using the multisprite kernel and the last bank is full, using extra might help you recover some of that space (which could be several hundred bytes.)

 

The syntax is:

 

extraN:

 

Where N is a number. End the extra block with "end," not indented, just like data statements, sprite definitions, etc. 0 will attempt to place your data or inline asm in the first block of wasted space, if it exists. 1 will place it in the second, 2 in the third, and so on. I can't remember what happens if the block doesn't exist.

 

A code example for extra might look like this:

 

 extra0: 
data getsound
2,4,15,8
end

asm
lda #1
...
end

end

 

 

This all sounds pretty great! Where can we find this new build?

 

Thanks,

Jarod

Edited December 10, 2008 by jrok

[+batari]

This all sounds pretty great! Where can we find this new build?

 

Thanks,

Jarod

http://www.atariage.com/forums/index.php?a...t&id=114295

[yuppicide]

Thanks for the info guys. I had only found this latest build by mistake as well when batari posted in another thread with a link to it.

[SeaGtGruff]

I can't remember how macros work.

I played around with it and figured it out.

 

For programmers who aren't familiar with macros, they're like routines that you can define, except you can pass them one or more parameters. That makes them sound like subroutines, or user-defined functions, but they *aren't* like that. When you *define* a macro, it doesn't use up any ROM at all-- but when you *call* a macro, it uses up ROM. A subroutine would be stored in ROM once, and then would use only 3 bytes of ROM each time you call it, and have an overhead of 12 cycles to call it (6 cycles to call it, and 6 cycles to return from it). But a macro always uses up *some* amount of ROM (which could vary each time depending on the circumstances), but it has *no* extra cycles of overhead to call it. In a sense, you can use macros to create your own "commands" or "programming statements"-- although that isn't quite right, either.

 

Defining a macro:

 

You must define a macro before you try to call it, otherwise you'll get a compile error. You can just define your macro(s) somewhere near the beginning of your program, such as right after your "dim" and "def" and "const" statements. The basic format should be as follows:

 

   macro my_macro_name
  rem * the statements that make up your macro go here
end

For example:

 

   macro backgroundcolor
  COLUBK = {1}
end

You can't *define* a macro inside the definition of another macro, but you can *call* an already-defined macro inside the definition of another macro. For example:

 

   macro backgroundcolor
  COLUBK = {1}
end

  macro playfieldcolor
  COLUPF = {1}
end

  macro screencolors
  callmacro playfieldcolor {1}
  callmacro backgroundcolor {2}
end

When you're defining a macro, you use {#} to refer to a parameter that's being passed to the macro (where "{#}" means some number inside of curly brackets). For instance, if you pass four parameters to a macro, then the first parameter will be {1}, the second parameter would be {2}, the third parameter would be {3}, and the fourth parameter would be {4}. You can also use {0}, which equals the entire parameter list.

 

Calling a macro:

 

Once you've defined a macro, you can call it by using the "callmacro" statement, as follows:

 

   callmacro my_macro parameter_1 parameter_2 parameter_3 etc.

Note that you should *not* separate the parameters by commas. Also, the parameter will be used just as you type it, so if you want the parameter to be treated as a value rather than as a variable, you'll need to put a pound (#) in front of it. For instance, here are some statements that call the macros we defined in the preceding examples:

 

   callmacro backgroundcolor #$04

   callmacro playfieldcolor #$1A

   callmacro screencolors #$04 #$1A

Michael

[jrok]

Thank you for the detailed explanation. I have a couple of of questions.

 

When you *define* a macro, it doesn't use up any ROM at all-- but when you *call* a macro, it uses up ROM. A subroutine would be stored in ROM once, and then would use only 3 bytes of ROM each time you call it, and have an overhead of 12 cycles to call it (6 cycles to call it, and 6 cycles to return from it). But a macro always uses up *some* amount of ROM (which could vary each time depending on the circumstances), but it has *no* extra cycles of overhead to call it.

 

I'm a little confused about what's going on behind the scenes, here. When we compile a program that contains a macro, does the the compiler tally the total number of calls and write them into ROM? I assume one shouldn't do even do this, but how would the compiler handle a macro in a looping or iterative statement, such as:

 

  dim my_var = a

 macro my_macro
 missile0x = {1}
end

 myLoop
 my_var = my_var + 1
 callmacro my_macro my_var
goto myLoop

 

Also, I'm a little confused by the use of "{#}" in the below definitions and calls. What happens when the program executes "callmacro backgroundcolor {2}."

 

You can't *define* a macro inside the definition of another macro, but you can *call* an already-defined macro inside the definition of another macro. For example:

 

   macro backgroundcolor
  COLUBK = {1}
end

  macro playfieldcolor
  COLUPF = {1}
end

  macro screencolors
  callmacro playfieldcolor {1}
  callmacro backgroundcolor {2}
end

 

Once again, thanks for making all this a little easier to digest.

 

Cheers,

Jarod.

[+batari]

I should note that you cannot jump to code within a macro, so if you put line numbers or labels in there, they won't be "visible" outside of the macro. When you do a callmacro, the code is placed inline, which will run more quickly than a function or subroutine. If the macro is long enough, however, it may take more code space.

 

I have just fixed the minor issue of requiring a # for constants. It won't "break" any code that already has a # in it, so there is no need to change any code when I get around to posting another build.

[yuppicide]

This sounds awesome.. so does this mean I can write a routine, like for example something I could use in multiple games and save it to call later?

 

Like for example instead of always making a joystick checking routine I could just make the macro once and call it?

[+batari]

This sounds awesome.. so does this mean I can write a routine, like for example something I could use in multiple games and save it to call later?

 

Like for example instead of always making a joystick checking routine I could just make the macro once and call it?

Yes, though you'd have to do a few things to get that working. Write a bB program containing nothing but the macro definitions, and build it. A temporary file called bB.asm will be built. Edit the file a little bit, and save as something else (like joystick.h.) Then just copy joystick.h to your working folder and include it using "include joystick.h." Just don't name it macro.h as that is reserved.

 

I just tried it, and bB had a bug where is was sometimes interpreting a macro variable (such as {1}) as a bit access. I have just fixed that.

So this code I wrote called joystick.bas:

  macro joyread
 if joy0left then {1}={1}-1
 if joy0right then {1}={1}+1
 if joy0up then {2}={2}-1
 if joy0down then {2}={2}+1
end

Builds a bB.asm file like this. Just remove the lines before MAC and after ENDM (highlighted in red.)

game

.L00; macro joyread

 

MAC joyread

 

.L01; if joy0left then {1} = {1} - 1

 

bit SWCHA

BVS .skipL01

.condpart0

DEC {1}

.skipL01

.L02; if joy0right then {1} = {1} + 1

 

bit SWCHA

BMI .skipL02

.condpart1

INC {1}

.skipL02

.L03; if joy0up then {2} = {2} - 1

 

lda #$10

bit SWCHA

BNE .skipL03

.condpart2

DEC {2}

.skipL03

.L04; if joy0down then {2} = {2} + 1

 

lda #$20

bit SWCHA

BNE .skipL04

.condpart3

INC {2}

.skipL04

ENDM

echo " ",[(scoretable - *)]d , "bytes of ROM space left")

 

Then use "include joystick.h" at the beginning of your code, and something like callmacro joyread x y to update x and y with joystick moves.

 

You'll have to wait until the next build is posted to actually use the above macro without error, however.

Edited December 13, 2008 by batari

[yuppicide]

Awesome!

[jbs30000]

Hello, it's been a while. I've been dealing with some health issues with my wife, and my last project, an Atari 2600 version of Space Harrier proved to be too much, especially with the problem of sprite 0 having slightly different positioning than sprites 1 through 3.

 

But anyway, I've been keeping an eye on this site, and when I saw there's a new build, albiet still experimental, I decided to download and give it a try. However, when I recompile programs that were compiled sucessfully before, I get an error

Unknown Mnemonic 'Command'.

Do I need to download something else?

[yuppicide]

Sorry to hear about your wife. Hope all is well. I don't have an answer for you on compiling, but figured I'd say what I just said.

[jbs30000]

Thank you. I clicked the link Batari gave in post 13, and replaced my existing:

2600basic.exe

optimize.exe

postprocess.exe

preprocess.exe

files with the new ones. I'm not sure what else I'm supposed to do.

[+batari]

Hello, it's been a while. I've been dealing with some health issues with my wife, and my last project, an Atari 2600 version of Space Harrier proved to be too much, especially with the problem of sprite 0 having slightly different positioning than sprites 1 through 3.

 

But anyway, I've been keeping an eye on this site, and when I saw there's a new build, albiet still experimental, I decided to download and give it a try. However, when I recompile programs that were compiled sucessfully before, I get an error

Unknown Mnemonic 'Command'.

Do I need to download something else?

Search for the word 'Command' in your .bas, and if it's there, post the context. If it's not there, search the .bas.asm and show us the context. It should be in one of those places.

[jbs30000]

OK. I already searched the .bas files, and it isn't in any of them. I just now tried to compile draw.bas, a sample program that comes with bB. Here is all that draw.bas.asm says:

 

Bad Command or File name

 

Here is what is in draw.bas.lst

 

------- FILE C:\PROGRA~1\ATARI2~1\bB\samples\draw.bas.asm LEVEL 1 PASS 1

C:\PROGRA~1\ATARI2~1\bB\samples\draw.bas.asm (1): error: Unknown Mnemonic 'Command'.

1 0000 Bad Command or file name