427 replies to this topic

[potatohead]

batari, on Wed Jul 27, 2005 3:32 AM, said:

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?

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]

Random Terrain, on Wed Jul 27, 2005 3:37 AM, said:

What is Lex besides a TV show?

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]

batari, on Wed Jul 27, 2005 4:21 AM, said:

Random Terrain, on Wed Jul 27, 2005 3:37 AM, said:

What is Lex besides a TV show?

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.

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]

potatohead, on Wed Jul 27, 2005 1:36 AM, said:

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]

kisrael, on Wed Jul 27, 2005 6:48 AM, said:

potatohead, on Wed Jul 27, 2005 1:36 AM, said:

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.

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 by potatohead, Wed Jul 27, 2005 2:15 PM.

[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]

Random Terrain, on Wed Jul 27, 2005 4:18 PM, said:

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

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]

potatohead, on Wed Jul 27, 2005 4:33 PM, said:

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 

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]

batari, on Tue Jul 26, 2005 8:29 PM, said:

Random Terrain, on Tue Jul 26, 2005 10:17 PM, said:

Labels

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


Thanks.

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

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 by vdub_bobby, Wed Jul 27, 2005 3:54 PM.

[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]

vdub_bobby, on Wed Jul 27, 2005 4:40 PM, said:

batari, on Tue Jul 26, 2005 8:29 PM, said:

Random Terrain, on Tue Jul 26, 2005 10:17 PM, said:

Labels

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


Thanks.

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

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

Will do.

[batari]

Random Terrain, on Wed Jul 27, 2005 6:08 PM, said:

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

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]

batari, on Wed Jul 27, 2005 6:38 PM, said:

Random Terrain, on Wed Jul 27, 2005 6:08 PM, said:

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

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.

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]

potatohead, on Wed Jul 27, 2005 3:44 PM, said:

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.

Quote

Also, I'm having trouble with some gosubs.

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

Edited by batari, Wed Jul 27, 2005 7:42 PM.

[potatohead]

batari, on Wed Jul 27, 2005 8:41 PM, said:

potatohead, on Wed Jul 27, 2005 3:44 PM, said:

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.

Quote

Also, I'm having trouble with some gosubs.

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

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

[potatohead]

potatohead, on Wed Jul 27, 2005 9:52 PM, said:

batari, on Wed Jul 27, 2005 8:41 PM, said:

potatohead, on Wed Jul 27, 2005 3:44 PM, said:

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.

Quote

Also, I'm having trouble with some gosubs.

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

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

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]

potatohead, on Wed Jul 27, 2005 11:27 PM, said:

potatohead, on Wed Jul 27, 2005 9:52 PM, said:

batari, on Wed Jul 27, 2005 8:41 PM, said:

potatohead, on Wed Jul 27, 2005 3:44 PM, said:

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.

Quote

Also, I'm having trouble with some gosubs.

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

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

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.

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]

Quote

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.

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