+batari Posted July 25, 2011 Share Posted July 25, 2011 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. Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted August 6, 2011 Share Posted August 6, 2011 (edited) 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 August 6, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 6, 2011 Share Posted August 6, 2011 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. Quote Link to comment Share on other sites More sharing options...
jwierer Posted August 6, 2011 Share Posted August 6, 2011 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 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted August 6, 2011 Share Posted August 6, 2011 (edited) 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 August 6, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
jwierer Posted August 6, 2011 Share Posted August 6, 2011 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 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted August 6, 2011 Share Posted August 6, 2011 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. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted August 7, 2011 Share Posted August 7, 2011 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 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted August 7, 2011 Share Posted August 7, 2011 I've got notepad++ all setup just fine, works great with bB. Thanks though. Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 24, 2011 Share Posted August 24, 2011 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 31, 2011 Share Posted August 31, 2011 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 10, 2011 Share Posted September 10, 2011 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 30, 2011 Share Posted September 30, 2011 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" 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 15, 2011 Share Posted October 15, 2011 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 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted November 2, 2011 Share Posted November 2, 2011 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 4, 2012 Share Posted June 4, 2012 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 1 Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 4, 2012 Share Posted June 4, 2012 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. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 4, 2012 Share Posted June 4, 2012 Ah, makes perfect sense. Thanks! I should spend more time with the standard kernel, and agreed there should be a compile-time warning. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 4, 2012 Share Posted June 4, 2012 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.) Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 4, 2012 Share Posted June 4, 2012 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. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 5, 2012 Share Posted June 5, 2012 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. Quote Link to comment Share on other sites More sharing options...
jasonwells Posted September 25, 2012 Share Posted September 25, 2012 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. Quote Link to comment Share on other sites More sharing options...
jasonwells Posted September 25, 2012 Share Posted September 25, 2012 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? Quote Link to comment Share on other sites More sharing options...
jwierer Posted September 26, 2012 Share Posted September 26, 2012 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 26, 2012 Share Posted September 26, 2012 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.