Jump to content
kisrael

Bug Report Thread

Recommended Posts

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

 

   else if ((fixpoint1 ==  && (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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

BugTest.bas

Edited by ScumSoft

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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"

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

Ah, makes perfect sense. Thanks!

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...