Jump to content
IGNORED

Bug Report Thread


kisrael

Recommended Posts

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 by Random Terrain
Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 2 months later...

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

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 month later...

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 by ScumSoft
Link to comment
Share on other sites

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 by batari
Link to comment
Share on other sites

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 by batari
  • Like 1
Link to comment
Share on other sites

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 by ScumSoft
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Man this has been one confusing bug, took two days to identify that it wasn't my fault :D

 

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?

Link to comment
Share on other sites

Man this has been one confusing bug, took two days to identify that it wasn't my fault :D

 

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

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

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?

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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 by ScumSoft
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by ScumSoft
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by ScumSoft
Link to comment
Share on other sites

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.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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