Jump to content
IGNORED

10-25-08 bAtari Basic build?


yuppicide

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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 by jrok
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by batari
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...