Author Topic: Bug Reports  (Read 454585 times)

0 Members and 2 Guests are viewing this topic.

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Bug Reports
« Reply #1050 on: January 28, 2011, 07:41:22 pm »
Nothing I can really do about that unfortunately unless someone wants to looking into the disassembly of the bcall.  It isn't documented.
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline jnesselr

  • King Graphmastur
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2270
  • Rating: +81/-20
  • TAO == epic
    • View Profile
Re: Bug Reports
« Reply #1051 on: January 28, 2011, 07:45:10 pm »
It's probably GetKey if that's what you are using Quigibo.

Offline Camdenmil

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 121
  • Rating: +4/-0
    • View Profile
Re: Bug Reports
« Reply #1052 on: February 01, 2011, 07:57:39 pm »
I don't know if I touched a section of memory I shouldn't have but every now and then when I compile a program the screen will turn off. When I turn it back on it will show that is crashed right after displaying the text that says compiling and then proceed to the ram cleared screen. I havn't figured out how to reproduce it though, it seems random.
It is bad luck to be superstitious.

Offline Deep Toaster

  • So much to do, so much time, so little motivation
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 8217
  • Rating: +758/-15
    • View Profile
    • ClrHome
Re: Bug Reports
« Reply #1053 on: February 01, 2011, 08:06:25 pm »
Maybe Axe got corrupted? Try redownloading it (make sure it's 0.4.8).
« Last Edit: February 01, 2011, 10:27:06 pm by Deep Thought »




Offline ztrumpet

  • The Rarely Active One
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5712
  • Rating: +364/-4
  • If you see this, send me a PM. Just for fun.
    • View Profile
Re: Bug Reports
« Reply #1054 on: February 01, 2011, 08:41:44 pm »
Nothing I can really do about that unfortunately unless someone wants to looking into the disassembly of the bcall.  It isn't documented.
I know Kerm took the [2nd] [Quit] away in DoorsCS7.  Maybe you could ask him how he did it. :)

Deep, [nobbc] is your friend!

Maybe Axe got corrupted? Try redownloading it (make sure it's 0.4.8).

Offline Deep Toaster

  • So much to do, so much time, so little motivation
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 8217
  • Rating: +758/-15
    • View Profile
    • ClrHome
Re: Bug Reports
« Reply #1055 on: February 01, 2011, 10:26:34 pm »
Didn't see that, whoops 8)




Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Bug Reports
« Reply #1056 on: February 01, 2011, 10:35:42 pm »
If it is the b_call that allows for modifier keys (EF7249), pressing [2nd]+[ON] should shut the calc off and when you turn it back on, it should return to the homescreen. I have never had a problem with that and that is what I normally use when I am debugging (and I've messed with the stack).

Offline Deep Toaster

  • So much to do, so much time, so little motivation
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 8217
  • Rating: +758/-15
    • View Profile
    • ClrHome
Re: Bug Reports
« Reply #1057 on: February 01, 2011, 11:08:18 pm »
If it is the b_call that allows for modifier keys (EF7249), pressing [2nd]+[ON] should shut the calc off and when you turn it back on, it should return to the homescreen. I have never had a problem with that and that is what I normally use when I am debugging (and I've messed with the stack).

Doesn't it lose you a few bytes? I always thought it did.




Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Bug Reports
« Reply #1058 on: February 01, 2011, 11:14:52 pm »
Yes! I never noticed that before... The number of bytes you lose is equal to how large the code is. So maybe that is the problem? It could just be messing with the RAM a little too much. I wonder how large the program is?

Offline Deep Toaster

  • So much to do, so much time, so little motivation
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 8217
  • Rating: +758/-15
    • View Profile
    • ClrHome
Re: Bug Reports
« Reply #1059 on: February 01, 2011, 11:21:16 pm »
Yes! I never noticed that before... The number of bytes you lose is equal to how large the code is. So maybe that is the problem? It could just be messing with the RAM a little too much. I wonder how large the program is?

I think it forces a return to the homescreen without cleaning up after the program, so a "ghost" copy is left in mem. Not sure, though.

In any case it's bad for anything but debugging. That's why I usually use GetKeyRetOff (EF0B50). Undocumented, though, which might have other problems.
« Last Edit: February 01, 2011, 11:21:41 pm by Deep Thought »




Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Bug Reports
« Reply #1060 on: February 01, 2011, 11:29:54 pm »
I think it forces a return to the homescreen without cleaning up after the program, so a "ghost" copy is left in mem. Not sure, though.
Yeah, I am fairly sure that is what happens. It is the same thing if you use that bcall that ends an app. I never knew about EF0B50... I'm going to check that out :D

Offline Deep Toaster

  • So much to do, so much time, so little motivation
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 8217
  • Rating: +758/-15
    • View Profile
    • ClrHome
Re: Bug Reports
« Reply #1061 on: February 02, 2011, 09:16:44 am »
It's basically GetKey (EF7249) but 2ND+[OFF] returns $3F instead of turning off the calc.




Offline Darl181

  • «Yo buddy, you still alive?»
  • CoT Emeritus
  • LV12 Extreme Poster (Next: 5000)
  • *
  • Posts: 3408
  • Rating: +305/-13
  • VGhlIEdhbWU=
    • View Profile
    • darl181.webuda.com
Re: Bug Reports
« Reply #1062 on: February 03, 2011, 02:38:34 pm »
Okay, IDK what's wrong with this.
Spoiler For code:
Code: [Select]
:.TIO Turn it off
:[F0F0F0F000000000]→Pic1
:DiagnosticOff
:ClrDraw
:0→C→M-1→D
:For(A,0,23
:A*4→X
:For(B,0,15
:D+1→D
:B*4→Y
:If rand^9^2
:Pt-On(X,Y,Pic1
:2→{L1+D}
:C+1→C
:Else
:1→{L1+D}
:End
:End
:End
:rand^23→X
:rand^15→Y
:Y*24+X→D
:Lbl 1
:!If C
:ClrHome
:Disp "WIN"
:Pause 1900
:Return
:End
:Repeat getKey(15)
:Repeat getKey(0)
:ReturnIf getKey(15)
:For(A,0,9
:Pt-Change(X*4,Y*4,Pic1
:DispGraph
:ReturnIf getKey(15)
:End
:If getKey(54)
:ClrHome
:Disp "C",C►Dec," D",D►Dec,i,"X",X►Dec," Y",Y►Dec,i,"L1+D",{L1+D}►Dec
:While getKey(54):Pause 10:End
:End
:End
:If getKey(2) and (X>0)
:While getKey(2):Pause 10:End
:D-1→D
:X-1→X
:sub(D)
:Goto 1
:End
:If getKey(3) and (X<23)
:While getKey(3):Pause 10:End
:D+1→D
:X+1→X
:sub(D)
:Goto 1
:End
:If getKey(1) and (Y<15)
:While getKey(1):Pause 10:End
:D+24→D
:Y+1→Y
:sub(D)
:Goto 1
:End
:If getKey(4) and (Y>0)
:While getKey(4):Pause 10:End
:D-24→D
:Y-1→Y
:sub(D)
:Goto 1
:End
:End
:Return
:
:
:Lbl D
:If {L1+D}=1
:2→{L1+D}
:C+1→C
:End
:If {L1+D}=2
:1→{L1+D}
:C-1→C
:End
:Pt-Change(X*4,Y*4,Pic1
.Return
Theoretically, C should change.  ++ every box every time a box turns black, -- for every box turned white.  Thing is, a good part of the time it doesn't.
C is the remaining number of black blocks to be turned off.  Clearly, it's not accurate.
I think there's a problem with it storing in L1.  but it's always worked fine before ???
If you hold 2nd, data comes up.  C is explained above, and the game ends when getkey(15) or C=0[zero].
D is the pointer's location.  The formula is Y*24+X→D.  ie if the selector is in the 9th row and the 3rd column, D is 3*24+9=81.  The xy coordinates are next.  (When drawn to the screen, they're inflated by 4.)
"L1+D" should be the status of the block beneath the selected square.  1 is off, 2 is on.
Hopefully somebody notices it here...I'm pretty sure it's an axe bug b/c pretty much the exact same thing worked before (in TWHG).  Ever since I've updated to Axe 0.4.8, I've been having one problem after another of this nature, also with some problems with RotC( and RotCC( which didn't work when I tried to use them.
So, I was wondering...what changed?  Because data storage to lists and external appvars wasn't failing like this before, and now it fails more often than it works. ???

This is kind of my last-ditch attempt to find out wtf is going wrong, after this I'm downgrading back to 0.4.5.  Can't seem to find another solution, unless I find this out.

EDIT: I'll apologize in advance if this sounds sort of rude or whatever, I'm in kind of a tense mood today  :(
« Last Edit: February 03, 2011, 02:52:42 pm by Darl181 »
Vy'o'us pleorsdti thl'e gjaemue

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1063 on: February 03, 2011, 03:34:39 pm »
Hopefully somebody notices it here...I'm pretty sure it's an axe bug b/c pretty much the exact same thing worked before (in TWHG).  Ever since I've updated to Axe 0.4.8, I've been having one problem after another of this nature, also with some problems with RotC( and RotCC( which didn't work when I tried to use them.
So, I was wondering...what changed?  Because data storage to lists and external appvars wasn't failing like this before, and now it fails more often than it works. ???

After close inspection, I noticed a few things that could be causing problems in the code you posted. Firstly, the End:If {L1+D}=2 in subroutine D should just be replaced with an Else. Otherwise, the first if statement may activate and change {L1+D} to 2, thus also activating the following if statement, effectively negating the change you want. The other problem I noticed is that the data isn't being generated correctly for how you step through it later. To generate the data, you loop through Y values inside of a loop through X values, thus making X the "major" direction. However, in all other places in your program, you assign Y as the "major" direction. You should change the data generation code so the X loop is inside of the Y loop. Hopefully these two things will solve your problems!

I also can explain the bugs in Axe 0.4.8 with rotC() and rotCC(), as those are my fault. I supplied Quigibo with optimized routines for them, but neither of us noticed until it was too late that the code had a slight fault. Instead of returning the pointer to the rotated sprite, they return the pointer plus eight. For a temporary fix you can add -8 after any rotate commands in Axe 0.4.8. Hopefully this problem will be fixed in the next version though, so if it is, make sure to get rid of any -8's that you may have added.

Quigibo: If you're reading this and haven't already fixed the rotate problem, I posted the corrected code a while back here.
« Last Edit: February 03, 2011, 03:35:33 pm by Runer112 »

Offline Darl181

  • «Yo buddy, you still alive?»
  • CoT Emeritus
  • LV12 Extreme Poster (Next: 5000)
  • *
  • Posts: 3408
  • Rating: +305/-13
  • VGhlIEdhbWU=
    • View Profile
    • darl181.webuda.com
Re: Bug Reports
« Reply #1064 on: February 04, 2011, 12:41:44 pm »
Okay, that helped and it looks like it's mostly taken care of.  Thanks!
« Last Edit: February 04, 2011, 12:43:11 pm by Darl181 »
Vy'o'us pleorsdti thl'e gjaemue