239 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   74 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.

[RevEng]

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

[SeaGtGruff]

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.

[RevEng]

Ah, makes perfect sense. Thanks!

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

[SeaGtGruff]

RevEng, on Mon Jun 4, 2012 3:15 PM, said:

Ah, makes perfect sense. Thanks!

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

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

[RevEng]

SeaGtGruff, on Mon Jun 4, 2012 4:40 PM, said:

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.

SeaGtGruff, on Mon Jun 4, 2012 4:40 PM, said:

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.

SeaGtGruff, on Mon Jun 4, 2012 4:40 PM, said:

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.

[SeaGtGruff]

RevEng, on Mon Jun 4, 2012 5:42 PM, said:

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.

[jasonwells]

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.

[jasonwells]

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?

[jwierer]

jasonwells, on Mon Sep 24, 2012 6:29 PM, said:

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.

jasonwells, on Mon Sep 24, 2012 6:50 PM, said:

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

[Random Terrain]

jwierer, on Tue Sep 25, 2012 8:37 PM, said:

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