Author Topic: Bug Reports  (Read 161616 times)

0 Members and 1 Guest are viewing this topic.

Offline Freyaday

  • The One And Only Serial Time Killing Catboy-Capoeirista-Ballerino
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1970
  • Rating: +128/-15
  • I put on my robe and pixel hat...
    • View Profile
Re: Bug Reports
« Reply #1485 on: September 21, 2011, 09:55:07 pm »
Thanks!

And, unfortunately, the problem is not like that. The scanlines are completely frozen.
In other news, Frey continues kicking unprecedented levels of ass.
Proud member of LF#N--Lolis For #9678B6 Names


I'm a performer at heart; I stole it last week.
My Artwork!

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1486 on: September 24, 2011, 07:07:02 pm »
Good news Freyaday, I found your bug. I always had a lingering feeling that the forward djnz I used in to optimize the 4-level grayscale entry was too good to be true. And it was. It works great 99.9% of the time, which is why nobody saw a problem until now. But the issue is, if (flags+asm_flag2) holds a vaue other than -2, -1, or 0 when the grayscale routine is first called, the grayscale mask isn't rotated for anywhere from 1-253 calls.

This is fixed easily enough to restoring the grayscale mask initialization code for p_Disp4Lvl to what it was in Axe 0.5.3, and changing the mask initialization code for p_Disp4Clr in a similar way.

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 #1487 on: September 24, 2011, 09:45:34 pm »
I refuse to lose bytes and de-optimize! ;) Found an alternative the same size as the original:

Code: (old) [Select]
ld a,%11011011
or a
ld hl,flags+asm_flag2
inc (hl)
jr z,__Disp4LvlSkip
rra
ld b,(hl)
djnz __Disp4LvlSkip
rra
ld (hl),-2
__Disp4LvlSkip:
Code: (new) [Select]
ld a,%10110110
ld hl,flags+asm_flag2
cp (hl)
jr z,__Disp4LvlSkip1
jr c,__Disp4LvlSkip2
ld a,%01101101
__Disp4LvlSkip1:
scf
rla
__Disp4LvlSkip2:
rla
ld (hl),a

Its a pretty cool optimization.  Instead of the mapping (-2:-1) (-1:0) (0:-2) the new mapping is now (equal:larger) (larger:smaller) (smaller:equal) with respect to the number %10110110.
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline Freyaday

  • The One And Only Serial Time Killing Catboy-Capoeirista-Ballerino
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1970
  • Rating: +128/-15
  • I put on my robe and pixel hat...
    • View Profile
Re: Bug Reports
« Reply #1488 on: September 26, 2011, 02:35:27 am »
Well, lookit that.
Also, I just downloaded 1.0.4 and the first thing I did was to try compiling LVEDIT

COMPILING...
1st pass 58%
ERROR:
UNKNOWN ERROR
Code: A429992

LVEDIT was archived, so I don't know what it erred on.

EDIT: I UnArchived it, and it compiled fine.

Got the same error at 5% with Minedit. Say, is this 1.0.4's version of BAD FLASH?

Also, MINER is experiencing a really bad bug that, as far as I can tell (which is not very far) seems to result from {Q+L1} erroneously returning a 1 instead of a zero, which is really odd, because if that is indeed what is happening, then it's only doing so in one loop, and not doing so in a later loop.

Also, holy crap! Quigibo, what did you do? Horizontal is waaay faster now!
« Last Edit: September 26, 2011, 02:47:27 am by Freyaday »
In other news, Frey continues kicking unprecedented levels of ass.
Proud member of LF#N--Lolis For #9678B6 Names


I'm a performer at heart; I stole it last week.
My Artwork!

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 #1489 on: September 26, 2011, 03:19:03 am »
Horizontal should only be unnoticeably faster... regular multiplication was the only routine that received a significant speedup, but only when you don't use ** or *^ anywhere in the code.

I've fixed the A429992 error now, I'll upload the patch soon.  I just need to find a couple other easy things to add to make the update have some kind of new features.  For that other problem, could you post some source code that caused the error (if it was indeed the compiler's fault)?
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline Freyaday

  • The One And Only Serial Time Killing Catboy-Capoeirista-Ballerino
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1970
  • Rating: +128/-15
  • I put on my robe and pixel hat...
    • View Profile
Re: Bug Reports
« Reply #1490 on: September 26, 2011, 04:57:37 am »
I'm using Horizontal to move the screen off to the right in an animation.

The source for MINEDIT is attached.
In other news, Frey continues kicking unprecedented levels of ass.
Proud member of LF#N--Lolis For #9678B6 Names


I'm a performer at heart; I stole it last week.
My Artwork!

Offline Darl181

  • Vy'o'us pleorsdti thl'e gjaemue
  • CoT Emeritus
  • LV12 Extreme Poster (Next: 5000)
  • *
  • Posts: 3408
  • Rating: +305/-13
  • VGhlIEdhbWU=
    • View Profile
    • darl181.webuda.com
Re: Bug Reports
« Reply #1491 on: September 26, 2011, 10:18:57 am »
I've had a few problems with the instant goto.  I'd get err:parenthesis and goto.  Editing is fine, but once I quit some program or another will sometimes have an edited name (ie one time the archived program "SDOTRUN2" became SDOTRU►2").  thepenguin's archive cleaner fixes it, btw, but it's still kind of concerning..
Still exists in 1.0.4 :(

Offline p2

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 848
  • Rating: +51/-11
  • I'm back :)
    • View Profile
Re: Bug Reports
« Reply #1492 on: September 26, 2011, 11:21:22 am »
Fryaday, I have two!!  ;D


Axe 1.0.4:    THE SAME ONE WHICH FRIADAY ALREADY HAD
compiling an AD´SM-progrsam (noshell), that already exists:
compiling 4%
Unknown Error
A429992

Backing-up after compiling an app:
unknown error
A429958


I don't think that's what it should do...  :-\
« Last Edit: September 26, 2011, 11:23:06 am by p2 »
*insert supercool signature*

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Bug Reports
« Reply #1493 on: September 26, 2011, 11:22:43 am »
Quigibo says he already fixed the A429992 error.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1494 on: September 26, 2011, 04:44:35 pm »
Good news everybody! After a bit of examination of Axe's string parsing code, I've pinned down the exact cause of random characters in strings being replaced with 'r'. I even found two other bugs in the process!

The errors lie in this routine, found at $66FC in Axe 1.0.4:

Code: [Select]
GetTokString:
or a
ret z
ld hl,OP1
ld (hl),a
cp tVarEqu
jr z,GetTokString_uvw
cp tProg
ld a,ProgObj
ret z
ld a,(hl)
B_CALL(_IsA2ByteTok)
call z,ReadAByte
GetTokString_Cont:
ld (OP1+1),a
ld hl,OP1
B_CALL(_Get_Tok_Strng)
ld a,(OP3)
ret
GetTokString_uvw:
call ReadAByte
ld b,a
cp tvn
ld a,AppVarObj
ret z
ld a,b
cp twn
jr nz,GetTokString_Cont
ld a,GroupObj
ret

First, the 'r' bug. When parsing a 2-byte token in a string, a second byte has to be read from the source file. This raises a (1-in-256?) chance of Axe updating the progress counter in the middle of the routine, and B_CALL(_DispHL) places the string representation of HL in OP1. So whenever the progress counter is updated in the middle of reading a 2-byte token in a string, the first byte of the token (which was stored at OP1) is destroyed and replaced with the character code for a space, $20. This is then passed as input into B_CALL(_Get_Tok_Strng), and token $20 is "randM(" which results in the phantom 'r'.

This leads into the next bug, the presence of which probably made diagnosing the first bug more challenging. The length of the token string as reported by B_CALL(_Get_Tok_Strng) (returned in a and bc) is disregarded by Axe, resulting in every token in a source string corresponding to only one character in the compiled string.

The final bug is regarding a token of special meaning to Axe. Although this routine correctly checks if the token is the "appv" or "grp" token, it doesn't check if it's the "var" token.

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 #1495 on: September 26, 2011, 05:30:20 pm »
That makes so much sense now, lol!  I can't believe you were able to get that from disassembly, awesome job!

Those other 2 are not bugs though:

Tokens that are more than 1 character are clipped to create their character counterparts.  For example, the token "det(" just turns into "d" to make it consistent since these are character strings, not token strings.  Also, this is the same routine used for individual character reading in single quotes so it wouldn't make sense there either.

The 'var' token is not a 1-to-1 mapping to a character in a searchable string form.  There is an extra zero that has to be added.  It is handled separately in the string parsing routine instead, just like the string, matrix, and custom list tokens.
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1496 on: September 26, 2011, 05:43:02 pm »
I see what you mean about the 'var' token now. But I still think that tokens that correspond to strings larger than 1 character should be represented in their full form. If someone entered "sin(" into an Axe string, I'm pretty sure they actually want to see "sin(". If they wanted to see "s", they probably would have entered "s". This would especially make more sense to less experienced Axe coders who are familiar with being able to include tokens in strings in TI-BASIC. One way or another, you're probably going to need to address the string parsing code again. Because right now, a 2-byte token in a string = instant crash. :P

EDIT: Whoops, I meant a multi-character token.
« Last Edit: September 26, 2011, 05:52:08 pm by Runer112 »

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 #1497 on: September 26, 2011, 05:49:05 pm »
Whaaaaaaaaat!  It was just working!  I swear!  One sec.

Eh... I'd rather keep string parsing simple for now, so no multi character tokens.

EDIT: That was it Runer, I just found it lol.  That's what I get for coding so fast  <_<
« Last Edit: September 26, 2011, 05:51:55 pm by Quigibo »
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline Oninoni

  • LV0 Newcomer (Next: 5)
  • Posts: 1
  • Rating: +0/-0
    • View Profile
Re: Bug Reports
« Reply #1498 on: September 27, 2011, 02:28:54 am »
Hi i just downloaded Axe 1.0.4 and wanted to compile a code i made with 1.0.2 into an app.
After backupping an unknown error appears :
A429958

If you close it the app still works normally

Offline Eeems

  • Mr. Dictator
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6161
  • Rating: +318/-36
  • C'est la vie
    • View Profile
    • Eeems
Re: Bug Reports
« Reply #1499 on: September 27, 2011, 02:32:42 am »
Hi i just downloaded Axe 1.0.4 and wanted to compile a code i made with 1.0.2 into an app.
After backupping an unknown error appears :
A429958

If you close it the app still works normally
You might want to try with the new 1.0.5b that Quigibo just released today.
/e