214 replies to this topic

[batari]

ScumSoft, on Mon Jul 25, 2011 3:58 PM, said:

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

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

[ScumSoft]

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.

[Random Terrain]

ScumSoft, on Fri Aug 5, 2011 8:56 PM, said:

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.

[jwierer]

ScumSoft, on Fri Aug 5, 2011 8:56 PM, said:

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

[ScumSoft]

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

•  BugTest.bas   116.81K   16 downloads

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

[jwierer]

ScumSoft, on Sat Aug 6, 2011 1:10 AM, said:

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

[ScumSoft]

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.

[SeaGtGruff]

ScumSoft, on Sat Aug 6, 2011 3:08 PM, said:

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

[ScumSoft]

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

[RevEng]

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

[RevEng]

RevEng, on Mon Sep 27, 2010 11:36 AM, said:

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.

[RevEng]

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

[RevEng]

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"

[RevEng]

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

[RevEng]

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.