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

[TomC]

Firstly - GreatWork!!! - to have our favorite machines work on readily available hardware.

My comments/wishes:
1. Complex Number Support
2. Keystroke programming (like 42)
3. More data memory (I regularly use 100 complex registers on my DM42).
4. Support for the 84'C' type machines (I've come to enjoy these backlit displays).

Thanks again for your fine work,
TomC

+++++++++++++++++++++++++++++++++++++++++

(11-22-2023 02:43 AM)bxparks Wrote:  

(11-21-2023 10:02 PM)floppy Wrote:  Ouch. Perhaps you just signed the death of my HP35S (no exchange with PC possible with that weird one). Now the TI84+ is on my amazon list. In few days will probably make its way to me. Then after install/test probably bye bye HP35S via eBay.

Texas Instruments seems to have thoroughly abused the "TI-84 Plus" brand. There are at least 4 calculators by that name:

* TI-84 Plus
* TI-84 Plus Silver Edition
* TI-84 Plus C Silver Edition
* TI-84 Plus CE

Plus the "Python" versions of some of those. Some of them are quite incompatible with each other. Make sure you are getting what you think you are getting.

The RPN83P works with the TI-84 Plus, and TI-84 Plus SE (and the TI-83 Plus), but *not* the TI-84 Plus C SE, and most *definitely* not the TI-84 Plus CE.

With regards to the HP-35S, it all depends on what you want the calculator for. Most reviewers seem to love the retro-quality of the 35S, with echoes of the old Voyager (10C to 15C) and Pioneer series (20S, 32S, 42S). All of its functions seem to be available directly through the buttons instead of menus. Some people really like that. I'd probably enjoy having this calculator, but not at the prices that I see on eBay.

(11-21-2023 10:02 PM)floppy Wrote:  The TI-84 Plus C Silver Edition would be ok? lt seems to be the highest spec version.

I don't have this calculator, but everything I read on the internet says, *never* get this calculator. It uses the same 15 MHz Z80 processor as the 84+ and 84+SE, but has a 320×240 color screen that requires a much higher CPU and memory resources. The Z80 processor apparently cannot render the fonts fast enough and does not have enough bandwidth to push the bits quickly enough to the LCD screen.

[bxparks]

(11-22-2023 05:43 AM)Gerald H Wrote:  My own preference is the 83+SE - awfully elegant. The 84+SE is merely greyish & looks much bulkier although it in fact weighs less.

That's true, the 83+SE is a better looking than the 84+SE. I prefer the perfectly straight, no-nonsense grid layout of its keys, versus the new-age-weird-artsy-curvy key layout of the 84+SE. And you are right, it is slightly smaller as well, which I hadn't notice before, probably because they are both pretty large compared to my HP calculators.

The problem I had with the 83+SE is that it uses a translucent, whitish plastic. From the photos on eBay, the contrast between the light Yellow (2ND) and light Green (ALPHA) key labels and the translucent plastic seemed terrible. As my eyes have grown older, I cannot read such small letters with such low contrast.

It turns out that TI created another hardware version of the 83+SE, which in their infinite wisdom, is called the exactly the same thing, the "83 Plus Silver Edition" (so I have no idea what it is actually called). This variant has a black plastic background, and I find the key labels to be far more readable. This variant is targeted towards teachers. It has an extra video port on the back to allow the the calculator screen to be projected with a special video projector. The problem with this model, as I discovered after my purchase, is that the humpback video port makes the calculator feel bulky.

The 84+/84+SE does have a few advantages over the 83+/83+SE though. One of them is that the 84+/84+SE has a USB-mini-B port in addition to the traditional 2.5mm serial port. So in theory, you don't need to buy that proprietary USB-to-serial cable from TI.

[bxparks]

(11-22-2023 01:32 PM)floppy Wrote:  TI 84 PLUS
This cable is for the connectivity to the PC? https://www.amazon.de/TI-Graph-Texas-Ins...6BXBS?th=1
Or this one ? https://www.amazon.de/Datenkabel-Ladekab...10&sr=8-17

Looks like 2 different types are listed. Not sure which one is the best.

(Wow that German Amazon website is painful to use. Captcha. Cookie authorization taking up 1/2 my screen, which can't be dismissed...)

The first one is a custom TI USB-to-serial cable that plugs into the 2.5mm port on many of the older TI graphing calculators, including the 83+, 83+SE, 84+, 84+SE that the RPN83P is compatible with. Don't buy it new, you should be able get it on eBay for $10-15.

The second one is a standard USB-A to USB-mini-B cable. That works for the 84+ and 84+SE which also have a mini-USB-B port. Many people have a lot of these cables already. If you don't, you should be able to get one from a thrift store for like $1 (or the equivalent in Euros).

[bxparks]

(11-22-2023 03:53 PM)Thomas Klemm Wrote:  I noticed the link while reading the source code of lnOnePlus in float.asm.

---

A few lines above we can find the following comment:

Quote: ; This uses ln(1+x) = x * log(1+x) / ((1+x)-1). I think this algorithm is
; faster than above, but apparently it doesn't work on certain computers
; (though I don't know why).
; See https://math.stackexchange.com/questions/175891

What do you mean exactly with "certain computers"?
Does it work with these TI calculators?
Otherwise, can you debug the code and maybe provide a trace of OP1, OP2 and FPS?

The "faster than above" is a slight typo, it should be "faster than below". I had flipped the order of the 2 implementations without updating the comments. The LOG1P_USING_LOG macro is now undefined by default, so the code selects the asinh() version. Hopefully that was clear from the context.

I have updated the comments, and added this new comment at the top of the function:

Quote:; Description: Calculate ln(1+x) such that it is less susceptible from
; cancellation errors when x is close to 0. By default the LOG1P_USING_LOG
; macro is not defined, so we end up with the hyperbolic asinh() version below.
; I prefer the asinh() version because I understand it. I could not follow the
; the explanation of why the LOG1P_USING_LOG version worked, or didn't work on
; certain environments.

So I think the x*ln(x)/((1+x)-1) *did* work for the TI calculators. But since I did not understand the explanation given in the math.stackexchange.com link about *why* it worked, I could not be sure that it worked for *all* ranges of numbers. The comment about not working on certain computers came from another source that has this formula, but I cannot remember what that other source was. (Maybe it was one of the old HP-15C or HP-34C solutions book.) Instead, I decided to use the asinh() version because I actually understand it. It's a mathematical identity, which I was able to re-derive. And as long as I used the expression which was less susceptible to numerical errors for x->0, that is log(1+x)=asinh((x/2)(1+1/(1+x))), I could depend on it. [Edit: Also added a stronger comment that the identity holds only for (1+x)>0, and this condition must be checked in the code. Because for (1+x)<0, the asinh() expression returns a value, but log(1+x) must throw an exception.]

[bxparks]

(11-22-2023 05:18 PM)TomC Wrote:  Firstly - GreatWork!!! - to have our favorite machines work on readily available hardware.

My comments/wishes:
1. Complex Number Support
2. Keystroke programming (like 42)
3. More data memory (I regularly use 100 complex registers on my DM42).
4. Support for the 84'C' type machines (I've come to enjoy these backlit displays).

Thanks! (1) and (2) and many others are already in the future enhancements section in the USER_GUIDE.md. So many features, so little time.

Part of the problem is that I'm finding Z80 assembly language programming to be about 1/3 as productive as C, and maybe 1/6 as productive as C++. Maybe that just means that I'm not a good assembly language programmer. It's a grind. Especially as the RPN83P application has become bigger, it takes more and more time to add new features, to make sure that I haven't broken everything else that has already been programmed. I am not aware of any way to do automated unit testing with assembly language programming. So all my testing has to be done manually. Very time consuming.

I'm curious about your (3). I can give you 100 real registers easily right now. I chose to limit to 25, because that's the HP-42S default, and because I thought, "who would need more than 25 registers?" :-) Why do you need 100 *complex* registers? Some sort of EE/signal processing work?

With regards to (4), are you talking about the 84+CSE, or the 84+CE? (The people who created the names for these calculators must have been on drugs. It is completely confusing.) The 84+CSE is a technological dead-end for TI calculators. I won't port to that. The 84+CE... maybe. Those use a different CPU (eZ80), a different screen, different development tools (probably). I hear there's a C compiler for it, no idea how good it is. But get this, the sizeof(int) on that compiler is 3 (not 2 or 4) because the eZ80 processor has 24-bit registers. What an adventure that would be.

[Addendum: Another higher-level question would be: Why would you want to use the RPN83P app on a budget TI calculator instead of the DM42? The DM42 uses Free42 which is an awesome piece of software. The DM42 hardware, from all I hear, is also awesome. Seems like RPN83P would be a poor substitute.]

[ijabbott]

(11-21-2023 10:02 PM)floppy Wrote:  

(11-21-2023 09:26 PM)bxparks Wrote:  Yes. There is a host app that runs on Windows (TI Connect), Mac (TI Connect) or Linux (TiLP2). It gives you a view of the contents of the calculator's memory that looks like a file system. You can drag-and-drop any app or variable from the calculator to the host. You can drag-and-drop those files from the host back to the calculator.

You can also connect 2 TI calculators together through a 2.5 mm cable, and transfer files between them. I've actually never done it myself, but apparently it's possible.

Ouch. Perhaps you just signed the death of my HP35S (no exchange with PC possible with that weird one). Now the TI84+ is on my amazon list. In few days will probably make its way to me. Then after install/test probably bye bye HP35S via eBay.

The TI-84 Plus C Silver Edition would be ok? lt seems to be the highest spec version.

Bear in mind that the current version of RPN83P is not (yet) programmable like HP calculators that inspired it.

You can usually get used TI-84 Plus or Plus Silver Edition pretty cheap on eBay. I have a few. Also look out for the TI-84 Pocket Plus SE, which is quite nice and compact.

[floppy]

"not (yet) programmable like HP calculators that inspired it."

got it.

[Thomas Klemm]

(11-22-2023 06:11 PM)bxparks Wrote:  But since I did not understand the explanation given in the math.stackexchange.com link about *why* it worked, I could not be sure that it worked for *all* ranges of numbers.

We can start with the geometric series for \(|q| < 1\):

\[
\begin{align}
\frac{1}{1-q}
&= \sum_{k=0}^\infty q^k \\
&= 1 + q + q^2 + q^3 + q^4 + q^5 + \cdots
\end{align}
\]

Substitute \(q = -x\) to get:

\[
\begin{align}
\frac{1}{1+x}
&= 1 - x + x^2 - x^3 + x^4 - x^5 + \cdots \\
\end{align}
\]

Integrate both sides:

\[
\begin{align}
\int \frac{1}{1+x} \; \mathrm{d}x
&= \log(1 + x) \\
&= x - \frac{x^2}{2} + \frac{x^3}{3} - \frac{x^4}{4} + \frac{x^5}{5} - \frac{x^6}{6} + \cdots \\
\end{align}
\]

In the following I'm using the same definitions of \(x\), \(y\) and \(z\) as in your code.

Example

I assume we use a 10-digit calculator.

x = 1.234509876e-5
y = 1 + x
    1.000012345
z = y - 1
    0.000012345

Due to cancellation we can't calculate \(\log(1+x)\) but calculate \(\log(1 + z)\) instead.

Thus we get:

\[
\begin{align}
\log(1 + z)
&= z - \frac{z^2}{2} + \frac{z^3}{3} - \frac{z^4}{4} + \frac{z^5}{5} - \frac{z^6}{6} + \cdots \\
&= z \cdot \left(1 - \frac{z}{2} + \frac{z^2}{3} - \frac{z^3}{4} + \frac{z^4}{5} - \frac{z^5}{6} + \cdots \right) \\
\end{align}
\]

We can improve the result by first dividing by \(z\) and then multiplying by \(x\):

\[
\begin{align}
\frac{x \cdot \log(1 + z)}{z}
&= x \cdot \left(1 - \frac{z}{2} + \frac{z^2}{3} - \frac{z^3}{4} + \frac{z^4}{5} - \frac{z^5}{6} + \cdots \right) \\
&= x - \frac{xz}{2} + \frac{xz^2}{3} - \frac{xz^3}{4} + \frac{xz^4}{5} - \frac{xz^5}{6} + \cdots \\
\end{align}
\]

Now both series start with \(x - \cdots\) which is the dominant term if \(x\) is small.

If \(x\) is very close to \(0\), that is \(z = 0\), we can ignore the higher order terms and just return \(x\).

If \(|x| > 1\), then the cancellation is minuscule and thus \(x \approx z\).
Therefore the factor \(\left | \frac{x}{z} \right | \approx 1\) and the multiplication doesn't change much.

I could be wrong, but I don't see a case where the use of this trick would lead to a problem.

[Albert Chan]

(11-22-2023 03:53 PM)Thomas Klemm Wrote:  

(11-21-2023 06:00 PM)bxparks Wrote:   ; This uses ln(1+x) = x * log(1+x) / ((1+x)-1). I think this algorithm is
; faster than above, but apparently it doesn't work on certain computers
; (though I don't know why).
; See https://math.stackexchange.com/questions/175891

What do you mean exactly with "certain computers"?

This was mentioned in Kahan's article,
"How Futile are Mindless Assessments of Roundoff in Floating-Point Computation?", page 22

Kahan Wrote:For example, no spike should mar the graph of
log₂(x) / (x–1) = ( 1 – (x–1)/2 + (x–1)² / 3 – (x–1)³ / 4 + … )/ log(2)
plotted at arguments x near but not 1 . However, here is a spike that has persisted since 1994 in
three M ATLAB versions 4.2 to 6.5 on all my computers (this graph came from an IBM PC)

The quote is for log2, but that is just a scaling factor for log.
My guess is code for log/log2 was bad, causing spikes in plots.

Note that Kahan's formula is actually designed for ratio, log1p(x)/x
(same article (page 19) have formula for expm1(x)/x, with similar idea)

Let y=x+1., z=y-1., error ε = exact - approx = x-z

log1p(x) = log(1+z+ε) = log(1+z) + log(1+ε/(1+z)) ≈ log(1+z) + ε/(1+z)
x = z + ε

If z is small, log(1+z) ≈ z, ε/(1+z) ≈ ε
Numerator and Denominator has about same relative errors, cancelled each other out.

--> log1p(x)/x ≈ log1p(z)/z = log(y)/(y-1)
--> log1p(x) ≈ x * log(y)/(y-1)

I prefer Dieter's formula, with slightly better accuracy: log1p(x) ≈ log(y) - (y-1-x)/y

[bxparks]

(11-21-2023 10:58 PM)dm319 Wrote:  Please do! I wrote a TVM solver for the DM42 (available here) specifically for NSTK mode. I suspect it may need a bit more work/optimising though as just managed to get a divide by 0 error putting in a really big N.

As promised, I documented my equations and algorithms in the TVM.md document, and posted a summary of it in the recent TVM formula error in programming manual? thread.

[bxparks]

(11-21-2023 05:24 PM)bxparks Wrote:  

(11-21-2023 09:26 AM)Gerald H Wrote:  PRIM actually finds a factor, otherwise returning 1 for prime input.
PRIM works very fast - What algorithm have you used?

[...]
The largest prime number <= 2^16 is 65521, so the longest execution time of PRIM is the factorization of 65521*65521=4 293 001 441. That takes 33 seconds on a TI-84+SE.
[...]

Good news. I made my app 2.5X faster on the 83+SE, 84+, and 84+SE models with almost no effort. So PRIM finishes the factorization of 65521*65521 in about 13 seconds instead of 33 seconds on these machines. It turns out these 3 later models use Z80 processors which can run at 2 speeds: 6 MHz or 15 MHz. But I didn't know that flash apps are configured to run at 6 MHz by default, for backwards compatibility with the original 83+ which can only run at 6 MHz. So I added a few lines of code to configure my app to run at 15 MHz, and bam, everything runs faster.

I guess I didn't need to optimize my app so much. But in return, I now have an app that is perfectly usable on the oldest, slowest, and cheapest TI-83+ calculator. I bought one locally for $10 the other day, for testing purposes. I expected my app to run 2.5X slower, but it ran just fine. Which led me down this rabbit hole.

[ebs]

(11-29-2023 10:00 PM)bxparks Wrote:  Good news. I made my app 2.5X faster on the 83+SE, 84+, and 84+SE models with almost no effort. So PRIM finishes the factorization of 65521*65521 in about 13 seconds instead of 33 seconds on these machines. It turns out these 3 later models use Z80 processors which can run at 2 speeds: 6 MHz or 15 MHz. But I didn't know that flash apps are configured to run at 6 MHz by default, for backwards compatibility with the original 83+ which can only run at 6 MHz. So I added a few lines of code to configure my app to run at 15 MHz, and bam, everything runs faster.

I don't own TI calculators but I find very interesting this project anyway.

Have you checked the battery consumption at 15 Mhz? If it's going to draw it quickly maybe you can do the frequency user selectable?

[bxparks]

(11-30-2023 09:57 AM)ebs Wrote:  Have you checked the battery consumption at 15 Mhz? If it's going to draw it quickly maybe you can do the frequency user selectable?

I have not, but it would interesting (Though I'm having some difficulty imagining how I would build a contraption that could inject an ammeter into the circuit in the AAA battery compartment. A thin insulator with 2 conductors on either side, with metallic tabs?).

My guess is that the battery consumption is not an issue because:

• These TI calculators are configured to run normally at 15 MHz. The OS runs at 15 MHz. The TI-BASIC programs run at 15 MHz. It's only when they are asked to run user-uploaded assembly language programs (ASM() function) or flash apps (APPS button) that the calculator switches to 6 MHz for backwards compatibility.
• Even if the power consumption is higher at 15 MHz (let's say, at least 2.5X more, probably a little more), the computation finishes 2.5X faster. The relevant quantity is the amount of computation per Joule (energy), not per Watt (energy/second). My guess is that TI chose to configure these Z80 processors at 15 MHz, because the computation per Joule was roughly the same as 6 MHz. Otherwise, the calculators would consume the batteries significantly faster.
• The RPN83P program spends the vast majority of its time in the GetKey() OS function just waiting for a key press from the user. My guess is that the Z80 goes into a deep sleep mode, and waits for an interrupt from the keyboard. So even if the processor uses slightly more than 2.5X power at 15 MHz, it spends only a small amount of time at the higher burn rate.
  

[floppy]

I received an TI 84 Plus from ebay (quite cheap HW: 40Eur). Will install Forth during Christmas time.

[goosnarrggh]

(11-22-2023 06:54 PM)bxparks Wrote:  With regards to (4), are you talking about the 84+CSE, or the 84+CE? (The people who created the names for these calculators must have been on drugs. It is completely confusing.) The 84+CSE is a technological dead-end for TI calculators. I won't port to that. The 84+CE... maybe. Those use a different CPU (eZ80), a different screen, different development tools (probably). I hear there's a C compiler for it, no idea how good it is. But get this, the sizeof(int) on that compiler is 3 (not 2 or 4) because the eZ80 processor has 24-bit registers. What an adventure that would be.

I gather that writing a community-driven freeware flash app for the 84+CE might be a dead end because TI has changed the signing algorithm for flash apps on that platform - I think the only viable path to distributing flash apps on that platform is to submit it to TI for commercial distribution.

Still, it might be viable to distribute it as a program that is totally resident in RAM. Although, native compiled/assembled programs running from RAM are restricted if the user has the latest OS version for the 84+CE. They'd need to jailbreak to get past this restriction.

Yes, there is at least one experimental fork of LLVM/clang with support for the eZ80. (And also the classic Z80 as part of the same fork.) Heck, the Z80 also had earlier C compilers as well, but to my knowledge none of them have been able to leverage the same kind of sophistication as you can get with LLVM. That being said, the Z80 architecture was never created with C-compatible calling conventions in mind, so it might be less efficient than what you could achieve coding assembly by hand.

[bxparks]

(12-01-2023 03:47 PM)goosnarrggh Wrote:  I gather that writing a community-driven freeware flash app for the 84+CE might be a dead end because TI has changed the signing algorithm for flash apps on that platform - I think the only viable path to distributing flash apps on that platform is to submit it to TI for commercial distribution.

Still, it might be viable to distribute it as a program that is totally resident in RAM. Although, native compiled/assembled programs running from RAM are restricted if the user has the latest OS version for the 84+CE. They'd need to jailbreak to get past this restriction.

Yes, there is at least one experimental fork of LLVM/clang with support for the eZ80. (And also the classic Z80 as part of the same fork.) Heck, the Z80 also had earlier C compilers as well, but to my knowledge none of them have been able to leverage the same kind of sophistication as you can get with LLVM. That being said, the Z80 architecture was never created with C-compatible calling conventions in mind, so it might be less efficient than what you could achieve coding assembly by hand.

There are several reasons why I hesitate to work on the TI84+CE platform, some of which you have described:

• The CE platform uses a 2048-bit RSA signing key, which has not been broken, compared to the earlier calculators which use 512-bit RSA keys which have been cracked. So I would not be able to create flash apps on the CE.
• TI furthermore disabled assembly language programs on the CE, to prevent cheating on exams. This forces users to run the arTIfiCE jailbreak, which increases friction and reduces the number of potential users of an RPN app for that platform.
• The CE calculators use cellphone technologies, such as custom Li-polymer batteries, instead of standard AAA batteries. Those batteries will need to be replaced every 3-5 years, and their replacements may be almost as expensive as the calculator. Longer term, say 20-40 years, those batteries may be unobtainable because no one makes them anymore. It would be ironic if the older TI calculators, with standard batteries, survive better than these newer CE calculators in the long term.
• (Added) I don't feel comfortable working on a platform where the manufacturer has expended so much energy to make sure that I fail. There are so many other interesting projects out there, why work in a hostile environment?
  

On the other hand, the 84+CE is appealing to me for the following reasons:

• The eZ80 processor has a 3-stage pipeline architecture, which means that it is almost 3X faster than the Z80 at the same clock speed. So the 48 MHz eZ80 on the CE is the equivalent of a 150 MHz Z80, making the CE almost 10X faster than the older TI 83+/84+ calculators.
• The eZ80 assembly is supposed to be backwards compatible with the Z80, which means that I might be able to reuse most of my RPN83P source code.
• I am technically curious about the eZ80 processor and would enjoy learning about it. A processor with 24-bit registers. A C compiler. How well could that possibly work?
• The backlit color display of the CE is actually useful in many situations. We expect our electronic devices to be as ergonomic as our cell phones.
  

I believe you are quite correct about a Z80 being terrible for C calling conventions. Even in hand-coded assembly, I am constantly suffering from register starvation, then forced to juggle them around due to the non-orthogonal Z80 instruction set, and the stack is basically useless for local variables due to the lack of stack addressing modes. (I am forced to use stack-local variables a handful times in the RPN83P, but it is not pretty.) No idea if the eZ80 fixes any of that pain.

[Eddie W. Shore]

Great work. It has given me a reason to insert batteries in my monochrome 84+ for the first time in a while.

[jthole]

That is a great accomplishment, and the most extensive RPN implementation for the TI-calculators I have seen so far!

About keystroke programming; I agree that it wouldn't be really needed on the TI-8x Plus, since it already supports TI-Basic. But it would be really nice if I could XEQ a Basic program from within the RPN app. However, I understand that might be challenging to implement.

I would love keystroke programming and a solver, but that is probably way more work than being able to call Basic programs. If I understand correctly, the register list variable can be manipulated from within a Basic program, so that these register values are available within the RPN app (would work both ways).

[ijabbott]

I've just tried out version 0.7, but haven't tried earlier versions yet. I couldn't get the SHOW (2ND ENTRY) function to work. Perhaps it got broken on this version?

Minor suggestions:

• 2ND ( could be used for ROLL UP.
• 2ND ) could have the same effect as ) ) (X⇄Y X⇄Y), effectively terminating digit entry, similar to the ON/EXIT key on HP-42S. (Maybe not worth it as ) ) would be easier to press.)
• If it is easy to do, could the leading 0 of decimal fractions between 0 and 1 be shown in fixed/normal mode (for example "0.1" rather than ".1")? (I suspect it isn't shown because the TI-83/84 routines do not show it either!)
  

[Eddie W. Shore]

If I didn't have a gray monochrome 84 Plus, I would have been an "excuse" to buy a white 84 Plus at Target. BTW, for those wanting to purchase an 84 Plus, there is a lot on sale used, almost no need to pay retail.

This is the best RPN application for the 84 Plus. I like the solid interface and how quickly and smoothly the app runs.

One thing to note: I think the arguments for polar/rectangular conversions are "reversed" from most RPN calculators:

Y-Stack: X or R
X-Stack: Y or theta

Examples (Degrees mode):

-2 ENTER 11 >POL
Expected: Y: -10.3048, X: 11.1803
Instead the results are: Y: 11.1803, X: 100.3048

30 ENTER 5 >REC
Excepted: Y: 2.5000, X: 4.3301
Instead the results are: Y: 29.8858, X: 2.6147