Jump to content

Photo

Bug Report Thread


244 replies to this topic

#201 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,464 posts
  • begin 644 contest

Posted Mon Jul 25, 2011 4:25 PM

I think it's in this line of code from statement.c

    else if ((fixpoint1 == <img src='http://www.atariage.com/forums/public/style_emoticons/<#EMO_DIR#>/icon_cool.gif' class='bbc_emoticon' alt='8)' /> && (fixpoint2 == 0))
    { // should handle 8.8=number w/o point or int var
      printf("	LDA #0\n");
      printf("	STA ");
      printfrac(statement[2]);
      printf("	LDA ");
      printimmed(statement[4]);
      printf("%s\n",statement[4]);

I think the problem lies in keyword.c, where it splits up if-then-else statements into smaller chunks and recursively dispatches the chunks of code to itself. The smaller chunks may contain uninitialized memory.

#202 ScumSoft OFFLINE  

ScumSoft

    Moonsweeper

  • 348 posts
  • Location:Polysorbate 60

Posted Fri Aug 5, 2011 8:56 PM

I'm getting this bug now in Visual Batari that whenever I press enter the screen jumps up a page so that the carriage return is at the bottom of the screen.
However the bug seems to go away once I switch my font, then it will start again after a while.

My game is above 5k lines now, so might it have something to do with this?

Edited by ScumSoft, Fri Aug 5, 2011 8:58 PM.


#203 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 24,674 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Fri Aug 5, 2011 9:02 PM

I'm getting this bug now in Visual Batari that whenever I press enter the screen jumps up a page so that the carriage return is at the bottom of the screen.
However the bug seems to go away once I switch my font, then it will start again after a while.

My game is above 5k lines now, so might it have something to do with this?

I had weird problems when editing a long program. Jwierer had me turn off syntax checking and the problems went away.

#204 jwierer OFFLINE  

jwierer

    Dragonstomper

  • 880 posts
  • Location:Seattle,WA

Posted Fri Aug 5, 2011 10:22 PM

I'm getting this bug now in Visual Batari that whenever I press enter the screen jumps up a page so that the carriage return is at the bottom of the screen.
However the bug seems to go away once I switch my font, then it will start again after a while.

My game is above 5k lines now, so might it have something to do with this?

Send me your code and I can see if I can replicate the problem.

-Jeff

#205 ScumSoft OFFLINE  

ScumSoft

    Moonsweeper

  • 348 posts
  • Location:Polysorbate 60

Posted Sat Aug 6, 2011 1:10 AM

It can be easily reproduced on my end, it starts to occur right after a compile or failed compile.
The file I attached will do it every time, although I won't rule out it being caused on my end, just that it only seems to do this on large projects.
Try to compile the file then goto bank3 and press enter to start a new line, it will jump the screen up till the cursor is at the bottom of the screen.

[edit] Note that what I attached isn't meant to compile, just show off the problem.

Attached Files


Edited by ScumSoft, Sat Aug 6, 2011 1:11 AM.


#206 jwierer OFFLINE  

jwierer

    Dragonstomper

  • 880 posts
  • Location:Seattle,WA

Posted Sat Aug 6, 2011 12:57 PM

It can be easily reproduced on my end, it starts to occur right after a compile or failed compile.
The file I attached will do it every time, although I won't rule out it being caused on my end, just that it only seems to do this on large projects.
Try to compile the file then goto bank3 and press enter to start a new line, it will jump the screen up till the cursor is at the bottom of the screen.

[edit] Note that what I attached isn't meant to compile, just show off the problem.

I can reproduce it, but as far as I can tell its not something I am doing. It occurs for me even if i have syntax checking and color coding. May just be a limit of the rich textbox control I am using?

-Jeff

#207 ScumSoft OFFLINE  

ScumSoft

    Moonsweeper

  • 348 posts
  • Location:Polysorbate 60

Posted Sat Aug 6, 2011 3:08 PM

Thanks for checking into it. It's gotten to the point now where I cannot use this IDE any longer to finish my game, it's become to large although it works almost perfect for smaller games.
I'll try and get it setup to compile from Notepad++ for now.

#208 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,440 posts
  • Location:Georgia, USA

Posted Sat Aug 6, 2011 10:19 PM

Thanks for checking into it. It's gotten to the point now where I cannot use this IDE any longer to finish my game, it's become to large although it works almost perfect for smaller games.
I'll try and get it setup to compile from Notepad++ for now.

If you ever decide to try Crimson Editor, I can probably help you set up the user tools for compiling batari Basic programs, assembling 6502 assembly programs, and running the programs in an emulator.

Michael

#209 ScumSoft OFFLINE  

ScumSoft

    Moonsweeper

  • 348 posts
  • Location:Polysorbate 60

Posted Sat Aug 6, 2011 11:18 PM

I've got notepad++ all setup just fine, works great with bB.
Thanks though.

#210 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,250 posts
  • bit player
  • Location:Canada

Posted Tue Aug 23, 2011 7:09 PM

Hi Fred,

There appears to be a bug in the "pull #-#" command. The following code displays a score of "010000" instead of the expected "012345"...

 dim sc0=score
 dim sc1=score + 1
 dim sc2=score + 2

 sc0=$01:sc1=$23:sc2=$45
 push sc0-sc2
 sc0=0:sc1=0:sc2=0
 pull sc0-sc2


Looking at the generated asm for the push and pull...

.L08 ; push sc0 - sc2

 ldx #255-sc2+sc0
pushlabelL08
 lda sc2+1,x
 sta DF7PUSH
        inx
 bmi pushlabelL08

.L09 ; pull sc0 - sc2
 ldx #255-sc2+sc0
pulllabelL09
 lda DF7DATA
 sta sc0+1,x
 inx
 bmi pulllabelL09

...it looks like they're operating through different ranges. The following manual fix gives the expected behavior...

 ldx #sc2-sc0
pulllabelL010
 lda DF7DATA
 sta sc0,x
 dex
 bpl pulllabelL010

-Mike

#211 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,250 posts
  • bit player
  • Location:Canada

Posted Wed Aug 31, 2011 2:55 AM

It looks like bB version 1.01 has something different going on with multiplication by powers of two.
...[snip]...
In summary, multiplication by powers of two greater than 8 are using the multiplication subroutines, instead of cycle-cheap ASLs.

This one still appears to be present in the latest beta.

#212 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,250 posts
  • bit player
  • Location:Canada

Posted Sat Sep 10, 2011 9:44 AM

Constants aren't treated correctly as loop limits. The following code...

 const limit=3

 for a=0 to limit
 next

...produces the following assembly...

 LDA #0
 STA a
.L01fora
.L02 ; next

 LDA a
 CMP limit ;*** this should be "CMP #limit"

 INC a
 bcc .L01fora


#213 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,250 posts
  • bit player
  • Location:Canada

Posted Fri Sep 30, 2011 12:39 PM

I found the source of some headaches I've been having with compiling the multisprite kernel... the lines in "multisprite.h" that reference the temp variables don't get fully resolved until the second dasm pass, causing rom location shifting in the kernel lines that use them. (assuming dasm ran with non-zero page in the first pass)

Changing these variable definitions to actual values resolves the situation. eg. change "P1display = temp2" to "P1display = $CC"

#214 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,250 posts
  • bit player
  • Location:Canada

Posted Sat Oct 15, 2011 5:23 PM

It seems that using vblank can sometimes cause the vblk2 label to shift between passes, due to this conditional code in std_overscan.asm...

vblk
; run possible vblank bB code
 ifconst vblank_bB_code
   jsr vblank_bB_code
 endif
vblk2

...for whatever reason, vblank_bB_code, isn't always defined in the first pass. This issue happens consistently every time I use vblank (for as many versions back as I remember) under Linux, but it appears it sometimes affects Windows as well.

I've been using the following workaround, though it would be better if vblank_bB_code was always defined in the first pass when vblank is used...

vblk
; run possible vblank bB code
 ifconst vblank_bB_code
   jsr vblank_bB_code
 else
   nop
   nop
   nop
 endif
vblk2


#215 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,250 posts
  • bit player
  • Location:Canada

Posted Tue Nov 1, 2011 8:55 PM

Not sure if this is an undocumented feature or bug, but when you check "rand" in an if...then statement, you always get the last random number rather than a new one, and the LFSR isn't advanced.

rem ** seed the first random value as 20. This isn't necessary, but it helps illustrate the point...
rand = 20

rem ** all of these if conditions will evaluate as true...
if rand=20 then b=1
if rand=20 then c=1
if rand=30 then d=1

The code should be fixed, or the documentation should be updated so this is clear.

#216 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,250 posts
  • bit player
  • Location:Canada

Posted Mon Jun 4, 2012 8:48 AM

It seems that pfres is broken with recent builds. The following minimal program doesn't display the correct playfield, and the playfield: command overwrites regular variables including the score...

const pfres=16

scorecolor=$0f

playfield:
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

mainloop
COLUPF=$18
drawscreen
goto mainloop

Guessing this happened when the standard kernel was modified to allow for mirroring the display to save 1/2 the bytes.

Relevant thread here

#217 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,440 posts
  • Location:Georgia, USA

Posted Mon Jun 4, 2012 2:52 PM

I don't know if it's broken or not. The standard kernel shouldn't work with pfres settings over 11 (or 12?) unless you've specified a Superchip bankswitching ROM format, because there's only room for 12 lines (although you can't see the 12th line unless you scroll the playfield vertically). Ideally I think the compiler should output some kind of error message if you try to use a pfres setting that's too large.

#218 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,250 posts
  • bit player
  • Location:Canada

Posted Mon Jun 4, 2012 3:15 PM

Ah, makes perfect sense. Thanks!

I should spend more time with the standard kernel, and agreed there should be a compile-time warning. :thumbsup:

#219 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,440 posts
  • Location:Georgia, USA

Posted Mon Jun 4, 2012 4:40 PM

Ah, makes perfect sense. Thanks!

I should spend more time with the standard kernel, and agreed there should be a compile-time warning. :thumbsup:

I may have been mistaken. If an option to use a 16-pixel-wide playfield had been added to the standard kernel, then using pfres settings over 11 (or 12?) should be okay, up to 23 (or 22? or 24?)-- in other words, up to twice as many playfield rows as normal, since each playfield row takes only half as many bytes as usual. If that's the case, then ideally the compiler should (if possible) output an error message whenever there's a problem with combination of the playfield width and the number of playfield rows. In the example you posted (which I haven't tried myself), each row is 32 pixels wide, in which case pfres=16 is too much.

I'm not familiar with the 16-pixel option-- I presume there's a kernel option statement for it? So if you specify that option, the compiler should either ignore anything past the 16th pixel on each row, or (if feasible) maybe output an error message about the number of pixels being incorrect for that option. And pfres=16 should be okay if you specify the option and keep the row length to 16 pixels.

On another note, it looks like your playfield pixels are lowercase x's. Shouldn't they be uppercase X's? I think you can define which characters you want to use for on/off, but I don't see a line for that in your sample. Are lowercase x's okay now? (I haven't kept up with all the recent changes in bB.)

#220 RevEng OFFLINE  

RevEng

    River Patroller

  • 3,250 posts
  • bit player
  • Location:Canada

Posted Mon Jun 4, 2012 5:42 PM

I may have been mistaken. If an option to use a 16-pixel-wide playfield had been added to the standard kernel, then using pfres settings over 11 (or 12?) should be okay, up to 23.


Well, not mistaken, but just requiring some qualification. Anyway, it looks like pfres doesn't play nice with the 16-pixel-wide playfield, or maybe it still needs superchip ram... enabling both pfres and 16-wide starts the playfield rolling.


I'm not familiar with the 16-pixel option-- I presume there's a kernel option statement for it? So if you specify that option, the compiler should either ignore anything past the 16th pixel on each row, or (if feasible) maybe output an error message about the number of pixels being incorrect for that option. And pfres=16 should be okay if you specify the option and keep the row length to 16 pixels.

You need to set the pfhalfwidth=1" constant to enable it... some DASM math and a conditional message should do it.


On another note, it looks like your playfield pixels are lowercase x's. Shouldn't they be uppercase X's?


They're upper case... maybe the font on your system is making them look small.

#221 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,440 posts
  • Location:Georgia, USA

Posted Mon Jun 4, 2012 9:27 PM

You need to set the pfhalfwidth=1" constant to enable it...

Thanks! I was able to turn on the pfhalfwidth option with the standard kernel.

It looks like a pfres up to 11 in the standard kernel will work with pfhalfwidth, but you get 2 less rows. For example, setting pfres to 11 gives you 9 rows plus the score.

#222 jasonwells OFFLINE  

jasonwells

    Combat Commando

  • 3 posts

Posted Mon Sep 24, 2012 6:29 PM

okay. i don't know if this is a bug but every time i try to open a sprite or a background, a message pops up that says it cant be opened. then it asks to open it in notepad instead of the editing window where you make the background and the sprites. can i get some help.

#223 jasonwells OFFLINE  

jasonwells

    Combat Commando

  • 3 posts

Posted Mon Sep 24, 2012 6:50 PM

i am trying ti make a game but i cant open the editor for sprites and backgrounds. in stead they just open in notepad. what should i do to fix this?

#224 jwierer OFFLINE  

jwierer

    Dragonstomper

  • 880 posts
  • Location:Seattle,WA

Posted Tue Sep 25, 2012 8:37 PM

okay. i don't know if this is a bug but every time i try to open a sprite or a background, a message pops up that says it cant be opened. then it asks to open it in notepad instead of the editing window where you make the background and the sprites. can i get some help.

i am trying ti make a game but i cant open the editor for sprites and backgrounds. in stead they just open in notepad. what should i do to fix this?


See this. Most problems aren't new. Try searching the forum first.

-Jeff

#225 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 24,674 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Sep 25, 2012 11:32 PM

See this. Most problems aren't new. Try searching the forum first.


A link to that post is also in the Troubleshooting section here:

www.randomterrain.com/atari-2600-memories-batari-basic-vbb.html#troubleshooting




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users