Or Calcsys.

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...

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.


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:



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.

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?

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:
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.

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.