+Philsan Posted January 21, 2011 Share Posted January 21, 2011 Fred, have you checked this bug? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 21, 2011 Share Posted January 21, 2011 (edited) A few fixes that will work are (obviously) to put the data statement first, or do a forward declaration of sorts - one way to do that is use "const pixelData_length=pixelData_length" at the beginning of your code. I'm adding the following to the bB page. See if it looks OK: These data _length constants will not work correctly as-is. Any time you need to use a data _length constant, declare it as a constant near the beginning of your program (using the name of the constant as the value). Example: const mydata_length=mydata_length Edited January 21, 2011 by Random Terrain Quote Link to comment Share on other sites More sharing options...
+batari Posted January 22, 2011 Share Posted January 22, 2011 Close. This is how it should read: These data _length constants will not work correctly if they are used before you declare the corresponding data statement. If you need to use a data _length constant before its data statement, declare the data _length constant near the beginning of your program (using the name of the constant as the value). Example: const mydata_length=mydata_length Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 22, 2011 Share Posted January 22, 2011 (edited) Close. This is how it should read: Thanks. The page has been updated. Edited January 22, 2011 by Random Terrain Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted April 1, 2011 Share Posted April 1, 2011 I found a small bug last night that could potentially waste up to 255 bytes each time it occurs. It's in the assembly code that automatically aligns data to the next page boundary if necessary: if (<*) > (<(*+64)) repeat ($100-<*) .byte 0 repend endif In this particular instance, the section of data that's being positioned is 64 bytes long. The code adds the number of bytes of data to the current address to see whether or not it would result in a page-crossing if the data were to be inserted at the current address. The problem is, if there's just exactly enough free bytes in the current page to insert the data, the check will (almost) always report it as a page-crossing. For example, if the current address were $F8C0, then the lo byte is $C0. Adding $40 to that (which is the hex equivalent of 64 bytes) gives you $100, which has a lo byte of $00. Since $C0 is greater than $00, the code will cause 64 bytes of filler to be inserted at $F8C0, such that the 64 bytes of data will be inserted at $F900 instead of at $F8C0. The worst-case scenario would be if you have 255 bytes of data and the lo byte of the current address is $01. (If you have 256 bytes of data to insert and the lo byte of the current address is $00, the data will be positioned at the current address without any wasted space.) The code can/should be corrected as follows: if (<*) > (<(*+BYTES)) repeat ($100-<*) .byte 0 repend endif where BYTES is 1 less than the number of bytes to be inserted. That's because we start numbering at 0, not 1. For example, if we insert 64 bytes of data at the current address, the data will begin at CURR_ADDR+0 and end at CURR_ADDR+63. Michael 2 Quote Link to comment Share on other sites More sharing options...
+batari Posted April 1, 2011 Share Posted April 1, 2011 Fixed. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted April 1, 2011 Share Posted April 1, 2011 Fixed. Are you fixing it in the beta and the pre-DPC+ version (the one found in bBWin7_64bit.zip)? Speaking of the DPC+ stuff, the DF#FRACINC thingies don't seem to be working correctly. For example, the following code never seems to work right: 192/64=n : 256/n=x DF0FRACINC = x DF1FRACINC = x DF2FRACINC = x DF3FRACINC = x DF4FRACINC = x DF6FRACINC = x The foreground/background row colors hardly ever line up properly. Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted May 29, 2011 Share Posted May 29, 2011 (edited) Has the DPC+ playfield stairstep issue been solved on your end? You talked about it a few post back last year and not being able to fix it. The issue is still here and I'd like it to be gone point me in the right direction and I'll have at it if not. and as RT mentioned the DFxFRACINC work fine in stella but act wonky on the harmony causing my playfield to bounce up and down. It may just be that I have them sat incorrectly though, still looking into it. Edited May 29, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
+batari Posted June 1, 2011 Share Posted June 1, 2011 (edited) Has the DPC+ playfield stairstep issue been solved on your end? You talked about it a few post back last year and not being able to fix it. The issue is still here and I'd like it to be gone point me in the right direction and I'll have at it if not. and as RT mentioned the DFxFRACINC work fine in stella but act wonky on the harmony causing my playfield to bounce up and down. It may just be that I have them sat incorrectly though, still looking into it. Yes, it has been fixed. I had been meaning to get playfield plotting and scrolling working before I do another release, but if you want a release without those features, I can probably do that. Edited June 1, 2011 by batari Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted June 2, 2011 Share Posted June 2, 2011 I'm not using those features myself, so toss the current build my way. Much appreciated! Quote Link to comment Share on other sites More sharing options...
+batari Posted June 2, 2011 Share Posted June 2, 2011 (edited) Has the DPC+ playfield stairstep issue been solved on your end? You talked about it a few post back last year and not being able to fix it. The issue is still here and I'd like it to be gone point me in the right direction and I'll have at it if not. and as RT mentioned the DFxFRACINC work fine in stella but act wonky on the harmony causing my playfield to bounce up and down. It may just be that I have them sat incorrectly though, still looking into it. Looks like this bug was always present but was exacerbated with the "fix" of the previous bug where DFxFRACHI was cleared with a write to DFxFRACLOW. Try this new DPC+.arm. DPC+.zip Edited June 2, 2011 by batari 1 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted June 2, 2011 Share Posted June 2, 2011 (edited) That solved the bouncing issue thank you. I can remove my workaround now and spare some cycles Now how do I go about removing the stairstep gfx bug? I can just edit the source myself if you'd like to hold off on the update package, just tell me where the issue is being caused and I'll go patch it. Edited June 2, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
gjc082071 Posted June 6, 2011 Share Posted June 6, 2011 Don't know if this count but I don't know where else to look for help. I've checked the official VbB guide & can find nothing. I've followed the video tutorial step by step, posted on Youtube VbB Atari posts, etc. When I try to compile & run I end up with: "Could not locate default.bas.bin and could not recompile. Please check to make sure it was compiled correctly". Can somebody please tell me how to fix this? Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted June 14, 2011 Share Posted June 14, 2011 Man this has been one confusing bug, took two days to identify that it wasn't my fault If you add a single line comment such as: var1 = 2 ;This comment will break the next line of code if var1 = 2 then goto skip_var1 var1 = 1 skip_var1 It will not test var1 and will continue to assign var1 = 1, however a rem comment works just fine Bug in the parser causing the next line to be treated as a comment? Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 14, 2011 Share Posted June 14, 2011 Man this has been one confusing bug, took two days to identify that it wasn't my fault If you add a single line comment such as: var1 = 2 ;This comment will break the next line of code if var1 = 2 then goto skip_var1 var1 = 1 skip_var1 It will not test var1 and will continue to assign var1 = 1, however a rem comment works just fine Bug in the parser causing the next line to be treated as a comment? I just checked this, the comment line is causing the lines before and after to be joined together. For example, COLUBK = $44 ; comment COLUBK = $C4 is compiled as though it were COLUBK = $44 COLUBK = $C4 which of course fails. This is probably something happening in the preprocessor. You can work around it by ending the previous line with a semicolon, although this assumes that it's okay for the two lines to be parsed together like that (which would not always be the case): COLUBK = $44 : ; comment COLUBK = $C4 will compile as COLUBK = $44 : COLUBK = $C4 Michael 1 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted July 17, 2011 Share Posted July 17, 2011 I'm not really sure if this is a bug or a coding error on my part, but if I try and evaluate score such as: score = 111111 :rem Value is example only, any value works if score = 0 then goto Game_Over :rem this always evaluates true It always evaluates true regardless of the scores value, is there a special way to go about checking this? Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 18, 2011 Share Posted July 18, 2011 With comparisons, bB treats score like a regular single byte variable. You can see that if you check the generated assembly file. The usual workaround is to check all 3 bytes yourself... dim sc0=score dim sc1=score+1 dim sc2=score+2 score=111111 if sc0=0 && sc1=0 && sc2=0 then goto Game_Over 1 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted July 25, 2011 Share Posted July 25, 2011 (edited) For the last few days I've been getting erroneous errors, for instance the latest: EggVentureNTSC.bas.asm (10549): error: Illegal character ':'. However the error is not on this line but somewhere above it. I've quintuple checked for out of place colons, and found none. The error seem to be related to whitespace, and/or comments. As removing them or adding/subtracting blank lines also let it then compile. I just now added some more legit code such as: temp1 = temp1 and BZZZZZZ! it breaks again, so something is causing it to be VERY temperamental as of late. I've been reworking the entire game, making changes little by little to ensure I wasn't breaking things along the way and this seems to crop up out of nowhere. Any encounters with this issue before? any ideas what might be going on? It compiles once white space is added or removed on random lines it seems... VERY strange issue. Edited July 25, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
jrok Posted July 25, 2011 Share Posted July 25, 2011 For the last few days I've been getting erroneous errors, for instance the latest: EggVentureNTSC.bas.asm (10549): error: Illegal character ':'. However the error is not on this line but somewhere above it. I've quintuple checked for out of place colons, and found none. The error seem to be related to whitespace, and/or comments. As removing them or adding/subtracting blank lines also let it then compile. I just now added some more legit code such as: temp1 = temp1 and BZZZZZZ! it breaks again, so something is causing it to be VERY temperamental as of late. I've been reworking the entire game, making changes little by little to ensure I wasn't breaking things along the way and this seems to crop up out of nowhere. Any encounters with this issue before? any ideas what might be going on? It compiles once white space is added or removed on random lines it seems... VERY strange issue. I'm not sure what the issue is either, but yes I've experienced it and it seems to be related to whitespace. I've had to CTRL-Z through dozen changes and generally walk on eggshells, adding hard returns where none seem needed, yet seem to satisfy the compiler. Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 25, 2011 Share Posted July 25, 2011 Which OS are you guys using? I've been working on a few projects and haven't run into any whitespace troubles yet, though I'm using Ubuntu, so it may be an OS-specific issue. Quote Link to comment Share on other sites More sharing options...
+batari Posted July 25, 2011 Share Posted July 25, 2011 For the last few days I've been getting erroneous errors, for instance the latest: EggVentureNTSC.bas.asm (10549): error: Illegal character ':'. However the error is not on this line but somewhere above it. I've quintuple checked for out of place colons, and found none. The error seem to be related to whitespace, and/or comments. As removing them or adding/subtracting blank lines also let it then compile. I just now added some more legit code such as: temp1 = temp1 and BZZZZZZ! it breaks again, so something is causing it to be VERY temperamental as of late. I've been reworking the entire game, making changes little by little to ensure I wasn't breaking things along the way and this seems to crop up out of nowhere. Any encounters with this issue before? any ideas what might be going on? It compiles once white space is added or removed on random lines it seems... VERY strange issue. If you can send me the source that generates this error, I can look into it. I want to do another release in a few days and want to take care of some lingering issues. Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted July 25, 2011 Share Posted July 25, 2011 (edited) Sorry, my project is in development and I cannot share the source at this time. However I believe I have tracked down what is going on. Here is a code snippet: ; ***************************************************** ; * BANK 5 ; ***************************************************** bank 5 temp1 = temp1 Start_Restart gosub titledrawscreen if proMode then P0lives = 5 else P0lives = 10 if P0_lockinput <> 0 then P0_lockinput = P0_lockinput - 1 if P0_lockinput = 0 && joy0fire then goto Intro_Animate proMode = SWCHB{6} goto Start_Restart Intro_Animate When it errors out it does something like this: .L0680 ; if proMode then P0lives = 5 else P0lives = 10 BIT Bool1 BPL .skipL0680 .condpart222 LDA #5 STA P0lives jmp .skipelse21 .skipL0680 LDA #10 STA P0lives STA C: ;<- It adds a extra store here to C: .skipelse21 However add a space right after the assignment where the parsing error happens and it fixes the problem: Start_Restart gosub titledrawscreen if proMode then P0lives = 5 else P0lives = 10 if P0_lockinput <> 0 then P0_lockinput = P0_lockinput - 1 if P0_lockinput = 0 && joy0fire then goto Intro_Animate proMode = SWCHB{6} goto Start_Restart Thus compiles to: .L0680 ; if proMode then P0lives = 5 else P0lives = 10 BIT Bool1 BPL .skipL0680 .condpart222 LDA #5 STA P0lives jmp .skipelse21 .skipL0680 LDA #10 STA P0lives ;<- No C: after this line, this is how it should be .skipelse21 . ; Hope this has enough info in it, if not I can try to conjure up some more. Edited July 25, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
+batari Posted July 25, 2011 Share Posted July 25, 2011 I tried putting the code above into a short bB program (with defines and dims to make it build) and I did not get the error. I can try a few things (the problem may be related to uninitialized memory, which I can clear) and you can tell me after the build if it worked or not. If the fixes don't work, I will need some code that replicates the error. Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted July 25, 2011 Share Posted July 25, 2011 (edited) 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]); Comparing the compiled statement, this is the only area I think that defines the LDA STA and another LDA after it. So I think that it thinks we are addressing a Fixed point VAR. Edited August 14, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted July 25, 2011 Share Posted July 25, 2011 If you can send me the source that generates this error, I can look into it. Sorry, my project is in development and I cannot share the source at this time. I'm pretty sure batari isn't going to rip your game off if you send him the code. It'll be much easier to track the bug down with it. 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.