The Museum of HP Calculators

HP Articles Forum

[Return to the Index ]
[ Previous | Next ]

HP12C Platinum "curiosities"

Posted by Vieira, Luiz C. (Brazil) on 24 Jan 2004, 9:01 p.m.

I read the HP12C Platinum Owner's Handbook & Problem Solving Guide (OHB&PSG) and I found some conflicting information regarding some facts exposed below. In fact, I counted on Gene Wright and Tony Hutchins who helped me when tracking down some of these conflicts, and I wish to thank them both for that. Maybe there are yesterday news here, so I ask you to forgive me if I'm talking about facts that are already known.

Indirect-Access-only Registers

This is not exactly a conflicting information; in fact, I saw no mention to these facts in the chapter I think they should be mentioned in the HP12C Platinum OHB&PSG. Please, if you have found something about this in the HP12C Platinum documentation, let me know.

As mentioned by Katie Wasserman in her excellent HP12C Sorting article and by Valentin Albillo in its "Serendipitous Solver" (follow the thread pointed above), all available numbered registers + [FV] (from the TVM register set) can be indirectly accessed by using [n]-contents as index. This gives us the "regular" HP12C the ability to hold up to 21 values accessed indirectly.

The HP12C Platinum allows up to 31 "cash flow data" to be stored and manipulated. The fact is that the first 20 values can be directly accessed the same way in both HP12C and HP12C Platinum. If the HP12C Platinum memory is cleared after any specific procedure OR no steps after step # 239 have yet been used, CF20 to CF29 exist and can only be accessed with [g][CFj] and [RCL][g][CFj], provided that [n] has the correct "indexing" value (from 20 to 29). Also, [PV] can be accessed with 30 as index. Keep in mind that in both calculators [g][CFj] always increase [n] by 1 BEFORE copying X-register contents to the indexed register, and [RCL][g][CFj] decreases [n] by 1 AFTER retrieving the indexed register contents back to X-register and also that [PV] holds the last possible cash flow data.

BTW, in both calculators the [Nj] register set seems to be composed by a group of single unsigned 1-byte, BCD-coded registers. Their range goes from 1 to 99, no negative, no fractional parts.

"Weird" Memory Count

This is something I'd like to read more about and know from your experience.

Those who have already programmed in the HP12C know the "memory shared" space, showed below...

CF reg.  # reg   PRGM steps
CF0      R0
CF1      R1
CF6      R6                 <- always available
CF7      R7      99 to 93
CF8      R8      92 to 86
CF19     R.9     15 to 09
CF20     FV      not applicable
I tested the HP12C Platinum memory usage after keying in program steps at the first byte of each available register, that was actually converted to seven program steps (bytes) automatically after keying them in. If we consider that all memory is available (memory cleared) we have:
CF reg.  # reg   PRGM steps
CF0      R0
CF1      R1
CF6      R6                  <- always available
CF7      R7      399 to 394  (weird: six bytes only ????)
CF8      R8      393 to 387
CF19     R.9     316 to 310
CF20     ---     309 to 303
CF21     ---     302 to 296
CF29     ---     246 to 240
CF30     FV      not applicable
The weirdness is related to CF7. I performed the "memory filling" maneuver at least two times to conclude this fact. Has anyone else checked for this? Is it correct? We all know that there is no way to "produce" a non-existing byte if it is not available. Otherwise it's possible to hide it, so the system uses it (R7) but the user doesn't "see" it (steps 394 to 399). If there is a 400 step # everything is fine, but...

[f][RPN] & [f][ALG]

These are actually the major "enhancement" offered with the new Platinum. Of course, as a consequence of the additional Algebraic mode, many "new" features are also available. The fact is that in Beta, pre-production units, these keystrokes could not be part of a program, i.e., are "non-programmable" sequences. The production-line units accept these key sequences as part of a program. Based on Beta-units behavior, these features were actually supposed to be not-programmable, and all program examples shown in the Platinum OHB&PSG consider them this way. Maybe the OHB&PSG original text was prepared with Beta units in mind, and these keys were not programmable in them. As for the examples, [f][RPN] and [f][ALG] are supposed to be pressed after PRGM mode is active and not generate keycodes or change program steps. In actual, regular Platinum units, pressing any of these key-sequences will add a program step with related keycode (42 16 for [f][RPN] and 42 26 for [f][ALG]).

No Return to zero after [f]CLEAR[PRGM] in RUN mode

This is completely based on Tony Hutchins very observation; his are the credits. And Tony adds that he knew about this from Jordi Hidalgo's Datafile article. I was not aware about this fact before Tony's mentioning in one of his e-mails. Credits to those who deserve!

If we press [f][P/R] twice, in sequence, the program "pointer" is always reset to 000, but [f]CLEAR[PRGM] does not do that (in the regular HP12C it does). Consider you have an HP12C Platinum with all memory cleared (you don't need to clear the memory contents of your calculator, just take care not causing an unexpected [ Error * ] message). In RUN mode, press:

It always work because step #005 is always available. If you press [f][P/R] you'll see
[005, anything_else] 
if you have programs stored in your calculator. Now, press [f][P/R] twice and you'll see
[000,         ]
Now get back to RUN mode and try this:
[SST] (hold it for a while) 
In a regular HP12C you'd see:
[ 01-43,33  00]
But in the HP12C Platinum you'll see:
(Remember we're assuming you have no programs stored in the calculator.) That's it! Program pointer was not set to [000,] as expected. And the "reset to 000 after [f]CLEAR[PRGM]" is mentioned in the HP12C OHB&PSG, although it does not work. You'd need to press [g][GTO]000 instead of [f]CLEAR[PRGM].

There's more about the HP12C Platinum, but I think there's something very important afterall: it's a curious, interesting calculator. Even if HP/Kinpo guys did not intend to, it has some "hidden" mysteries that, at least, are "teasing".

Please, if you have any suggestions, comments or want something to be added here, let me know.

Luiz C. Vieira - Brazil

Edited: 21 Mar 2004, 1:33 a.m.


[ Return to the Message Index ]

Go back to the main exhibit hall