RPN83P: RPN calculator for TI-83+ TI-84+ inspired by HP-42S

[johnb]

(04-14-2024 11:30 AM)floppy Wrote:  Under windows, looks like a student TI-NSPIRE whatever graph&OS SW must be installed, a license key must exists (since I bought one as second hand, no license key so far given) = I am stuck there, too.

Have you considered reaching out to TI's support and asking what it takes to get a license key for a used Inspire? This cannot be the only scenario that leaves a user stranded. It may be as simple as providing them the serial number of your device.

[bxparks]

(04-14-2024 11:30 AM)floppy Wrote:  What are the instructions for installing on "TI-Nspire with TI-84 Plus Keypad (OS v2.46)"?

So far my findings.

Under linux, a first try with OS 2.54 and tilp was not successfull (the upload of the rpn83p.8xk had no effect: no error, app not seen in the calculator).

Under windows, looks like a student TI-NSPIRE whatever graph&OS SW must be installed, a license key must exists (since I bought one as second hand, no license key so far given) = I am stuck there, too.

I'm not sure what's causing your problems. My Nspire (w/ the 84+ keypad) behaves exactly like a regular 84+SE. I used the same tilp program (the package name is 'tilp2' on my Linux Mint 21.1, basically an Ubuntu Linux 22.04). I needed no license key, no OS upgrade, nothing. I verified the installation process using both the mini USB-B port and the 2.5mm GraphLink port.

[floppy]

(04-14-2024 03:37 PM)bxparks Wrote:  My Nspire (w/ the 84+ keypad) behaves exactly like a regular 84+SE

In TILP under Linux, by chosing the device "TI84+USB" and NOT "TI-NSPIRE" , the RPN83P was uploaded. Will see if it works fully like the usual TI84+ hardware. I assume that will be the case.

[bxparks]

(04-14-2024 08:30 PM)floppy Wrote:  In TILP under Linux, by chosing the device "TI84+USB" and NOT "TI-NSPIRE" , the RPN83P was uploaded.

Yes, that's definitely a potential source of confusion, since people may not fully realize that "the TI-Nspire is emulating a TI-84+" really means exactly what that says. I have updated the USER_GUIDE.md document with a note that explains this.

[bxparks]

I am changing the appearance of the RPN83P menus so that a MenuFolder is displayed with a small line above the box, so that it looks like a file folder icon. This makes the menus look like the HP-48 series, instead of the HP-42S. Here's a screenshot:

   

If anyone has strong objections, this would be the time to raise them, before I spend multiple days updating the 400-500 screenshots of those menus in various documents. It is possible to make this configurable with MODE options (a "42S-style" or a "48-style"), but I'm not seeing any downsides to the 48-style menus, so I would prefer to avoid a MODE option for this.

Funny story: I had seen screenshots of the HP-48 series for 20+ years, and I never knew what those little lines meant. Until 1-2 months ago, when I realized that those are file folder icons.

[Steve Simpkin]

(04-16-2024 06:43 PM)bxparks Wrote:  I am changing the appearance of the RPN83P menus so that a MenuFolder is displayed with a small line above the box, so that it looks like a file folder icon. This makes the menus look like the HP-48 series, instead of the HP-42S. Here's a screenshot:



If anyone has strong objections, this would be the time to raise them, before I spend multiple days updating the 400-500 screenshots of those menus in various documents. It is possible to make this configurable with MODE options (a "42S-style" or a "48-style"), but I'm not seeing any downsides to the 48-style menus, so I would prefer to avoid a MODE option for this.

Funny story: I had seen screenshots of the HP-48 series for 20+ years, and I never knew what those little lines meant. Until 1-2 months ago, when I realized that those are file folder icons.

I would be surprised if anyone complained since it just makes it obvious that it is a Menu Folder rather than just a command. It would have been nice to have this feature on the HP-42S but I suspect they didn't have space on the limited LCD.

[johnb]

(04-16-2024 06:43 PM)bxparks Wrote:  I am changing the appearance of the RPN83P menus so that a MenuFolder is displayed with a small line above the box, so that it looks like a file folder icon.

...

If anyone has strong objections, this would be the time to raise them, before I spend multiple days updating the 400-500 screenshots of those menus [...] It is possible to make this configurable with MODE options [...], but I'm not seeing any downsides to the 48-style menus, so I would prefer to avoid a MODE option for this.

I see no reason for the option, either. Why would you _want_ to not see the difference? BTW, I think this is definitely a worthwhile change. I like the fact that the difference is subtle but obvious, and I always found the on screen menus of the 48-series to be pretty intuitive.

(04-16-2024 06:43 PM)bxparks Wrote:  Funny story: I had seen screenshots of the HP-48 series for 20+ years, and I never knew what those little lines meant. Until 1-2 months ago, when I realized that those are file folder icons.

I think this must be an occupational hazard with scientists, engineers, and technical types. We see what others don't, but sometimes miss the obvious. Either that, or it's a built-in "feature" of our personality type. My own canonical example is that I've liked "Monty Python and the Holy Grail" since my teen years (in the 1970s), but it wasn't until a dozen years ago when I was writing a funny response to someone and called them "a filthy English Knnn--nigit!" that I realized they were just grossly mispronouncing "knight!"

[bxparks]

(04-17-2024 06:19 PM)johnb Wrote:  

(04-16-2024 06:43 PM)bxparks Wrote:  but I'm not seeing any downsides to the 48-style menus, so I would prefer to avoid a MODE option for this.

I see no reason for the option, either. Why would you _want_ to not see the difference? BTW, I think this is definitely a worthwhile change. I like the fact that the difference is subtle but obvious, and I always found the on screen menus of the 48-series to be pretty intuitive.

It turns out there *is* a downside to the 48-style folder icon.

The RPN83P used a non-blinking underscore cursor to match the one used by the HP-42S. The problem is that the underscore character is visually too similar to the short dash of the menu folder tab. If multiple menu folders are displayed, the underline character can get lost in the sea of short dashes, and user can have difficulty finding the location of the cursor. (See screenshot 1).

   

The solution was to change the RPN83P cursor to be a blinking block character. (See screenshot 2).

   

The side benefit of using the blinking block cursor is that it is supported natively by the TI-OS. This makes it much easier to implement a scrollable cursor that supports the LEFT and RIGHT arrow keys to edit a long input line before input termination. (see screenshot 3) This feature is similar to the command line editing of the 48/49/50 series, but using the traditional RPN mode instead of RPL.

   

Anyway, the code for these UI changes is basically done. Changing the shape of the cursor means that I have to update the majority of the 1346 screenshots embedded in various documents. And since the cursor is blinking, I have to hit the screen capture just at the right time to grab the cursor. This will be so much fun.

[Eric Rechlin]

(05-08-2024 05:08 PM)bxparks Wrote:  Changing the shape of the cursor means that I have to update the majority of the 1346 screenshots embedded in various documents. And since the cursor is blinking, I have to hit the screen capture just at the right time to grab the cursor.

Or just manually edit the screenshots to paste the block over the underscore instead of making new ones. Still tedious, but way quicker than making new ones and timing the blink just right. Or just don't worry about it yet and deal with it when you have time; it's a trivial thing and maybe some of those screenshots you may have to remake again soon anyway for later changes.

[bxparks]

The next version (v0.11.0) of RPN83P is focused on improving the user interface and experience of the app. It will add very few mathematical or numerical features. Many of these UI/UX changes could have been made earlier, but I often have to implement a feature before I can figure out the best UI for it ("form should follow function" as they say).

But the other reason that these UI/UX changes were delayed is that I find UI programming difficult (compared to math functions, computer algorithms, storage formats, for example). It tends to involve intricate handling of lots of UI events from the user, which cause a combinatorial explosion of internal states, with tons of edge cases and error conditions, which must all be handled correctly, to prevent crashing the application (if I'm lucky), or corrupting of some unrelated data randomly exposed at a later time (if I am unlucky). An off-by-one bug seems to be lurking in every 2-3 lines of assembly code. I cannot tell you how many times an off-by-one error completely wiped the memory of the calculator and crashed my emulator during the development of this release.

Anyway, I think the best way to summarize the upcoming UI/UX changes is with this annotated screenshot:

   

I have mentioned some of these changes in my earlier posts, but here is a summary:

• use new icon for menu folders, with a small dash to represent a folder tab
• change cursor from an underscore to a blinking block, and support the following arrow keys (similar to the HP 48/49/50 series):
  • LEFT arrow: move the cursor left
  • RIGHT arrow: move the cursor right
  • 2ND LEFT: move to the beginning of line
  • 2ND RIGHT: move to the end of line
    
• update the input modifier keys to behave reasonably
  • . (period): insert a decimal point, unless there is already one inserted
  • (-) (CHS): change the sign of the mantissa, exponent, or Record component (e.g. Date, Time, DateTime) appropriately
  • 2ND EE: insert an 'E', unless it has already been entered (this is different from the 48/49/50, mostly because I'm not entirely sure what the HP-50g is doing, and I ran out of energy to try to figure out my 50g)
    
• new MODE > SSIZ: resize the RPN stack, supports 4 to 8 levels
  • new annunciators on the top status line (4STK, 5STK, 6STK, 7STK, 8STK)
  • compress the top status line, to squeeze in the 'xSTK' annunciator
  • (if you are wondering, an infinite NSTK feature, similar to Free42 is *not* planned for RPN83P, mostly because the memory management functionality of the underlying TIOS seems too primitive to implement this reasonably, and because I don't find an infinite stack to be particularly useful in an RPN system)
    
• new MODE > RSIZ: resize the storage registers, supports 25 to 100 registers
  • NOTE: This is called SIZE on an HP-42S (and Free42), but I have always found this to be confusing because there are other "SIZE" commands: WSIZ (word size), SSIZ (stack size), and RSIZ (register size). I named this RSIZ to avoid that confusion.
  • On RPN83P, the WSIZ, SSIZ, and RSIZ commands all behave exactly the same. They prompt for the size value. And there exist the corresponding WSZ?, SSZ? and RSZ? functions to retrieve the current values.
    
• extract the 13 STAT registers (R11-R23) into their own separate set of registers (using a new TIOS appVar named RPN83STA)
  • all storage registers R00-R99 are now available for end-users, with no conflicts with the STAT functions
  • add new STAT > SIGMA folder: contains functions to retrieve each of the 13 STAT registers (e.g. SigmaX, SigmaX2), following the convention used by the Plus42 app
    
• add new RPN stack operators
  • "2ND u" button (above the 7 button): implement the Rup (RollUp) function on the keypad. This seems to be an important function when the RPN stack size is increased beyond 4. (I could not think of any better alternative button to bind the Rup functionality. You can think of the "u" as a mnemonic for "up")
  • STK > DUP menu function: duplicate X (similar to ENTER, without the complicated logic with "disable stack lift")
  • STK > DROP menu function: delete X
  • (the DUP and DROP functions are more relevant for keystroke programming, but these functions were already implemented internally, so I decided to just expose them in the UI with only a handful lines of code)
    
• update storage format of various appVars (RPN83REG, RPN83STK, RPN83STA) to allow future migrations without losing data
  

If you have made it this far in this post, you have the opportunity to send me feedback about the various UI/UX changes by installing the preview version of RPN83P (v0.11.0-dev) from here: https://github.com/bxparks/rpn83p/releas...0.11.0-dev . I would appreciate such feedback, before I spend ~2 weeks updating most of the screenshots of my various documents.

WARNING: v0.11.0-dev changes the storage format of the RPN stack and storage registers. They will be cleared if you install and run the new version of RPN83P.

[rohdo]

(05-14-2024 06:51 PM)bxparks Wrote:  If you have made it this far in this post, you have the opportunity to send me feedback about the various UI/UX changes by installing the preview version of RPN83P (v0.11.0-dev) from here: https://github.com/bxparks/rpn83p/releas...0.11.0-dev . I would appreciate such feedback, before I spend ~2 weeks updating most of the screenshots of my various documents.

Thank you very much for your efforts on this software!

It was so intriguing to hear about your work that I purchased a TI-83+ just to try it out (although my DIY serial cable didn't work yet, but managed to find a used one).

Probably won't use the calc too intensely, but I'll keep it close for BASE conversion and bitwise ops etc. (currently most common ops I do). Will let you know if I stumble on any bugs.

[bxparks]

(05-14-2024 09:28 PM)rohdo Wrote:  Probably won't use the calc too intensely, but I'll keep it close for BASE conversion and bitwise ops etc. (currently most common ops I do). Will let you know if I stumble on any bugs.

Since RPN83P is written in assembly, I also need to do bitwise calculations relatively often. I don't own a real HP-16C, but I did use the JRPN 16C app on my phone early on.

But nowadays, I use the RPN83P app itself. Mostly because I like physical buttons instead of a touchscreen, and because the calculator is readily accessible on my desk compared to digging out, unlocking, and selecting the app on my phone. And because it's hard to go back to a single-line display of the 16C, after being able to see the entire RPN stack on RPN83P.

But the BASE functions on the RPN83P are not ideal. I did the best I could given the hardware and software constraints:

* There are no dedicated keys on the 83+/84+ related to BASE functions, so I have to place all of them under the BASE soft menu.
* The BASE menu folder has too many functions, 8 rows, which can be hard to navigate. But a flat hierarchy seemed preferable to nested subfolders which can be even more annoying to navigate.
* The A-F digits for HEX numbers require the use of the ALPHA shift key, because there isn't any way to expose them through unshifted keys. (The 83+/84+ has only 5 buttons across for the soft menu, so it didn't make sense to expose only 5 out of 6 HEX digits through the soft menu buttons either.)
* The integer word size (WSIZ) can only be 8, 16, 24, 32 bits, instead of an arbitrary integer between 1 and 64 bits like the 16C. It's probably technically possible to extend RPN83P to support 64 bits, but that would require a substantial amount of work.
* There is no support for *signed* integer types in the BASE functions of RPN83P. This would not be difficult to add with regards to complexity, but it would require a lot of grunt work: All of those extended bitwise and integer arithmetic routines would need to be written by hand, since the Z80 does not have hardware support for most of them beyond 8 or 16 bits.

There is one bit of UI improvement I added yesterday: Base-2 numbers (binary numbers) are now rendered in small font instead of large font. That allows 16 digits to fit across one line, so both WSIZ 8 and 16 numbers can be displayed in full, like this:

   

This will be included in the next release.

Brian

[bxparks]

The next version (v0.11.0) of RPN83P is now available at https://github.com/bxparks/rpn83p/releases. Download the rpn83p.8xk file and transfer it to your 83+ or 84+ calculator. WARNING: The storage formats for the RPN stack and storage registers have changed again (this should be the last time... hahaha). They will be reset to 0 when you install and run this version.

I have refactored much of the RPN83P documentation. The User's Guide is now spread across 6 files, and comes to a total of 131 pages when converted to PDF:

• USER_GUIDE.md
• USER_GUIDE_BASE.md
• USER_GUIDE_COMPLEX.md
• USER_GUIDE_DATE.md
• USER_GUIDE_STAT.md
• USER_GUIDE_TVM.md
  

All screenshots that needed to be updated were retaken.

The changes I described previously for v0.11.0-dev remain valid. To summarize, the big changes for v0.11.0 are:

• new menu folder icon
• resizable RPN stack, 4 to 8
• resizable storage registers, 25 to 100
• scrollable input cursor, using LEFT and RIGHT arrow keys
• extract the 13 STAT registers into their own namespace, no longer overlap with R11-R23
• new BASE formatting: HEX digits grouped in 2's, OCT digits grouped in 3's, and BIN digits grouped in 4's
  

I'm particularly fond of the code that handles the scrollable input cursor. Because there's a heck of a lot of logic and edge-case handling going on, but it stays mostly out of the way, letting the user move around the input buffer easily and intuitively. Ironically, the code that handles this is basically incomprehensible to me, because it was too complex for me to write it in assembly from scratch. I tried, but failed several times. I had to write most of it in C, then compile it to assembly by hand, producing a chunk of code which is unmaintainable. I would have to go back to the C code to modify it, then recompile it down to assembly.

As usual, bug reports are welcome.

Brian

[bxparks]

The latest version (v0.12.0) of RPN83P is available at https://github.com/bxparks/rpn83p/releases. Download the rpn83p.8xk file and transfer it to your 83+ or 84+ calculator. This version should be compatible with v0.11.0, no data should be lost.

The primary purpose of this release is to improve some rough edges of the TVM functionality:

* support C/YR (compoundings per year)
* add "dots" to P/YR and C/YR when they differ from the default value of 12
* synchronize the END/BEG flag of RPN83P with the END/BEGIN flag of the "Finance" app of the 83+/84+ (finally)
* change default initial guesses of IYR1 and IYR2 to -50% and 100% respectively, supporting negative interest rates by default
* improve accuracy of I%YR very close to 0%
* display new status message "TVM Calculated (Multiple)" when multiple solutions are known to exist, but only one solution was found
* bug fix: fix incorrect logic for determining if commas are allowed in the middle of the input buffer

Unless major problems are found, I plan to cut v1.0 on top of this version in the near future.

[bxparks]

I am happy and relieved to announce that RPN83P has graduated from Beta, and the latest release (v1.0.0) is available at https://github.com/bxparks/rpn83p/releases. Download the rpn83p.8xk file and transfer it to your 83+ or 84+ calculator. This version should be compatible with v0.12.0, no data should be lost.

For this release, I wanted to add enough improvements to be worth downloading, but not change the code too much as to introduce bugs and instability. Here are the major changes:

• User Interface
  
  • the CLEAR button clears only to the end of line if the cursor is in the middle of the input buffer
  • this is similar to the behavior of the CLEAR button on the TI-89/92+/Voyage 200 series
  • this is also similar to the CLEAR button on the HP-50g, but only in Algebraic mode, not RPN mode
    
• TVM
  
  • improve accuracy for small I%YR by adjusting the transition to small-i approximation
    
• UNIT
  
  • add new conversion functions
  • convert between mpg (miles per US gallon) and liters per 100 km
  • convert between psi (pounds per square inch) and kPa
  • convert between acres and hectares
    
• PRIM
  
  • improve performance of the Prime Factor function by 2.4X from v0.12
    
    • now 25X faster than the first floating point version
    • and 9X faster than the first u32 integer version
      
  • benchmarks for PRIM for 65521*65521=4_293_001_441:
    
    • TI-83+ (6 MHz): 8.3 s
    • TI-83+SE (15 MHz): 3.2 s
    • TI-84+SE (15 MHz): 3.9 s
    • TI-Nspire w/ TI-84+ keypad: 3.0 s
      

I'm not entirely sure why I spend so much time optimizing the PRIM function. I think it's because it's complex enough that optimization matters, but small enough that I can hold the entire problem in my head at once. There are other areas of RPN83P (e.g. some parts of the UI code) which are sometimes too big to hold in my head at the same time, and those problems are less attractive to work on.

What's interesting about PRIM is that essentially all of the 9X performance improvements from the first u32 integer version have come from micro-optimizations. Normally micro-optimizations don't produce such significant performance improvements, but the PRIM function pushes the Z80 processor to its limits.

What does v1.0 mean? I'm going to take a short break (several months?) from its development. It looks like I have spent about one year working on RPN83P, which is 6 months longer than I had initially estimated (which many of you know is completely normal for a software project). The list of future RPN83P features is long, and I plan to tackle them in the future. Just not immediately. In the meantime, my other open source projects are in need of maintenance and attention.

As always, bug reports are welcome. I will handle them as best as I can. Enjoy!

Brian