Jump to content
kisrael

Bug Report Thread

Recommended Posts

Just a follow-up that TwentySixHundred tracked this down, in a PM. It appears that pfpixel was being given some off-screen data in certain circumstances.

 

It's a known bB limitation that you need to keep pf* function coordinates within bounds, so it's not a bB bug.

  • Like 2

Share this post


Link to post
Share on other sites

I have found a bug with the score in DPC+ where by adding this code

score = score + 252
score = score - _blahblah

or

score = score + 252
score = score - t

One random digit becomes a garbled mess.

default.bas_13.thumb.png.1886f0471feb935df6c0b56f1d8f976e.png

 

If i comment out 'score = score - t' then everything is fine again. The variable 't' only increments by 9 for every pfread and never exceeds 252.

Edited by TwentySixHundred

Share this post


Link to post
Share on other sites

I don't have a link handy at the moment, but take a look in the batari Basic guide for the discussion about the score and binary coded decimal.  in short, the score is stored as binary coded decimal, and you're adding a variable which is not.

  • Like 1

Share this post


Link to post
Share on other sites
22 minutes ago, Karl G said:

I don't have a link handy at the moment, but take a look in the batari Basic guide for the discussion about the score and binary coded decimal.  in short, the score is stored as binary coded decimal, and you're adding a variable which is not.

Thanks! yes i was just about to remove the post as i worked this out. That solved the issue, i really didn't think it aplied for the math that added the to the variable (thought it was the total value) turns out the math also needs to be BCD 👍

 

Edit: Actually it still does it, i will keep playing around with it however everything that stores the value is BCD. Might need to code it a different way/

Edited by TwentySixHundred

Share this post


Link to post
Share on other sites
36 minutes ago, TwentySixHundred said:

Thanks! yes i was just about to remove the post as i worked this out. That solved the issue, i really didn't think it aplied for the math that added the to the variable (thought it was the total value) turns out the math also needs to be BCD 👍

 

Edit: Actually it still does it, i will keep playing around with it however everything that stores the value is BCD. Might need to code it a different way/

 

Have you looked at this:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#bcd_dec

Share this post


Link to post
Share on other sites
10 minutes ago, Random Terrain said:

Yeah i have, for some reason it just wasn't liking my subtraction however i never tested in dec mode. It's all good as i scrapped that idea and rewrote for the cost of an additional 8bytes. Rather then subtracting the value of that variable i just added the score per playfield check with and 'else' condition.

 

I had plans to still use that variable globally later down the track and i still can, as the next feature doesn't require addition or subtraction to the score. I was just trying to eliminate any unnecessary code and share the variable but for the cost of 8bytes im happy 👍

Share this post


Link to post
Share on other sites

Version 1.0, build 568, Win7 64bit.

 

Whenever I post even a small line of code the program will endlessly scroll up then freeze and crash. Am I doing something wrong? It's making me crazy!

 

Also, in forums, I see that I can edit a post but is it possible for me to delete a post completely? I only recently started posting here and sometimes I reply in the wrong forum. I don't want to be annoying.

 

Thanks for any help.
 

Share this post


Link to post
Share on other sites

Seems that bBasic doesn't like simple expresssions wrapped in parenthesis:

.L0803 ;    rem --- set bonus if red plane group

.L0804 ;    if NewCOLUP1 = _CI_RedPlane then w_stage_bonus_counter = (32 - stage)

	LDA NewCOLUP1
	CMP #_CI_RedPlane
     BNE .skipL0804
.condpart149
	LDA #(32
	SEC
	SBC stage)
	STA w_stage_bonus_counter
.skipL0804

 

Share this post


Link to post
Share on other sites

Seems to be working on my end...

    735  8000                              .L04                 ;; w_stage_bonus_counter = ( 32 - stage )
    736  8000
    737  8000                                                   ; complex statement detected
    738  8000                  a9 20                  LDA       #32
    739  8002                  38                     SEC
    740  8003                  e5 e9                  SBC       stage
    741  8005                  85 e8                  STA       w_stage_bonus_counter

From the source code in your generated file, it looks like the preparser didn't add whitespace to the end brace. Guessing that something earlier is leaving the preparser in a bad state.

 

You can likely work around it by manually adding the whitespace to the braces.

 

  • Like 2

Share this post


Link to post
Share on other sites

Yes.  I fixed the issue by adding whitespace.  It's still a tokenizer/parser bug that should be probably be fixed.

 

Also, I think I found a limitation on the number of constants that are allowed to be defined.  If the user exceeds that limitation, the compiler (and/or assembler) should notify the user of that issue.

Share this post


Link to post
Share on other sites
2 hours ago, splendidnut said:

Yes.  I fixed the issue by adding whitespace.  It's still a tokenizer/parser bug that should be probably be fixed.

Yep, I'd just need more info to fix it, since I can't reproduce it. It could be there's a missing "end" or some other similar syntax issue that's leaving the preparser stuck in an incorrect state. That's my working theory anyway, but it's all guessing at this point.

 

Agreed that the compiler should error on constant overflow. I don't have personal cycles to do more than critical bug fixes, and even then not enough for that. I do accept pull requests.

Share this post


Link to post
Share on other sites

The code was within 1942-Bb.  I ended up rewriting that code in a different way, so it's no longer an issue.

 

But, I was able to recreate it (using AtariDevStudio v0.7.5 with bBasic v1.5.)  If you replace https://github.com/splendidnut/1942-bB/blob/main/src/1942_HSC.bas#L1388

with:

   rem --- set bonus if red plane group
   if NewCOLUP1 = _CI_RedPlane then w_stage_bonus_counter = (32-stage)
   rem w_stage_bonus_counter = r_stage_bonus_counter & %01111111

 

Then the Assembly output appears as follows:

.L0797 ;    rem --- set bonus if red plane group

.L0798 ;    if NewCOLUP1 = _CI_RedPlane then w_stage_bonus_counter = (32 - stage)

	LDA NewCOLUP1
	CMP #_CI_RedPlane
     BNE .skipL0798
.condpart148
	LDA #(32
	SEC
	SBC stage)
	STA w_stage_bonus_counter
.skipL0798

 

I completely understand not having the time/energy to commit to fixing this.  So, no worries.  🙂

 

Share this post


Link to post
Share on other sites

Ok, I was close-enough able to reproduce it. "Close-enough" because the source relies on the pluscart bB fork, so I don't get a successful compile, but I can see the issue in the generated list file.

 

It seems this statement is throwing the preparser into a bad state...

if temp2 < 226 then _read_attack_data

...the issue appears to be the "_data" ending of the label name, which is switching the preparser into "data" statement preparsing mode, which it will be stuck in until the preparser encounters an "end" statement. When I change all the labels and variables that end in "_data" to instead end with "_dat" or "_qdata", the reported issue goes away.

 

To avoid unpredictable errors, I'd recommend at this time to not end symbols with an underscore followed by a valid bB statement name. I'll see if this can be fixed when I have more time (and frankly fortitude to dive into the lex code) but at least it's now "known bug with work-around" status.

 

 

  • Like 3

Share this post


Link to post
Share on other sites
24 minutes ago, RevEng said:

To avoid unpredictable errors, I'd recommend at this time to not end symbols with an underscore followed by a valid bB statement name. I'll see if this can be fixed when I have more time (and frankly fortitude to dive into the lex code) but at least it's now "known bug with work-around" status.

 

What happens if the first letter of the valid bB statement name is capitalized?

Share this post


Link to post
Share on other sites
2 minutes ago, Random Terrain said:

What happens if the first letter of the valid bB statement name is capitalized?

That works to avoid the issue, too.

  • Like 2

Share this post


Link to post
Share on other sites

It seems the bB priming reads were problematic. (reverted them in the github master.)

 

If there isn't any other bug reported between now and the weekend, I'll push out a release with the correction.

  • Like 1

Share this post


Link to post
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...