Bug Report Thread

[+batari]

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

I can't repeat your issue with your source, either. What version of bB are you using?

[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

I can't repeat your issue with your source, either. What version of bB are you using?

 

Mac OS-X version dated 2/14/07 12:59. It is the same one as on the bBasic homepage.

[+batari]

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

I can't repeat your issue with your source, either. What version of bB are you using?

 

Mac OS-X version dated 2/14/07 12:59. It is the same one as on the bBasic homepage.

Here is the latest OSX build that should fix that issue (and will also give you the features of the 10-25-08 DOS/Windows build.)

OSX_1.01.zip

[Robert M]

Here is the latest OSX build that should fix that issue (and will also give you the features of the 10-25-08 DOS/Windows build.)

 

 

Yes, that fixed the problem. Thanks. Will you be updating the download link on the bBasic homepage to link to these newer binaries for OS-X?

[yuppicide]

I was going to say I tested it fine, but you guys already beat me to it.

 

BTW, nice looking game. Could it be made in to Satan's Hollow? That game is awesome!

 

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

[+batari]

I found a bug in startup.asm. This will only affect games using a custom pfrowheight (which means very few.) The bug will only manifest itself on real hardware, and not all hardware will exploit it.

 

The fixed file is attached.

startup_fix.zip

[devwebcl]

Although is was asked before, I didn't get the solution.

 

Using ImgtoCode I got the following when I was trying to compile:

 

DASM V2.20.07, Macro Assembler (C)1988-2003
--- Unresolved Symbol List
game                     0000 ????         (R )
bs_mask                  0000 ????         (R )

Fatal assembly error: Source is not resolvable.
Errors were encountered during assembly.

 

and the snippet header of the batari code is:

 

 set romsize 32kSC
set tv ntsc
set kernel_options no_blank_lines
set smartbranching on
COLUBK = $00
COLUPF = $0E
const noscore = 1
const pfres=86
playfield:

[jwierer]

Although is was asked before, I didn't get the solution.

 

Using ImgtoCode I got the following when I was trying to compile:

 

DASM V2.20.07, Macro Assembler (C)1988-2003
--- Unresolved Symbol List
game 0000 ???? (R )
bs_mask 0000 ???? (R )

Fatal assembly error: Source is not resolvable.
Errors were encountered during assembly.

 

and the snippet header of the batari code is:

 

 set romsize 32kSC
set tv ntsc
set kernel_options no_blank_lines
set smartbranching on
COLUBK = $00
COLUPF = $0E
const noscore = 1
const pfres=86
playfield:

Are you using the Windows 64-bit compiler found in this thread? I've encountered a couple different situations where code would not compile with that version. I just use a 32-bit machine and the older compiler until it's resolved.

 

-Jeff

[devwebcl]

Are you using the Windows 64-bit compiler found in this thread? I've encountered a couple different situations where code would not compile with that version. I just use a 32-bit machine and the older compiler until it's resolved.

 

-Jeff

 

Well, I just had updated from the RanomTerrain update, but I tried out with the original batari 1.0 and still is not working.

 

I just upload the bas source code I'm trying to compile if someone else can do it, so there I can see I have something with my configuraton.

 

thanks in advance.

 

Devwebcl

imagen.bas

[jwierer]

Are you using the Windows 64-bit compiler found in this thread? I've encountered a couple different situations where code would not compile with that version. I just use a 32-bit machine and the older compiler until it's resolved.

 

-Jeff

 

Well, I just had updated from the RanomTerrain update, but I tried out with the original batari 1.0 and still is not working.

 

I just upload the bas source code I'm trying to compile if someone else can do it, so there I can see I have something with my configuraton.

 

thanks in advance.

 

Devwebcl

Thanks for posting the source. The good news is your compiler is working normally because the problem is that the playfield is too large for a normal bB playfield. If you want a larger than supported playfield you'll need to generate the assembly option in imgToCode and use the bitmap kernel.

 

-Jeff

[Cliff Friedel]

Reporting this as a bug. I have come across a problem using the background kernel option where the screen will display differently based on whether the no_blank_lines option is present or not. When no_blank_lines is used, the screen appears to render normally:

 

 

When I take out no_blank_lines though, the screen distorts:

 

 

Here is the code I used to produce the issue.

 

default.bas

 

I am hoping this is just an example of poor programming instead of an actual bug, but I figured I would post it to make sure.

[+Random Terrain]

I am hoping this is just an example of poor programming instead of an actual bug, but I figured I would post it to make sure.

I played with your code and can't figure out what is making that odd stair step between the colors, but I do know if you put the following in your main loop, the top row will turn blue again:

 

   COLUBK = $80

[Cliff Friedel]

I am hoping this is just an example of poor programming instead of an actual bug, but I figured I would post it to make sure.

I played with your code and can't figure out what is making that odd stair step between the colors, but I do know if you put the following in your main loop, the top row will turn blue again:

 

   COLUBK = $80

 

It really doesn't make sense. The code appears ok. Can you think of any reason that no_blank_lines would fix it? Also, I don't want to change the background color as I am using that to make the sand (so I can build the pylons with COLUPF = 00). If I can't figure it out, I may just shelve the project for now and work on the other game I am making.

 

Cliff

[+Random Terrain]

It really doesn't make sense. The code appears ok. Can you think of any reason that no_blank_lines would fix it? Also, I don't want to change the background color as I am using that to make the sand (so I can build the pylons with COLUPF = 00). If I can't figure it out, I may just shelve the project for now and work on the other game I am making.

Maybe batari will see this and he'll be able to explain.

[+batari]

The bankground color code simply exchanges the playfield color store with the background color store. Due to timing issues, when no_blank_lines is off, the color change occurs in the middle of the scanline, and you don't notice since the playfield is normally off here. Of course the background can't be turned off so you see the stairstep. I remember encountering this bug years ago and not being able to fix it.

 

When you use no_blank_lines, a missile is not displayed and the color changing code is used in its place. The missile code occurs before the visible scanline so you don't see any glitches.

 

I looked again and I still don't think I can fix this bug. I recall being able to move the stairstep to the left a bit, and it looks like this is the best I can do:

Edited August 25, 2010 by batari

[Cliff Friedel]

Ok, thanks. I will have to try and think of something else to get that sky effect. I think I have an idea. If I set the background to the sand color, I could draw the sky as a negative of the upcoming pyramid and the ground would be background. To draw the pylons, I could just set the lines to black and put them up. That will let me get rid of the background altogether and I can use or not use the no_blank_lines as needed. Thanks for the info. I appreciate it. Definitely appreciate bB too!

 

Cliff

[+Philsan]

Hi Fred.

According to RevEng (who helped me very much with title screen and other things), there's a bug in bB that causes jumps between 311 and 312 scanlines in PAL50 version of my L.E.M. game (NTSC and PAL60 version are OK).

I attach a test version without title screen.

LEM-bug-PAL50.bas.bin

[RevEng]

Here's a minimal program that triggers the "less than 312 scanlines" problem...

 

set tv pal
set kernel_options player1colors

dim frame=a
scorecolor=$0f

gameloop
frame=frame+1
frame=frame&31
rem ** burn a variable amount of time
for t=0 to frame
 z=z
next
drawscreen
goto gameloop

...the player1colors kernel option is key. Without it, the scanlines are stable.

Edited September 20, 2010 by RevEng

[+atari2600land]

I don't know whether this is a bug or if bB was programmed this way. I can't do this:

p=(rand/t)*4

Instead, I have to do this:

if t=1 then p=rand/64
it t=2 then p=rand/32

Any thoughts?

[SeaGtGruff]

I don't know whether this is a bug or if bB was programmed this way. I can't do this:

p=(rand/t)*4

Instead, I have to do this:

if t=1 then p=rand/64
it t=2 then p=rand/32

Any thoughts?

I don't understand what you're trying to do, because the lines of code aren't equivalent. Assuming that t will equal either 1 or 2, the first line of code gives you

 

p=(rand/t)*4

=([a number between 1 and 255]/t)*4

 

if t=1:

p=([a number between 1 and 255]/1)*4

=[a number between 1 and 255]*4

=[a multiple of 4 between 4 and 252]

 

if t=2:

p=([a number between 1 and 255]/2)*4

=[a number between 0 and 127]*4

=[a multiple of 4 between 0 and 252]

 

If the second two lines of code show what you're trying to do, then the first line of code should have been as follows:

 

p=rand/(64/t)

 

What exactly are you trying to do? P is supposed to be a random number, but what kind of random number is it supposed to be?

 

Michael

[RevEng]

It looks like bB version 1.01 has something different going on with multiplication by powers of two. I'm not entirely sure if this was intentional or not.

 

The following program...

include div_mul.asm

a=b*1
a=b*2
a=b*4
a=b*8
a=b*16
a=b*32
a=b*64
a=b*128

 

compiles as...

.L01 ;  a = b * 1

LDA b
STA a
.L02 ;  a = b * 2

LDA b
asl
STA a
.L03 ;  a = b * 4

LDA b
asl
asl
STA a
.L04 ;  a = b * 8

LDA b
asl
asl
asl
STA a
.L05 ;  a = b * 16

LDA b
LDY #16
jsr mul8
STA a
.L06 ;  a = b * 32

LDA b
LDY #32
jsr mul8
STA a
.L07 ;  a = b * 64

LDA b
LDY #64
jsr mul8
STA a
.L08 ;  a = b * 128

LDA b
LDY #128
jsr mul8

 

In summary, multiplication by powers of two greater than 8 are using the multiplication subroutines, instead of cycle-cheap ASLs.

 

The situation is even worse for bankswitched binaries, as you get bankswitch penalties on top of it all.

[diogoandrei]

Hello,

 

there's seems to be a bug related to the constant *_length for data arrays. It looks like it returns weird values. RevEng was helping me out and he suggested that this might be a bug (here).

 

So, an action like this:

 

a = pixelData_length

 

...for an array like this:

 

data pixelData
1,1,2,2,3,3,4,4,5,5,6,6
end

 

...won't return the value of 12.

 

Anyone else experienced that? Thanks & cheers

[+batari]

Hello,

 

there's seems to be a bug related to the constant *_length for data arrays. It looks like it returns weird values. RevEng was helping me out and he suggested that this might be a bug (here).

 

So, an action like this:

 

a = pixelData_length

 

...for an array like this:

 

data pixelData
1,1,2,2,3,3,4,4,5,5,6,6
end

 

...won't return the value of 12.

 

Anyone else experienced that? Thanks & cheers

It won't return a value of 12 if you reference pixelData_length before you define the data statement. Any time bB parses a statement, it has to decide if a value is a variable or a constant, and since it doesn't yet know about your data statement, it treats it as a variable.

 

As for a permanent fix, that might be tough. If I treat everything ending in "_length" as a constant, it might break existing games. What I will do is issue a warning if it finds "_length" treated as a variable.

 

A few fixes that will work are (obviously) to put the data statement first, or do a forward declaration of sorts - one way to do that is use "const pixelData_length=pixelData_length" at the beginning of your code.

Edited January 21, 2011 by batari

[diogoandrei]

It won't return a value of 12 if you reference pixelData_length before you define the data statement. Any time bB parses a statement, it has to decide if a value is a variable or a constant, and since it doesn't yet know about your data statement, it treats it as a variable.

 

As for a permanent fix, that might be tough. If I treat everything ending in "_length" as a constant, it might break existing games. What I will do is issue a warning if it finds "_length" treated as a variable.

 

A few fixes that will work are (obviously) to put the data statement first, or do a forward declaration of sorts - one way to do that is use "const pixelData_length=pixelData_length" at the beginning of your code.

 

Makes sense, thanks!

Edited January 21, 2011 by batari

[+batari]

Made tiny edits to the above two posts to correct something. Also, I changed bB source to issue a warning for anything ending in "_length" treated as a variable.