Bug Report Thread

[Fort Apocalypse]

Aha! Impaler found that kernel fix that batari posted a few months ago here. Looks like we all should be using this...

 

http://www.atariage.com/forums/index.php?s...t&p=1314595

[Fort Apocalypse]

The following code appears to put the compiler (the latest version at least) into an infinite loop. Be warned that killing Crimson Editor won't kill the process (have to manually kill it, and it isn't obvious which one it is).

compilerinfiniteloop.bas

[+batari]

The following code appears to put the compiler (the latest version at least) into an infinite loop. Be warned that killing Crimson Editor won't kill the process (have to manually kill it, and it isn't obvious which one it is).

Yep, it's an infinite loop alright.

 

The line it's choking on is this one:

 

if joy0right then if skierdirfloat < 7 then skierdirfloat = skierdirfloat + 0.05 + ( level * 0.05 )

 

The problem is that only simple statements are supported when using fixed point math. Infinite loops are bad so I'll see if I can't correct this.

[Fort Apocalypse]

bB compiler is reporting its own bug:

Warning - there seems to be a problem.  Your code may not run properly.
If you are seeing this message, please report it - it could be a bug.
... (infinite loop - had to kill process)
If you are seeing this message, please report it - it could be a buDASM V2.20.07, Macro Assembler (C)1988-2003
--> cycle74_HMCLR f084				  
--> WaitForVblankEnd f096				  

> Terminated with exit code 0.

 

Attached is code. Using latest version of bB last mentioned in this thread.

ufotraffic0.3.bas

ufotraffic0.3.bas.asm.txt

ufotraffic0.3.bas.bin

[Fort Apocalypse]

Seemed to fix it by changing:

groundcol = level * 34

to

groundcol = level + 14

and it turns out that I hadn't put a dim in for level, but that has nothing to do with it (it still has bug if you dim level without changing multiply). Turns out that I forgot to do this since 34 is not divisible by 2:

include div_mul.asm

but that doesn't fix it either.

Edited February 9, 2008 by Fort Apocalypse

[+batari]

Oops. bB was supposed to check the multiplicand to see if its prime factorization contains only 2, 3, 5, or 7 but apparently that isn't working right, as 34 (prime factorization 17*2) got through. But as a good programmer I put a message that the code shouldn't ever execute had I coded correctly.

 

I see the bug right now - there's a line of code in the multiplicand check that shouldn't be there.

 

If you want your code to compile and run, however, try groundcol=level*17*2 (don't ask, but it should work.)

Edited February 13, 2008 by batari

[MausGames]

Using the PFheights kernel option with vertical scrolling causes the score to bounce like crazy, and the playfield doesn't scroll every 8th time pfscroll is called.

[SeaGtGruff]

Note that there were some updates to version 1.0 that batari posted in these forums. I think the zipped file that's attached to the following post includes all or most of them...

 

http://www.atariage.com/forums/index.php?s...t&p=1490744

 

Michael

[+Random Terrain]

As a reminder, including and adding to what SeaGtGruff posted, until a new version of bB is released, if you haven't already, here are three things you might want to download to make sure bB is working properly:

 

This fixes various things:

http://www.atariage.com/forums/index.php?s...p;#entry1490744

 

This fixes statusbarcolor:

http://www.atariage.com/forums/index.php?s...p;#entry1488657

 

The following fixes score jitter/bounce related to scrolling, but only download it if the std_kernel.asm file in the first link doesn't fix your problem:

http://www.atariage.com/forums/index.php?s...p;#entry1430601

Edited October 25, 2008 by Random Terrain

[jrok]

(I originally posted this problem in a different thread, but this seems like the more appropriate forum)

 

I noticed there seems to be some sort of problem with using fixed point math and batari 1.0 bankswitching. When you include either bankswitch.inc (or the supercharger version), DASM fails on the following for fixed-point subtractions:

 

Sub44from88			  0000 ????		 (R )
bs_mask				  0000 ????		 (R )

 

...and the following for fixed-point additions:

 

Add44fto88			  0000 ????		 (R )
bs_mask				  0000 ????		 (R )

 

I've tested this with both the original set of Batari includes and the most recent updates.

 

EDT: I attached a sample file demonstrating the issue.

jumping_bs.bas

Edited October 16, 2008 by jrok

[+Random Terrain]

I noticed there seems to be some sort of problem with using fixed point math and batari 1.0 bankswitching. When you include either bankswitch.inc (or the supercharger version), DASM fails on the following for fixed-point subtractions . . .

Do you think the following post has anything to do with your problem:

 

http://www.atariage.com/forums/index.php?s...t&p=1383898

[Primordial Ooze]

The life bar is supposed to change color from green(no missed), to yellow(1 miss) to red(2 misses) and then completely disappear(lost 3 misses). However the first time it starts black, then yellow, then red and disappears and then it turns orange, yellow then green. The code that sets the color of the lives counter is pasted below and i have attached the full source to my game as a .bas file.

	rem if the player hasn't missed then set the live bar color to green
if lives > 64 && lives < 97 then lifecolor = 192

rem if the player missed once then set the live bar color to yellow
if lives > 32 && lives < 65 then lifecolor = 30

rem if the player missed twice times then set the life bar color to red
if lives > 0 && lives < 33 then lifecolor = 78

You can also view this topic for reference.

Is this a confirmed bug?

 

Sincerely,

 

Open Source Pong

2600DeAmigo.bas

Edited October 30, 2008 by Open Source Pong

[+batari]

The life bar is supposed to change color from green(no missed), to yellow(1 miss) to red(2 misses) and then completely disappear(lost 3 misses). However the first time it starts black, then yellow, then red and disappears and then it turns orange, yellow then green. The code that sets the color of the lives counter is pasted below and i have attached the full source to my game as a .bas file.

	rem if the player hasn't missed then set the live bar color to green
if lives > 64 && lives < 97 then lifecolor = 192

rem if the player missed once then set the live bar color to yellow
if lives > 32 && lives < 65 then lifecolor = 30

rem if the player missed twice times then set the life bar color to red
if lives > 0 && lives < 33 then lifecolor = 78

You can also view this topic for reference.

Is this a confirmed bug?

 

Sincerely,

 

Open Source Pong

It's not a bug in bB but a bug in your code. Here is the corrected code:

		rem if the player hasn't missed then set the live bar color to green
	if lives > 95 && lives < 128 then lifecolor = 192
  
	rem if the player missed once then set the live bar color to yellow
	if lives > 63 && lives < 96 then lifecolor = 30
  
	rem if the player missed twice times then set the life bar color to red
	if lives > 31 && lives < 64 then lifecolor = 66

Personally, I would write the code like this:

	temp1=lives/32
  lifecolor=colortable[temp1]
 data colortable
 0,66,30,192
end

[Primordial Ooze]

Oops sorry, and thanks.

 

Sincerely,

 

Open Source Pong

[Primordial Ooze]

bB doesn't work in 64bit system. When run on Windows Vista 64 bit it generates the error:

---------- Capture Output ----------

> "C:\Atari2600\bB\2600bas.bat" C:\Atari2600\bB\samples\zombie_chase.bas

This version of C:\Atari2600\bB\preprocess.exe is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.

 

> Terminated with exit code 255.

 

Non working System Specs: Windows Vista Home Premium Edition with an AMD Athlon™ 64 X2 Dual Core Processor 5200+ 2.70Ghz, 64bit Operating System.

 

Sincerely,

 

Michael

 

CONFIRMED: Tested on a 32 bit system and works as expected, thus a confirmed bug. Working System Specs: Windows Vista Home Premium Edition with an Intel® Core2 Quad CPU Q6600 @ 2.40GHz 2.39GHz

Edited May 26, 2009 by Primordial Ooze

[Z80GUY]

Hello there I am new to Batari Basic and I am having a problem with it, I i set up the program according to readme file (Ie set the Bb environment variable and path) and when I type 2600basic sample.bas it just sits there until I control Z to quit. below is a pic of its output.

 

 

I looked through this thread but could not find a problem like mine

 

any help would be appreciated thank you.

 

Carl

[+batari]

Hello there I am new to Batari Basic and I am having a problem with it, I i set up the program according to readme file (Ie set the Bb environment variable and path) and when I type 2600basic sample.bas it just sits there until I control Z to quit. below is a pic of its output.

 

 

I looked through this thread but could not find a problem like mine

 

any help would be appreciated thank you.

 

Carl

Try 2600bas sample.bas instead of what you typed (2600basic.)

 

2600bas is the batch file that runs the preprocessor, compiler, linker and assembler.

[+atari2600land]

This is probably a bug, but I just want to make sure there's nothing wrong with my file. I'm using the multisprite kernel to make my new Aquarium game. I modified the score graphics, and between the first and second digits, there's an extra space. See what I mean?

I've also put the file in question in this post so you can check it out.

score_graphics_aquarium_txt.txt

[SeaGtGruff]

I'm using the multisprite kernel to make my new Aquarium game. I modified the score graphics, and between the first and second digits, there's an extra space.

I haven't checked out your code yet, but it could be a minor timing glitch with the score routine in the multisprite kernel. I think several versions of the multisprite kernel have been released, What's the date on your multisprite_kernel.asm file?

 

Michael

[+atari2600land]

2/14/2007.

[SeaGtGruff]

2/14/2007.

I'll compare that to what I have when I get home later. I think I have about three or four different versions of the multisprite kernel that batari posted over the last few years, to correct minor glitches that had become apparent. I'm almost certain there's at least one version from 2008, but I'll have to check to be sure.

 

Michael

[+batari]

I'm aware of this. If using "normal" score graphics, you won't see this. I'm tempted to call it a limitation rather than a bug since it is known and done intentionally to allow for more features.

 

It occurs because of the pfscore bars. These bars need precise timing to occur in the middle of the score kernel, and this makes the update of the score graphics to be just slightly late. IIRC, the last bit of the first character will be the same as the last bit of the third, or something like that. You may be able to work around this bug if you design your graphics just right.

 

What may help is modifying the kernel slightly to shift the score one pixel to the left (or maybe it is the right?) This will not remove the limitation but will transfer the limitation to another part of the score, which may or may not be easier to work around.

[Robert M]

I think I found a bug with const. When I write something like this:

   const ENEMY_MAX_Y = 80
  
  player1y = ENEMY_MAX_Y

 

I expected to get the following ASM:

   lda #ENEMY_MAX_Y
  sta player1y

 

Instead I get:

   lda ENEMY_MAX_Y
  sta player1y

 

So the const value is compiled as the address to read the value from and not the value itself. Is this the correct behavior for bBasic?

 

I can see where if the expression contains a variable added to a constant it would imply I want to index memory from the variable address+constant. So this may be the expected behavior for bBasic.

 

Thanks

Edited July 10, 2009 by Robert M

[+batari]

I think I found a bug with const. When I write something like this:

   const ENEMY_MAX_Y = 80
  
  player1y = ENEMY_MAX_Y

 

I expected to get the following ASM:

   lda #ENEMY_MAX_Y
  sta player1y

 

Instead I get:

   lda ENEMY_MAX_Y
  sta player1y

 

So the const value is compiled as the address to read the value from and not the value itself. Is this the correct behavior for bBasic?

 

I can see where if the expression contains a variable added to a constant it would imply I want to index memory from the variable address+constant. So this may be the expected behavior for bBasic.

 

Thanks

I cannot replicate that behavior. I get this, which is the "correct" behavior:

   lda #ENEMY_MAX_Y
  sta player1y

Can you post your source or PM it to me?

[Robert M]

I cannot replicate that behavior. I get this, which is the "correct" behavior:

   lda #ENEMY_MAX_Y
  sta player1y

Can you post your source or PM it to me?

 

Search for ENEMY_MAX_Y in the source for an example.

 

main052.txt

 

Thanks