(2025-05-12) HP's sole survivor among the touchscreen madness ------------------------------------------------------------- For a bit, let's diverge from the tiny VM topic (I promise I have something to return to that topic with in the next post) and talk about another piece of nice hardware. In my story about the TI-74S, I already told you about the calculator I grew with: Elektronika MK-52. Nowadays, I also have a full-kit MK-61, but it still is too large to carry around in a pocket and too battery-hungry. So, for all these years, I've been continuously looking for a pocketable enough RPN-only programmable calculator that would have a longer battery life and, most importantly, would be realistic to get where I live (which, unfortunately, is not the case for SwissMicros models). Last week, I finally found one on a local eBay-like platform for a more than humane price of around $16, in a mint condition, with a stock pouch and a printed instruction manual. And couldn't be happier about this find. Partially because it still is one of the original architectures that comes from the inventors of the RPN calculator concept themselves: Hewlett-Packard. Alas, as of now, HP calculators don't have a fraction of the glory they had in the past. In fact, modern HP calculator division primarily boils down to the boring OEM crap from the OfficeCalc line, some remnants from their scientific and business lines (10s+, 300s+, 10bII+, 17bII+), all non-RPN and mostly also OEM AF, and a touchscreen monstrosity called Prime G2. Of course, they also have had a limited-run buggy cash grab from the Voyager series called 15C Collector's Edition. There is, however, a single specimen that truly continues the same series of HP calculators and still is being produced in both the "standard" (gold) and the "platinum" variants: HP 12C. Of course, I despise the "platinum" one because it was the first step for HP to bow to normies and introduce an optional algebraic input mode in the series. The gold one is more than enough in my opinion. Although its internal design and architecture had changed several times, it had never been discontinued since its introduction in 1981, while the rest of the series died out in 1989. Why did the 12C get so lucky? Well, because it catered to the right kind of people: those who handled big finance. Yes, it is a financial calculator, one that got the highest reputation in those circles. While scientists and engineers could just eat up the discontinuation of the 10C, 11C, 15C and 16C and move on to something newer or more powerful, business people just refused to switch to the newer financial calculator models offered by HP at the start of the 1990s. The demand for the 12C still was high, and HP responded to it. In 1990s, they still had to move the production lines out of the USA to cut costs (first to Brazil, then to Malaysia, then to China), but production never stopped. In 2001, they switched to a new Agilent (and later Marvell) CPU with the same HP Nut architecture but lower voltage (now a single CR2032 instead of 3xLR44), and in 2008, they switched to an ARM7DTMI-based CPU (that ran an emulator of HP Nut) with two CR2032 batteries in parallel. Again, I won't cover what happened to the 12C Platinum and Prestige versions introduced in 2003, just gonna say they first ran on a 6502-compatible CPU and then, just like with the gold version, an ARM-based emulator was put in there instead. And just like the 12C model was lucky enough to survive thoughout 44 years, I was lucky enough to find one here in a mint condition. If I got all the information about the model right and decoded the serial number correctly, my unit was manufactured in the week 23 of the year 2001, which makes it one of the first batches in the Agilent-based production run, because the serial numbers for CR2032-powered 12Cs started from the week 15 of that very year. Another things that confirm my dating are that my unit has the dates from 1999 and 2000 as examples on the backplate, and also that the manual I got with it is much older as it had been printed back in November 1994 and still depicts an old battery compartment. So yeah, this very calculator already is 24 years old. Yet it looks and works like new. I mean, nothing surprising, I do have a late-1980s Casio fx-3400P, but still, this already was after they moved production to China. Also, while I understand that the current ARM-based models are much faster and (at least theoretically) reflashable, I'm kinda glad that I got a non-ARM one on the native 884 KHz clock speed, because its battery life surely will be much longer, yet it is new enough to consume even less energy and not have to fiddle with three LR44 cells. Well, for firmware upgradeability, I'll probably get a SwissMicros someday. This one is just fine as it is. When it comes to "normal" (non-programming and non-financial) usage, the 12C is not something very different from a usual scientific calculator, keeping in mind that it's RPN-only though. The only thing you might really be missing is trigonometry. That's pretty much it. All the other essentials are there: square root, square, arbitrary powers, reciprocal, natural exponent, natural logarithm, scientific notation, statistical functions, even a factorial. It even has some functions I've been missing in almost all other calcs I ever had, like getting an integer or a fractional part of the number. Yes, MK-52, MK-61 and 12C are the only three calculators where I had seen the integer and fractional part functions. Anywhere else we need to resort to some sort of hacks, like switching to the base-N mode and back (Casio fx-3200P, all Sharp EL-506P clones) or running the degrees-minutes-seconds conversion 22 to 25 times to get rid of the fraction (Citizen SRP-145). I really don't understand why Casio and Citizen couldn't get such simple functions into their programmable models of the past. I'd also like to see an absolute value function in 12C (it's also present in MK-52/61 btw), but, to be honest, it's easily emulatable here with successive application of the square (ENTER x) and square root functions if you're writing a program, or just by pressing the CHS key when necessary if you're in the manual mode. The programming mode though... While the overall vibe and principles are roughly the same as in the MK-52/61, the 12C's programming capabilities are totally different, sometimes even inferior to those two (as well as being clearly inferior to any other Voyager series model). No, I don't mind the Els having 105 program steps vs. 99 in 12C, or their 15 registers not interfering with the program memory while each seven extra steps in 12C eat away one register, or even having four different conditions instead of two in 12C. What I really miss is indirect addressing and indirect jumping. The latter was a really powerful feature in the 3rd-gen programmable Els that would allow writing advanced programs otherwise impossible to fit into their 105-step memory, because it allowed for easy conditional selection of various logic pieces without cascading conditional jumps. The HP Voyager series, and 12C is no exception, does not have such a feature. It does have storage arithmetic for the lower five registers though, and it really helps with saving extra program steps sometimes. That being said, I'm still really enjoying the process of discovering what this little machine can do even with all these limitations. Besides, we can compensate for some of the missing registers by using the financial registers instead. Yes, the n, i, PV, PMT and FV financial variables can be used with the STO and RCL operations just like any other registers. Thus, in theory, you can never have less than 12 addressable registers available for data storage in a 12C program. In practice though, there's almost always guaranteed to be even more space unless you max out the steps. The formula for the amount of registers taken by an S-step program is: regs = ceil((S - 8)/7). So, even a 78-step program will not eat into the first 10-register area. From my MK-52 experience, I don't remember needing more than 10 operating registers at a time anyway, so I don't see any problem here at all. I do wish it had an EEPROM like MK-52 had (to be able to store several programs 98 steps each), but at least a single program is gonna persist in 12C: as long as a working battery is in there, nothing is lost when the power is off. Now, "talk is cheap, show me the code". Of course, this still ain't a 41C and we still are only limited to numeric input here, but that doesn't prevent us from being creative with the vast amount of tasks we can accomplish. For instance, we don't have trigonometric functions but they are much easier to approximate than e.g. logarithms. I have studied the topic of sine/cosine approximations and it turns out that the best one from the keystroke count perspective is ye olde goode Taylor. Because the series is very similar for both functions, we can combine the logic and make it dependent on the incoming parameters. The following is a Python equivalent of the algorithm, taking the argument, the first Taylor term t and the first denominator factorial constant value c: def taylorsincos(x, t=1, c=0): sq = -x*x res = t prev = 0 while abs(prev - res) > 0.00000001: prev = res t *= sq / (c + 1) / (c + 2) c += 2 res += t return res If we pass t = x and c = 1 to this function, we get a sine. If we pass t = 1 and c = 0 to this function, we get a cosine. Now, here's the 12C program to calculate sines and cosines. For sine, type 1 STO 3 [arg] STO 1 STO 2 R/S, for cosine, type 0 STO 3 1 STO 1 STO 2 [arg] R/S: 01 ENTER ; commit x to stack 02 x ; calculate x^2 03 CHS ; calculate -x^2 04 STO 5 ; save -x^2 to R5 05 RCL 2 ; loop start; save the current result at R2 06 STO 6 ; ...to the previous result cache at R6 07 RCL 5 ; recall -x^2 08 RCL 3 ; recall c 09 1 ; calculate c + 1 10 + 11 / ; calculate (-x^2) / (c + 1) 12 RCL 3 ; recall c 13 2 ; calculate c + 2 14 + 15 / ; calculate (-x^2) / (c + 1) / (c + 2) 16 STO x 1 ; multiply this result by t and store into t 17 2 ; add 2 18 STO + 3 ; ...to the c value 19 RCL 1 ; recall t 20 STO + 2 ; and add it to R2 21 RCL 2 ; recall the result 22 RCL 6 ; recall the previous result cache 23 - ; subtract the cache value 24 x=0 ; if they are equal... 25 GTO 27 ; then skip to the end 26 GTO 05 ; else go to the loop start 27 RCL 2 ; display the result 28 GTO 00 ; program end This version might not be the most optimal in terms of program steps but at least it avoids using some time-costly operations like power and factorial. There is, however, another cosine approximation that is a bit (4 steps) longer but takes much less time to execute and is terribly good because it returns the results usually accurate within the maximum machine precision, or with 6 guaranteed digits after the decimal point in the worst cases. It takes advantage of the fact that 12C, among others, has two functions available under the g-modifier: a natural exponent function and a special "12/" key to easily divide anything by 12 (and also store the result into the financial register i). Behold! 01 STO 0 ; store our argument x into R0 02 4 ; push 4 03 y^x ; calculate x^4 04 12/ ; calculate x^4 / 12 as the variable K and store it into Ri 05 STO 1 ; as well as into R1 06 ENTER ; push into the stack 07 x ; calculate K^2 08 1 09 4 10 0 11 / ; calculate K^2 / 140 12 STO + 1 ; append into R1 13 RCL i ; recall K 14 x ; calculate K^3 / 140 15 9 16 9 17 0 18 / ; calculate K^3 / 138600 19 STO + 1 ; append this into R1 too 20 RCL 0 ; recall x 21 e^x ; natural exponent 22 ENTER ; push into the stack 23 1/x ; reciprocal: calculate e^(-x) 24 + ; calculate e^x + e^(-x) 25 2 ; calculate (e^x + e^(-x))/2 26 / ; the result is cosh x which can be used to approx cos x 27 STO - 1 ; subtract this from R1 28 RCL 1 ; recall the result 29 2 ; and add the final 2 30 + ; ??? 31 GTO 00 ; PROFIT! There is a similar algorithm for the sine function approximation as well, although this one is a bit longer and doesn't use the 12/ command: 01 STO 0 ; store our argument x into R0 02 4 ; push 4 03 y^x ; calculate x^4 as the variable K 04 6 05 0 06 / ; divide by 60 07 STO 1 ; store K into R1 08 STO 2 ; store into R2 (result cache) 09 ENTER ; push into the stack 10 x ; calculate K^2 11 5 12 0 13 . 14 4 15 / ; calculate K^2 / 50.4 16 STO + 2 ; append into R2 17 RCL 1 ; recall K 18 x ; calculate K^3 / 50.4 19 2 20 8 21 6 22 / ; calculate K^3 / 14414.4 23 STO + 2 ; append this into R2 too 24 2 ; add constant 2 25 STO + 2 ; into R2 26 RCL 0 ; recall x 27 STO x 2 ; multiply R2 by x 28 e^x ; natural exponent 29 ENTER ; push into the stack 30 1/x ; reciprocal: calculate e^(-x) 31 - ; calculate e^x - e^(-x) 32 2 ; calculate (e^x - e^(-x))/2 33 / ; the result is sinh x which can be used to approx sin x 34 STO - 2 ; subtract this from R2 35 RCL 2 ; recall the result 36 GTO 00 ; PROFIT! In case you're tight on memory and need both functions at the same time, you can, of course, derive one value from another using the formula (sin x)^2 + (cos x)^2 = 1, but if you need the maximum precision, you can combine both programs into one just like with the Taylor series. In Python, the combined algorithm looks like this: def fastsincos(x, a, b, c, d, e): t = x ** a k = (x ** 4) / b m = k * k / c hyp = (math.exp(x) + d/math.exp(x)) / 2 return t * (2 + k + m + m * k / e) - hyp And the set of (a, b, c, d, e) parameters is: * (1, 60, 50.4, -1, 286) for sine, * (0, 12, 160, 1, 990) for cosine. Let's use the 12C's financial registers to store these parameters ([a] n [b] i [c] PV [d] PMT [e] FV) so that only R0 to R2 will be used among the general purpose registers. According to all this, here's what the program looks like: 01 STO 0 ; store the argument x into R0 02 4 ; push 4 03 y^x ; calculate x^4 04 RCL i ; recall the parameter b 05 / ; calculate the K value 06 STO 1 ; store the K value into R1 07 STO 2 ; store the K value as the first result part in R2 08 ENTER ; push into the stack 09 x ; calculate K^2 10 RCL PV ; recall the parameter c 11 / ; calculate the M value 12 STO + 2 ; add M to the result in R2 13 RCL 1 ; recall K 14 x ; calculate M * K 15 RCL FV ; recall the parameter e 16 / ; calculate M * K / E 17 STO + 2 ; add this to the result in R2 18 2 ; push constant 2 19 STO + 2 ; add it to the result in R2 20 RCL 0 ; recall x 21 RCL n ; recall the parameter a 22 y^x ; calculate x^a 23 STO x 2 ; multiply the result value by it (1 or x) 24 RCL 0 ; recall x again 25 e^x ; calculate its natural exponent 26 ENTER ; push into the stack 27 1/x ; reciprocal e^(-x) 28 RCL PMT ; recall the parameter d (1 or -1) 29 x ; multply the reciprocal by it 30 + ; add to the natural exponent 31 2 ; calculate (e^x (+-) e^(-x))/2 32 / ; the result is sinh/cosh 33 STO - 2 ; subtract this from R2 34 RCL 2 ; recall the result 35 GTO 00 ; PROFIT! To run the sine, preload the registers like this: 1 n 60 i 50.4 PV 1 CHS PMT 286 FV. To run the cosine, preload the registers like this: 0 n 12 i 160 PV 1 PMT 990 FV. Then, just enter the argument and press R/S. The result is guaranteed to appear within five seconds with the precision of at least 6 figures after the decimal point. Finally, here's a "noob-friendly" version that is just 3 steps longer but doesn't require you to pre-enter any registers, uses just three of them (R0, R1 and Ri) and is, in fact, an extended fast-cosine routine that then calculates sine according to the (sin x)^2 + (cos x)^2 = 1 formula and puts both of them into the stack registers (the cosine is in X, the sine in Y): 01 STO 0 ; store our argument x into R0 02 4 ; push 4 03 y^x ; calculate x^4 04 12/ ; calculate x^4 / 12 as the variable K (storing it into Ri) 05 STO 1 ; store it into R1 too 06 ENTER ; push into the stack 07 x ; calculate K^2 08 1 09 4 10 0 11 / ; calculate K^2 / 140 12 STO + 1 ; append into R1 13 RCL i ; recall K 14 x ; calculate K^3 / 140 15 9 16 9 17 0 18 / ; calculate K^3 / 138600 19 STO + 1 ; append this into R1 too 20 RCL 0 ; recall x 21 e^x ; natural exponent 22 ENTER ; push into the stack 23 1/x ; reciprocal: calculate e^(-x) 24 + ; calculate e^x + e^(-x) 25 2 ; calculate (e^x + e^(-x))/2 26 / ; the result is cosh x which can be used to approx cos x 27 STO - 1 ; subtract this from R1 28 2 ; and add the final 2 29 STO + 1 ; the cosine value is now in R1 30 RCL 1 ; recall it 31 ENTER ; push into the stack 32 x ; calculate (cos x)^2 33 1 ; push 1 34 - ; calculate (cos x)^2 - 1 35 CHS ; calculate 1 - (cos x)^2 = (sin x)^2 36 SQRT ; calculate sin x 37 RCL 1 ; recall cos x 38 GTO 00 ; PROFIT! Enter the argument (from 0 to pi radians), press R/S and get both results within 4 seconds. The first result will be the cosine, press the x<>y key to see the sine, or press the division key to get the tangent. Of course, you may also then press the 1/x key to get the cotangent. Despite being the longest among all five trigonometric programs provided so far, this one is the fastest and easiest to use and only consumes three registers, so I use it myself and definitely recommend it for most people. Now, we need at least one inverse trigonometric function. For instance, here's a straightforward Taylor-based arcsine algorithm which looks like this in Python: def taylorasin(x): t = x c = 3 sq = x*x res = t prev = 0 while abs(prev - res) > 0.00000001: prev = res t *= sq * (c - 2) / (c - 1) res += t / c c += 2 return res On the 12C, it looks like this (just enter the argument and press R/S): 01 STO 1 ; save the argument as t into R1 02 STO 2 ; save the argument as the first result term 03 ENTER ; commit into stack 04 x ; calculate x^2 05 STO 5 ; save x^2 to R5 06 3 ; enter 3 07 STO 3 ; save 3 into c 08 RCL 2 ; loop start; save the current result at R2 09 STO 6 ; ...to the previous result cache at R6 10 RCL 5 ; recall x^2 11 RCL 3 ; recall c 12 2 ; subtract 2 13 - 14 * ; calc x^2 * (c - 2) 15 RCL 3 ; recall c again 16 1 ; subtract 1 17 - 18 / ; calc x^2 * (c - 2) / (c - 1) 19 STO x 1 ; multiply this result by t and save into t 20 RCL 1 ; recall t 21 RCL 3 ; recall c 22 / ; divide t by c 23 STO + 2 ; add this to the result register 24 2 ; add 2... 25 STO + 3 ; to the c variable in R3 26 RCL 2 ; recall the result 27 RCL 6 ; recall the previous result cache 28 - ; subtract the cache value 29 x=0 ; if they are equal... 30 GTO 32 ; then skip to the end 31 GTO 08 ; else go to the loop start 32 RCL 2 ; display the result 33 GTO 00 ; program end The problem is, the arcsine series converges too slowly if the value of x is close enough to 1. So, for the values of x >= 0.7, what I recommend is running the program like this: [arg] ENTER ENTER x 1 - CHS SQRT 2 x 2 + SQRT / R/S (...wait until the program finishes...) 2 x Now, in the worst case scenario (when the argument is 1 and scaled down to sqrt(2)/2), the program will run for about 38 seconds. Too slow bro. I also have stumbled upon a rather long but relatively fast-converging arctangent algorithm. Here's what it looks like in Python: def machinatan(x): a = 2/x b = 1 k = 1 - 4/(x*x) sum = 0 prev = 1 i = 1 while abs(prev - sum) > 0.00000001: prev = sum sum += a / (a*a + b*b) / i a_prev = a a = a * k + 4 * b / x b = b * k - 4 * a_prev / x i += 2 return 2 * sum Implementing this "fast-converging" algorithm had led to a 69-step program that still was too slow and now also too large, as well as sensitive to the argument range. Fortunately for us, there exists a much smaller and more practical approach: arithmetic-geometric mean. It even doesn't have any argument constraints. The only limitation is that we need to specify a fixed number of iterations. In Python, it looks like this: def agmatan(x): a = a0 = 1/math.sqrt(1 + x*x) b = 1 iters = 15 for i in range(0, iters): a = (a + b) / 2 b = math.sqrt(a*b) return x * a0 / a The corresponding 12C program looks like this, using R0 for iteration count and R1 and R2 as the a and b parameters: 01 STO 4 ; store the x argument into R4 02 ENTER ; push into the stack 03 x ; calculate x^2 04 1 ; push 1 05 STO 2 ; store 1 into b while at it 06 + ; calculate 1 + x^2 07 SQRT ; calculate sqrt(1 + x^2) 09 1/x ; calculate a0 09 STO 1 ; store a 10 STO 3 ; store a0 11 1 ; push the iteration count (15 by default) 12 5 13 STO 0 ; store iteration count into R0 14 RCL 1 ; loop start, recall a 15 RCL 2 ; recall b 16 + ; a + b 17 2 ; push 2 18 / ; get the arithmetic mean 19 STO 1 ; store the new a value 20 RCL 2 ; recall b again 21 x ; calculate a*b 22 SQRT ; calculate sqrt(a*b) 23 STO 2 ; store the new b value 24 1 ; push 1 25 STO - 0 ; decrement the iteration count 26 RCL 0 ; recall the iteration count 27 x=0 ; if out of iterations, then 28 GTO 30 ; go to the end 29 GTO 14 ; else go to the loop start 30 RCL 4 ; recall x 31 RCL 3 ; recall a0 32 x ; multiply them 33 RCL 1 ; recall a 34 / ; the result is x * a0 / a 35 GTO 00 ; program end Much, much better. Just under 17 seconds of runtime, regardless of the argument, and it loses accuracy very slowly, giving you a result accurate to 9 digits after the decimal point for any x. This is definitely a keeper in my library. If you want even faster results at the expense of precision, just reduce the number of iterations in the code. For instance, I have reduced mine to 14 as the accuracy difference is negligible compared to 1-second economy. Yeah, all that fuss just to find an arcsine/arctangent. But the point is, it can be done here even though it might not be supposed to. The stack language itself is extremely fun to learn, and I hope to really master it sooner than later just like I did with the MK-52 over 20 years ago. On top of that, the original 884 KHz speed stimulates me to find new ways to optimize algos for speed rather than step count: for instance, I don't think that I'd stumble upon those epic sin/cos formulas to get their approximations from sinh/cosh values if I got an ARM-based version that could run the Taylor-based algo fast enough. Mind you, this still is an upgrade from about 75 KHz clock speed I had in the MK-52, so nothing to actually complain about. And yes, I have started a document in my Gopherhole ([1]) to collect the most interesting 12C programs I have created so far. Obviously, this document is going to be updated regularly, but the trigonometry topic, I think, is finally closed. Of course, these sine/cosine/arcsine/arctangent examples are just a minor scratch on the surface. The hpcc.org website contains a lot of useful stuff for this and similar devices, including but not limited to a whole trigonometry suite ([2]), but I honestly prefer my own algorithms as I fully understand how they work and what to expect from them. So I rolled my own suite in the aforementioned document. And... for the direct sine/cosine call, it's even faster than the V. Albillo's one. Not to mention that it provides a built-in radian/degree conversion routine. Within just three days of owning this device, I also have created another suite that adds another missing piece of functionality, namely geographical coordinate conversion (between degrees-minutes-seconds and decimal degrees) and some nautical-related unit conversions. By the way, I also have devised a way to add a missing pseudorandom number generator using the financial register Rn (that must be pre-populated with a seed value from 0 to 1) in just five steps: RCL n FRAC e^x 12x FRAC. I can't think of a shorter method so far. But how well does the S[n] = frac(12 * exp(S[n-1])) formula work as a PRNG? Alas, not very well: it is slightly biased in favor of smaller values. Fortunately, this is easy enough to fix: we need to add a small constant value > 2 before exponentiation. So, the improved version S[n] = frac(12 * exp(S[n-1] + 3)) already takes seven steps: RCL n FRAC 3 + e^x 12x FRAC. Can we make it six? Not sure yet. As of now, seven steps is the observed minimum for a fully autonomous unbiased PRNG in this calculator. On a side note, the overall ergonomics of this device is exceptional, with all that tactile feel and distinct clicks that won't leave you in a doubt whether or not you have pressed the key you intended to press. The force required to press a key is just right to give that much needed feedback but not give any stress on the finger at all. Unlike e.g. Casio fx-3400P with its softy rubber keys, this design just invites you to tinker with the calculator and to use it more and more and more. And tinker with it I do a lot. Within just four days, it has completely shifted my focus away from the fx-3400P and other goodies in my calculator collection. Hell, it even has replaced the fx-991DE PLUS: who needs "natural VPAM" when you've got RPN? On the other hand, the TI-74S is kinda irreplaceable, but that one is a full-featured portable computer from another league, and I cannot put it into any of my pockets. But I can put the 12C in there instead and call it a day. Additionally, since my Seiko SBTM291 (that I've been wearing ever since I got it) doesn't have a date display, I often use the 12C's date calculation functions to find the day of the week for the current or some future date, and it's been very efficient and fun, provided the D.MY mode is set, of course. Yes, I can't stress enough how compact and lightweight this calculator is. It is not tiny by any means (after all, it's not a card-shaped SwissMicros DM12C) but perfectly sized to fit into a standard man's shirt chest pocket. Remember, when it was first introduced, most calculators marketed as "programmable pocket calculators" could not actually fit into pretty much any pockets. Now I see how much of an exception to this rule the Voyager series had been. In all probability, financial specialists might also have refused to switch to the newer HP models because those models, besides looking more generic and lame, no longer could be fully placed inside the chest pocket. Even though the technology began allowing to make calculators pocketable enough, this gigantomaniac trend has been observed among other calculator brands too, including my most favorite ones like Casio and Sharp. Gargantuan creatures like HP Prime, Casio fx-CG and TI-nspire series are just logical consequences of this trend. The absurdity of the situation has led to most people actually switching to the calculator apps on their always-on spying consumerist bricks called "smartphones", losing all tactile feel but still having a single device in their pockets. And yes, even the 12C has an official emulator at least for Android. It may be based off the original ROM but they somehow managed to screw it up, and did this even more than I expected. Needless to say, I refuse to go that route. My new old gold, normal, physical, non-platinum, non-prestige, non-limited-edition, non-collectors-edition, non-anniversary-edition 12C is still standing against all this nonsense, running virtually forever on a single CR2032 and being able to go with me anywhere. Finally, an MK-52-like device that I actually have no trouble carrying around. Well, what else can I say? When writing this post, I suddenly remembered a rather old viral video where an old fisherman caught a really large ide in a lake and started shouting: "Here it is, the fish of my dreams! Here it is, here it is! An ide! Guys, it's a huge ide, A HUUUUUUGE IIIIIDDDDE!" So, is there anything better out there, or can this Agilent-based HP 12C be really called "a fish of my dreams" when it comes to calculator collecting? Not sure yet, but I think it's quite close to that. Besides, I'm just being realistic about the probability of me finally obtaining a 41C/CV/CX or a titanium SwissMicros DM15L/15C in the nearest future, which is rather close to zero. Even when/if I get any of those, will I be using them to the same extent I'm now using the 12C? Will any of them really become my daily driver, knowing that I paid about $16 for the 12C and I'll have to pay >$150 for any of those choices and some extra for the batteries if the choice is from the 41C series? In a way, this situation is akin to my Casio G-Shock dilemma: the GW-5000U might be hard to get but I do have it here and now and it already is good enough for every practical occasion, but the absolute grail G-Shock, the MRG-B5000D, is pretty much an unobtainium for me due to different factors (not just price). Maybe... just maybe... that ide just needs to be released back into the lake. --- Luxferre --- [1]: gopher://hoi.st:70/0/documents/own/hp-12c-soft.txt [2]: https://hpcc.org/datafile/hp12/12c_TrigonometryFunctions.pdf