[kisrael]

This thread is for reporting bugs in the Batari BASIC language itself.

Please include a description of the problem, any error messages that come up, and ideally a minimal amount of code that would make the problem occur.

[Jess Ragan]

Not sure if this counts, but I've noticed something funny with IF/THEN statements. You can specify a line number without writing GOTO if there's only one condition in the IF/THEN statement, but if there are two (using the AND/OR keywords), then GOTO must be specified. For instance:

if switchreset && e = 10 then 20

...will not work. However,

if switchreset && e = 10 then goto 20

...will.

JR

[batari]

Jess Ragan, on Mon Jul 25, 2005 3:10 AM, said:

Not sure if this counts, but I've noticed something funny with IF/THEN statements.  You can specify a line number without writing GOTO if there's only one condition in the IF/THEN statement, but if there are two (using the AND/OR keywords), then GOTO must be specified.  For instance:

if switchreset && e = 10 then 20

...will not work.  However,

if switchreset && e = 10 then goto 20

...will.

JR

This is confirmed to be a bug... It will be fixed in the next release.

[kisrael]

Should something like
pfpixel xpix[ptr] ypix[ptr] on

work? the array offset notation seems to work for simple = but not for this...

[batari]

kisrael, on Tue Jul 26, 2005 4:58 PM, said:

Should something like
pfpixel xpix[ptr] ypix[ptr] on

work?  the array offset notation seems to work for simple = but not for this...

Not yet, but it will in Alpha 0.3 - or at least it's on the list, anyway.

[vdub_bobby]

Possible bugaboo: I think the compiler is miscalculating nested gosubs.

Specifically, when I try to compile the code (see bottom of post) I get this:

Quote

Max. nested gosubs exceeded in line L022
DASM V2.20.10, Macro Assembler ©1988-2004
--- Unresolved Symbol List
0.UserInputSub          0000 ????        (R )
NO_ILLEGAL_OPCODES      0000 ????        (R )
0.CollisionsSub          0000 ????        (R )
0.UpdateCountersSub      0000 ????        (R )
0.NPCsSub                0000 ????        (R )
--- 5 Unresolved Symbols

There are no nested gosubs in my code. Commenting out any one of the gosubs causes the program to work fine. What gives?

  rem smartbranching on

  rem CONSTANTS

  dim WHITE = $0E
  dim BLACK = $00

  rem VARIABLES

  dim FrameCounter = x

  rem initial setup

  score = 0
  scorecolor = #WHITE

  rem main game loop
MainLoop
  rem first, setup display variables, update counters, and play music & sound fx

  gosub UpdateCountersSub

  rem next, drawscreen
  drawscreen

  rem last, game calculations:
  rem   act on collisions
  rem   get user input and take appropriate action
  rem   cause non-player characters to take their appropriate actions
  rem   check boundaries

  gosub CollisionsSub

  gosub UserInputSub

  gosub NPCsSub

  gosub CheckBoundariesSub

  goto MainLoop

  rem subroutines

CollisionsSub
  return

UserInputSub
  return

NPCsSub
  return

CheckBoundariesSub
  return

UpdateCountersSub
  return

  rem data

[batari]

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

Possible bugaboo: I think the compiler is miscalculating nested gosubs.

yes, I know about this bug. It's been fixed in the current build. But for now, a workaround is to change a gosub to inline asm, as:

gosub subroutine

would become:
asm
jsr subroutine
end

[potatohead]

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

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

Possible bugaboo: I think the compiler is miscalculating nested gosubs.

yes, I know about this bug. It's been fixed in the current build. But for now, a workaround is to change a gosub to inline asm, as:

gosub subroutine

would become:
asm
jsr subroutine
end

This didn't work for me. I'm going to go ahead and use the goto for the time being.

[batari]

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

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

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

Possible bugaboo: I think the compiler is miscalculating nested gosubs.

yes, I know about this bug. It's been fixed in the current build. But for now, a workaround is to change a gosub to inline asm, as:

gosub subroutine

would become:
asm
jsr subroutine
end

This didn't work for me. I'm going to go ahead and use the goto for the time being.

"jsr subroutine" needs to be indented... The intendation doesn't show up in the message in some cases.

[Random Terrain]

batari, on Thu Jul 28, 2005 12:18 AM, said:

"jsr subroutine" needs to be indented... The intendation doesn't show up in the message in some cases.

How strange, the indentation works for me here both ways:

asm
 jsr subroutine
end

asm
 jsr subroutine
end

Yes, you can slap me now.

[potatohead]

Just confirmed the bit comparison operators appear to work backward. Or, I need a whack with the clue stick!

This line:

if s(4) then s(4) = 0 : goto shipslow

Should set s(4) to 0, if it is currently a 1. (Toggle)

However, it seems to do just the opposite.

if !s(4) then s(4) = 0 : goto shipslow

Works as I think it should.

[batari]

You're right - just tried it out. Another addition to the todo list.

potatohead, on Fri Jul 29, 2005 1:35 AM, said:

Just confirmed the bit comparison operators appear to work backward.  Or, I need a whack with the clue stick!

This line:

if s(4) then s(4) = 0 : goto shipslow

Should set s(4) to 0, if it is currently a 1.  (Toggle) 

However, it seems to do just the opposite.

if !s(4) then s(4) = 0 : goto shipslow

Works as I think it should.

[potatohead]

Are hex values allowed in the data statements?

Just tried this

a = some number 

data scoretab
 $10,$20,$50,$48,$37
end

score = score + scoretab[a]

Thought I might get around the whole BCD thing with a lookup table.

Didn't add to score.

Maybe it's the array index in the score function?

Tried running it through a variable

data scoretab
 $10,$20,$50,$48,$37
end

temp3 = scoretab[y]

score = score + temp3

Got this interesting error message:

test.asm (1269): error: Value in 'adc #$683' must be <$100.

This post has been edited by potatohead: Fri Jul 29, 2005 1:45 AM

[batari]

potatohead, on Fri Jul 29, 2005 2:44 AM, said:

Are hex values allowed in the data statements?

Just tried this

a = some number 

data scoretab
 $10,$20,$50,$48,$37
end

score = score + scoretab[a]

yep. The problem is that arrays are not allowed in the score right now.

Quote

Thought I might get around the whole BCD thing with a lookup table.

I suggest supercat's suggestion in the Solar Plexus thread to get around BCD - it was pretty nifty, I think.

Quote

score = score + temp3
[/code]

Looks like you found another bug - I think score addition only works with a-z. I should change this.

[potatohead]

batari, on Fri Jul 29, 2005 2:51 AM, said:

potatohead, on Fri Jul 29, 2005 2:44 AM, said:

Are hex values allowed in the data statements?

Just tried this

a = some number 

data scoretab
 $10,$20,$50,$48,$37
end

score = score + scoretab[a]

yep. The problem is that arrays are not allowed in the score right now.

Quote

Thought I might get around the whole BCD thing with a lookup table.

I suggest supercat's suggestion in the Solar Plexus thread to get around BCD - it was pretty nifty, I think.

Quote

score = score + temp3
[/code]

Looks like you found another bug - I think score addition only works with a-z. I should change this.

I'll give it a look. --Thanks.

[Luigi301]

Got info on the bit inversion bug: bits 0-5 are inverted, but 6 and 7 are read properly. Figured that out while testing my Breakout program.

[Luigi301]

joy1left and joy1right aren't working for me. DASM gives me an unrecognized symbol error, but my code compiles fine when I comment out the two lines using it.

[batari]

Luigi301, on Sat Jul 30, 2005 8:14 PM, said:

joy1left and joy1right aren't working for me. DASM gives me an unrecognized symbol error, but my code compiles fine when I comment out the two lines using it.

Yeah, I realized the other day that I forgot to write those routines in. Alpha 0.3 will have them. But for now, I think you can use the following:

Joystick 1 right:
if SWCHA(3) then ...

Joystick 1 left:
if SWCHA(2) then ...

I haven't tried this, but I think it will work.

[Luigi301]

wtf? My missile routine is:

makemissile
  m = 1
  missile0x = z
  missile0y = y
  missile0height = 8
  if f = 1 && m = 1 then missile0y = y - 1
  goto 70

called by

51 if joy0fire && m = 0 then gosub makemissile 
70 drawscreen
71 f = f + 1
72 if f = 2 then f = 0
73 if joy0fire && m = 1 then gosub makemissile
75 goto 5

This works for a few frames, then the game completely weirds out. The screen turns odd colors and both player0 and the missile disappear. This shouldn't be happening because I haven't even written collision detection yet!

[batari]

Luigi301, on Sun Jul 31, 2005 10:47 AM, said:

wtf? My missile routine is:

makemissile
  m = 1
  missile0x = z
  missile0y = y
  missile0height = 8
  if f = 1 && m = 1 then missile0y = y - 1
  goto 70

called by

51 if joy0fire && m = 0 then gosub makemissile 
70 drawscreen
71 f = f + 1
72 if f = 2 then f = 0
73 if joy0fire && m = 1 then gosub makemissile
75 goto 5

This works for a few frames, then the game completely weirds out. The screen turns odd colors and both player0 and the missile disappear. This shouldn't be happening because I haven't even written collision detection yet!

It's probably because you are doing "gosub makemissile" but not using a "return" at the end of the routine. Either that or those gosubs should be gotos.

[attendo]

Dont know for sure its a bug in bB or its just a 2600 thing, but I wonder why I cant align 2 sprites just right even using the same y number (40 in this)?

10 COLUP0 = $18 : COLUP1 = $18
20 player0:
 %11111111
 %10010001
 %10010001
 %11111111
end
30 player0x = 30 : player0y = 40
40 player1:
 %11111111
 %10010001
 %10010001
 %11111111
end
50 player1x = 38 : player1y = 40
60 drawscreen
70 goto 20

Attached thumbnail(s)

• 

[Luigi301]

batari, on Sun Jul 31, 2005 2:23 PM, said:

It's probably because you are doing "gosub makemissile" but not using a "return" at the end of the routine.  Either that or those gosubs should be gotos.

Changing the gosubs to gotos fixed it. Thanks.

[supercat]

attendo, on Sun Jul 31, 2005 3:59 PM, said:

Dont know for sure its a bug in bB or its just a 2600 thing, but I wonder why I cant align 2 sprites just right even using the same y number (40 in this)?

What happens if you set VDELP0 or VDELP1 to 1?

[Jess Ragan]

A friend of mine tested Solar Plexus on a real 2600, and had some difficulty loading the game on his Crocodile Cartridge. Apparently, two bytes are missing from the end of the compiled program, a problem he solved by adding the two missing bytes with a hex program. Don't know if that's worth mentioning, but I thought I'd bring it up just in case anyone else was interested in selling their games.

JR

[batari]

attendo, on Sun Jul 31, 2005 3:59 PM, said:

Dont know for sure its a bug in bB or its just a 2600 thing, but I wonder why I cant align 2 sprites just right even using the same y number (40 in this)?

It's the kernel - the sprites are updated on alternate scanlines. However, vdub_bobby rewrote the original kernel to fix this, so by Alpha 0.3 the problem should go away.