Bug Report Thread

kisrael · July 21, 2005

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 · July 25, 2005

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 · July 25, 2005

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

898026[/snapback]

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

kisrael · July 26, 2005

Should something like

pfpixel xpix[ptr] ypix[ptr] on

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

+batari · July 26, 2005

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

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

899142[/snapback]

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

vdub_bobby · July 27, 2005

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:

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 · July 28, 2005

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

899815[/snapback]

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 · July 28, 2005

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

899815[/snapback]

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

899933[/snapback]

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

+batari · July 28, 2005

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

899815[/snapback]

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

899933[/snapback]

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

900029[/snapback]

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

+Random Terrain · July 28, 2005

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

900047[/snapback]

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 · July 29, 2005

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 · July 29, 2005

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

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.

900685[/snapback]

potatohead · July 29, 2005

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.

Edited July 29, 2005 by potatohead

+batari · July 29, 2005

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.

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.

score = score + temp3
[/code]

900710[/snapback]

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

potatohead · July 29, 2005

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.

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.

score = score + temp3
[/code]

900710[/snapback]

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

900713[/snapback]

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

Luigi301 · July 29, 2005

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 · July 31, 2005

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 · July 31, 2005

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.

901604[/snapback]

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 · July 31, 2005

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 · July 31, 2005

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!

901825[/snapback]

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 · July 31, 2005

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

Luigi301 · July 31, 2005

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.

901912[/snapback]

Changing the gosubs to gotos fixed it. Thanks.

supercat · July 31, 2005

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 · August 1, 2005

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 · August 1, 2005

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

901954[/snapback]

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.

Bug Report Thread

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members