Author Topic: Bug Reports  (Read 398094 times)

0 Members and 1 Guest are viewing this topic.

Offline aeTIos

  • Nonbinary computing specialist
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3915
  • Rating: +184/-32
    • View Profile
    • wank.party
Re: Bug Reports
« Reply #1095 on: February 18, 2011, 02:43:08 pm »
Yeah I agree with Compynerd. Sometimes we don,t expect to run out of memory too.

Also what's with the 3 GB app thing juju? O.O (on IRC)


You can do stuff like that. Just change the size bytes of any var to anything you want, and the OS will think it's that big.
That happens to me often if i have some bugs/wrong codes in my prog, then i have a Y1 that is 36656 bytes big or a Str1 that is 123333 bytes O.O only remedy: ram clear.
« Last Edit: February 18, 2011, 02:43:30 pm by aeTIos »
I'm not a nerd but I pretend:

Offline Mighty Moose

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 141
  • Rating: +4/-0
    • View Profile
Re: Bug Reports
« Reply #1096 on: February 18, 2011, 02:54:23 pm »
Or Calcsys.
Cheers!
I beta test, so...yeah.  PM me if you want me to test anything :D.

Almost only counts in horseshoes and handgrenades.

Cogito ergo sum.

Calcs:
TI-84+, OS 2.43, Boot Code 1.02, 128k RAM
TI-84+SE VSC, OS 2.43, Boot Code 1.00, 128k RAM  (I'm spoiled :P)
TI-81, OS 1.6K (only borrowed)
Casio fx-CG10 (Prizm), OS 01.04.0200
TI-Nspire Clickpad, OS 1.4
TI-Nspire Clickpad, OS 3.1.0.392
TI-Nspire CAS Clickpad, OS 1.6.10110 (!?) now OS 3.1.0.392

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 #1097 on: February 18, 2011, 03:30:57 pm »
* Qwerty.55 is impressed that Mighty Moose keeps a list of the size of every variable on his calc memorized.
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline Mighty Moose

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 141
  • Rating: +4/-0
    • View Profile
Re: Bug Reports
« Reply #1098 on: February 18, 2011, 03:39:20 pm »
Naw, I may be a computer calculator but I am not that good. ;) j/k
You can find the size of a variable wherever the variable is located in memory - the first 2 bytes of any(?) variable are its size bytes, meaning that if you set them to 0, then the OS thinks that they don't exist or they are zero bytes in length - useful for removing excessively large equations that crash the Y= editor... :P
Cheers!
I beta test, so...yeah.  PM me if you want me to test anything :D.

Almost only counts in horseshoes and handgrenades.

Cogito ergo sum.

Calcs:
TI-84+, OS 2.43, Boot Code 1.02, 128k RAM
TI-84+SE VSC, OS 2.43, Boot Code 1.00, 128k RAM  (I'm spoiled :P)
TI-81, OS 1.6K (only borrowed)
Casio fx-CG10 (Prizm), OS 01.04.0200
TI-Nspire Clickpad, OS 1.4
TI-Nspire Clickpad, OS 3.1.0.392
TI-Nspire CAS Clickpad, OS 1.6.10110 (!?) now OS 3.1.0.392

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 #1099 on: February 20, 2011, 05:17:32 pm »
Bug: getKey(0) doesn't work anymore.




Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1100 on: February 22, 2011, 03:48:22 am »
I don't know if this is more of a bug report or a feature request, but none of the GetCalc() routines account for real and complex number variables lacking a 2-byte header. Although a few other data types like lists and matrices don't have a 2-byte size header, they do have a 2-byte dimension header which I think works well with the current method. However, for real and complex number variables, I would suggest the following changes.


p_GetCalc: Also optimized a byte off the page checking.

Code: (Old) [Select]
p_GetCalc:
.db __GetCalcEnd-1-$
MOV9TOOP1()
B_CALL(_ChkFindSym)
ld hl,0
ret c
inc b
dec b
ret nz
inc de
inc de
ex de,hl
ret
__GetCalcEnd:





   
Code: (New) [Select]
p_GetCalc:
.db __GetCalcEnd-1-$
MOV9TOOP1()
B_CALL(_ChkFindSym)
ld hl,0
ret c
dec b
ret p
and %00011111
ret z
cp CplxObj
ret z
inc de
inc de
ex de,hl
ret
__GetCalcEnd:




p_NewVar: No special optimizations here.

Code: (Old) [Select]
p_NewVar:
.db __NewVarEnd-1-$
B_CALL(_EnoughMem)
pop hl
ex (sp),hl
jr c,__NewVarFail
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__NewVarSkip
B_CALL(_DelVarArc)
__NewVarSkip:
pop hl
ld a,(OP1)
B_CALL(_CreateVar)
ex de,hl
inc hl
inc hl
ret
__NewVarFail:
ld hl,0
ret
__NewVarEnd:







   
Code: (New) [Select]
p_NewVar:
.db __NewVarEnd-1-$
B_CALL(_EnoughMem)
pop hl
ex (sp),hl
jr c,__NewVarFail
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__NewVarSkip
B_CALL(_DelVarArc)
__NewVarSkip:
pop hl
ld a,(OP1)
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:




p_GetArc: Takes a new approach to determining if the VAT entry is variable length by comparing the VAT pointer to (progPtr) instead of throwing it out and using a list of compares and jumps based on the variable type. This also alleviates 2 other discrepancies with the previous routine, which were that the CListObj and TempProgObj variable types both have variable-length VAT entries but were not accounted for. In the end, even with the added code for checking if the type equals RealObj or CplxObj the whole thing is 3 bytes smaller than the original!

Code: (Old) [Select]
p_GetArc:
.db __GetArcEnd-1-$
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
ld hl,0
jr c,__GetArcFail
ld a,(OP1)
cp ListObj
jr z,__GetArcName
cp ProgObj
jr z,__GetArcName
cp ProtProgObj
jr z,__GetArcName
cp AppvarObj
jr z,__GetArcName
cp GroupObj
jr z,__GetArcName
__GetArcStatic:
ld hl,14
jr __GetArcDone
__GetArcName:
ld hl,9
add hl,de
B_CALL(_LoadDEIndPaged)
ld d,0
inc hl
inc hl
__GetArcDone:
add hl,de
__GetArcFail:
ex de,hl
pop hl
ld (hl),e
inc hl
ld (hl),d
inc hl
ld (hl),b
ex de,hl
ret
__GetArcEnd:



   
Code: (New) [Select]
p_GetArc:
.db __GetArcEnd-1-$
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__GetArcFail
push de
ex de,hl
ld hl,(progPtr)
sbc hl,de
pop de
ld hl,9
jr c,__GetArcName
__GetArcStatic:
ld l,12
and %00011111
jr z,__GetArcDone
cp l ;cp CplxObj
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:






And while we're on the topic of OS variable manipulation, using GetCalc() to create variables can result in an ERR:MEMORY because it doesn't account for the size of the VAT entry or the size bytes when calling B_CALL(_EnoughMem). Here's the easy, although wrong, way to guarantee that you won't get an error. It also includes the changes I made above. The right way would probably end up bloating the routine to a massive size and wouldn't be fun to write.


Code: (Easy way) [Select]
p_NewVar:
.db __NewVarEnd-1-$
push hl
ld de,17
add hl,de
B_CALL(_EnoughMem)
pop de
pop hl
ex (sp),hl
jr c,__NewVarFail
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__NewVarSkip
B_CALL(_DelVarArc)
__NewVarSkip:
pop hl
ld a,(OP1)
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: March 05, 2011, 10:10:50 pm by Runer112 »

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 #1101 on: March 05, 2011, 08:31:04 pm »
L3->DispGraph and L6->DispGraph both produced
Unknown Err
Code: 4726231
on the 1st pass. When I pressed prgm, the cursor was on DispGraph both times.
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 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 #1102 on: March 05, 2011, 08:50:49 pm »
Hey Runer112, with those changes I think you'll need to and $1f before checking for real/complex variables. You might find this particularly necessary for negative real values. It can replace the or a because it affects the Z flag, so only 1 byte lost.
"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 #1103 on: March 05, 2011, 08:59:20 pm »
Are you sure? ASM in 28 days says the following regarding the type byte:

   Bit   
Meaning
0-4
Object type
5
If a graph equation, then it's active if set.
6
Variable is used during graphing if set.
7
Variable is designated for link transfer if set.


I considered bits 5-7 possibly being set, but I don't think they ever should be set for a real or complex variable. I believe bits 5 and 6 only apply to graph equations, and bit 7 should only be set by the OS link transfer system, which wouldn't be used in the middle of an assembly program.

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 #1104 on: March 05, 2011, 09:12:19 pm »
Actually, looks like bit 6 applies to real variables, meaning that the variable is referenced in an equation. Ever noticed that if you change a variable that is used in an equation, the OS knows to regraph?
"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 #1105 on: March 05, 2011, 10:00:35 pm »
Ah, you are indeed correct, I'll fix that now.

Offline Compynerd255

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 336
  • Rating: +53/-4
  • Betafreak Games
    • View Profile
    • Betafreak Games
Re: Bug Reports
« Reply #1106 on: March 07, 2011, 10:24:04 am »
L3->DispGraph and L6->DispGraph both produced
Unknown Err
Code: 4726231
on the 1st pass. When I pressed prgm, the cursor was on DispGraph both times.
This actually happens with all <pointer>->DispGraph functions, ever since Axe 0.4.7. That is an incredibly annoying bug. However, I do have a workaround. You could replace P->DispGraph with:
Code: [Select]
Copy(P,L6,768)
DispGraph
This will take up the draw buffer, but not only will the picture appear, you can also draw on it.
The Slime: On Hold, preparing to add dynamic tiles

Axe Eitrix: DONE

Betafreak Games: Fun filled games for XBox and PC. Check it out at http://www.betafreak.com



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 #1107 on: March 07, 2011, 10:28:36 am »
L3->DispGraph and L6->DispGraph both produced
Unknown Err
Code: 4726231
on the 1st pass. When I pressed prgm, the cursor was on DispGraph both times.
This actually happens with all <pointer>->DispGraph functions, ever since Axe 0.4.7. That is an incredibly annoying bug. However, I do have a workaround. You could replace P->DispGraph with:
Code: [Select]
Copy(P,L6,768)
DispGraph
This will take up the draw buffer, but not only will the picture appear, you can also draw on it.
Unfortunately, this also negates the purpose of L3->DispGraph, to display just the back buffer without messing up the front? buffer.
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 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 #1108 on: March 07, 2011, 08:49:35 pm »
And it's a bug, so it should be reported :)

And bump for
Bug: getKey(0) doesn't work anymore.
It returns just the key value of the key group, without taking the group value into account or converting it to GetCSC format.




Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Bug Reports
« Reply #1109 on: March 07, 2011, 09:48:33 pm »
Deep Thought, getKey(0) wasn't designed to give a specific value according to which key was pressed. It was simply designed to return 0 if no key is pressed and something that's not 0 otherwise. If you want a value corresponding to the actual key pressed, the normal getKey does that.
« Last Edit: March 07, 2011, 09:54:42 pm by Runer112 »