Atari 2600 BASIC compiler is here!

[potatohead]

Just curious if you think that all I need to include is the input file to lex in the source, or if the generated lex.yy.c file should be in there too for those who don't have lex?  I.e. what's the "normal" thing to do?

899431[/snapback]

 

I think Lex should be assumed to be on the system. Just call out the version you are using and anyone wanting to run this can just do what it takes to get Lex on their particular box. With some things, like gfx and sound libs, this can be a pain in the arse. Lex is pretty standard and tame, IMHO.

 

Lets try it with my box and the SGI for starters to see.

[+Random Terrain]

What is Lex besides a TV show?

[+batari]

What is Lex besides a TV show?

899435[/snapback]

You mean Lexx?

 

Anyway, long story short, lex is a program that helps compiler writers write compilers. You probably don't need lex unless you are planning to download the bB source code and build it in Linux, Mac OSX or something like that.

[+Random Terrain]

What is Lex besides a TV show?

899435[/snapback]

You mean Lexx?

 

Anyway, long story short, lex is a program that helps compiler writers write compilers. You probably don't need lex unless you are planning to download the bB source code and build it in Linux, Mac OSX or something like that.

899444[/snapback]

Oh, thanks. Nope, I won't be doing that. I'll be lucky if I can get a couple of games made with the existing program. The command list is pretty short, so I shouldn't have too much trouble. I made some tiny Commodore 64 games for a while to see how much could be squeezed into a small space and this reminds me of the same kind of thing, so it should be fun after I scrape off the rust.

[kisrael]

I think Lex should be assumed to be on the system.  Just call out the version you are using and anyone wanting to run this can just do what it takes to get Lex on their particular box.  With some things, like gfx and sound libs, this can be a pain in the arse.  Lex is pretty standard and tame, IMHO.

 

I disagree. If you bring along DASM you should bring along Lex.

Fact is only a small small minority of the target auidence will have lex around. You want to keep the distribution as friendly as possible, and assuming a relatively uncommon Unix app (relative to say, tar) is installed on what is most likely a windows box is a bit of a stretch.

[+batari]

I think Lex should be assumed to be on the system.  Just call out the version you are using and anyone wanting to run this can just do what it takes to get Lex on their particular box.  With some things, like gfx and sound libs, this can be a pain in the arse.  Lex is pretty standard and tame, IMHO.

 

I disagree. If you bring along DASM you should bring along Lex.

Fact is only a small small minority of the target auidence will have lex around. You want to keep the distribution as friendly as possible, and assuming a relatively uncommon Unix app (relative to say, tar) is installed on what is most likely a windows box is a bit of a stretch.

899480[/snapback]

You only need lex to compile bB from source, so I can't see any reason to include it in a binary-only distribution for Windows. I can't see any reason to include lex in the source code either.

 

The question was not whether or not to include lex, but if I should include the C source file that lex generates, instead of the source file to lex itself, assuming that most people who would compile bB from source would already have lex (i.e. those who are using unix-based systems, mostly.)

[kisrael]

Oh, sorry if I misunderstood.

 

Can't wait to see the next release...there are some bugfixes I'm really jonesing for! It's amazing to see how this goes...

[potatohead]

Anyone work with the bit operators yet?

 

They don't seem to be working correctly for me. Since we had the math lib issue on UNIXes, maybe it's a platform thing.

 

Actually, they seem to work backward.

 

s(0) = 0

 

if s(0) then goto itequals1

 

This actually branches. Using if !s(0) works when it shouldn't.

Edited July 27, 2005 by potatohead

[potatohead]

Found bugs in the pfhline & vline code.

 

clplay
for n = 0 to 32
pfvline n 0 10 on
next

for n = 0 to 32
pfvline n 0 10 off
next
return

 

The above should clear the playfield, but leaves stripes behind. I did both of them because I also think turning a pixel off on a line by line basis does not work correctly each time either.

 

Also, I'm having trouble with some gosubs.

 

I know this will be long, but check out this next listing:

 

rem smartbranching on

reset

gosub title


rem Init Game code
rem
rem x, w, v = ship and bullet position variables
rem
rem
rem
COLUP0 = 120 : COLUP1 = 47
x = 50 : w = 60 : v = 60
rem
s = 0
rem s = game status flags
rem s(0) = bullet launched

goto clplay




gameloop
COLUPF = 43 : COLUP0 = 120 : scorecolor = 10 : COLUP1 = 47
PF0 = 140
player1x = w : player1y = v : player0x = x : player0y = 89
player0:
%01000010
%11100111
%11111111
%01111110
%00111100
%00011000
%00011000
%00011000
end
player1:
%00011000
%00010000
%00001000
%00010000
%00001000
end
drawscreen



rem GameCode
gosub checkswitches
gosub moveship
gosub moveshot
goto gameloop



rem Subroutines Live below Here



moveship
if joy0left then x = x - 1
if joy0right then x = x + 1
if x < 35 then x = 35
if x > 147 then x = 147
return




moveshot
if !s(0) then goto fire
if joy0fire then s(0) = 1 : goto fire
w = x : v = 89 - 8
goto shotdone
rem bit operators are working backward, change this code when it gets 
rem fixed.  Symptom will be always shooting.
fire
v = v - 4
if v < 3 then s(0) = 0 : v = 89 - 8 : w = x
shotdone
return





checkswitches
if switchreset then goto reset
return




title

COLUPF = 45 : a = 0 : b = 0

titleloop

COLUPF = b

drawscreen

if joy0fire then goto titleexit
if switchreset then goto reset

gosub drawdot

goto titleloop

data titlemap
0,0,0,0,1,1,0,0,0,1,1,0,0,1,1,1,1,0,1,1,1,1,0,0,0,0,0,0,0,0,0,0
0,0,0,1,0,0,1,0,1,0,0,1,0,0,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,1,0,0,1,0,1,0,0,1,0,0,1,0,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,1,0,0,1,0,1,0,0,1,0,1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,1,1,0,0,0,1,1,0,0,1,1,1,1,0,1,1,1,1,0,1,0,1,0,1,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,1,1,1,0,1,0,1,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,1,1,1,1,0,1,0,1,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0
end

drawdot
if b > 240 then b = 0 : x = 0 : a = 0
if titlemap[b] = 1 then d = a + 2 : pfpixel x d flip
x = x + 1
if x > 32 then a = a + 1 : x = 0
b = b + 1
return      

titleexit
for y = 0 to 9
pfhline 0 y 31 off
next 
return

clplay
for n = 0 to 32
pfvline n 0 10 on
next

for n = 0 to 32
pfvline n 0 10 off
next

goto gameloop

 

If you replace the goto clplay, near the top, with gosub clplay and also change the goto gameloop at the bottom with a return, it won't compile, and it should. Seems to get confused on the labels. Does not matter where you put the code either.

 

I remember this problem with 0.1 too. Happened after I tried to insert a title screen. Thought this time around, I would go ahead and build the screen first, then try and write the game inbetween the two drawscreen calls. Maybe this has nothing to do with it.

[+Random Terrain]

Aliasing

 

I am making my own adapted help file where some of the things are reordered and some of the jargon or uncommon words are converted to something I can understand better. Can the word aliasing be replaced by the word renaming or is there a better word I should use?

 

Original:

"Unlike other Basics, the dim statement is not used for arrays in Batari Basic, but rather for aliasing the existing variables a-z."

 

Adapted:

"Unlike other Basics, the dim statement is not used for arrays in Batari Basic, but rather for renaming the existing variables a-z."

[potatohead]

Aliasing

 

I am making my own adapted help file where some of the things are reordered and some of the jargon or uncommon words are converted to something I can understand better. Can the word aliasing be replaced by the word renaming or is there a better word I should use?

 

Original:

"Unlike other Basics, the dim statement is not used for arrays in Batari Basic, but rather for aliasing the existing variables a-z."

 

Adapted:

"Unlike other Basics, the dim statement is not used for arrays in Batari Basic, but rather for renaming the existing variables a-z."

899802[/snapback]

 

Renaming is not quite correct. When you make your own variable name, it points back to the included letter variables. That is what makes it an alias and not a rename, which would eliminate the original variable name from the environment.

 

Of course, it's your help file --do what you want to

[+Random Terrain]

Renaming is not quite correct.  When you make your own variable name, it points back to the included letter variables.  That is what makes it an alias and not a rename, which would eliminate the original variable name from the environment.

 

Of course, it's your help file --do what you want to 

899807[/snapback]

Thanks. Maybe I'll just reword it so only the word alias is used. The 'ing' at the end makes it so I have to decode it every time I read it.

[vdub_bobby]

Labels

 

How long can a label be? What is the limit? I didn't see that in the documentation.

 

 

Thanks.

899278[/snapback]

It's 20 chars, I think. If you think this isn't enough, I can easily change this.

899289[/snapback]

Please increase dramatically. Greater than 50 characters, please. I like descriptive labels

 

EDIT: Another request: can you have dasm output a list file when it compiles? (The -l flag.)

Edited July 27, 2005 by vdub_bobby

[+Random Terrain]

accessing bits

 

If I want to read or write to a specific bit, I just use 0 through 7, right? And you can do that with any of the 26 variables?

 

Here are some random examples to make sure I understand:

 

Sets the first bit in the variable a:

a(0)=1

 

Sets the last bit in variable d:

d(7)=1

 

Clears the third bit in variable m:

m(2)=0

[+Random Terrain]

Here's another semi-stupid question if someone has the time to answer it. Is the following sentence correct or does it need an adjustment?

 

"Accessing the bits of a variable is almost like turning it into 8 separate variables. Instead of having only 26 variables, you potentially have 208."

[+batari]

Labels

 

How long can a label be? What is the limit? I didn't see that in the documentation.

 

 

Thanks.

899278[/snapback]

It's 20 chars, I think. If you think this isn't enough, I can easily change this.

899289[/snapback]

Please increase dramatically. Greater than 50 characters, please. I like descriptive labels

 

EDIT: Another request: can you have dasm output a list file when it compiles? (The -l flag.)

899811[/snapback]

Will do.

[+batari]

Here's another semi-stupid question if someone has the time to answer it. Is the following sentence correct or does it need an adjustment?

 

"Accessing the bits of a variable is almost like turning it into 8 separate variables. Instead of having only 26 variables, you potentially have 208."

899854[/snapback]

Yes, you can access bits in any of the 26 variables. In a sense it's like having 208 variables, but they can only hold 0 or 1.

[+Random Terrain]

Here's another semi-stupid question if someone has the time to answer it. Is the following sentence correct or does it need an adjustment?

 

"Accessing the bits of a variable is almost like turning it into 8 separate variables. Instead of having only 26 variables, you potentially have 208."

899854[/snapback]

Yes, you can access bits in any of the 26 variables. In a sense it's like having 208 variables, but they can only hold 0 or 1.

899870[/snapback]

Thanks. To be clear, I'll say this then:

 

"Accessing the bits of a variable is almost like turning it into 8 separate variables. Instead of having only 26 variables, you potentially have 208, understanding that they can only hold 0 or 1."

[+batari]

Found bugs in the pfhline & vline code.

I foud the source of this bug - it's in the 2600basic.asm file. Since it's here, you can patch the file without needing to modify C source or anything... Just change this snippet of code from this:

pixeloff
 lda playfield,y
 eor #$ff
 and setbyte,x
 sta playfield,y
 rts

To this:

pixeloff
 lda setbyte,x
 eor #$ff
 and playfield,y
 sta playfield,y
 rts

Clearly a very subtle yet important difference.

Also, I'm having trouble with some gosubs.

899781[/snapback]

Is it "max nested gosubs exceeded"? If so, it's a known bug with a workaround... Check the bug report thread.

Edited July 28, 2005 by batari

[potatohead]

Found bugs in the pfhline & vline code.

I foud the source of this bug - it's in the 2600basic.asm file. Since it's here, you can patch the file without needing to modify C source or anything... Just change this snippet of code from this:

pixeloff
 lda playfield,y
 eor #$ff
 and setbyte,x
 sta playfield,y
 rts

To this:

pixeloff
 lda setbyte,x
 eor #$ff
 and playfield,y
 sta playfield,y
 rts

Clearly a very subtle yet important difference.

Also, I'm having trouble with some gosubs.

899781[/snapback]

Is it "max nested gosubs exceeded"? If so, it's a known bug with a workaround... Check the bug report thread.

899931[/snapback]

 

 

i'll do the patch. The gosubs are not nested in this case at all. I'll double check that.

[potatohead]

Found bugs in the pfhline & vline code.

I foud the source of this bug - it's in the 2600basic.asm file. Since it's here, you can patch the file without needing to modify C source or anything... Just change this snippet of code from this:

pixeloff
 lda playfield,y
 eor #$ff
 and setbyte,x
 sta playfield,y
 rts

To this:

pixeloff
 lda setbyte,x
 eor #$ff
 and playfield,y
 sta playfield,y
 rts

Clearly a very subtle yet important difference.

Also, I'm having trouble with some gosubs.

899781[/snapback]

Is it "max nested gosubs exceeded"? If so, it's a known bug with a workaround... Check the bug report thread.

899931[/snapback]

 

 

i'll do the patch. The gosubs are not nested in this case at all. I'll double check that.

899959[/snapback]

 

 

Well, that didn't quite fix things. Instead of a set of left over bars, I get random pixels now.

 

Tried both horizontal and vertical lines. It seems only the pixel command works as it should.

 

I'm going to use that for now as time does not matter at that point in the game.

 

I'll also try the inline asm function again. Been itching to try that. I want the finished game to be completed with the basic only (just to push the limits). However, I do want to toy with assembler too. So it's all good.

[+batari]

Found bugs in the pfhline & vline code.

I foud the source of this bug - it's in the 2600basic.asm file. Since it's here, you can patch the file without needing to modify C source or anything... Just change this snippet of code from this:

pixeloff
 lda playfield,y

 eor #$ff
 and setbyte,x
 sta playfield,y
 rts

To this:

pixeloff
 lda setbyte,x
 eor #$ff
 and playfield,y
 sta playfield,y
 rts

Clearly a very subtle yet important difference.

Also, I'm having trouble with some gosubs.

899781[/snapback]

Is it "max nested gosubs exceeded"? If so, it's a known bug with a workaround... Check the bug report thread.

899931[/snapback]

 

 

i'll do the patch. The gosubs are not nested in this case at all. I'll double check that.

899959[/snapback]

 

 

Well, that didn't quite fix things. Instead of a set of left over bars, I get random pixels now.

 

Tried both horizontal and vertical lines. It seems only the pixel command works as it should.

 

I'm going to use that for now as time does not matter at that point in the game.

 

I'll also try the inline asm function again. Been itching to try that. I want the finished game to be completed with the basic only (just to push the limits). However, I do want to toy with assembler too. So it's all good.

900019[/snapback]

It seems to work in the current build, but I did change things around a little so you can use indexed variables in pf drawing commands. I may have inadvertantly fixed a bug when I did this.

[potatohead]

It seems to work in the current build, but I did change things around a little so you can use indexed variables in pf drawing commands.  I may have inadvertantly fixed a bug when I did this.

900056[/snapback]

 

Ahh, they don't work now. That explains my current trouble.

[JLsoft]

batari,

 

Please consider renaming the files for alpha 0.3 to 8.3 format...since it -is- a DOS program, it should be usable in pure DOS (without having to hex-edit the EXE )

[potatohead]

Not sure where to put this, so I'm going to post it here.

 

I'm running into storage limits. (What's new right?) Anyway, I'm at a point where I need to either giveup some gameplay (on the ooze game), or really start doing some heavy bit lifting to pack everything into the RAM.

 

It looks to me like we are going to run into variable storage limits first, time constraints second and ROM storage space third.

 

Long winded feature request:

 

Can we get 4 bit variables? --Or maybe just the ability to sub-divide the 8bit vars we have into two smaller ones? This sounds like a lot of work, but I think the feature will be worth it based on how the overall system constraints are falling into place.

 

something like:

 

dim al = 5 ah = 3 (For one 5 bit var and one octal one, with both being parts of the 8 bit letter a variable?

 

What do you all think? Too much to ask? Maybe just get better at bit mangling?

 

(Which is what I am about to start doing.)