Author Topic: Bug Reports  (Read 454466 times)

0 Members and 5 Guests are viewing this topic.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1395 on: July 15, 2011, 10:13:44 pm »
'appv' is not parsed as 15h, unlike it is when in a string. This should probably be changed to return the same ASCII value it would represent in a string. The same probably goes for 'var' and 'grp'.


EDIT: Also, an entirely unrelated bug. B_CALL(_DelVarArc) apparently trashes (OP1) if the variable was archived, so attempting to create a variable that already exists in the archive deletes the old one and then fails to create the new one. Luckily, this is easily fixable. I found a solution that I think is as good as it gets, but I could be wrong. It only costs a single byte.

Code: [Select]
p_NewVar:
.db __NewVarEnd-1-$
B_CALL(_EnoughMem)
pop hl
ex (sp),hl
jr c,__NewVarFail
push de
push hl
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__NewVarSkip
B_CALL(_DelVarArc)
__NewVarSkip:
pop hl
ld a,(hl)
MOV9TOOP1()
pop hl
push af
B_CALL(_CreateVar)
pop af
ex de,hl
and %00011111
ret z
cp CplxObj
ret z
inc hl
inc hl
ret
__NewVarFail:
ld hl,0
ret
__NewVarEnd:
« Last Edit: July 15, 2011, 10:57:46 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 #1396 on: July 18, 2011, 04:30:00 pm »
Apparently the bad flash error is still there.  I upgraded straight from 053 to 101 (no, I didn't use 100 at all and yes, it's actually 101) and it's happening.

Edit: have now downgraded back to 053 :P
« Last Edit: July 19, 2011, 01:49:52 am by Darl181 »
Vy'o'us pleorsdti thl'e gjaemue

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: Bug Reports
« Reply #1397 on: July 18, 2011, 05:20:09 pm »
Apparently the bad flash error is still there.  I upgraded straight from 053 to 101 (no, I didn't use 100 at all and yes, it's actually 101) and it's happening.
I chatted with Quigibo the other day and he's going to fix some of the flash handling stuff soon.
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

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 #1398 on: July 19, 2011, 02:42:02 am »
I know I know, I've been meaning to update but I've been so busy IRL, as soon as I have free time again, I'm going to fix all the bugs.  Sorry about that.
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline mrmprog

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 559
  • Rating: +35/-1
    • View Profile
Re: Bug Reports
« Reply #1399 on: July 19, 2011, 03:57:05 am »
Will the update add any thing new, or just bug fixes? I just printed the documentation and command list, and I don't want to have to reprint :)

Offline TIfanx1999

  • ಠ_ಠ ( ͡° ͜ʖ ͡°)
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 6173
  • Rating: +191/-9
    • View Profile
Re: Bug Reports
« Reply #1400 on: July 19, 2011, 08:25:52 am »
I know I know, I've been meaning to update but I've been so busy IRL, as soon as I have free time again, I'm going to fix all the bugs.  Sorry about that.

It's all good. No need to rush. Everyone appreciates all the hard work and time put into axe. :)

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1401 on: July 20, 2011, 01:10:28 am »
Yay, another bug involving a routine dealing with OS variables. In p_GetArc, it's possible that the VAT entry inside of the archived variable can span two pages, which isn't accounted for. It's unfortunate to have to add 9 bytes to account for a one in a thousand error, but it must be done. It doesn't have to be done after B_CALL(_LoadDEIndPaged) though, because Axe's archive access routines account for page overflows on their own.

EDIT: An even worse bug, the routine doesn't even verify that the variable being searched for is archived in the first place! This has been fixed too in the second code block.

Code: (Old code) [Select]
p_GetArc:
.db __GetArcEnd-1-$
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__GetArcFail
B_CALL(_IsFixedName)
ld hl,9
jr z,__GetArcName
__GetArcStatic:
ld l,12
and %00011111
jr z,__GetArcDone
cp l
jr z,__GetArcDone
ld l,14
jr __GetArcDone
__GetArcName:
add hl,de
B_CALL(_LoadDEIndPaged)
ld d,0
inc e
inc e
__GetArcDone:
add hl,de
ex de,hl
pop hl
ld (hl),e
inc hl
ld (hl),d
inc hl
ld (hl),b
ex de,hl
ret
__GetArcFail:
ld hl,0
pop de
ret
__GetArcEnd:
       
   
Code: (New code) [Select]
p_GetArc:
.db __GetArcEnd-1-$
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__GetArcFail
dec b
inc b
jr z,__GetArcFail
B_CALL(_IsFixedName)
ld hl,9
jr z,__GetArcName
__GetArcStatic:
ld l,12
and %00011111
jr z,__GetArcDone
cp l
jr z,__GetArcDone
ld l,14
jr __GetArcDone
__GetArcName:
add hl,de
bit 7,h
jr z,$+7
res 7,h
set 6,h
inc b
B_CALL(_LoadDEIndPaged)
ld d,0
inc e
inc e
__GetArcDone:
add hl,de
ex de,hl
pop hl
ld (hl),e
inc hl
ld (hl),d
inc hl
ld (hl),b
ex de,hl
ret
__GetArcFail:
ld hl,0
pop de
ret
__GetArcEnd:
       
« Last Edit: July 20, 2011, 06:32:15 pm by Runer112 »

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1402 on: July 20, 2011, 06:51:55 pm »
Some more bugs:

  • Axe doesn't recognize 00h as an invalid token when parsing.

  • Zeros(0) should add zero bytes of data, not 65536.

  • This has been brought up before, but apparently not dealt with yet. getKeyr should perform res appRetKeyOff,(iy+APIFlg) (that's res 7,(iy+28h)) after grabbing a keycode so this doesn't happen:

    getKeyr has a slight problem, not sure whether or not it's worth fixing. The bit that is set to prevent 2nd + ON from turning off the calculator is still set when the program exits. If the program is simply run from the homescreen, when it returns, 2nd + ON does nothing. Although this effect can be reversed by doing something like opening a menu, it's still a slight problem.

  • When listing Axe source programs and Axe backups, it doesn't appear that Axe ANDs the variable type of located variables with %00011111. This can result in backups being treated like source programs, having compile and back up options instead of a leading hash mark and a restore option.

« Last Edit: July 20, 2011, 11:03:15 pm by Runer112 »

Offline defmenge

  • LV3 Member (Next: 100)
  • ***
  • Posts: 40
  • Rating: +5/-0
    • View Profile
Re: Bug Reports
« Reply #1403 on: July 25, 2011, 10:19:52 am »
The increment/decrement operators (++/--) seem to be "invalid tokens", if used with memory locations/curly brackets (haven't tested variables).
Spoiler For DROD8x:
Status: Pre-Alpha "ROACHIE" - Progress: 20%
[=====] Graphics: 100% (full greyscale tileset)
[==== ] Tilemapping: 80% (maps load successfully, additional tile data not implemented yet)
[=    ] Storage formats: 20% (planned: segmentable holds, composed of levels, made of up to [presumably] 8x8 rooms)
[==   ] Monsters: 40% (roaches and roach queen AI working; planned: eyes, wubbas, golems and possibly more)
[     ] Gameplay Elements: 0% (walls and floors only)
[     ] GUI: 0% (very bare in-game GUI)
[=    ] Editor: 20% (integrated basic editor)
Project is currently on hold due to lots of homework and tests.

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: Bug Reports
« Reply #1404 on: July 25, 2011, 11:11:53 am »
The increment/decrement operators (++/--) seem to be "invalid tokens", if used with memory locations/curly brackets (haven't tested variables).
Did you put them before or after? They need to go after.
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

Offline defmenge

  • LV3 Member (Next: 100)
  • ***
  • Posts: 40
  • Rating: +5/-0
    • View Profile
Re: Bug Reports
« Reply #1405 on: July 25, 2011, 11:34:49 am »
I put it after the expression, the bug was not present in 1.0.1.
Spoiler For DROD8x:
Status: Pre-Alpha "ROACHIE" - Progress: 20%
[=====] Graphics: 100% (full greyscale tileset)
[==== ] Tilemapping: 80% (maps load successfully, additional tile data not implemented yet)
[=    ] Storage formats: 20% (planned: segmentable holds, composed of levels, made of up to [presumably] 8x8 rooms)
[==   ] Monsters: 40% (roaches and roach queen AI working; planned: eyes, wubbas, golems and possibly more)
[     ] Gameplay Elements: 0% (walls and floors only)
[     ] GUI: 0% (very bare in-game GUI)
[=    ] Editor: 20% (integrated basic editor)
Project is currently on hold due to lots of homework and tests.

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: Bug Reports
« Reply #1406 on: July 25, 2011, 11:53:59 am »
I just tried it myself, you are right. It only seems to occur with one-byte constant pointers, though.
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1407 on: July 29, 2011, 03:31:27 pm »
The increment/decrement operators (++/--) seem to be "invalid tokens", if used with memory locations/curly brackets (haven't tested variables).

I just tried it myself, you are right. It only seems to occur with one-byte constant pointers, though.

It's probably worth clarification that although parsing only fails with one-byte increments/decrements at constant pointers, all increments/decrements at constant pointers are afflicted with a problem. It seems that somehow all the routine references were shifted one position according to the number of r modifiers. If you specify n r modifiers, the parser will look for the routine that would correspond to n-1 r modifiers. So the one-byte increments/decrements fail because there is no routine for -1 r modifiers, but although the other two do not error, they look to the wrong routines.

Offline calcdude84se

  • Needs Motivation
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2272
  • Rating: +78/-13
  • Wondering where their free time went...
    • View Profile
Re: Bug Reports
« Reply #1408 on: July 30, 2011, 03:49:46 pm »
It's not just increment/decrement. For example, this code will display the value of the two bytes at $BEEF (arbitrary value):
Disp {EBEEF}minY>Disp
Note that by ">Disp" I mean the single token, and that minY is a two-byte token (It's a statistics variable) whose second byte happens to be the same as the single byte of the r token.
« Last Edit: July 30, 2011, 03:50:22 pm by calcdude84se »
"People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster."
-Adam Osborne
Spoiler For "PartesOS links":
I'll put it online when it does something.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1409 on: July 30, 2011, 04:00:28 pm »
Well that's a whole other problem entirely. Axe 1.X seems to have problems identifying invalid tokens and throwing errors upon reaching them. As an extension of this problem, if you use an invalid token that Axe does recognize as invalid but you have included an Axiom in your program, it takes Axe a good few seconds upon reaching the invalid token to finally throw an error.