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:



Code: [Select]

179->A
For(B,0,7)
If bit{A*8+B}
.Do Stuff
End
End

It already is possible to extract single bits from a byte or word with the e command (that's Euler's constant, not just a plain lowercase e). For instance, AeB would retrieve the Bth bit of the low byte of A, with B=0 corresponding to the most significant bit and B=7 corresponding to the least significant bit. The code you posted could be emulated with the following:

{POINTER}→A
For(B,0,7)
If AeB
.Do Stuff
End
End


I may be wrong, but aren't .xml files platform independent? In that case you could just use these same 2 files with a Mac version and it would work just like with the Windows version.

TL;DR: 2 modified .xml files for TI's Program Editor to convert it from a TI-BASIC into an Axe program editor.

---

I like programming for calculators on the computer for a few reasons. You have a much larger space to work with, things like copy, paste, undo, redo, etc. Also, your programs are always safe on your computer if your calculator crashes.

A lot of my calculator programming is done in Axe. Because the Axe language is based on TI-BASIC tokens and programs, I write and edit my programs with the TI-BASIC program editor called "TI Program Editor" bundled with TI-CONNECT. Unfortunately, TI decided to remove the only useful program to me from the TI-CONNECT suite, so you can't download it from TI anymore. You may or may not be able to find a download link in the description of a video from a YouTube search, though...

Anyway, I write Axe programs with this software that was intended for editing TI-BASIC programs. Because of this, it obviously lacks things like Axe token replacements and such. Even worse, it doesn't properly support some tokens like lowercase letters, making some programs impossible to open and others annoying to edit. And although it has a nice catalog of commands and calculator tokens to select from, it can be tedious to navigate it and find the Axe commands you want. Anyways, it looks like this:




It definitely has some nice features for TI-BASIC program editing:

• Tabbed file management
• Easily edit program details like the name it will be on a calculator or lock status
• The usual text editing features like cut, copy, paste
• A font specifically designed to mimic the font on the TI calculators and display special characters very nicely
• A categorized catalog of special symbols and all the functions you would find on your normal calculator, often sorted by an identical menu system
• Token hotkeys, useful for quickly entering common tokens you can't type on a keyboard

For an Axe programmer, a lot of those features are just as nice as for a TI-BASIC programmer. But the fact that it wasn't designed for Axe programming, chokes on some lowercase letters, and has a few other quirks sometimes made it difficult for me to write Axe programs on it. I could have decided to write my own Axe IDE, but I'm lazy. So I decided to just modify TI's already existing and pretty well-developed program editor. The same program you saw above with two modified source files suddenly becomes so much more Axe friendly:




Every token that displays differently in Axe has been changed to its Axe equivalent, so no more needing to look up which rotate command Shade_t() was! Commands actually make sense! And you can now simply type something like Copy( and not wonder why you get a compile error at the "o". Additionally, although the old catalog of tokens and TI-BASIC commands remains in a section called "Normal" in the command chooser, a whole new section exists just for Axe! In this section are tokens for every symbol, variable, and constant used in Axe, followed by tokens for every Axe command. And if you're familiar with the Commands.htm file included in Axe releases, it should be a piece of cake to navigate the commands because they're sorted in the same exact order. I just finished this myself so haven't been able to fully try programming with it, but I'm sure it will be a lot nicer programming in Axe with it now than without it.

---

If you have TI's Program Editor and want to test this out, I have attached a zip file containing the two modified xml files that constitute this modification. To hAxe the program, simply find the directory it exists in and replace "83PlusDictionary.xml" and "TI-83 PlusFunctionTree.tree" with the modified versions in the zip file. It may be a good idea to back up the originals first, though.

And once you've tested it out, tell me how it is!

Docs on the TI-Nspire CX Wireless Adapter:

https://fjallfoss.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=336646&fcc_id='V7R-TINAVWNA'



Here's a picture from one of the pdf's. Click for a larger size.

You definitely won't be dealing with anything over 65535, because the calculator is physically incapable of storing a number larger than that in its 16-bit registers. When it comes down to signs, the only difference between an unsigned and a signed number is just how you interpret the number. ⁻1 and 65535 are stored exactly the same on the calculator. It has no idea if it should be unsigned or signed. The only thing that "makes" a number signed is if you treat it as so.

The sin() function is periodic, meaning that for every 256 input values, it loops back around to where it started. For example, sin(254) would return the same result as sin(510) or sin(⁻2) (which is the same exact thing as sin(65534)), so you don't even have to worry about negative inputs.

Regarding the locations of variables in RAM, you can find the pointer to any variable by prefixing the variable with a degree symbol, such as °A. There are 27 2-byte variables, and they are stored in a contiguous 54-byte section of RAM in the order A,B,C,...,Z,θ. The variables start, by default, at the hexadecimal location $89B6 in RAM, which is equal to L₁+714.

This is effectively what it does, only this is larger and slower.

.Top Left
29-O/2/2/2+J*[map_width]+(45-N/2/2/2+I)+E
.Top Right
29-O/2/2/2+J*[map_width]+(51-N/2/2/2+I)+E
.Bottom Left
35-O/2/2/2+J*[map_width]+(45-N/2/2/2+I)+E
.Bottom Right
35-O/2/2/2+J*[map_width]+(51-N/2/2/2+I)+E